Propietary modules within GPL and BSD kernels

Question

Since the Linux kernel is GPL and not LGPL I suppose that it is illegal to link proprietary code to it. How does the industry circumvents this? I would expect that the GPL license will force any developer to release under GPL driver and/or kernel module.

Maybe I am confused and implementing a new module is not really linking against the kernel code ??? How do companies deal with this? Maybe linking the other way around (from kernel to their binaries)?

On the other hand there is the BSD kernel. Where you are free to link protected IP. Can you get a better design implementing your drivers within a BSD kernel? Is there any design restriction when implementing drivers for GPL kernels?

Answer 1

As you said the BSD license as used by the BSD kernel is much more liberal so it is no issue to link whatever licensed modules there.

For the linux case it is correct that the GPL per se forbids the linkage of non-GPL-compatible code which would not allow to link in proprietary modules, or even LGPL modules.

However, the linux copyright holders grant you to link your "LGPL" module with any proprietary code. An example for this is the nvidia driver:

/------------.-\
| Kernel       |
|              |
|   /--------\ |
|   | Module | |     /-------------------\
|   | (LGPL) <========> proprietary code |
|   \--------/ |     \-------------------/
\--------------/

This would still be illegal under GPL in general, but is explicitely allowed for the Linux kernel. As a reference, see what Linus Torvalds has to say about the issue here:

http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html

p.s.: Linking is a symmetrical operation in the terms of GPL.

Answer 2

I can't tell from your question, but you may be thinking about this backwards. If you are trying to use a proprietary driver on Linux, then yes, this should be allowed.

It is true that any code that links against GPL-ed code must itself be GPL-ed. However, GPL-ed code can link against closed-source libraries without altering the license of those libraries (otherwise, we could make every library in existence open-source simply by writing a GPL program and linking it against the library). Therefore, the GPL-ed Linux kernel can link against your closed-source driver without any problems.

That being said, this requires that the driver is written such that it is either fully self-contained or links only against libraries that allow unrestricted linking (LGPL, MIT, etc). That also means that your driver would need to be a loadable kernel module and not statically compiled into the kernel.

Answer 3

It is not the act of linking itself that activates the GPL restrictions.

It is the distribution of a "derived work" of the GPL work that activates the restrictions - you have to give anyone you gave the "derived work" to the source code needed to recreate the "derived work".

Now, the question becomes one of where the "derived work" line is drawn - which is far from crystal clear (and is likely to be different in different jurisdictions!). For example, if you distribute a compiled Linux kernel binary with your code statically linked in as a part of that, it's pretty clear that the whole binary is a "derived work". On the other hand, if you distribute just your module that uses only "published interfaces" of the kernel, then it probably isn't a "derived work".

There's lots of space in between those two positions, though. For example, if you distribute a device which contains flash memory containing a Linux kernel and a compiled binary driver, is the complete contents of the flash memory a "derived work"? It sure looks like it to me - but opinions differ, and only definitive answer will come when it's tested in court (and even then, only for the jurisdiction of that court).