Possibly OT: Splitting Hairs Over GPL?
sjansen at buscaluz.org
Wed Apr 7 16:35:13 MDT 2010
On Wed, 2010-04-07 at 14:02 -0600, Aaron Toponce wrote:
> My understanding of the GPL says this is allowed. Further, my
> understanding of the GPL says that writing software under the GPL
> license and linking to proprietary licensed software is not allowed.
> With that said, I don't know how the Linux kernel gets away with it.
> Maybe I'm missing something crucial.
The GPL spills a lot of inking trying to distinguish how intimately two
pieces of code depend on each other. Basically "linking to" versus
"talking to". Any code that links against GPL code must be GPL
compatible. Code that merely launches or connects to GPL code has a less
strict dependency and therefore it is less reasonable to require that it
be GPL. (Though some will still try to require it, usually as an
anti-competitive bit of FUD.)
The Linux kernel is basically a very complex process with a higher
privilege level than other processes. When your process makes a system
call, it is basically performing a very low level RPC call. Or in other
words, it is "talking to" the kernel, not "linking against" the kernel.
For this reason, proprietary software can legally run on Linux so long
as it doesn't depend on any GPL libraries.
Linux modules, on the other hand, must be linked against the kernel to
work. That means that by a strict interpretation of the GPL, they pretty
much have to be GPL also.
HOWEVER, most of the Linux developers have arrived at a gentleman's
agreement with proprietary module writers. Linux developers have stated
they won't raise a fuss as long as proprietary modules play by certain
rules. (1) All modules must embed honest information about their license
in a machine readable format viewable using modinfo. (2) All non-GPL
modules must limit themselves to a subset of the kernel API. This makes
it possible for developers who prefer a strict interpretation of the GPL
to flag their portion of the kernel code as "for use by GPL modules
Linus Torvalds has stated that he prefers judging modules by asking
himself "could this module's code reasonably work with a different
kernel like the FreeBSD kernel or the Windows kernel"? If the module is
basically generic, with only a small Linux-compatibility shim, he
doesn't feel it is fair to enforce strict GPL terms. (But legally
speaking, he probably could if he wanted to.) On the other hand, if it
has a lot of Linux-specific dependencies then it must be GPL.
(Of course I'm paraphrasing 'cause I'm too lazy to GOOGLECITATION.)
nVidia gets away with their proprietary driver for two reasons. (1) They
claim the proprietary driver is not Linux specific but in fact basically
the same code for Linux, FreeBSD, and Windows alike. The only part that
is Linux specific is their compatibility shim which they provide under
the GPL. (2) So many people use the nVidia driver that if the Linux
developers decided go after nVidia, they'd have to deal with so much
whining and hate mail that it just isn't worth it.
"XML is like violence: if it doesn't solve your problem, you aren't
using enough of it." - Chris Maden
More information about the PLUG