Slashdot Mirror
Linux: the GPL and Binary Modules
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."
Maybe I'm wrong here but perhaps this is a way to look at it. If I wrote a story that was derived from the LOTR then it would not be a derived work in the legal sense it would be copyright by me. Although I'd have to get permission to use the trademarked names etc. Isn't this a bit like the linux kernel issue? The module is not directly derived from the kernel it is an extension that uses the hooks that were created in the previous "story". Maybe I'm on crack here....
I have a theory that the truth is never told during the nine-to-five hours. - Hunter S. Thompson
A certain amount of pragmatism has to prevail here -- were binary modules disallowed, the phrase 'shoot yourself in the foot' jumps to mind. Linux is probably better off with them, as it lowers the entry barrier to companys wishing to contribute. And that's rarely a bad thing.
((lambda x ((x))) (lambda x ((x))))
This "grey area" exists because there is no clearly defined boundary defining the seperation between the kernel and the drivers. Modules are parts of the kernel which have not been linked yet. When they're required, they are loaded and linked with the kernel.
The fact that Linus states that there is no exception must worry a lot of companies out there who are producing binary drivers for Linux E.g. nVidia, or SciTech (Who started the LKML thread, after all!) Are nVidia's kernel modules under the GPL? If the possibility exists that they are then I would expect them to suddenly get cold feet over Linux.
If the kernel had a proper boundary with E.g. a set of API's that the kernel and drivers can use to communicate with each other then it would help to solve the issue of what is and isn't "the kernel". For example in Syllable drivers are ELF images which are loaded by the kernel ELF loader. The drivers are loaded under the kernels memory space but there is a very well defined API between the two, and a very clear seperation between them. Under this model I can argue that the kernel is actually being linked to the driver, so the driver can be under any licence while the kernel remains under the GPL. There is no "cross pollenation" between the driver and the kernel. Which is a good thing IMHO, if it avoids issues like the ones being raised on the LKML.
Syllable : It's an Operating System
Linus talks all about linking source with the kernel and stuff like this. But guess what: With most binary modules this part is done by the user, not by the distributor, and this is clearly your right - you just cannot distribute the binary.
See for example stuff like driverloader (the ndis-wrapper around windows wlan drivers for the centrino and other cards): They are shipping a source which you can compile against the kernel headers (which are provided by YOU!) and will form a kernel module which can be loaded (by YOU!) against the kernel.
I really can't see how linus can claim copyright to the distribution of any source which happens to run with the linux kernel - but does not contain any part of it. And the enduser is free to compile and link this sources against the kernel, as the GPL allows modifications for own use without any restriction.
I guess the whole discussion is politics. Linus dislikes binary only drivers (for good reasons: they are unflexible, hard to debug and can cause user confusion and problems) and would like to have them not happen. But i don't think it is helpful to take a extreme shaky legal position (and downright confusing the users by making legal statements which simply do not apply here) to achieve this goal.
Although i dislike binary-only drivers in general, i came to the understanding that sometimes this might be the best you can get. In the business software world copyright is often a diverse field, and even companies who would like to release the source might be barred from that through NDAs and copyrights of third companies. So some companies have no choice but releasing binary drivers and i'm happy that they do at least that. If all would adhere to linus position we would just keep some users alone out in the rain. I'm all for helping users getting their hardware running. They might have made the wrong purchase in the first (getting a hardware with open sourced drivers would have been wiser), but just saying "tough stuff, you have lost, now go away" won't help them.
I know some people just hate the idea of binary drivers to begin with, and if that is your stance, fine; I don't agree, but I understand where you're coming from. But if you're going to allow binary modules (as Linux does), why do it in such a half-assed fashion that a company that might provide a Linux driver can't be sure one way or another how you're going to view their code (exempt from GPL or bound by it)? Either do it right and enforce a clear boundary or just stick with source only drivers.
Er, yeah, that's a little warped.
It might make sense to take that position, if such a thing as a "module vendor" existed. As it happens, it doesn't, and no one is out trying to sell binary modules for Linux. The creators of binary modules are *hardware vendors* and they are "contributing" by making their hardware compatible with the free system.
This is not parasitic; if they want, they can just not bother, and you can just not use that hardware in Linux. Let's not forget, it's not like you wrote the driver; why would you want to keep people from making their hardware usable on your system? If a manufacturer says "well, sorry, I want to support linux, but not if it means letting the competition get a sneak peak at this crazy technology in my drivers" you would just say, "ok, parasite, we don't need your stupid hardware."
When the manufacturer in question is a leading producer of video boards, such fanaticism is extremely foolish.
Given a choice between free speech and free beer, most people will take the beer.
The original purpose of restricting derived works was to make it so that authors (companies or not) could not copy code from the public domain and claim it as private work, No?
Kernel Modules cannot exist without the Linux Kernel. This dependancy means that any part of the Kernel Module that depends on the kernel for *module* interface purposes is not derived work. It is when authors base their code off of other code that is in the GPL that they must in turn release thier code under the GPL.
So in short, if the module could have been written entirely with Manpages and documentation, it is not derived work. If the author views the code of other modules, then it is derived work.
Deriving functions and invoking them are two very different things.
I think you've missed the point, the problem is to define what does "based upon" means.
When you compile a binary, you have to compile with some header files which are GPLed. So you are "based upon" GPL code right?
IIRC Linus argued that this wasn't sufficient. He stated that for a module needed to be written with Linux in mind (ie targeted at it), accessing particular data structures, then it would have to be GPLed.
My second printer was a Citizen 120-D 9-pin mono dot matrix, and it was also very Epson-compatible. It had a beautiful programmer's manual replete with examples of how to access each feature, from simple double width text to high-density image graphics, and even went so far as to provide timing details for the Centronics interface. {Hey, you might be plugging the thing into some device of your own construction}. It was even known for owners of EPROM burners to patch the charsets to match certain manufacturers' non-strict interpretation of ASCII {the BBC model B, for example, had a pound sign at CHR$(96) instead of a backtick, so it could keep the comment mark at CHR$(35) - a comment in BASIC is denoted by REM, but the # was used to specify immediate mode in assembler}.
..... you get a Quick Start guide which says "Plug the printer into your computer. Do exactly what Windows tells you to do" and a huge manual, replete this time not with useful programming information but with dire warnings about attempting to do anything "unauthorised" with the printer, and it probably illegal to examine the printout with a magnifier to see how the fonts are made up.
Compare and contrast that with today
IMHO the lawful owner of an instrument has the right to know everything about that instrument. My property can, by definition, contain no secrets from me {though I might reasonably be bound to keep any secret I discover}. It's time that this was enshrined into law. If you can't handle the concept of people knowing how to write drivers for your hardware then you perhaps shouldn't be selling it. Mandatory Full Disclosure would put an end to this argument once and for all.
Je fume. Tu fumes. Nous fûmes!
You clearly missed the point in my signature. It has nothing to do with pessimism. Karl Popper (famous natural philosopher) wrote a book after WW2 called "The Open Society and its enemies" as a defence of democracy and a critique of totalitarian rule (including fascism, communism and various religious ways to rule).
In the book he argues that democracy has an incremental approach to society building whereas e.g. communism (and political islam for that sake) has a "revolutionary" approach. The point is that those who promise us paradise on Earth after we have made the society in whatever way they would like us to - they have always ended up giving us hell on Earth (Soviet Union, Iran, Afghanistan and so on).
The manufacturer is selling hardware. Anything they want to protect from being exposed in the module means little to other hardware companies who have competent developers. The details of how the hardware is controlled and any setup and tables can be discovered using the Windows drivers and debuggers.
Contrary example: In Nvidia's case, they don't own everything they ship so unless they convince other companies to opening those parts (unlikely) Nvidia has to either drop those parts or replace them.
The motivations of different companies are important. Server-grade hardware companies fall all over themselves supporting Linux in the main kernel source tree. If Linux becomes popular on the desktop -- even if modestly so -- the kernel modules that support desktop software will likely be open. Nvidia might even change (though this is speculation on my part).
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
In ye olde days, drivers did nothing more thancanfigure and move data back and forth to a piece of hardware. They were fairly trivial pieces of software, and so no one cared if they were protected. Many types of drivers are still like this today. Network card drivers typically do nothing magical.
A few generations ago, hardware designers realized that they could offload some of the task traditionally done in hardware to the driver. Thus they could simplify the hardware and save money. The driver for a WinModem doesn't just configure and communicate with a hardware modem, it actually performs in software some tasks that were usually done in the modem hardware itself.
At this point, drivers aren't trivial programs, but represent substantial investment and competative edge for the hardware manufacturer. If WinModem company B could look at WinModem company A's driver, they would see the tricks that they used in order to reduce the part count that much further. Company B could immitate Company A, and match their price.
Video cards are like WinModems, although the competititon is not based price but performance. The card manufacturers are using tricks in the driver in order to boost the performance of their hardware. Those tricks may confer to them a competetive advantage, so they won't open source the drivers.
Smart companies are quick to release software as open source when the software doesn't give them a specific and compelling competitive advantage. Cisco released CUPS as OSS because they felt they would benefit far more from having a community enhance their internal printing system than the would be hurt because Bay Networks could reduce their overhead a few hundred thousand dollars. Cisco is not going to open source their routing software anytime soon, because other router manufacturers could use it to compete against Cisco.