From: tytso@mit.edu (Theodore Y. Ts'o)
Newsgroups: comp.os.linux.development.system,comp.os.linux.misc,
	comp.os.linux.advocacy
Subject: Re: Linux should not support non-free modules
Date: 16 Oct 1998 21:22:09 -0400

   From: mettw@bowerbird.com.au (Matthew Parry)
   Crossposted-To: comp.os.linux.misc,comp.os.linux.advocacy

   1) The kernel is released under the GPL, so linking a module
   against the kernel is effectively the same as linking a
   program against a GPL'd library.  Therefore releasing non-free
   modules for linux is illegal.

It really depends on what is the definition of "linking".  One can
easily argue that a loadable kernel module which is using well-defined
kernel interfaces is no more "linking" to the kernel than what happens
when the kernel loads a user-program and interacts it with the
user-program using the system call interface.

This is one only of the big problems with FSF position that releasing
modules which link against GPL'ed code is illegal.  The definition of
"link" is not well-defined, and has no legal definition.  Linus Torvalds
has long ago stated that in his judgement, loadable kernel modules which
limit themselves to the interfaces defined in /proc/ksyms could be
distributed in binary-only form.  That's how the AFS client code is
distributed.  So there's a long precedence for this.

Consider the following --- what defines "link"?  Does an RPC call mean
linking?  What about shared libraries?  What about making calls via the
system call interface?  What about running GPL'ed programs via the
system() command from a commercial program?  If you take things to
extremes, a commercial program which uses the system() program will be
interfacing with the GPL'ed /bin/bash on most systems --- is that
considered "linking"?

And if not, what is the legal distinction between what /etc/ld.so does
when it maps a GPL'ed library into memory and the thread of control is
temporarily tranfered from propietary code to GPL'ed library code when a
library function is called, and what happens when a propietary program
calls system() and the kernel maps /bin/bash into system memory, and the
thread of control transfers temporarily from the propietary program to
/bin/bash?  You can see how things can get quite ridiculous quite
quickly.

Fortunately, the ambiguity of the word "link" isn't a real problem,
because the FSF's assertions aren't really grounded in any legal
reality.  Various legal professors have been quoted as saying that the
FSF would be "laughed out of court" if they tried to pursue this theory.
Copyright law has well-defined definitions of what "derivative works"
means, and code which happens to work against a specific interface
simply doesn't count.  (It's ironic that the FSF is against interface
copyrights, because this is really just another case of a claimed
interface copyright.)

If a company writes a driver completely from scratch, there's simply
no way that Copyright law can be used to stop the driver for
distributing the driver.  A driver (or any other software) which
happens to be useful when it somehow interfaces with GPL'ed code does
not become derived from the GPL'ed code.  It only becomes a Derived
Work if it contains some GPL'ed code itself.  Copyright law and the
GPL is quite clear on this point.  To quote from from the GPL itself:

>The "Program", below, refers to any such program or work, and a "work
>based on the Program" means either the Program or any derivative work
>under copyright law: that is to say, a work containing the Program or a
>portion of it, either verbatim or with modifications and/or translated
>into another language.

A driver which "links" with a program does not contain the Program or a
portion of it, and therefore is not a derived work.  As a copyright
owner, I can control what happens to derived work, but if it isn't a
derived work, I can't control what happens to it.

One could possibly argue that what the user does when she "links" the
driver with the Program results in a derived work.  (Similarly, when I
run a propietary program under Linux, the contents of memory at that
point might be considered a derived work --- a combination of the GPL'ed
kernel plus the propietary user-mode program.)  However, this derived
work exists only in memory, and the GPL only restricts Copying,
Distribution, and Modification.  The user is not actually copying or
distributing the memory image, but is simply using the derived work, and
that is always allowed:

>Activities other than copying, distribution and modification are not
>covered by this License; they are outside its scope.  The act of
>running the Program is not restricted....

So the FSF claims that code which "links" to GPL code itself must be
under the GPL is quite specious.  And as I've said earlier, various
professors of law have been quite incredulous at the FSF's legal
logic.  Copyright law simply doesn't work this way.

The FSF assertion also a very dangerous legal argument to make.  If this
is true, does this mean that if you write code which happens to make use
of interfaces developed by Microsoft and implemented by Microsoft DLL's,
that Microsoft somehow has a claim over your code which it could enforce
via copyright law?  What about any i386 assembly code which makes use of
the Intel machine language?  Does Intel now have a copyright claim on
all i386 object code, and can try to prevent people from executing i386
object code on non-Intel processors?  (After all, when a Pentium
interprets your object code, one could argue that it is "linking" your
object code with the Pentium microcode, which is copyrighted by
Intel....)

What the FSF is trying to advocate is one step down the slippery slope
of interface copyrights, and we really, really don't want to go there.

   2) By allowing companies to release non-free modules the development
   of free ones may lag or in some cases cease all together.

This is doubtful.  As I've pointed out before, it is almost certain that
native drivers will be faster than UDI drivers.

   a) You can rest assured that the companies will only
   release i386 drivers - or maybe even ones that won't
   run on 386/486 machines.

This is another reason why free drivers won't cease....

   b) With the kernel it is sometimes necessary to
   provide fixes as fast as possible.  With non-free
   drivers this will not be possible for those drivers.
   we'll have to wait for those companies to release
   a fix.

This will be yet another reason why free drivers won't cease, and why
hardware manufacturers which make it possible for people to write free
drivers will have an advantage in the Linux community.

                                            - Ted