[erlang-questions] GNU GPL, MIT, BSD and compatibility

Richard Carlsson richardc@REDACTED
Fri Apr 11 16:33:19 CEST 2008


Alceste Scalas wrote:
> Yes, I am pretty sure that this is wrong.  Maybe it is necessary to
> specify what "on the terms of the GNU GPL" means in the passage above.

I think that is clear: the entire GNU GPL, every word of it, applies.

> Let's say that I have a file bar.c, released by some third party under
> the (GPL-compatible) BSD license.  I modify it and make it depend on
> libfoo, which is GNU GPL'ed, in order to create the application gplbar.
> What does it happen?  Let's make two hypothesis:
> 
>      A. the bar.c license is overwritten/substituted by the GNU GPL for
>         further redistributions, even when separated from "the whole"
>         gplbar;
>      B. the (GPL-compatible) bar.c license remains the same, except
>         (maybe) for the changes I made for linking libfoo.  Anyway, the
>         resulting application must now also respect the license of the
>         new component (i.e. libfoo).  And thus, "the whole" gplbar
>         application must now be distributed on the terms of the GNU GPL.
>         If someone later removes my changes, however, the bar.c code
>         will not be bound to the GNU GPL anymore.
> 
> If I understood correctly, you think that "A" is correct, while I think
> that "B" is correct.

Not quite, I think that C is correct:

     C. The GNU GPL is *added* to the licensing of bar.c (the version
        shipped in the combined work gplbar). It does not invalidate the
        existing licenses. This is why license compatibility is an issue.
        The previous licenses must not contain restrictions that go against
        the GPL, otherwise the programs cannot be combined and distributed.

        If someone breaks out bar.c from gplbar, he must have the right to
        use and distribute it under the combined licenses including GPL.
        If this bar.c, modified or not, is identical to the bar.c published
        separately under some other license, then it is of course legal to
        also keep distributing it without GPL attached, but that does not
        take away the right of people to use it *with* GPL if they want.

> a change of license "of each and every part" is not required.

Not a change, but the addition, of a GPL license is required. This is
exactly what the phrase "under the terms of this License" means. It says
nothing about replacing any existing licenses. Here's a hint from the
FAQ: "If there is no way to satisfy both licenses at once, they are
incompatible."

> And the lack of this requirement is good, because the
> substitution/overwriting of the original license may be *illegal*: under
> the copyright law of every country I know about, only the author has the
> right to decide the usage conditions of the code he/she wrote --- and,
> for example, the BSD license does *not* allow such relicensing [2].

Naturally, if the person who combines the programs and distributes them
*has no right to do so*, either because the involved licenses are
incompatible, or because that person is not allowed to relicense some
of the involved parts, then the result has no legal effect; the act would
be illegal. The "viral" part happens when you *do* have the right to
relicense the non-GPL parts: in that case you *must* relicense them if
you distribute the combined work, otherwise it is a violation of the GPL.

> Therefore, saying that GNU GPL'ed software requires to change the
> license of every other code it touches/links to is *not* correct.
> 
> It is a "viral" property that the license simply does not have, and
> would make it incompatible with most of the "GNU GPL-compatible"
> licenses (!).

On the contrary, the only way a license *can* be GPL-compatible is
if it allows such relicensing. The MIT and Rodified BSD licenses,
for example, both allow this (mainly because they do not *disallow*
relicensing as long as it is in a compatible way), while the original
BSD license with its "banner" clauses is incompatible due to its extra
restrictions.

     /Richard





More information about the erlang-questions mailing list