The Linux kernel is unambiguously licensed under GPL version 2.0.

The Linux kernel is unambiguously licensed under GPL version 2.0.

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.