On the value of EXPORT_SYMBOL_GPL
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. The module loader will enforce this distinction by denying access to GPL-only symbols if the module's declared license does not pass muster. Currently, less that 10% of the kernel's symbols are GPL-only, but the number of GPL-only symbols is growing. There is a certain amount of pressure to make new exports GPL-only in many cases.
It has often been argued that there is no practical difference between the two types of exports. Those who believe that all kernel modules are required by the kernel license to be GPL-licensed see all symbols as being implicitly GPL-only in any case. Another camp, which sees the module interface as a boundary which the GPL cannot cross, does not believe that GPL-only restrictions can be made to stick. In any case, GPL-only symbols can be easily circumvented by patching the kernel, falsely declaring a GPL-compatible license, or by inserting a shim module which provides wider access to the symbols of interest.
Linus, however, believes that GPL-only exports are significant.
The fact is, the law isn't a blind and mindless computer that takes what you say literally. Intent matters a LOT. And using the xxx_GPL() version to show that it's an internal interface is very meaningful indeed.
One of the lawyers said that it was a much better approach than trying to make the license explain all the details - codifying the intention in the code itself is not only more flexible, but a lot less likely to be misunderstood.
He also points out that circumventing a GPL-only export requires an explicit action, making it clear that the resulting copyright infringement was a deliberate act.
Regardless of any legal significance they may have, the GPL-only exports do succeed in
communicating the will of the large subset of the kernel development
community which wants to restrict the use of non-free kernel modules. The
outright banning of such modules may not be on the agenda anytime soon, but
the functionality available to them is not likely to grow much.
| Index entries for this article | |
|---|---|
| Kernel | Copyright issues |
| Kernel | EXPORT_SYMBOL_GPL |
| Kernel | Modules/Licensing |
Posted Oct 6, 2005 5:39 UTC (Thu)
by zlynx (guest, #2285)
[Link] (6 responses)
The *end user* of any GPL software has been granted a right to modify it. That means the end user is perfectly free to sed every EXPORT_SYMBOL_GPL into EXPORT_SYMBOL if they like.
If this lets them use their favorite binary-only module with the newest kernels, they'll do it. I've done such things in order to get -mm or -rc kernels working with VMware or nVidia.
It's even doubtful that there's any restriction on changing _GPL exports to non _GPL exports or adding new exports. There's no magic EXPORT_SYMBOL fairy, so who gets to decide?
Even if that wasn't kosher, you could just write a GPL kernel module that marshalled kernel calls to user space through some kind of RPC ioctl, filesystem or netlink socket. Call it an experiment in micro-kernel message passing.
EXPORT_SYMBOL_GPL works okay as long as both the kernel devs and proprietary vendors stay polite. If the proprietary guys get too obviously evil, someone will smack them. On the other hand, if the kernel devs go too crazy with spreading the _GPL around, people will just ignore it and dare a court case.
Posted Oct 6, 2005 7:37 UTC (Thu)
by lacostej (guest, #2760)
[Link] (4 responses)
Because of that companies won't be able to use these exports except by cheating and making their module described as GPL. It's been done before. But Linux believes that this technical restriction is sufficient to protect Linux from these kinds of cheating. I agree with him.
Posted Oct 6, 2005 8:04 UTC (Thu)
by mingo (guest, #31122)
[Link] (3 responses)
so the rule here too is "if you want to do that, talk to your lawyer".
Posted Oct 6, 2005 15:46 UTC (Thu)
by zlynx (guest, #2285)
[Link]
Posted Oct 6, 2005 15:50 UTC (Thu)
by dmarti (subscriber, #11625)
[Link] (1 responses)
Oh, and just in case the interfaces you're depending on ever change, better keep that lawyer on retainer.
About 20% of people who use Linux in business don't consider the driver license when buying hardware.
About 20% will not use a proprietary driver on Linux, period.
About 60% take the license of the driver into account in some way -- won't buy hardware if there's competing hardware with a GPL driver, won't use a proprietary driver unless their distribution commits to supporting it, or just use licensing as one of several factors when considering hardware.
Posted Oct 14, 2005 4:29 UTC (Fri)
by turpie (guest, #5219)
[Link]
Posted Oct 6, 2005 8:08 UTC (Thu)
by fenrus (guest, #31654)
[Link]
proprietary vendors will generally be careful to not say "change your kernel in this way to run this module" since that opens them up to "you're a derived work" claims (it's really hard to claim you're independent if you require changes in the other thing to work after all, especially if you have to document them and maybe even provide a patch), and the smart ones at least will have lawyers that tell them not to do it.
There are dumb ones out there of course and it's thus almost inevitable that a lawsuit is going to happen in the next year or two.
Posted Oct 6, 2005 8:00 UTC (Thu)
by mingo (guest, #31122)
[Link] (17 responses)
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.)
Posted Oct 6, 2005 11:38 UTC (Thu)
by dwmw2 (subscriber, #2063)
[Link] (13 responses)
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]
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.
Posted Oct 6, 2005 14:32 UTC (Thu)
by sepreece (guest, #19270)
[Link] (2 responses)
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.
Posted Oct 6, 2005 15:01 UTC (Thu)
by dwmw2 (subscriber, #2063)
[Link] (1 responses)
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.
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).
Posted Oct 6, 2005 17:46 UTC (Thu)
by nchip (guest, #13292)
[Link] (9 responses)
> 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.
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).
Think of it like this:
Posted Oct 6, 2005 21:46 UTC (Thu)
by fenrus (guest, #31654)
[Link] (6 responses)
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...
Posted Oct 7, 2005 9:37 UTC (Fri)
by jschrod (subscriber, #1646)
[Link] (5 responses)
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.
Posted Oct 7, 2005 9:41 UTC (Fri)
by fenrus (guest, #31654)
[Link] (4 responses)
Linus never said he considered binary only modules allowed. That's an urban myth he himself has defused many times.
Posted Oct 7, 2005 9:50 UTC (Fri)
by jschrod (subscriber, #1646)
[Link] (3 responses)
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
Posted Oct 8, 2005 1:13 UTC (Sat)
by fenrus (guest, #31654)
[Link] (2 responses)
(and anyway linus didn't say binary modules are allowed, he said the derived work part is a case by case basis)
Posted Oct 8, 2005 11:57 UTC (Sat)
by jschrod (subscriber, #1646)
[Link] (1 responses)
Joachim
Posted Oct 8, 2005 12:40 UTC (Sat)
by dwmw2 (subscriber, #2063)
[Link]
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.
Posted Oct 8, 2005 12:27 UTC (Sat)
by dwmw2 (subscriber, #2063)
[Link]
There can be a lot of ambiguity there -- but there are some cases where it's fairly obvious too. For example:
Posted Oct 6, 2005 13:28 UTC (Thu)
by arafel (subscriber, #18557)
[Link] (1 responses)
Ingo, you've been reading way too many press releases...
Posted Oct 6, 2005 16:40 UTC (Thu)
by jamesh (guest, #1159)
[Link]
Posted Oct 6, 2005 15:02 UTC (Thu)
by sepreece (guest, #19270)
[Link]
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.
Posted Oct 6, 2005 15:52 UTC (Thu)
by ccyoung (guest, #16340)
[Link] (1 responses)
1. is there a one sentence summary of the problem?
2. is it a problem now or anticipated?
3. is this a heavy handed attempt to get others to play fair in the sandbox?
Posted Oct 7, 2005 18:45 UTC (Fri)
by giraffedata (guest, #1954)
[Link]
I presume the mods you mean are the ones that created EXPORT_GPL_ONLY many years ago.
A one sentence summary of the problem would be close to useless, since it is a very complex legal and social problem. But here's my attempt:
People can exploit the open source, free Linux kernel and not contribute back by open sourcing their own code.
Now bear in mind what is said in the article: Many people believe "the mods" don't make this less of a problem. There are some fairly complex legal arguments on either side.
For those who believe it's a problem, it is a problem now and they anticipate it getting bigger in the future. People are shipping binary-only kernel modules today and as the Linux kernel grows, they'll ship even more, exploiting even more open source code, in the future.
It doesn't seem heavy handed to me, but it is an attempt to get others to play fair in the sandbox.
The _GPL exports don't really prevent anything, legally or technically.On the value of EXPORT_SYMBOL_GPL
Yes but I don't see Joe Lambda recompile his kernel. In the majority of the cases, it's up to the kernel distributors, i.e. the Linux distributions. I don't see why those ones would revert the GPL friendly symbols.On the value of EXPORT_SYMBOL_GPL
if someone modifies those symbol exports (even if not using the binary-only module), with the intent to enable the use of binary-only modules by third parties, they are potentially involved in contributory copyright infringement.On the value of EXPORT_SYMBOL_GPL
If the vendor does it, it's probably some sort of infringement. However, if they just keep publishing their module with a note "Works with Linux Kernel 2.6.11 and earlier.", they're fine. If someone _else_ creates a kernel patch to allow that module to run on 2.6.17, the vendor isn't responsible, and I don't really see how you could convince a court that a 3rd party unrelated to the vendor is infringing anything by modifying code when that 3rd party has a license granting him an explicit right to modify the code.On the value of EXPORT_SYMBOL_GPL
Talk to your lawyer -- and build your own software testing and distribution infrastructure, and hire full-time testers because you don't know when the next kernel, or a distribution's kernel, is going to break your driver, and basically do the whole driver as a full-blown independent proprietary software product -- only it's a "product" that will make you no money.On the value of EXPORT_SYMBOL_GPL
"Oh, people can come up with statistics to prove anything, Kent. 14% of people know that." - Homer Simpson.On the value of EXPORT_SYMBOL_GPL
> EXPORT_SYMBOL_GPL works okay as long as both the kernel devs and proprietary vendors stay polite.On the value of EXPORT_SYMBOL_GPL
On the value of EXPORT_SYMBOL_GPL
Ingo writes: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: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.
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.
IANAL as well, so this is, of course, speculation, but...On the value of EXPORT_SYMBOL_GPL
On the value of EXPORT_SYMBOL_GPL
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.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!On the value of EXPORT_SYMBOL_GPL
> 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
> In addition, mere aggregation of [module] not based on the [kernel]On the value of EXPORT_SYMBOL_GPL
> 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
Or in other words, it's not mere aggregation!
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.
> 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
You want a distribution? Easy: SUSE and VMware.On the value of EXPORT_SYMBOL_GPL
> Luckily, Linus made clear that his opinion on binary-only kernel modules is different from yours.On the value of EXPORT_SYMBOL_GPL
No, you're wrong.On the value of EXPORT_SYMBOL_GPL
Read the thread at http://kerneltrap.org/node/1735
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".On the value of EXPORT_SYMBOL_GPL
On the value of EXPORT_SYMBOL_GPL
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.
On the value of EXPORT_SYMBOL_GPL
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.On the value of EXPORT_SYMBOL_GPL
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.
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.
Linux kernel copyright owners have also added an effective technological protection measure to ensure that the kernel's copyrighted code [...]
On the value of EXPORT_SYMBOL_GPL
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
The core advice here is completely solid - if you're distributing a non-GPL kernel module you should definitely consult a lawyer. IANAL.On the value of EXPORT_SYMBOL_GPL
obviously these mods are to fix a problem.the problem please
the problem please
obviously these mods are to fix a problem.
1. is there a one sentence summary of the problem?
2. is it a problem now or anticipated?
3. is this a heavy handed attempt to get others to play fair in the sandbox?