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:

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:

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:

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.

---

to post comments