Messages in this thread | | | 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/
| |