| |||||||||||||
Proprietary loadable kernel modulesProprietary loadable kernel modulesPosted Mar 21, 2011 7:20 UTC (Mon) by wahern (subscriber, #37304)In reply to: Proprietary loadable kernel modules by FlorianMueller Parent article: Has Bionic stepped over the GPL line?
> In my understanding, LKMs need to be compiled against at
> least module.h, and in practical terms against more headers. > If any of those headers could just be un-GPL'd the way Google > claims it can un-GPL the raw headers for Bionic, there might > still be other arguments remaining for which one can claim > that LKMs are derived works, but one argument would be gone.
Indeed, that is the heart of the issue. A compiler similarly "strips" comments and normalizes code; and in no sense is a piece of code dependent on a comment, or on the amount of white space in a declaration or definition; those things are semantically meaningless in a source file. Google posits, therefore, that all those things with semantic meaning in those header files is not copyrightable.
If Google isn't violating the GPL, then neither would any company distributing closed-sourced binary modules built against kernel headers. At best they would be liable under some sort of contributory infringement theory, except a non-distributing end-user would have a license to use the GPLd work, so there would be no infringement to contribute to. Under Google's theory, the derivative-ness doesn't happen until being loaded into the kernel. (Because if the headers are not copyrightable, it implies that neither are the interfaces to which they're intended to be run against; in other words, that there are other potential non-infringing Linux clones that might load that module. So until it's actually loaded, it's not derivative.)
People's defense of Google here is baffling. It's one thing to critique lawyers' poor technical comprehension. It's another to defend a copyright theory which affects such a clear and momentous change in Free Software licensing.
(Log in to post comments)
Proprietary loadable kernel modules Posted Mar 21, 2011 7:28 UTC (Mon) by viro (subscriber, #7872) [Link]
This is complete crap. Kernel module will be _UNABLE_ to stay within the subset of definitions that covers syscall-related constants and structs, to start with.
Proprietary loadable kernel modules Posted Mar 21, 2011 8:35 UTC (Mon) by FlorianMueller (guest, #32048) [Link]
@viro, you appear to be saying that a kernel module will need MORE definitions than the "subset of [them] that covers syscall-related constants and structs".
1) If that is so, does this mean you consider constants and structs potentially copyrightable?
2.1) If the answer to 1) is yes, please consider that Bionic contains approximately 750 files containing a total of approximately 2.5 megabytes of constants and structs (plus other material, but the bulk of it is constants and structs). At the start of each such file, Google claims that this is "no copyrightable material" and threw out any copyright and GPL notices found in the raw headers.
2.2) If the answer to 2) is no, of if you wish to add something anyway, please specify what your derivative work theory for a loadable kernel module would be.
Proprietary loadable kernel modules Posted Mar 21, 2011 12:04 UTC (Mon) by dgm (subscriber, #49227) [Link]
It amuses me that you find very important for the argument that Alexander Viro considers that something is copyrightable or not. Instead you chose to obviate something that's much more interesting: his intention. Were he and the rest of kernel developers trying to prevent others from using those constants and structures in non-GPL code? I cannot speak for them, but my guess is that they were not.
Additionally, it's clear that, even in the case constants and structs were copyrightable, there's the special exception about the syscall interface. There's no such exception for kernel modules.
Proprietary loadable kernel modules Posted Mar 23, 2011 23:28 UTC (Wed) by baldridgeec (guest, #55283) [Link]
I should probably keep my mouth shut, not being a kernel developer, but I have always understood a (non-GPL) loadable kernel module's ability to link to code as being governed by the "#define GPL" sections.
This obviously DOES NOT mean that they cannot have include files which also have text defining the GPLed interfaces (indeed, AFAIK most if not all proprietary LKMs simply #include the kernel's own header files.) It is the use of those interfaces in the code which determines the behavior of cc and ld, and determines whether the module is considered a derivative work for the purpose of license compliance.
That being said, I'm not sure why the question of LKM licensing is coming up anyway, since Bionic is a reimplementation of libc, not a module.
Proprietary loadable kernel modules Posted Mar 24, 2011 13:07 UTC (Thu) by vonbrand (subscriber, #4458) [Link] That is the intent of the kernel hackers; whether the law agrees with this is quite another thing...
Proprietary loadable kernel modules Posted Mar 24, 2011 14:04 UTC (Thu) by etienne (subscriber, #25256) [Link]
The intent of the kernel hackers is a bit like the intent of GCC developers when they say that the resulting executable is not a derived work of GCC, or the intent of word processors developers when they say the final document is fully owned by the author of said document.
If the law disagree that may have very high consequences.
Proprietary loadable kernel modules Posted Mar 24, 2011 19:53 UTC (Thu) by vonbrand (subscriber, #4458) [Link] OK, perhaps I misspoke. What I meant is that the kernel gang considers stuff using userland interfaces OK under whatever licence you fancy (not in the sense that such code is "not derivative", but that that such use is allowed), while using kernel-internal interfaces (specially ones marked GPL-only) is strictly GPL. It might be that the law says that both uses create derivatives, in which case you are being given an explicit permission for userland while in-kernel use is strictly GPL-only because it is a derivative; or it might say neither does, in which case the whole discussion is moot.
Proprietary loadable kernel modules Posted Mar 25, 2011 0:42 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] The stated intent of the kernel hackers (or anyone in a similar position) has a great deal of effect when they say that something is permitted. If Linus says "you're in the clear as long as you don't use anything within
Proprietary loadable kernel modules Posted Mar 21, 2011 8:49 UTC (Mon) by wahern (subscriber, #37304) [Link]
Right, and neither do Google's processed header files only produce definitions that cover syscall related constants and structs. Just because they excise everything guarded by __KERNEL__ doesn't mean they aren't capturing copyrightable code; similarly, just because something is guarded by __KERNEL__ doesn't mean it's copyrightable. The law says what's copyrightable, not the author; the author can only license--explicitly or impliedly--what he has copyright in.
Go through those files yourself, and then ask yourself if you would mind if such collections of your own code of similar complexity and expressiveness to be entirely without copyright protection.
http://android.git.kernel.org/?p=platform/bionic.git;a=tree;...
The point is that _some_ of the output of the processing may be copyrightable; *not* that _all_ of it is. There's significantly more there than the syscall descriptor number for the read system call.
So you have to ask yourself, is the convenience to Google worth the circumscription of copyright protection for copyleft works? Perhaps it is; but don't pretend that their legal theory doesn't have repercussions.
Proprietary loadable kernel modules Posted Mar 21, 2011 10:59 UTC (Mon) by nix (subscriber, #2304) [Link]
Uh, the kernel header files *are* a collection of (in part) viro's own code.
Proprietary loadable kernel modules Posted Mar 21, 2011 11:41 UTC (Mon) by wahern (subscriber, #37304) [Link]
Yes, I realize that. I've been using Linux and programming since 1994. I know who's who.
I'm merely trying to impress upon people that if you look at the actual code outside of the __KERNEL__ defines; and the actual code inside of the __KERNEL__ defines; unless you can identify differences in the inherent expressiveness of that code without substantially relying on practical intentions about making it difficult to create derivative binary modules, then by asserting *all* of the code outside of those defines is not copyrightable, you're also asserting that much of the code inside of those defines is likewise not copyrightability.
These are important distinctions (or lack thereof), because there is no shortage of very well regarded copyright lawyers and judges who believe almost no source code or software should be copyrightable. And they believe that because of expressivity concerns. But I'm not making a slippery slope argument, merely trying to point out that the legal issue turns on expressivity. If you think that expressivity primarily turns on the prevalence of logical operators and conditional statements (i.e. what we consider to constitute the body of functions), then you're already down the wrong path. Those things principally describe process; as such, they are considered more often not matters of copyright but of patent; things generally regarded as mutually exclusive. As they aren't expressive elements per se, it would be imprudent to suggest that code which does not implicate them does not implicate copyrightability at all. That is, if you care about the enforcement of copyleft license covenants.
Proprietary loadable kernel modules Posted Mar 21, 2011 8:42 UTC (Mon) by FlorianMueller (guest, #32048) [Link]
It's not so hard to explain why people would fail to understand the significance of this. To understand it requires the combination of (i) a grasp of the issue (including the ability to understand that in certain contexts, uncertainty is bad enough even if there's no certainty for a bad hypothesis being true) _AND_ (ii) the ability to focus on an issue without thinking about possible sympathies for, or allegiances to, particular companies.
But again, there's a few vocal apologists and they are all quite weak. None of them has stood up to say that what Google does to those headers isn't infringing. So in a way they all agree with me :-)
Concerning LKMs, while one might try to come up with other derivative work theories, the use of copyrighted, GPL'd headers would of course be the best chance to prevail in court. All you would have to do then is request, in discovery, production of the source code of a proprietary LKM (in the US that's child's play, and even in Europe you could get to that point if you do it right). Then you prove that GPL'd material was part of the source code that was compiled, and you've won. Any other theories are far harder to prove, if they can work at all.
Proprietary loadable kernel modules Posted Mar 21, 2011 9:53 UTC (Mon) by foom (subscriber, #14868) [Link]
> But again, there's a few vocal apologists and they are all quite weak. None of them has stood up to say that what Google does to those headers isn't infringing. So in a way they all agree with me :-)
If what google does is considered infringing, it'd be nice for someone to explain how it's different than what glibc does. Perhaps they're both infringing, then...
(unlikely)
Proprietary loadable kernel modules Posted Mar 21, 2011 9:56 UTC (Mon) by FlorianMueller (guest, #32048) [Link]
The differences are quite fundamental. glibc uses the "sanitized" headers provided by the kernel maintainers for the purpose of creating libraries. Google reprocesses and repurposes the "raw" (original, non-sanitized) kernel headers.
Proprietary loadable kernel modules Posted Mar 21, 2011 11:01 UTC (Mon) by nix (subscriber, #2304) [Link]
So... what magic does the headers_install script perform to strip out copyright that the (very similar) script that Google provides omits to do? It would be trivial for Google to use the output of headers_install, and then all your doom-mongering would be for nothing (except to spread FUD, but that *of course* isn't your intention, oh no).
Proprietary loadable kernel modules Posted Mar 21, 2011 11:05 UTC (Mon) by FlorianMueller (guest, #32048) [Link]
One of the differences is that the output of headers_install is provided by the kernel maintainer for the purpose of integration into C libraries. That's different than just repurposing something else.
Your thinly-veiled FUD accusation is unwarranted. If it's (according to you) trivial for Google to use the output of headers_install, and if they do that in the future, everything's fine from my point of view. I'd love to see exactly that happen, and the sooner, the better. So the easier it is for them to do it, the better. Still I believe this must be done.
Proprietary loadable kernel modules Posted Mar 21, 2011 12:44 UTC (Mon) by sorpigal (subscriber, #36106) [Link] You're talking lawyer-magic here, not reality. Only in lawyer-magic-land does it matter whether they use the "raw" headers and then create their stripped version or use the headers_install version and then create their stripped version. Lawyers may think that there's a difference, but there isn't.
Proprietary loadable kernel modules Posted Mar 21, 2011 21:33 UTC (Mon) by chrisV (subscriber, #43417) [Link]
"It's not so hard to explain why people would fail to understand the significance of this. To understand it requires ..."
Since you are neither a lawyer nor a kernel developer, to be perfectly frank your understanding probably doesn't mean very much.
Judging by the number of post you have made to this thread, you also have a significant amount of time on your hands, so you could consider using it to obtain a legal qualification.
Proprietary loadable kernel modules Posted Apr 18, 2011 20:31 UTC (Mon) by nix (subscriber, #2304) [Link]
What? Florian's not even a lawyer? But he spouts off so much about other poeple (hello PJ) not being lawyers and therefore not being eligible to say a blessed thing...
*boggle*
Proprietary loadable kernel modules Posted Apr 18, 2011 20:33 UTC (Mon) by FlorianMueller (guest, #32048) [Link]
You miss the point here. I never said that non-lawyers are ineligible to talk about those matters. I pointed out that the avatar named "PJ" doesn't provide any background other than the status of "paralegal".
Proprietary loadable kernel modules Posted May 9, 2011 11:12 UTC (Mon) by nix (subscriber, #2304) [Link]
Yes, you did. Over and over again. What you failed to indicate is why we should care at all, much less why we should consider her employment credentials more significant than the things she's done under the groklaw banner. "Florian does it" is not sufficient evidence.
Proprietary loadable kernel modules Posted Mar 21, 2011 8:45 UTC (Mon) by FlorianMueller (guest, #32048) [Link] A compiler similarly "strips" comments and normalizes code; and in no sense is a piece of code dependent on a comment, or on the amount of white space in a declaration or definition; those things are semantically meaningless in a source file. Google posits, therefore, that all those things with semantic meaning in those header files is not copyrightable. FULL ACK. Google's approach is that they harvest all the fruit from the trees and say only the remainder is copyrightable...
Proprietary loadable kernel modules Posted Mar 24, 2011 21:17 UTC (Thu) by filipjoelsson (subscriber, #2622) [Link]
If you refer to the ABI when you write "all the fruit", then you are correct. Isolating the ABI is what the header laundering is all about. It's just that THE ABI IS EXPLICITLY NOT COVERED in the COPYING file!
I do not belong to the group who think you are spreading FUD, but that's just because I recognize that you are a troll.
|
|||||||||||||