| |||||||||||||
OS abstraction - not always a trapOS abstraction - not always a trapPosted Aug 20, 2011 19:34 UTC (Sat) by BenHutchings (subscriber, #37955)In reply to: OS abstraction - not always a trap by giraffedata Parent article: Avoiding the OS abstraction trap
The owners of that have authorized folks to prepare and distribute derivative works only if they provide their source code in "preferred form." 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?
(Log in to post comments)
OS abstraction - not always a trap Posted Aug 20, 2011 21:01 UTC (Sat) by giraffedata (subscriber, #1954) [Link] 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.
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
OS abstraction - not always a trap Posted Oct 2, 2011 0:39 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
I'll also point out that there are a lot of people who don't see binary blobs that are not executed on the main CPU as being any problem
|
|||||||||||||