The Linux kernel is unambiguously licensed under GPL version 2.0.
Posted May 26, 2006 2:09 UTC (Fri) by xoddam
In reply to: The Linux kernel is unambiguously licensed under GPL version 2.0.
Parent article: Kororaa and the GPL - Update 1
Okay, standard disclaimer: IANAL, and when I write IMO, that's *my*
opinion and has very little correlation with what a court might find.
Do you really thing copyright law cares about the last
letter of a file name (c vs h)?
Of course not, not a whit. The distinction I'm making is between
source code which doesn't incorporate copyrightable implementations
(interfaces are not copyrightable in themselves -- that
would make Linux and glibc derivative works of the original AT&T
SCO claimed for a while) and object code which may or may not incorporate
the implementations, depending on the implementations themselves and on
what has been linked to what. Writing #include <stdio.h>
does not incorporate the contents and implementation
details of the stdio API into your program's source code. Does anyone
care whether putchar() is a macro, an inline function or a
call to a function defined elsewhere?
I do think there is a difference between using an interface and
incorporating it. You only make derivative works by actually
incorporating the parent work into your own -- not by
referencing its published interface. The source of your
program does not derive in any way from libc or the standard
headers. On the other hand the ELF executable may or may not derive from
the contents of the headers, depending on implementation, and if you link
statically with libc.a then your executable is also a derived
work of libc (dynamic linking would produce a derived work
in-core, but I have been told -- IANAL -- that a running process image is
not considered to be a copy for legal purposes; certainly you don't
distribute it). No-one minds that you do this because the LGPL
explicitly permits it, but the distinction and the implementation details
become relevant when you begin to make derived works using GPL'd
interfaces. Source code which uses an interface is not
a derived work of the header file which declares the interface. Object
code may be, depending on the details of the
Do you really think GPL symbols are anything but a debug
Yes. "The stated purpose
of that marking is to prevent non-GPLd code from using those
symbols." Nothing to do with debugging. It's a technique for
enforcement of the licence -- a kind of DRM. (joke)
In your opinion:
If a shim pulls in inlines or macros that could not easily have been
reverse engineered from a header, is it derived or not?
The source of the shim is not derived from the header. The object
code may be. Supposing the code generated by the inlines
and macros is sufficiently nontrivial to be copyrightable, that
derivation becomes a copyright issue.
If that shim is statically linked to a binary blob, is the
resulting module derived from the shim, or not?
Yes of course the linked module is derived from the shim. If there's
a disagreement here it is as to whether the actual shim in
question (for NVIDIA display driver) uses any disputable inlines or
macros. AFAIK it doesn't use any symbols marked GPL-only, which is the
'do not cross this line' marker used by the kernel developers. So it
comes down to whether locking primitives and access functions for kernel
data structures -- which all modules have to use -- are
So a question for the audience (and the lawyers): If a module uses
spin_lock() and list_for_each_safe(), does that make
its object code a derived work of spinlock.h and
list.h? Linus has explicitly endorsed the distribution of such
modules without complete source code (though I know other people have
reservations), and it is my understanding that the NVIDIA driver fits
As far as I have understood, the objection to kororaa is not about
considering a single .ko to be a derived work of the kernel
headers, but rather that the kernel as a whole, when distributed on a CD
as a bzImage file and some .kos, one of which is
non-free, which are to be linked with the kernel on boot.
I am open to correction on either of these points. It would be very
helpful if anyone comes up with a pointer to clear
information as to whether the kernel developers' objection is to the
distribution of the .ko alone, or only together with the kernel
to which it is to be linked at runtime.
to post comments)