The Linux kernel is unambiguously licensed under GPL version 2.0. [LWN.net]

The Linux kernel is unambiguously licensed under GPL version 2.0.

Posted May 25, 2006 2:22 UTC (Thu) by xoddam (subscriber, #2322)
In reply to: The Linux kernel is unambiguously licensed under GPL version 2.0. by Wol
Parent article: Kororaa and the GPL - Update 1

Hmmm. The whole subject of whether using macros & inline functions from
a work constitutes incorporating portions of it is a big grey area. FWIW
my opinion is that a .c file which uses APIs is not a derivative work (at
least not for that reason) -- whether it's only a symbol declaration (and
function prototype), or a macro or inline function, is an implementation
detail. The .o file built from the .c and .h files *obviously*
incorporates parts of both works though -- though as you say, fair use
rules might apply in jurisdictions lucky enough to have such a doctrine.

I do not think the "GPL only" APIs change the gist of this discussion at
all: they imply an added condition to the licence for the kernel that
these APIs not be used by non-GPL modules, but that exception, like the
rest of the conditions in the licence, only comes into play where the act
of copying and distributing does.

But neither question is actually relevant to the NVIDIA and ATI display
driver modules. Those drivers do not use Linux kernel APIs directly, but
only via a 'shim', which is (a) GPL licenced, at least in letter (though
the final .ko which is insmodded can't technically be considered GPL),
and (b) doesn't use GPL-only kernel APIs anyway.

The GPL violation Kororaa is alleged to have made is nothing to do with
including bits of kernel headers into shim objects which are then linked
to binary-only non-free modules.

The question is whether providing a GPL'd kernel binary and a non-free
module together on the same bootable medium with the clear intention of
linking them together as soon as the system is booted (thus producing a
non-free and nondistributable kernel 'in core') is equivalent to
*distributing* a non-free kernel binary, which would *clearly* violate
the GPL.

I do feel I'm repeating myself... does anyone actually disagree?

(Log in to post comments)

The Linux kernel is unambiguously licensed under GPL version 2.0.

Posted May 25, 2006 21:38 UTC (Thu) by filipjoelsson (subscriber, #2622) [Link]

Some things you are writing are a bit unclear to me:
Do you really thing copyright law cares about the last letter of a file name (c vs h)?
Do you really think GPL symbols are anything but a debug convenience?
In your opinion:
If a shim pulls in inlines or macros that could not easily have been reverse enginerd from a header, is it derived or not?
If that shim is statically linked to a binary blob, is the resulting module derived from the shim, or not?

My opinion is very clear, the .ko files are derived from headers that are made available under the GPL. If the ABI of modules was stable enough, ati and nvidia would address the ABI directly - and there would be no need for a shim. Since the need is there, the shim is derived from the headers, and the .ko is also so. QED.

The Linux kernel is unambiguously licensed under GPL version 2.0.

Posted May 26, 2006 2:09 UTC (Fri) by xoddam (subscriber, #2322) [Link]

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 Unix, as 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 implementation.

Do you really think GPL symbols are anything but a debug convenience?

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 sufficiently nontrivial.

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 that description.

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.

Replying to myself...

Posted May 26, 2006 2:21 UTC (Fri) by xoddam (subscriber, #2322) [Link]

> (though I know other people have reservations)

There's also this:

"The only exception we make is for code which was written for other
operating systems and was then ported to Linux."

http://lkml.org/lkml/2005/2/4/53

This contradicts my thoughts about conventional interfaces like
spin_lock(), but explicitly endorses the NVIDIA driver, in direct
contradiction to Filip's argument (which I agreed with in broad strokes
but argued in the fine detail).

Enough armchair lawyering for me, as Greg K-H would say.