Date Sat, 6 Dec 2003 10:38:45 -0500 From Theodore Ts'o <> Subject Re: Linux GPL and binary module exception clause? 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

-

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at http://vger.kernel.org/majordomo-info.html

Please read the FAQ at http://www.tux.org/lkml/



