User: Password:
|
|
Subscribe / Log in / New account

On the value of EXPORT_SYMBOL_GPL

On the value of EXPORT_SYMBOL_GPL

Posted 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.

But when you distribute those same [modules] as part of a whole which is a work based on the [kernel], the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the [kernel]

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:

  • A tarball containing both Linux-specific GPL'd 'wrapper' code and also binary blob or 'HAL'
  • Firmware for an embedded Linux device, containing both the kernel itself and also some Ethernet driver modules
In each of these cases, the fact that the binary blob is distributed as part of a larger whole is very important, despite the fact that in itself it isn't a derived work. The binary blob is still covered by the GPL, because of the nature of the distribution.

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 (guest, #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 (guest, #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]
> 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.

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).
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 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:

  • 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.

On the value of EXPORT_SYMBOL_GPL

Posted Oct 6, 2005 13:28 UTC (Thu) by arafel (guest, #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 (guest, #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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds