| |||||||||||||
On the value of EXPORT_SYMBOL_GPLOn the value of EXPORT_SYMBOL_GPLPosted Oct 6, 2005 8:00 UTC (Thu) by mingo (subscriber, #31122)Parent article: On the value of EXPORT_SYMBOL_GPL
i'd like to extend/correct this simplified assertion in the article:
"Exports come in two flavors: vanilla (EXPORT_SYMBOL) and GPL-only (EXPORT_SYMBOL_GPL). The former are available to any kernel module, while the latter cannot be used by any modules which do not carry a GPL-compatible license."
symbols exported via EXPORT_SYMBOL are "available to any kernel module" only technically, but what license covers the module depends on the type of symbol that the module uses.
If the module is clearly separate work (legally), then it can be non-GPL. If a module uses internal symbols of the kernel, even if those symbols are exported via EXPORT_SYMBOL, it could still very much be a derived work of the kernel, and thus its distribution is covered by the GPL. So the advice is: if your module is non-GPL-compatible, "talk to your lawyer".
in other words: EXPORT_SYMBOL is not a blanket permission by kernel developers to limit the scope of the GPL covering derived work kernel modules.
If your module is GPL, then it is fine to distribute it as allowed by the GPL, independently of whether the module is a derived work of the kernel or not.
If your module is non-GPL then obviously it very much matters whether it is a derived work of the GPL-ed Linux kernel! The scope and type of kernel-internal symbols used by a module is a large factor in deciding whether the module is a derived work of the Linux kernel. Using an EXPORT_SYMBOL_GPL symbol is a clear indicator that the module is using something that kernel developers consider deeply internal.
Linux kernel copyright owners have also added an effective technological protection measure to ensure that the kernel's copyrighted code covered by EXPORT_SYMBOL_GPL can only be used by modules that explicitly declare themselves GPL-compatible.
EXPORT_SYMBOL symbols do not mean the opposite of EXPORT_SYMBOL_GPL - they are simply "undefined" - you have to find out for yourself.
(this might sound like nitpicking, but the devil is in the details, and these are important details. IAALKD, IANAL.)
(Log in to post comments)
On the value of EXPORT_SYMBOL_GPL Posted Oct 6, 2005 11:38 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] Ingo writes:If your module is non-GPL then obviously it very much matters whether it is a derived work of the GPL-ed Linux kernel!Very true. But remember -- the GPL speaks not only of 'derived' works, but also of 'collective' works. Consider section 2 of the GPL:
If [your modules] are not derived from the [kernel], and can reasonably be considered independent and separate works in themselves, then this License, and its terms, do not apply to those [modules] when you distribute them as separate works.So while what Ingo said was true, it wasn't quite complete. Not only does it matter whether your module is a derivative work, it also matters if your module is part of a collective work. Examples of a collective work with both GPL'd sections and sections which would otherwise be unaffected by the GPL:
We should probably try to stop using the term 'derived work' as if it's synonymous with 'GPL-affected'. The GPL actually goes a lot further than that.
On the value of EXPORT_SYMBOL_GPL Posted Oct 6, 2005 14:32 UTC (Thu) by sepreece (subscriber, #19270) [Link] IANAL as well, so this is, of course, speculation, but...
1) The clauses you quote about collective works include the phrase "as part of a whole which is a work based on the Program". Earlier in the license (clause 0) that phrase is defined to mean "either the Program or any derivative work under copyright law" [this definition is immediately followed by an explanatory clause that seems to say something different, making the whole thing splendidly unclear]. That seems to imply that the collective work would have to be a derivative work for the collective rule to apply.
2) There's also that aggregation clause, which immediately follows the clauses you cite and says "mere aggregation...does not bring the other work under the scope of this License", which would seem to negate the notion that bundling pieces together in a distribution medium (such as a tarball or an embedded device) would bring them under the License.
I believe the central point here is what the "work" is. The aggregation clause says that simply distributing things together does not make them part of a single work, for purposes of the GPL. However, if the pieces are part of a single work (as, for instance, code linked into the kernel), then the collective clause applies.
Again, though, IANAL.
On the value of EXPORT_SYMBOL_GPL Posted Oct 6, 2005 15:01 UTC (Thu) by dwmw2 (subscriber, #2063) [Link] I believe the central point here is what the "work" is. The aggregation clause says that simply distributing things together does not make them part of a single work, for purposes of the GPL. However, if the pieces are part of a single work (as, for instance, code linked into the kernel), then the collective clause applies.That is indeed the question. Certainly, when a bunch of different programs are collected onto a CD and distributed, that would clearly be "mere aggregation" -- although some Linux distributions do, interestingly, claim copyright on the whole distribution as a collective work, which is an interesting problem in itself. However, if the parts are interdependent, and each cannot usefully function without the other, it would be much harder to claim that it's "mere aggregation". The two examples I gave were cases where the individual parts were clearly part of a greater whole, rather than being related to each other only by their coincidental presence in the same location. Obviously there is no 'correct' answer until/unless it's tested in court, but I find it hard to believe that "mere aggregation" could be argued in those cases.
On the value of EXPORT_SYMBOL_GPL Posted Oct 6, 2005 18:18 UTC (Thu) by vonbrand (subscriber, #4458) [Link] IANAL, so take the following with the appropiate amount of salt... In the distribution case, you certainly can have a claim on the collection as such, even if you have no claim on the individual parts. I.e., if you gather "geek folk tales", and then publish them in book form, you can claim copyright on the book, not on each tale (presumably public domain, or GPLed by each geek).
On the value of EXPORT_SYMBOL_GPL Posted Oct 6, 2005 17:46 UTC (Thu) by nchip (guest, #13292) [Link] >> If your module is non-GPL then obviously it very much matters whether it is a derived work of the GPL-ed Linux kernel!
> Very true. But remember -- the GPL speaks not only of 'derived' works, but also of 'collective' works. Consider section 2 of the GPL:
Ingo is right here. GPL also states:
> In addition, mere aggregation of [module] not based on the [kernel]
So it boils back to the "is the binary-only module derived from Linux" argument. Many Linux distributors bundle on their liveCD's and installers both Linux kernel and binary-only modules/firmwares, so this isn't an embedded-only phenomea.
On the value of EXPORT_SYMBOL_GPL Posted Oct 6, 2005 21:45 UTC (Thu) by fenrus (guest, #31654) [Link] > In addition, mere aggregation of [module] not based on the [kernel]> with the [kernel] (or with a work based on the [kernel]) on a volume of > a storage or distribution medium does not bring the other work under > the scope of this License
except that you can't argue that a binary (compiled) module is NOT based on the kernel! it is really tied to it in all sorts of way (it contains code fromt he kernel, it was compiled using files from the kernel, it will only work for one specific compiled version of the kernel etc etc).
Think of it like this:
On the value of EXPORT_SYMBOL_GPL Posted Oct 6, 2005 21:46 UTC (Thu) by fenrus (guest, #31654) [Link] > Many Linux distributors bundle on their liveCD's and installers both Linux kernel and binary-only modules/firmwares, so this isn't an embedded-only phenomea.
please name one.. I'm looking for someone to sue to set a precedent for binary kernel modules and this sounds like an closed-and-shut case...
On the value of EXPORT_SYMBOL_GPL Posted Oct 7, 2005 9:37 UTC (Fri) by jschrod (subscriber, #1646) [Link] You want a distribution? Easy: SUSE and VMware.
While the source of the VMware kernel modules is distributed, it is not under an open-source license, but proprietary code.
In fact, each SUSE distribution has a package that's called kernel-nongpl. In 9.1, there were 22 non-GPL kernel modules.
Please note that for many professional users, VMware is a necessity. Luckily, Linux made clear that his opinion on binary-only kernel modules is different from yours.
So, will you now go forward and sue Novell? Good companionship you'll have.
Joachim.
On the value of EXPORT_SYMBOL_GPL Posted Oct 7, 2005 9:41 UTC (Fri) by fenrus (guest, #31654) [Link] > Luckily, Linus made clear that his opinion on binary-only kernel modules is different from yours.
Linus never said he considered binary only modules allowed. That's an urban myth he himself has defused many times.
On the value of EXPORT_SYMBOL_GPL Posted Oct 7, 2005 9:50 UTC (Fri) by jschrod (subscriber, #1646) [Link] No, you're wrong.Read the thread at http://kerneltrap.org/node/1735
Linus says that one has to look at each kernel module seperately and judge anew if it's a derived work or not.
You told, as far as I understood you, that all binary-only modules are by definition derived works. That is not Linus' opinion, as stated by me and proofed by the lkml thread above.
Joachim
On the value of EXPORT_SYMBOL_GPL Posted Oct 8, 2005 1:13 UTC (Sat) by fenrus (guest, #31654) [Link] you missed the point; this part of the thread isn't about derived works; it's about the "ship together" clause in the gpl which has nothing to do with "derived work" but with "being independent".
(and anyway linus didn't say binary modules are allowed, he said the derived work part is a case by case basis)
On the value of EXPORT_SYMBOL_GPL Posted Oct 8, 2005 11:57 UTC (Sat) by jschrod (subscriber, #1646) [Link] you missed the point; this part of the thread isn't about derived works; it's about the "ship together" clause in the gpl which has nothing to do with "derived work" but with "being independent".Ah, you mean you never reacted on nchip who wrote ``So it boils back to the "is the binary-only module derived from Linux" argument.'' and you never threatened to sue anybody who distributed a binary-only module because it would be ``a closed-and-shut case.''? Well, go forward, follow-up your strong words and sue Novell. (and anyway linus didn't say binary modules are allowed, he said the derived work part is a case by case basis)Exactly my words. Go back and read my post: I never wrote that Linus allows binary-only modules. I wrote that his opinion differs from yours in so far as distribution of binary-only modules are not a ``closed-and-shut case'' as you wrote. You just agreed to that and make it sound as if it was your opinion in the first place. Go figure, since that's your style of discussion, I'm out now. Joachim
On the value of EXPORT_SYMBOL_GPL Posted Oct 8, 2005 12:40 UTC (Sat) by dwmw2 (subscriber, #2063) [Link] Ah, you mean you never reacted on nchip who wrote ``So it boils back to the "is the binary-only module derived from Linux" argument.''Fenrus did respond to this. He made the analogy about glue -- highlighting the difference between two items which are each useful in their own right but which happen to be shipped together coincidentally, and two items which are fundamentally interdependent such that each cannot function without the other. That's basically the difference between a collective work and 'mere aggregation on a volume of a distribution medium', which nchip seemed to have missed. It seems as if nchip was taking 'mere aggregation' to include any kind of combined work, even when the parts are fundamentally interdependent.
On the value of EXPORT_SYMBOL_GPL Posted Oct 8, 2005 12:27 UTC (Sat) by dwmw2 (subscriber, #2063) [Link] So it boils back to the "is the binary-only module derived from Linux" argument.No. It boils back to a question of whether the resulting whole (including the kernel and the module in question) is a combined work, or whether it's mere aggregation on a volume of a storage or distribution medium. There can be a lot of ambiguity there -- but there are some cases where it's fairly obvious too. For example:
On the value of EXPORT_SYMBOL_GPL Posted Oct 6, 2005 13:28 UTC (Thu) by arafel (subscriber, #18557) [Link] Linux kernel copyright owners have also added an effective technological protection measure to ensure that the kernel's copyrighted code [...]Ingo, you've been reading way too many press releases...
On the value of EXPORT_SYMBOL_GPL Posted Oct 6, 2005 16:40 UTC (Thu) by jamesh (guest, #1159) [Link] He's just using the same terminology as found in laws like the DMCA. There is a real possibility that working around the GPL symbol protection mechanism would fall foul of the DMCA anti-circumvention provisions.
On the value of EXPORT_SYMBOL_GPL Posted Oct 6, 2005 15:02 UTC (Thu) by sepreece (subscriber, #19270) [Link] The core advice here is completely solid - if you're distributing a non-GPL kernel module you should definitely consult a lawyer. IANAL.
I'd like to bring in a couple of additional considerations.
It's important to remember that copyright covers only expression, not function. I would tend to think [IANAL!] that any exported interface would inherently be a functional aspect, not an expressive aspect, and hence not covered by copyright, no matter what restrictions you claimed for it. The abstraction-filtration-comparison method is supposed to make sure that simple functional equivalences can't be claimed.
HOWEVER, the important thing about the GPL is that it's what allows you to distribute all the rest of the kernel. So, if you don't play by the rules, which in a future version could conceivably include abiding by the EXPORT_SYMBOL_GPL rule, you could still lose the ability to distribute the kernel, whether or not your work was legally derivative. I think, though, that that would only be the case if the license explicitly stated that rule. Since the rules in the license today are based on whether your work is derivative, I think it would be hard to win a legal case, under the current license, based on that distinction.
In particular, I would think that the "shim" or "adaptation" approach mentioned in the article would be a reasonable defence under the current license language. Assuming the shim module connects to Linux-exposed interfaces on one side and provides non-Linux interfaces that a binary module needs on the other side, I think you would have a hard time claiming the binary module was a derived work of the kernel, even if the shim module itself was, especially if the [non-Linux] interfaces exposed by the shim to the binary module were preexisting interfaces from another operating system or environment.
Again, IANAL. I've read a lot about copyright law, but don't claim to be an expert. I also believe that it's good practice and good ethics to respect the intentions of the license, not just the language. However, that said, the function of an operating system is to provide an execution environment for stuff that is explicitly not part of the operating system, potentially including both user-space and kernel-space non-parts.
I would prefer to see the license drawn and interpreted so that it kept that distinction. I would prefer to see the license distinguish between changes to the kernel functionality (the code that provides the operating environment) and changes to things that run in the operating environment, The former changes being derivative works, the latter being simply uses of the system.
|
|||||||||||||