Weekly Edition
Return to the Kernel page
| |||||||||||
|
| |||||||||||
Binary modules and derived works
This week's Front Page contains an interview
with a lawyer on the issue of what makes one program a derived work of
another. That topic has also been prominent on the linux-kernel mailing
list recently as part of the never-ending debate over the status of
closed-source kernel modules. Unusually, Linus Torvalds has taken an
active part in the discussion this time around. Linus does not have the
last word on this issue - his copyrights only cover a small part of the
kernel code base - but his thoughts are influential in this regard and can
be taken as a sort of guidance for anybody who is considering distributing
a binary module.
It is reasonably widely accepted that a program which simply uses a well-documented API does not become a derived work of the code implementing that API. The obvious application of this principle is the kernel's system call interface. That interface is an API (and ABI as well) which, to a great extent, conforms to a well-documented standard, and which is meant to be stable over time. The COPYING file supplied with the kernel explicitly states that programs using the system call interface are not considered to be derived works, but, according to Linus, that statement is not strictly necessary:
In other words: even without that disclaimer of derivation, user
space would almost certainly (with a very high probability indeed)
be safe from a copyright infringement suit. Such a suit would most
likely be thrown out very early, exactly because the UNIX system
call interface is clearly extensively documented, and the Linux
implementation of it has strived to be a stable ABI for a long
time.
Of course, there are differences of opinion. Thus, as Ted Ts'o points out, the FSF claims that users of the readline library must be licensed under the GPL, even though there are two BSD-licensed implementations of the same stable, well-documented API. But let us accept, for the moment, that this sort of API does, in fact, create a boundary for derived works. A fundamental question that some developers have raised is: what is different about the interface used by kernel modules? Several developers have argued that the module interface is a boundary in just the same way as the system call interface. Linus's response is that the module interface is, indeed, different:
But when you have the GPL, and you have documented for years and
years that it is NOT a stable API, and that it is NOT a boundary
for the license and that you do NOT get an automatic waiver when
you compile against this boundary, then things are different.
He go on to explain, in fairly graphic and non-technical terms, that the stated intent of the interface matters, even if the technical steps involved in using it are the same. The module interface is not a boundary because the copyright holders never intended it to be one. One can go further and say that the module interface is truly not an API in the usual sense. It is, indeed, highly volatile, and has been known to change even in the middle of a stable kernel series. The module interface provides extensive access to low-level kernel functionality, often solely for the convenience of other in-tree kernel code. Code which makes use of many exported symbols is clearly Linux-specific. Some exported symbols are so low-level that the kernel developers have concluded that no code can use them without being a derived product; that is why EXPORT_SYMBOL_GPL() exists. But, as Linus notes, EXPORT_SYMBOL_GPL() should be seen as a form of documentation in specific cases; its existence does not imply that modules restricting themselves to non-GPL-only symbols are automatically not derived. The crucial test, as seen by Linus, is whether a particular module was implemented independently of Linux. Code ported from another system (such as the Andrew filesystem) is a fairly obvious example. Device drivers are generally seen as being independent as well. Before going any further, though, distributors of closed-source modules should consider one other thing that Linus said:
So in order for nVidia to be able to legally distribute a
binary-only kernel module, they have to be able to feel damn sure
that they can explain (in a court of law, if necessary) that the
module isn't a derived work. Enough to convince a judge. That's
really all that matters. Our blathering matters not at all.
Until a court makes a ruling, nobody really knows what the law really says. Even then, as Dan Ravicher told us, the ruling will only hold in the geographical area covered by that particular court. There are no clear answers to this question. The ambiguous legal state of closed-source modules may suit some developers who want to discourage them strongly without trying to ban them outright. But it is not beneficial for the Linux community as a whole. We really do not need more messy court cases; we have better things to do with our time and energy. As LWN has said before, it would be in the community's interest to clarify the situation and make the boundary clear. One possible step in that direction was suggested by Al Viro. He has pointed out in the past that the module interface is a mess which could do with some cleaning up. Now he suggests looking at who actually uses each exported symbol and thinking about whether that symbol should really be made available to modules or not. There are, as he points out, over 7500 EXPORT_SYMBOL() declarations in the 2.6 kernel; seemingly, only about half of them are used by in-tree modules. A lot of these symbols, Al suggests, could probably go away altogether. Others could be explicitly exported only to certain modules with a clear need to use them - though the mechanism to restrict exports in this manner does not yet exist. An effort to clean up the list of exported symbols could, eventually, lead to some clarity in the legal status of the users of those symbols. The export list could be trimmed down to a point where most observers could see it as a somewhat well-defined programming interface. At that point, maybe most developers might be able to agree on a subset that binary-only modules could safely use. The benefits of this agreement would be significant. There would be one minor disadvantage in that the kernel developers would have to find something else to argue about. One suspects that they are probably up to the task, however. (Log in to post comments)
Binary modules and derived works Posted Dec 11, 2003 15:15 UTC (Thu) by zone (guest, #3633) [Link] Restricting the symbols that are available to binary modules would effect modules such as NVidia's that are distributed as binary modules meant to be used with standard distributor kernels. However, for Linux-based appliances, which symbols are available in the mainline kernel might be a non-issue. An appliance manufacturer could just apply EXPORT_SYMBOL() to every symbol in the kernel that they needed, release their changes under the GPL, and then create a binary module that uses their newly created interface. Some kernel developers might cry foul, but the GPL protects the right of the appliance manufacturer to create a derived work, and deciding which symbols to export to binary modules could definitely be seen as a valid technical change.
Binary modules and derived works Posted Dec 11, 2003 18:30 UTC (Thu) by maolson (subscriber, #4077) [Link] The problem with your example, as I see it, is that having enough exposure to the kernel source to create the exports strongly suggests that the binary module would be a derived work. To understand which new exports would be needed, the person creating them would need to be intimately familiar with GPL'd code and would be working from that knowledge when creating the hypothetical binary module.
Binary modules and derived works Posted Dec 11, 2003 15:29 UTC (Thu) by kreutzm (subscriber, #4700) [Link] Looking from the user side, I don't see the advantage you imply at the end of your article. If I happen to have the wrong kernel version (e.g. 2.6/2.2) or even worse the wrong architecture (3D with nvidia on non-x86) or the module simply does not work as advertised - I am busted. I'd rather see the vendor supplying source and some precompiled modules as service than some semitechnical means to calm down the debate.
Binary modules and derived works Posted Dec 11, 2003 15:35 UTC (Thu) by corbet (editor, #1) [Link] Free drivers with source are obviously the right solution; I didn't really see any point in even mentioning that. That's the only kind of driver I'm interested in running on my systems. But there will always be code that, for whatever reason, will not be licensed that way. I don't believe I've ever said "make life easy for closed-source modules" or any such. What I am saying is that ambiguity helps nobody. It would be best if people simply knew what is, or is not, allowed.
Binary modules and derived works Posted Dec 11, 2003 17:31 UTC (Thu) by elanthis (subscriber, #6227) [Link] Unfortunately, with a changing API even in stable kernel series, Open Source or Free drivers are still just as much of a pain in the arse to end users.End users don't upgrade kernels. They don't even know a kernel is. They don't *want* to know what a kernel is. They just want to slap in the new whizbang thingie they bought, load a driver, and have it work. If it's assumed that all drivers will be distributed with a kernel, and that users of older versions of the kernel without the driver must upgrade, the system will not work for these users. But, even if the distributor of the hardware supplied drivers, it's still very, very likely the driver won't build. Even if we toss ABI compatibility out the window, a *true* solid API is needed. One that will not change, *ever*, for 90% of driver needs. The API can of course be versioned, so that newer/better APIs can be added, but every kernel neesd to (perhaps only optionally) support the older APIs as well, to guarantee that modules released before the current kernel version can be compiled and installed. Because these APIs would be intended for non-mainline modules, it's quite feasible to make them abstract and high-level, and thus perhaps slower, in order to make it very easy to keep them frozen solid, but let the underlying implementation change.
Binary modules and derived works Posted Dec 11, 2003 16:55 UTC (Thu) by zmower (subscriber, #3005) [Link] Linus also said about NVidia "I think the NVidia people can probably reasonably honestly say that the code they ported had _no_ Linux origin."NVidia's "Linux Advantage" document (off their website) says "Allows NVIDIA to easily support numerous operating systems - 95% of all code base is shared between all operating systems". Sounds to me (but IANAL) like the NVidia binary modules are not derived works and thus legal (if not moral from a Free Software perspective).
Binary modules and derived works Posted Dec 11, 2003 17:55 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] Ted T'so is, I think, incorrect about the FSF's opinion on GPL'ed libraries where alternative implementations exist (I assume you're interpreting what he said accurately). We had this fight a few years ago, when GMP (the GNU arbitrary-precision math library) was under the GPL. Someone distributed patches to make RSA's RIPEM work with GMP, which was much faster than the math routines RIPEM contained. The FSF objected that this was a license violation. People objected that the FSF was claiming a user interface copyright. The FSF denied this, saying that the new code could work with nothing but GMP and was therefore a derivative work of GMP. There were some troubling aspects to the FSF's position, as they were in essence objecting to the distribution of a rather small patch, which in itself did not contain any of their code. Someone whacked together something called FGMP, which provided the same interface as GMP for the subset of routines used by the patched RIPEM. RMS agreed that, under the changed circumstances, he could no longer claim that the patched RIPEM was a derivative work of GMP -- even though FGMP was far inferior to GMP in performance terms, meaning that no one would really use it. In the end, the FSF changed the license of GMP to the LGPL to end that fight. Now, in the readline case, I'm not sure what the facts are, but it would seem that the FSF would need to back off if there truly are complete BSD-licensed readline implementations. And if so, they probably will; generally, their goal has been to use the GPL to leverage the creation of more free software, and they've used less restrictive licensing for libraries that implement standards or where competing implementations exist.
Law of Conservation of Argument Posted Dec 12, 2003 23:51 UTC (Fri) by wa1hco (subscriber, #3628) [Link] ... There would be one minor disadvantage in that the kernel developers would have to find something else to argue about. One suspects that they are probably up to the task, however.Ah! The law of conservation of arguement rediscovered again!
Binary modules and derived works Posted Dec 13, 2003 20:12 UTC (Sat) by giraffedata (subscriber, #1954) [Link] There's an underlying implication in this article that a program might be a derived work of the Linux kernel if it uses the Linux kernel in some way. There's absolutely nothing in the definition of derived work even to suggest that.The binary module/derived work question is whether a package that contains both the Linux kernel and a binary loadable kernel module is a derived work of the Linux kernel. If it is, then the package cannot be distributed except according the terms of the Linux kernel license, which means in particular that you have to make the source code for that binary module available. There's also a separate binary module/derived work question that wasn't mentioned here: Some people believe that in creating the binary module, you may be copying the Linux kernel because 1) you may be #including .h files from the Linux kernel, and 2) you may be copying example code from the Linux kernel, since it's the only way you could figure out how to use the LKM interface.
|
|||||||||||