Daniel Pope wrote:
> 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.
I have heard than the hardware manufacturers cannot release the source
code because:
a) They don't own all the IP associated with the code
b) Their competitors could gain an understanding of the workings of the
hardware if they had access to the driver source code
I can't vouch for the truth or falseness of either of these statements.
>
> Dan
>
