Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for December 5, 2013
Deadline scheduling: coming soon?
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
Proprietary loadable kernel modules
Posted Mar 21, 2011 8:35 UTC (Mon) by FlorianMueller (guest, #32048)
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.
Posted Mar 21, 2011 12:04 UTC (Mon) by dgm (subscriber, #49227)
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.
Posted Mar 23, 2011 23:28 UTC (Wed) by baldridgeec (guest, #55283)
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.
Posted Mar 24, 2011 13:07 UTC (Thu) by vonbrand (subscriber, #4458)
That is the intent of the kernel hackers; whether the law agrees with this is quite another thing...
Posted Mar 24, 2011 14:04 UTC (Thu) by etienne (subscriber, #25256)
Posted Mar 24, 2011 19:53 UTC (Thu) by vonbrand (subscriber, #4458)
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.
Posted Mar 25, 2011 0:42 UTC (Fri) by rgmoore (subscriber, #75)
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 #define GPL", then he can be legally barred from turning around and suing somebody when they take him seriously. Even without a formal statement along those lines, officially designating some symbols as GPL only implies that the rest of the symbols may be used by non-GPL modules.
Posted Mar 21, 2011 8:49 UTC (Mon) by wahern (subscriber, #37304)
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.
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.
Posted Mar 21, 2011 10:59 UTC (Mon) by nix (subscriber, #2304)
Posted Mar 21, 2011 11:41 UTC (Mon) by wahern (subscriber, #37304)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds