Re: [Hampshire] No more non-GPL Linux kernel modules?

Top Page

Reply to this message
Author: Daniel Pope
Date:  
To: Hampshire LUG Discussion List
Subject: Re: [Hampshire] No more non-GPL Linux kernel modules?
Jamie Webb wrote:
> On Thu, Dec 14, 2006 at 10:59:27PM -0000, Vic wrote:
>>> a) they are building on top of the linux kernel and if you feel as I
>>> do about GPL vs BSD then the module should be GPL. If 99% of the PVR
>>> is open source code, how _dare_ they hold 1% back!
>> Morally, you're right, of course. The GPL helps us all, and is a Good
>> Thing(tm).
>>
>> Legally, though, it's not nearly as clear.
>> http://www.gnu.org/licenses/gpl-faq.html#MereAggregation gives some
>> examples of the difference between derivative works and aggregation; a
>> court *might* decide that a kernel module is part of a bigger programme,
>> and is therefore a derivative work (i.e. covered by the GPL) - but that's
>> not certain, so (for the timebeing at least) there appears to be room for
>> non-free modules alongside a GPL kernel. And LT's arguments about opening
>> the floodgates elsewhere ring rather too true for my liking; attempting to
>> plug this "loophole" (if that is what it is) runs the risk of outlawing
>> all sorts of desirable activities...
>
> I'd say a kernel module binary (though not the source code) must be a
> derived work of the kernel headers, though of course I completely
> agree with Linus for practical purposes.


Strangely, that GPL FAQ reads totally differently to the actual language
of the GPLv2.

Semantically, I think I would look at drivers modules as separate
software units, that run within an execution environment of the kernel,
and which perform a task of controlling a hardware device by exporting a
common interface back to the kernel.

At a hardware level, there's very little distinction between userspace
programs running on a kernel and kernel-space drivers running within a
kernel. It seems rather silly that there should be two different
standards based on a fuzzy notion of how you map physical address space
and schedule the CPU.

Obviously if the driver is a derivative work of GPLed code then it must
be GPLed, but it would make more sense to me that the kernel-headers
were LGPLed rather than the opposite: forcing GPL on all kernel developers.

I'm not sure that merely requiring kernel headers to build constitutes
"derivative work", anyway. The kernel headers provide a contract with
modules that the kernel source then implements. Claiming that developing
original software which refers to those headers must be subject to the
GPL is equivalent to claiming that any piece of software written with
reference to an O'Reilly programmer's reference book requires a licence
from Tim O'Reilly.

Of course I don't advocate proprietary drivers, particularly because I
don't see why hardware manufacturers need to protect their drivers, when
the drivers are beer-free and useless without the corresponding
hardware. But anyway, those of us who want to be able to use hardware
which only provides proprietary drivers could, assuming drivers are
actually available, migrate to Hurd, which wouldn't be subject to this
nonsense.

Dan