Reverse engineering: more than NVIDIA deserves?
Reverse engineering: more than NVIDIA deserves?
Posted Feb 18, 2008 21:16 UTC (Mon) by jejb (subscriber, #6654)Parent article: Reverse engineering: more than NVIDIA deserves?
It depends what you think the pain points for NVIDIA actually are. Having done similar sorts of things in the past, I think it's mainly: 1. Running an entire engineering team just to keep up with the latest greatest API breakage so the binary module will still work 2. Having to make sure the distribution model works on a huge variety of vanilla and vendor kernels (this becomes a huge validation and installation effort). Having a reverse engineered Nouveau driver does nothing to address either of those. Furthermore, for an evolving hardware platform (which the NVIDIA graphics cards are), reverse engineered drivers are always behind the curve because you actually have to see the hardware to test and fix things. Conversely, I don't think Intel (and eventually AMD) actually expect the community to take over their drivers. In many ways, companies like to keep control of their products, so they tend to hire the driver writers who work on them anyway. The key benefits companies gain from open sourcing are 1. Community assistance: bug fixes, end test cases (even Intel can't test all their chip configs) 2. Freedom from distribution pain ... it's just upstream and the distros ship it automatically. 3. Franchise in the development model. Imagine what would happen if Nvidia sent an email to x.org asking for changes in the X server to support their hardware ... now imagine what happens when Intel does it ... So Nvidia still has all of the costs and none of the benefits even with the Nouveau driver; it's hardly a gift to them (in fact, if they actually look at it it might end up being a trojan horse because they could get GPL contamination of their binary blob).
Posted Feb 18, 2008 22:05 UTC (Mon)
by arjan (subscriber, #36785)
[Link] (6 responses)
Posted Feb 19, 2008 3:05 UTC (Tue)
by xoddam (subscriber, #2322)
[Link] (5 responses)
Posted Feb 19, 2008 8:31 UTC (Tue)
by khim (subscriber, #9252)
[Link] (4 responses)
If something 'built on top of' a free work is not a derivative work,
it is not subject to the free work's copyright licence.
Posted Feb 19, 2008 13:45 UTC (Tue)
by flewellyn (subscriber, #5047)
[Link] (3 responses)
Xoddam seems a bit confused. I think I understand the source of the confusion, though. One of the most prominent free software projects, the Linux kernel, explicitly states that the boundary between "derived work" and "mere aggregation" for the kernel is at the system call boundary (and presumably the /proc and /sys filesystem interfaces as well). Any user-space program that uses the system calls is not bound by the kernel's GPLv2 license, but kernel modules and other code which interact with internal kernel interfaces is operating inside the kernel's "license domain", if you will. The same does not necessarily hold true for other projects, though! If the license for a particular user-space library is GPL, or some equivalent copyleft license, you must abide by that license's terms if you link it to your code. This isn't the case for libraries that are LGPL, or under a non-copyleft permissive license like the BSD or X11 licenses. So you can write programs that link to GLIBC without having to make them GPL, and of course you can write X programs under any license too. But the idea that all free software allows you to build "on top" of it without license concerns is not even wrong; it's too vague to be evaluated.
Posted Feb 19, 2008 14:39 UTC (Tue)
by khim (subscriber, #9252)
[Link] (1 responses)
When you are poking files in /sys directory you are directly playing with kernel internals, there are no clear well-defined API. There are talks about declaring some parts of /sys as some sort of stable API, but certainly not the whole /sys. Otherwise you can say that "my program which used clearly defined API over /dev/kmem is not derived work" even if said program in fact injected huge kernel module this way...
Posted Feb 19, 2008 15:47 UTC (Tue)
by flewellyn (subscriber, #5047)
[Link]
Okay, that makes sense. Thanks for the correction. It doesn't change the rest of what I said, though. :-)
Posted Feb 21, 2008 1:37 UTC (Thu)
by jdivine (guest, #18042)
[Link]
Posted Feb 18, 2008 23:02 UTC (Mon)
by sayler (guest, #3164)
[Link]
Reverse engineering: more than NVIDIA deserves?
Intel very much wants people to work on the graphics (or wireless or .. or ..) drivers. And
thankfully this is being done somewhat in the last year or so. It's not about control really;
There is pain to have binary graphics drivers as you mentioned; but it goes beyond the kernel.
X is (thankfully!) now going forward at a faster pace since the X.org split/modularization.
The one big thing Open Source has over proprietary "parasites" [1] is to keep the pace of
innovation up to a level that users pick the new innovated versions over proprietary older
versions. This is what the Linux kernel has over, say solaris. And now X.org is thankfully
innovating and improving rapidly.
To some degree the Linux desktop could use another burst of innovation; while there's a lot of
work going on there I'm at the point where I'm hoping that a next big thing will rock the boat
there and innovates the Linux desktop leaps beyond the current status quo.
[1] No disrespect, I mean companies that build on top of open source but themselves giving
nothing or little back. Some open licenses allow that, others.. less so. Either way, the
parasites exist.
Parasitism
> I mean companies that build on top of open source but themselves
> giving nothing or little back. Some open licenses allow that,
> others.. less so.
*All* Free Software copyright licences permit any product to be
'built on top'. It's part and parcel of the Four Freedoms.
Copyright can only restrict what is 'built on top' in circumstances
where the new product is considered to be a derivative work; to
make or to disseminate distributed works requires permission from
the original copyright owner, except where Fair Use provides otherwise.
If something 'built on top of' a free work is not a derivative work,
it is not subject to the free work's copyright licence.
Many free software copyright licences are so permissive as to allow
even derivative works to be distributed on non-free terms.
Parasitism
If something 'built on top of' is not a derivative work then how the hell you can say it's 'built on top of' ? It's separately developed thing which is just tied to free software somehow...Parasitism
/proc - may be, /sys - not in your life
/proc - may be, /sys - not in your life
Parasitism
Defining the boundary between "derivative work" and "mere aggregation" is not a matter for the
kernel people to decide. It's a matter of copyright law. I have no idea how a court would
actually rule on this issue, but I thought I'd point out that it's not really for the kernel
people to decide. I suspect, however, that a court might think any arbitrary technical
"boundary" -- whether that be system calls, dynamic linking, whatever -- is irrelevant. US
Copyright law says that derivative status depends on whether the work in question is "based
upon" preexisting work.
Imagine the following scenario: A video card manufacturer writes a Windows driver for its
product. Later, they decide that they'll port the existing Windows driver to run on Linux.
(Whether that is actually feasible is not relevant to this thought experiment.) So using the
"clean room" approach, one engineer documents the Linux system calls that the driver needs to
hook into, and posts that information publicly. A second engineer takes that documentation
and uses it to port the driver. Is this driver now "based upon" the Linux kernel? The bulk
of the software existed before the kernel entered the picture, and the guy who developed it
never even looked at the kernel code. Is the API documentation itself a "derived work?"
That being said, I don't approve of (and try to avoid) proprietary kernel modules and
proprietary software in general. I just doubt that there can be a "technical test" to
determine what is and is not a derived work as a matter of copyright.
Reverse engineering: more than NVIDIA deserves?
"(in fact, if they actually look at it it might end up being a
trojan horse because they could get GPL contamination of their binary blob)."
Surely we can all politely stop paying service to this silly idea?