[lkml]   [2003]   [Dec]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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

    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

    * 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

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:59    [W:0.028 / U:56.832 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site