[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 Sat, Dec 06, 2003 at 09:13:00AM -0500, Andrew Pimlott wrote:
    > On Fri, Dec 05, 2003 at 07:00:37PM -0800, Larry McVoy wrote:
    > This last is unfounded. It may be true to say that Sun could only
    > release Solaris+XYZ under the GPL, but it is fantasy to imagine that
    > this makes Solaris now GPLed.

    Right you are, my apologies. My brain was in contract space, not
    copyright space.

    > and--where appropriate--attorneys' fees. A defendant found to
    > have wrongfully included GPL'd code in its own proprietary work
    > can be mulcted in damages for the distribution that has already
    > occurred, and prevented from distributing its product further.
    > That's a sufficient disincentive to make wrongful use of GPL'd
    > program code. And it is all that the Copyright Act permits.
    > (At first, I had hoped that "mulcted" was a typo for "mulched", but
    > then I looked it up.)

    I did too, for those who didn't, it's an old word with two meanings and
    the meaning here (I am pretty sure) is "punished with a fine". Leave it
    to a lawyer to know that one :)

    > It might be true that Sun's misdeed perpetually voids their license
    > to XYZ.

    That's a good question, it's not clear what the answer to that is. I reread
    the GPL and I don't see where it spells out what happens if you try and cheat.

    > > Roll forward a bit and see how this plays out in court. Suppose there is
    > > code in Linux that is derived from Unix. Remember, if Unix licenses had
    > > the same viral effect as the GPL, all it takes is a function or two and
    > > the rest of the code is GPL-ed (or in this case, Unix-ed). If you are
    > > arguing that an API isn't a boundary for the GPL you are going to look
    > > bloody two faced when you go and argue that an API is a boundary for Unix.
    > Your comparisons to the SCO case are far-fetched. In part because
    > of what I said above (your idea of "viral" is divorced from
    > reality)

    In copyright law, yes. Contract law is a bit different. Linus and
    you yanked me back into copyright law and you're right that SCO can't
    claim rights to Linux, they don't own it. But isn't it true that if
    the Unix license they have with IBM (actually more likely Sequent) is a
    contract then that contract could extend to anything that was originally
    written in the context of Unix, even if 100% of was written by Sequent
    and removed from Unix and ported to Linux?

    If I wrote a contract that gave you rights to use and extend some program
    I wrote and I put into that contract that you may not distribute any code
    that was written as part of the program to a third party that did not have
    a license, isn't that legal?

    And if it is, which I believe to be true, and if you wrote a new widget
    that was originally done in the context of that program but now wanted
    to put that widget someplace else and the widget removed all references
    to the original program, do I still have any contractially based rights
    to that widget? This is the crucial question for SCO. I doubt that
    the answer is really simple but I think that the answer has a lot to do
    with the concept of a boundary which is why I keep harping on that.

    > You seem to think that this boundary thing is black and white. "If
    > the GPL crosses the kernel-module boundary, any license can cross
    > any boundary." I think you have to do better than that.

    Nothing in law is black and white, it's all sorted out in caselaw
    typically. But as far as I can tell there has to be some way to limit
    the influence of a contract or a license or otherwise everything that
    ran on a GPLed kernel would be GPLed (the HURD is a GPLed kernel, right?
    How much you want to bet that the FSF is not going to try and make the
    claim that userland has to be GPLed?)

    My guess is that at some point there will be a court case that clarifies
    fair use for code and the clarification will be focussed on the concept
    of a boundary with the definition of the boundary being the ability to
    replace one section of the program with a different work, said work not
    be derived from the program, and have the program continue to operate
    as it did before. I.e., a different userland implementation of "cat"
    shows that the kernel can't infect userland, a different implementation
    of shows that libc can't infect user programs.

    The sticky one is the one where we started, kernel modules. Linus is
    saying that kernel modules are covered by the GPL because they are
    combined with the kernel. I think his reasoning is weak and unlikely
    to be upheld by the courts. If we remove the issue of inline functions
    for a moment then we are talking about pure API's and there is no way
    that the courts are going to uphold that a copyright license can cross a
    pure API (famous last words). Well, no way if both sides of the dispute
    have equally good lawyers, without that who knows. Let's just suppose
    that things work out reasonably and the courts say that using an API
    is "fair use". That leaves the inline functions. If they are small I
    believe there is a lot of precedent for ignoring them. Even the FSF says
    that one liner patches don't need copyright assignment to the FSF. And if
    the module doesn't use those functions or provides their own version of
    those functions then I doubt that the inline functions have any bearing.
    Larry McVoy lm at
    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.026 / U:23.992 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site