Recent Features
| |||||||||||||
On the value of EXPORT_SYMBOL_GPLOn the value of EXPORT_SYMBOL_GPLPosted Oct 6, 2005 11:38 UTC (Thu) by dwmw2 (subscriber, #2063)In reply to: On the value of EXPORT_SYMBOL_GPL by mingo Parent article: On the value of EXPORT_SYMBOL_GPL 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.
(Log in to post comments)
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:
|
|||||||||||||