BSD legal question

Joel rees at ddcom.co.jp
Fri May 20 00:11:52 PDT 2005


> > > Suppose I distribute a library that is under my own copyright,
> > > yet carries a BSD-like license.
> > >
> > > Suppose you then come along and take my library, and a GPLed
> > > library, link both of them together into a new program of yours.
> > >
> > > The FSF says that the entire code now becomes GPL.
> >
> > That's not true. The GPL requires you to license any distributed code
> > derived from GPLed code under the GPL.
> 
> This is a hairsplit since FSF=GPL, but yes, technically it's not the FSF
> saying the entire code now becomes GPL, it's the GPL saying that the
> entire
> code now becomes GPL.

NOT(FSF=GPL)

You can assign a copyright you own to the FSF if you've put it under the
GPL. You can also put the code under GPL and retain the copyright to
yourself. This is clearly explained on the FSF's FAQs.

<http://www.fsf.org/licensing/licenses/gpl-faq.html#DoesUsingTheGPLForAProgramMakeItGNUSoftware>

And splitting hairs is exactly how lawyers and judges get us to behave
civilly towards each other, so splitting hairs or not splitting hairs is
also irrelevant. Or, rather, you do have to split hairs to understand
what's going on because this is a contract. It's the same thing as
understanding the fine print on your car loan.

The GPL does not say the entire code becomes GPL. It says the work as a
whole is licensed under the GPL. In fact, section 2 is explicit about
parts:

    If identifiable sections of that work are not derived from 
    the Program, and can be reasonably considered independent 
    and separate works in themselves, then this License, and 
    its terms, do not apply to those sections when you 
    distribute them as separate works.

Therefore, the GPL is explicit that it does not attempt to alter the
original license of any part that has an independent existence. The
original license of a part remains in force. (If the license of a part
is to be changed when incorporated into the combined work, the author or
copyright holder of the part must explicitly change it.)

If the license of the part is incompatible, distribution of the whole
can't legally occur under the GPL.

If the license of the part is compatible, it remains in force on the
part as an independent work. 

There is some detail following the part I quoted, which specifies that
you can't take the license of a part and extend it to new works derived
from the whole as a way to get around the GPL, but there is nothing in
the GPL that alters (or allows a licensee to alter) the license of a
part.

Well, if I leave it at that, there may be some confusion. There is a FAQ

<http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLIncompatibleAlone>

which says that the license for a part would have to allow the part to
be distributed as an independent part under the GPL for the license to
be compatible with the GPL. In other words, the license of the part has
to be at least as liberal as the GPL. 

But what this FAQ is about is conditions like, "You may distribute this
program as a part of a combined work under an approved open source
license, but as a standalone program, it must be distributed under
license Q." 

I'm not sure I agree with that interpretation. But if it is the case, it
does not mandate distribution under GPL, only requires it to be allowed.
And it still does not remove or alter the original license.

If the license is incompatible, distribution of the combined work is
engaging in illegal activity, not modifying licenses.

On the other hand, nothing prevents an author from offering more than
one licensing option, as long as none of the optins is an exclusive
license.

> > Since, as you point out...
> >
> > > The problem here is that since you never owned copyright on
> > > my library, you do not have legal rights to modify the copyright
> > > and license on it.  Thus, you cannot legally apply GPL to it.
> > > Nor can the FSF or anyone else apply GPL to it.
> >
> > ... the conclusion is that you cannot *distribute* the derived
> > program;
> > NOT that it magically relicenses code you've used to build it.
> 
> Except that this is only the case if your definition of distribution
> is limited like the FSF's.

Distribution is distribution, even if it comes with a little sleight of
hand.

> That is exactly why the FreeBSD ports system was created.

I don't think it's the only reason.

> The idea behind ports is that 'unknowledgeable user' who I will
> refer to as a UU, can go to the ports, flick a switch (type
> make install) and whala- instantly the GPL licensed libraries that
> the FSF wants to prevent you from distributing with your nasty
> BSD stuff, are FTP'ed from whatever dark hole that
> they come from, the nasty BSD stuff is FTP'ed from wherever it
> comes from, the mixmaster is turned on at high speed and Bing!
> Instantly the UU has your intermixed program, while you have neatly
> avoided the little trap that the FSF has built to prevent UU's
> from getting ahold of nasty intermixed stuff!

Sigh. So that's why it's called mixmaster. I think I understand why ...

Anyway, that little trick can only get you a certain distance.

> The result is the same as if you build your program, and thoughtfully
> distribute intermixed source for your UUs - which runs afoul of the
> FSF's daffynition of distribution. 

I would not want to try to defend this in court, particularly since the
user is not informed that he has created a derived work, and that
distribution of the derived work is subject to various conditions
including those of the GPL.

It may well be that a judge would declare that, since the link points
were defined and mechanized in the scripts fed to mixmaster, this merely
constitutes delaying the linking, and that, for all that the end user is
the one that "pushes the button", the linkage was predefined, and the
distribution of the scripts and the machinery to execute them therefore
constitutes distribution of a combined work.

Particularly, calling the end user an "unknowledgeable user" emphasizes
that it is not the end user doing the combining.

> The FSF never envisioned that
> someone would actually go to the trouble of creating something like
> the FreeBSD ports software when they wrote the GPL, so they fortunately
> didn't define that kind of distribution mechanism in their license's
> definition of "distribution"

Oh, sure they did. It is not mentioned explicitly in the license, but it
is mentioned in the FAQ.

<http://www.fsf.org/licensing/licenses/gpl-faq.html#MereAggregation>
<http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLOutput>

among others.

Mixmaster is a really useful tool, but the utility is not in overcoming
the limits of licenses.

Now, because mixmaster is available to the user, and because the user
knows he can get the source of the parts and the whole by using it, the
conditions of offering redistribution, at any rate, are likely to be met
by the porting system. That does leave a few other license conditions,
however.

> But you can bet that if they had known Ports was coming, they would
> have written language proscribing that kind of distribution in the
> GPL.
> 
> Another more obvious note is that the 'configure' script doesen't have
> that fetching capability in it - although it would be trivial to add.
> 
> Ted

Thanks for the warning. Now I know one of the things I'll need to be very
careful about if I sell FreeBSD workstations with ports pre-installed.

--
Joel Rees   <rees at ddcom.co.jp>
digitcom, inc.   株式会社デジコム
Kobe, Japan   +81-78-672-8800
** <http://www.ddcom.co.jp> **



More information about the freebsd-questions mailing list