OS abstraction - not always a trap [LWN.net]

OS abstraction - not always a trap

Posted Aug 20, 2011 21:01 UTC (Sat) by giraffedata (subscriber, #1954)
In reply to: OS abstraction - not always a trap by BenHutchings
Parent article: Avoiding the OS abstraction trap

And they have also made it clear that a "portable" version of the driver would not be the preferred form. So, where's the problem?

How have they made that clear?

Every one of them has given a license to anyone who chooses to use it that is described in its entirety by one document: GPL V2. That document gives no detail at all on what "the preferred form of the work for making modifications to it" is.

And incidentally, if one of the kernel authors did decide to be more specific, he'd be violating some previous author's copyright, because of GPL's condition that one offer one's own additions under GPL.

(Log in to post comments)

OS abstraction - not always a trap

Posted Oct 1, 2011 9:48 UTC (Sat) by Duncan (guest, #6647) [Link]

> Every one of them has given a license to anyone who chooses to use it that is described in its entirety by one document: GPL V2.

AFAIK, the GPLv2 describes the collected work, and individual files/patches must of course have compatible licenses, but no, the GPLv2 does not describe "in its entirety" the license of every individual part, as some parts are more liberally licensed (2-Clause BSD, LGPLv2, GPLv2 or later instead of specific v2 as applies to the kernel as a whole, etc.).

Additionally, I do not believe the GPLv2 describing the license "in its entirety" is fully correct for even the kernel as a whole, due to Linus's specific waiver of the "derived work" claim for userspace as opposed to kernelspace, or as specifically worded in the kernel's GPLv2 preamble in the COPYING file, "user programs that use kernel services by normal system calls".

FWIW, your statement might have been "loosely acceptable" if not entirely accurate, had it not used the words "in its entirety", but it's clearly incorrect with the inclusion of the "entirety" claim, because that claim is clearly factually incorrect.

Finally, there's the various binary firmware blobs, some of which are still in the kernel, which don't really comply with the GPLv2 at all, and which make a lot of people nervous. However, they're gradually being moved out of the kernel, there's various "deblobbed" kernel sources available, and should someone legally force the issue, it's now to the point where they could be stripped and packaged separately with, probably less technical disturbance than for instance the switch to the two-digit kernel 3.0 numbering scheme caused... which might be why nobody's bothered asserting legal claim to force the issue, since it's hardly worth it now and the separation is gradually happening on its own anyway.

Meanwhile, just in case someone gets the wrong idea... I'm not a lawyer, nor do I even pretend to play one, anywhere. However, it's not like this actually requires a lawyer to see, since the waiver's clearly there in the COPYING file, individual files clearly carry their own various licenses, and the firmware issues are well known.

Not that many will likely read this, over a month after original publication of the parent article, but there's always the few coming in via Google, or following links in later LWN articles referring back to this one.

Duncan