Linux: the GPL and Binary Modules 657
An anonymous reader writes "When first made available in September of 1991, the Linux kernel source code was released under a very restrictive non-GPL license requiring that the source code must always be available, and that no money could be made off of it. Several months later Linus changed the copyright to the GPL, or GNU General Public License, under which the kernel source code has remained ever since. Thanks to the GPL, any source code derived from the Linux kernel source code must also be freely released under the GPL. This has led many to question the legality of 'binary only' kernel modules, for which no source code is released. Linux creator Linus Torvalds talks about this issue in a recent thread on the lkml."
It's really simple (Score:2, Informative)
If a module is not "based upon" the GPL code, then no such restriction exists in regards to its licensing.
In fact, you could say that the Linux kernel in a particular system was "based upon" these closed modules, but it is difficult to argue in the other direction.
different perspective (Score:4, Informative)
here's two well writtens articles: (Score:5, Informative)
http://lwn.net/Articles/53780/ [lwn.net]
http://lwn.net/Articles/51561/ [lwn.net]
These two articles are in relation to Linksys, but they cover the general issue. There have been some other great GPL-related articles on LWN.net if anyone wants to search the site.
Re:What Linus is missing here... (Score:2, Informative)
For device driver (and similar) modules that run within the kernel, the statement that they "don't contain any part of it [the kernel source]" can't be made so easily. To develop and compile the driver, the kernel header files are needed. Even putting aside structure definitions and the like, which are kernel sources, it is very easy to get whole functions subject to GPL be included in binary-only drivers by way of inlining (see the example of "static inline ..." functions mentioned in the original discussion).
Re:It's really simple (Score:3, Informative)
Re:It's really simple (Score:2, Informative)
Re:Pragmatism (Score:5, Informative)
I'm a programmer. None of the NVIDIA core is available as source. None of the NVIDIA GLX is available as source. The only source provided is a small kernel interface. Even if you're not a programmer, notice the compiled file sizes: nv-linux.o (wrapper) = 47Kb. nv-kernel.o (binary-only NVIDIA core) = 1.8Mb. The nv-linux.o source code is just over 6000 lines of code. Extrapolating, NVIDIA are keeping over a quarter of a million lines of code out of our site, and that's just the kernel module!
what's this about not having one compiled for your archetecture? Have you ever installed these?
I have -- for an IA32 architecture consumer/home PC. Have you installed one on a SPARC box? You can't! NVIDIA don't provide a SPARC architecture build. Have you installed one on a RISC PC? You can't! NVIDIA don't provide an ARM architecture build. Have you installed one on an iMac? You can't! NVIDIA don't provide a POWERPC architecture build.
I have run a lot of video cards in a lot of Linux boxes.
You sound like an unreformed Windows-using home/consumer PC builder. "Just download drivers from the manufacturer's support site" is the worst possible form of providing hardware support in an operating system.
Re:Pragmatism (Score:2, Informative)
From your description it sounds like you ran an Nvidia installer script that compiled the kernel->proprietary_module wrapper code that Nvidia has made available for Linux and BSD on x86 platforms. When the parent poster said "architecture" he actually meant architecture like PPC, MIPS, x86, etc... You are confusing computer architecture with Linux Distributions. Those Nvidia binaries aren't going to do any good on a PowerMac -- that was his point.
Re:Pragmatism (Score:4, Informative)
Because most Linux drivers began their life as "sub-par reverse engineered drivers". It was only because they were open source that they got better.
Re:Amazing (Score:3, Informative)
Hard to believe you're not a troll but just in case...
The Linux community wants SCO's "intellectual property" out of Linux. The GPL doesn't permit their IP to stay in there. It must be removed; the license and the law demands it.
But first they have to tell us WTF their IP actually is. We can't remove it because we don't know WTF they're talking about! Even IBM doesn't know and the judge couldn't figure it out either, which is why SCO has been compelled to tell the court WTF they think they own in 30 days time.
Linux developers are very respectful of IP rights, even if sometimes the users (*cough*MP3 thieves*cough*) are not. This is why we wrote our own operating system, from scratch, rather than subject ourselves to binary-only licensing.
Re:This isn't limited to the kernel. (Score:3, Informative)
Re:Pragmatism (Score:5, Informative)
Companies may licence parts of the code from third parties, usually under other licences that do not allow unlmited source release - so they would have to re-write (clean room) to get a version that they could release source for.
Regulations (depending on your location, eg. on things like wireless cards, modems) sometimes require that stuff works within set limits (eg. power, spectrum). Often the hardware is more flexible, and the limits have to be encoded in the driver software. The law will then require the company to take resonable steps to ensure that end users can't change the software to circumvent the limits. Usually this will mean preventing release of modifiable source code.
That's just two examples - there are plenty more reasons that might apply.
Re:Linux linkiing analogy (Score:3, Informative)
Re:Pragmatism (Score:1, Informative)
Sorry kiddies, GPL doesn't jive with a lot of the real world where business arrangements such as that above are incredibly common and one company typically doesn't own anything, even stuff written in-house, outright.
Re:Pragmatism (Score:3, Informative)
You might be interested in this [xfree86.org].. or this. [xfree86.org]
I believe you still need the patched agpgart w/ the precomplied binaries.
-1 Flamebait (Score:5, Informative)
For example, NVidia's linux drivers contain S3TC tecxture compression algorithms, which is patented and licenssed. It is not theirs.
They CANNOT open source these drivers, nor could Linux developers create an implementation of them without being sued by the company who owns the rights.
And people just don' t seem to get this and it really really pisses me off. NVidia is just trying to do The Right Thing (tm), releasing Linux drivers at a LOSS nonetheless ( you think they make enough on Linux-owner sales of their cards ot cover these programmers salaries? I doubt it. ), and all the community does is flame them. No wonder hardware companies are so hesitant to support Linux in any shape or form.
I also need to throw this in to close... I don't know what people's problems with these drivers are. I have been using them since version 1043 (3+ years), and I have *NEVER* had a problem that wasn't fixed by reading the FAQ. And their feature and 3D support totally blows away any of the open source drivers (ATIs always lag 1-2 years behind the release of a card, and they still don't have all the features of the windows ones like FSAA and anisotropic filtering, while NVidia has had them for years).
Re:Pragmatism (Score:4, Informative)
And, as has been said many times before, NVidia doesn't own all the code in their drivers. Some of that is licensed. As a result, they are not allowed to change the licensing to GPL-only. To do that, they'd have to strip out much of the functionality that makes the card useful.
Re:Linux driver model doesn't help (Score:3, Informative)
It has long been held in copyright law (through case history) that using an API does not, of itself, mean that the program that uses it is a derivitive of an implementation of that API.
This would be especially true if two implementations of the same API existed, which is probably the case in the nVidia drivers that were being discussed; there is a small driver module (whose source code is available) that merely provides an API layer between the kernel and another program (no source code available). My guess is that that program is simply a recompilation, with no source code changes, of the equivalent program under Windows, which would use a different compatibility layer.
It is therefore plainly not a derivitive of the Linux compatibility layer, because it could be used separately from it. And by the terms of the GPL, as it is a separable program that doesn't depend entirely upon the other, it does not have to be GPL licensed.
Re:Pragmatism (Score:1, Informative)
Nvidia's drivers have some sort of VM or "re-compiler" designed to optimize code on their cards.
And even if that's not a compiler in your book, the drivers still do contain a bunch of opengl technology, proprietary "optimizations", and for the Pro cards, code that carries expensive app certifications.
Re:Linux linkiing analogy (Score:3, Informative)
But for some reason Linus believes that anything that uses interface to kernel is derived work then and should be GPLed...,/i>
No he doesn't. RTFA. He specifically used NVidia did not have to GPL the drivers. I don't understand at all where this confusion comes from. It is really pretty simple. Derived works are GPL. Works which are not derived are not GPL. So if you have to include code from the kernel your work shoudl be GPL. If not, then no. This is why the Nvidia wrapper is GPL and the rest of the driver is not.
Re:-1 Flamebait (Score:3, Informative)
I am 100% in favour of Open Source, but I am also 100% in favour of ENCOURAGING companies that TRY to support it.
Open Source People don't seem to understand the concept of compromise and that Rome wasn't built in a day. Alienating hardware companies with your ideological rants is just going to discourage them and turn them off of the idea of supporting Linux altogether, and then you'll be stuck with no specs AND no drivers.
Re:Linux linkiing analogy (Score:3, Informative)
Also watch out when using the word "use," its vague and open to interpretation. The GPL itself uses the word 4 times in specific contexts; two of these are in the "CAPITAL TEXT WARNING - NOT FIT FOR HUMAN CONSUMPTION" clauses. The kerneltrap.org article had a posting concerning this very word. Since I like to encourage reading, you'll have to do the homework as an extra credit exercise.
Re:Pragmatism has to win out (Score:3, Informative)
There are a few basic reasons for this. The first is simplicity and performance. An OS which moves data around device drivers by sharing memory and providing direct access will be faster and easier to understand and debug than one which attempts to use a message passing scheme for all IO data internally.
The second is really just reality. A device driver is something that talks to a bare hardware device. This is the very thing that the idea of "protection" and "decoupling" and such is trying to avoid. Hence, by definition, it has horribly powerful low level control over the computer. All sorts of catastrophic actions by a device driver are trivial and also impossible to block. Want to crash the entire system bus? Read and write over any random section of kernel memory? Crash other hardware devices? Cause other hardware devices to walk over memory? Deadlock core subsystems by taking locks in the wrong order? Etc.
All of these things are trivial to do with low level hardware access. Even making a "microkernel" with different protection levels for device drivers doesn't really help at all. Even if there's some redumentary memory protection through the CPU, the driver can certainly hang the computer, or read/corrupt any memory it pleases through the DMAC or some other hardware access primitive.
The only correct way to consider a device driver is that it's a core component of the OS kernel itself. There may be some interfaces the kernel makes available to particular sorts of devices so they can work in a generic way, but certainly in any sense of stability, security, or correct operation the device driver is just as critical as anything else in the OS.
This is the problem with closed source ones, of course. They can't be supported by anyone except the company that made them, so they'll break whenever the kernel changes in a way that's incompatible or simply exposes a bug in the driver. Since nobody can fix it, this simply means that any poor person stuck with such a badly supported piece of hardware will be left out in the cold when new kernel releases come out, having to wait for the company they bought the hardware from to update the drivers.
And of course, when the OS crashes, no matter what the problem is, only that company can fix it since nobody else has the requisite information. So, unless that company feels comfortable fixing all kernel bugs, not just their own drivers', for their customers, anyone with such a piece of hardware is effectively eliminated as part of the general debugging community for Linux. Meaning, Linux as a whole suffers since any problems these people have in the rest of the kernel are not going to be fixable.
Proprietary software may be ok for applications in some situations, but it's really horrible when the core system software isn't available. You have problems that are simply unfixable - and break all applications too!
Computers should work properly (ie., they shouldn't crash and should perform well), and keeping IO device specifications and drivers a big secret is one of the most significant things keeping them from doing that. I really think hardware manufacturers should take far more of the blame than they do for this issue - operating systems and software in general gets a bad rap in terms of stability, but how can something be stable when the way it talks to the hardware it runs on is this big secret kludge and any problem will cause it all to fall apart?