"As attorneys we don't understand"

"(Actually, that's not quite true, but unfortunately for the FSF, Linus has veto rights as far as this issue is concerned, and he has been pretty blatant (ie read the COPYING file) that he will use them.)"

Linus doesn't officially have veto rights. He didn't collect copyright assignments, and doesn't really have any more rights than any other significant contributor. However, I suppose he does effectively have veto rights in one way... if I was bringing a lawsuit against a distributor of binary-only modules I might be inclined to back down if Linus specifically asked me to.

However, I suspect that it's unlikely that he'd do so. You are wrong about what it says in the COPYING file, if you think it gives an exception for kernel modules. Here's Linus' own response (LKML, 2003-12-03) to someone else who had the same mistaken impression, once before:

Nope. No such exception exists.

There's a clarification that user-space programs that use the standard system call interfaces aren't considered derived works, but even that isn't an "exception" - it's just a statement of a border of what is clearly considered a "derived work". User programs are _clearly_ not derived works of the kernel, and as such whatever the kernel license is just doesn't matter.

And in fact, when it comes to modules, the GPL issue is exactly the same. The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result, anything that is a derived work has to be GPL'd. It's that simple.

Now, the "derived work" issue in copyright law is the only thing that leads to any gray areas. There are areas that are not gray at all: user space is clearly not a derived work, while kernel patches clearly _are_ derived works.

But one gray area in particular is something like a driver that was originally written for another operating system (ie clearly not a derived work of Linux in origin). At exactly what point does it become a derived work of the kernel (and thus fall under the GPL)?

THAT is a gray area, and _that_ is the area where I personally believe that some modules may be considered to not be derived works simply because they weren't designed for Linux and don't depend on any special Linux behaviour.

Basically:
- anything that was written with Linux in mind (whether it then _also_ works on other operating systems or not) is clearly partially a derived work.
- anything that has knowledge of and plays with fundamental internal Linux behaviour is clearly a derived work. If you need to muck around with core code, you're derived, no question about it.

Historically, there's been things like the original Andrew filesystem module: a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. Is that derived just because it got ported to Linux that had a reasonably similar VFS interface to what other UNIXes did? Personally, I didn't feel that I could make that judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray area.

Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so.

Does that mean that any kernel module is automatically not a derived work? HELL NO! It has nothing to do with modules per se, except that non-modules clearly are derived works (if they are so central to the kenrel that you can't load them as a module, they are clearly derived works just by virtue of being very intimate - and because the GPL expressly mentions linking).

I claim that a "binary linux kernel module" is a derived work of the kernel, and thus has to come with sources.

But if you use those same sources (and _you_ wrote them) they do not contain any Linux code, they are _clearly_ not derived from Linux, and you can license and use your own code any way you want.

You just can't make a binary module for Linux, and claim that that module isn't derived from the kernel. Because it generally is - the binary module not only included header files, but more importantly it clearly is _not_ a standalone work any more. So even if you made your own prototypes and tried hard to avoid kernel headers, it would _still_ be connected and dependent on the kernel.

And note that I'm very much talking about just the _binary_. Your source code is still very much yours, and you have the right to distribute it separately any which way you want. You wrote it, you own the copyrights to it, and it is an independent work.

But when you distribute it in a way that is CLEARLY tied to the GPL'd kernel (and a binary module is just one such clear tie - a "patch" to build it or otherwise tie it to the kernel is also such a tie, even if you distribute it as source under some other license), you're BY DEFINITION not an independent work any more.