Kororaa and the GPL - Update 1 [LWN.net]

Kororaa and the GPL - Update 1

Posted May 23, 2006 17:47 UTC (Tue) by JoeBuck (subscriber, #2330)
Parent article: Kororaa and the GPL - Update 1

Eben Moglen has said that it's not clear to him that the Linux kernel is really under the GPL. Under his interpretation, if I recall it correctly (and I apologize for putting words in his mouth) proprietary kernel modules violate the GPL, but he seems to think that the symbol labeling mechanism, which reserves some symbols for use by GPL modules and permits other symbols to be accessed by non-GPL modules, implies that there is a license of some sort for proprietary kernel modules, a kind of permission that goes beyond the GPL, but the problem is that this extra permission isn't really in writing anywhere.

Then you've got the problem that there are many copyright holders for the Linux kernel, and some of the copyright holders think there should be no proprietary kernel modules.

(Log in to post comments)

The Linux kernel is unambiguously licensed under GPL version 2.0.

Posted May 24, 2006 2:01 UTC (Wed) by xoddam (subscriber, #2322) [Link]

I'm surprised Moglen would draw such a conclusion.

Hooks for non-GPL modules imply that you have permission to *use* non-GPL modules with your Linux kernel. But the GPL is not a 'shrink-wrap' contract. You don't need permission to use the software in any way you please. The GPL is a *copyright* licence only, and all it does is to permit *copying* the kernel providing that certain conditions are met. And the kernel is unequivocally licenced with version 2.0 of the GPL, without any special exceptions.

Running 'insmod' is not distributing GPL software. Providing CDs and ISOs for download is. The only question open for argument here is whether it violates the GPL to distribute proprietary modules alongside a GPL'd kernel with the sole intention of linking them together at runtime.

Is this equivalent to distributing a kernel binary pre-built from a combination of GPL and proprietary source, which would *obviously* violate the GPL?

The Linux kernel is unambiguously licensed under GPL version 2.0.

Posted May 24, 2006 10:50 UTC (Wed) by Wol (guest, #4433) [Link]

I think the idea of the "GPL only" stuff is that a binary module (which pretty much has to include at least header files) is placed on notice that the inclusion of header files will be considered a copyright violation!

Let's say I write a nifty .h file with loads of macros. Any binary that includes my .h file is a derivative. In the normal course of events the contents of a .h file are considered "fair use" or "scenes a faire" or whatever - the consequences of which is that copyright is not violated.

The "GPL only" flag is a big red warning that use of this particular .h will NOT be considered fair use ...

Cheers,
Wol

The Linux kernel is unambiguously licensed under GPL version 2.0.

Posted May 24, 2006 14:47 UTC (Wed) by kakareka (subscriber, #5204) [Link]

Macros will only get included in a binary if actually used. Just including your header (ie, #include in the source) doesn't mean the binary contains your code and couldn't be considered derivative. Also, most macros are probably too simplistic to be copyrightable (eg, min and max macros).

John

The Linux kernel macros

Posted May 24, 2006 16:29 UTC (Wed) by pflugstad (subscriber, #224) [Link]

Heh - have you seen the min/max macros the kernel uses? Here's the debate (the first 1/2 a dozen entries or so):

<http://www.google.com/search?q=min+max+macro+site%3Alwn.n...>

And the current form (as of 2.6.16.18), which do type checking:

<http://lxr.linux.no/source/include/linux/kernel.h>

Also, I think a lot of the time, the kernel uses inline functions, and they are frequenly non-trivial. I think a lot of the scheduling and locking (spinlocks, sems, etc) functions are actually inline functions. Basically, a LOT of functionality is incorporated in in kernel headers.

So it get really hard to interact with the kernel without including kernel headers and using these inline functions - and from there, you get to a derived work pretty quickly.

Pete

The Linux kernel is unambiguously licensed under GPL version 2.0.

Posted May 25, 2006 2:22 UTC (Thu) by xoddam (subscriber, #2322) [Link]

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?

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.