Re: Linux GPL and binary module exception clause?

[Larry McVoy]

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 libc.so 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.
Comments?
-- 
---
Larry McVoy              lm at bitmover.com          http://www.bitmover.com/lm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/