| |||||||||||||
OS abstraction - not always a trapOS abstraction - not always a trapPosted Aug 19, 2011 22:11 UTC (Fri) by giraffedata (subscriber, #1954)In reply to: OS abstraction - not always a trap by Eliot Parent article: Avoiding the OS abstraction trap
Which could be defended against with estoppel because the generation of the kernel code and then labelling it as GPL was done by the copyright owner. Wrong code. We're talking about the copyright on the rest of the kernel. The owners of that have authorized folks to prepare and distribute derivative works only if they provide their source code in "preferred form." So if the generated code isn't preferred form, and a copyright owner gets nasty, there could be trouble both for the authors of the asihpi driver and anyone who distributes a kernel that contains it. It exists in its own right independent of our private version. The scripted conversion just saves us the process of porting changes manually when our version changes. Note that you could say the same thing about an ELF version which the author compiles from C, and everyone agrees ELF is not "the preferred form." The fact that the generated code is C, and presumably pretty normal C, is a much more persuasive argument that it is "the preferred form." I guess the answer is irrelevant until the copyright owner of the code in question decides to turn nasty. First, to be clear: "the code in question" is the Linux kernel in its entirety. And if the asihpi driver code is not in the preferred form, then the code in question has not been released - its release was conditional on everything lumped with it being available in preferred form.
(Log in to post comments)
OS abstraction - not always a trap Posted Aug 20, 2011 19:34 UTC (Sat) by BenHutchings (subscriber, #37955) [Link] 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?
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
|
|||||||||||||