Re: Linux GPL and binary module exception clause?

["Theodore Ts'o" <tytso@mit.edu>]

On Fri, Dec 05, 2003 at 09:14:33PM -0800, Larry McVoy wrote:
> Your view that "(b) is compiled into a Linux kernel module, then it
> _is_ part of (a+b) whether (a) is physically present or not." is not
> something that I have managed to seen in any caselaw.  On the other hand,
> it is widely held that you can't force licenses across an API and it's
> perfectly reasonable to see the loadable module interface as an API.

Well, whether or not you can force licenses across an API is not well
settled, as far as I know (IANAL) Microsoft and Apple still have
licenses that try to claim ownership across API's.  And to the extent
that the FSF still tries to claim that programs written to use the GNU
readline library must fall under the GPL, when two other BSD-licensed
implementations of the readline interface exist, they are claiming
exactly the same thing (although the FSF has been known to call for
bycotts of companies that try to claim interfacde copyrights; heh).

Which brings up an interesting point.  The moment someone implements
BSD-licensed code which implements a particular interface, it very
strongly weakens the case that anyone implementing code to that
interface is a derived work of the GPL'ed interface.  This is one of
the reasons why claiming that the GPL can infect across an interface
(whether it is a module interface, a system call interface, or
dynamically linked shared library interface) is bizarre at best.

For example, let me give the following example.  Debugfs of the
e2fsprogs library uses libss, which I recently enhanced to attempt to
dynamically load one of the following libraries via dlopen: readline
(GPL'ed), editline (BSD licensed), or libedit (BSD licensed), which
all export the same interface.  Libss dates back to 1985 or so, and
has a BSD-style license.  It is also used in Kerberos V5 (which is
also BSD licensed), and so Solaris has a propietary derived version of
Krb5 whose administration client uses libss.  So if you compile the
latest version of e2fsprogs on Solaris, and Solaris' krb5 admin client
manages to use the new version of libss, then you could potentially
have in the single address space:

	* Solaris's propietary admin client
	* The libss shared library (BSD)
	* The GPL'ed readline library

OK, riddle me this: is there a GPL violation, and if so, who committed
it?  The user, for running the admin client in this configuration?
But the GPL explicitly says that it's only about distribution, and
doesn't restrict usage in any way, and the end-user is only using the
code.  

Solaris, the owner of the propietary admin client?  But they weren't
involved in my enhancing the libss shared library to dynamically load
either a GPL'ed or a BSD-licensed library, and they created the admin
client before I added the libss enhancement.  And heck, the original
admin client was created by me while I was working at MIT, and is part
of the original MIT Kerberos V5 disitribution (although Sun has
modified it extensively since then).

Me, for modifying a BSD-licensed library to try to dynamically load a
GPL'ed library?  But I was trying to make a perfectly legitimate stack
work:

	* Debugfs (which is GPL'ed)
	* The libss shared library (BSD)
	* The GPL'ed readline library

and the reason why I used dynamic linking was because I wanted debugfs
to only optionally depend on readline library, since the readline
library is a monster (over 600k) and so it wouldn't fit on a rescue
floppy.

So trust me, you really don't want to claim that just because a
program was written to use a particular interface, the license infects
across the API.  Apple and Microsoft are playing that game, and a very
unsavory game it is.  And it leads to all sorts of paradoxes, such as
the one I described above.

						- Ted