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
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,
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
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.
to post comments)