Re: Linux GPL and binary module exception clause?

From: Linus Torvalds (torvalds_at_osdl.org)
Date: 12/04/03

  • Next message: Fredrik Tolf: "Why is hotplug a kernel helper?" 
    Date:	Wed, 3 Dec 2003 16:00:21 -0800 (PST)
To: Kendall Bennett <KendallB@scitechsoft.com>

    On Wed, 3 Dec 2003, Kendall Bennett wrote:
    >
    > I have heard many people reference the fact that the although the Linux
    > Kernel is under the GNU GPL license, that the code is licensed with an
    > exception clause that says binary loadable modules do not have to be
    > under the GPL.

    Nope. No such exception exists.

    There's a clarification that user-space programs that use the standard
    system call interfaces aren't considered derived works, but even that
    isn't an "exception" - it's just a statement of a border of what is
    clearly considered a "derived work". User programs are _clearly_ not
    derived works of the kernel, and as such whatever the kernel license is
    just doesn't matter.

    And in fact, when it comes to modules, the GPL issue is exactly the same.
    The kernel _is_ GPL. No ifs, buts and maybe's about it. As a result,
    anything that is a derived work has to be GPL'd. It's that simple.

    Now, the "derived work" issue in copyright law is the only thing that
    leads to any gray areas. There are areas that are not gray at all: user
    space is clearly not a derived work, while kernel patches clearly _are_
    derived works.

    But one gray area in particular is something like a driver that was
    originally written for another operating system (ie clearly not a derived
    work of Linux in origin). At exactly what point does it become a derived
    work of the kernel (and thus fall under the GPL)?

    THAT is a gray area, and _that_ is the area where I personally believe
    that some modules may be considered to not be derived works simply because
    they weren't designed for Linux and don't depend on any special Linux
    behaviour.

    Basically:
     - anything that was written with Linux in mind (whether it then _also_
       works on other operating systems or not) is clearly partially a derived
       work.
     - anything that has knowledge of and plays with fundamental internal
       Linux behaviour is clearly a derived work. If you need to muck around
       with core code, you're derived, no question about it.

    Historically, there's been things like the original Andrew filesystem
    module: a standard filesystem that really wasn't written for Linux in the
    first place, and just implements a UNIX filesystem. Is that derived just
    because it got ported to Linux that had a reasonably similar VFS interface
    to what other UNIXes did? Personally, I didn't feel that I could make that
    judgment call. Maybe it was, maybe it wasn't, but it clearly is a gray
    area.

    Personally, I think that case wasn't a derived work, and I was willing to
    tell the AFS guys so.

    Does that mean that any kernel module is automatically not a derived work?
    HELL NO! It has nothing to do with modules per se, except that non-modules
    clearly are derived works (if they are so central to the kenrel that you
    can't load them as a module, they are clearly derived works just by virtue
    of being very intimate - and because the GPL expressly mentions linking).

    So being a module is not a sign of not being a derived work. It's just
    one sign that _maybe_ it might have other arguments for why it isn't
    derived.

                    Linus
    -
    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/

  • Next message: Fredrik Tolf: "Why is hotplug a kernel helper?"

    Relevant Pages

    • [OT] Re: Is sharpzdc_cs.o not a derivitive work of Linux?
      ... If Linux does things in a sufficiently different way than other ... not a derived work of Linux". ... if the Linux developers are faced with a module like ... If you have a copyright interest in the Linux kernel, ...
      (Linux-Kernel)
    • RE: GPL vs non-GPL device drivers
      ... people claim that any driver written for Linux will ... modules that the interface between the module and the kernel is quite ... derived work for the purposes of the Linux kernel license. ...
      (Linux-Kernel)
    • Re: Why is Fedora not a Free GNU/Linux distributions?
      ... Neither will anyone seeing the other in numerous statements made by Linus I have referred to. ... a standard filesystem that really wasn't written for Linux in the first place, and just implements a UNIX filesystem. ... Personally, I think that case wasn't a derived work, and I was willing to tell the AFS guys so. ... Does that mean that any kernel module is automatically not a derived work? ...
      (Fedora)
    • Re: Why is Fedora not a Free GNU/Linux distributions?
      ... ZFS was included in FreeBSD 7.0 because the BSD license is more free than the GPL with that regard. ... merged in the upstream kernel. ... THAT is a gray area, and _that_ is the area where I personally believe ... they weren't designed for Linux and don't depend on any special Linux ...
      (Fedora)
    • Re: GPL vs non-GPL device drivers
      ... Linus is not in any position to do anything. ... Does combining your work with Linux create a derived work. ... If someone who owns copyright in part of the Linux kernel that you ...
      (Linux-Kernel)