On the value of EXPORT_SYMBOL

On the value of EXPORT_SYMBOL_GPL

Posted Oct 6, 2005 17:46 UTC (Thu) by nchip (guest, #13292)
In reply to: On the value of EXPORT_SYMBOL_GPL by dwmw2
Parent article: On the value of EXPORT_SYMBOL_GPL

>> 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]
> 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

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.

(Log in to post comments)

On the value of EXPORT_SYMBOL_GPL

Posted Oct 6, 2005 21:45 UTC (Thu) by fenrus (guest, #31654) [Link]

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).
Or in other words, it's not mere aggregation!

Think of it like this:
You can buy 2-component glue that has 2 tubes, and to make it stick you combine both during use, or you can buy a pack of 2 superglue tubes that each is useful on its own. The later is "mere aggregation" of two separately useful bits, the former is not. THe kernel+module case is the former, 2 apps on a distro cd is the later.

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:

In the case where a computer magazine happens to include a bunch of gratis software and/or shareware on a cover CD, and some of it happens to be GPL'd while other parts are not, that would clearly be 'mere aggregation on a volume of a distribution medium'
On the other hand, in the case where the firmware for an embedded router device contains both a Linux kernel and some binary-only network driver modules, and the device cannot perform its intended function if either of those integral parts of its software is removed, that's equally clearly a combined work and not 'mere aggregation on a volume of a storage medium'
When a Linux driver is shipped in the form of GPL'd wrapper code and a binary-only object, those two parts are fundamentally interdependent. It isn't merely coincidence that they're both present in the tarball you download. It would be very hard to argue that it's "mere aggregation on a volume of a distribution medium" rather than being a complete work made up of those two parts.

The case of a Linux distribution is an interesting one. Not so much because of the kernel, which makes an explicit exception for userspace, but because of GPL'd userspace software. If it's 'mere aggregation on a distribution medium' then that's fine -- it can include both GPL'd and non-GPL'd software (like Apache). However, if the distributors are explicitly claiming a copyright on the distribution itself as a combined work, that would seem to be problematic.