Re: [Chicken-hackers] Re: Backdoor GPL in message-digest

[John Cowan]

(Response to multiple messages)

Alaric Snell-Pym scripsit:

> AIUI, the GPL issue is this: We can have BSD or GPL licenses on source
> code to our heart's content, but a binary that contains GPL code *or
> dynamically links to GPL code* is then a GPL binary, and all source code
> that went into it must be released?

That's definitely true if it contains GPLed code.  If it only dynamically
links to GPLed code, the position is less clear; it depends how deeply
intertwingled the plugin is with its invoker.  If it uses a very hands-off
protocol (call a main entry point, pass it some strings, get back a
single integer result -- the same as main()), then even in the FSF's
view the programs do not taint one another.

A GPLed plugin that implements a well-documented protocol for which
drop-in non-GPL replacements exist probably does not taint its invoker
either: now that editline exists, arguably you can write programs that
invoke readline dynamically without having to make them GPL, since it's
easy to replace the readline .so/.dll with the editline one.

Even in more complex situations, the FSF is careful to say "we believe
[the plugin and its invoker] form a single program" rather than simply
"they form a single program".  So the law is unsettled.

> I'm a bit hazy on how that extends from "one binary" to "a tarball",
> mind; an egg can generate multiple libraries and executable binaries.

There is no separate copyright on a tarball other than the copyrights
on the files inside, so a tarball can safely contain both GPLed and
non-GPLed components, just as an ISO image can.

> But by that interpretation, a BSD egg could have an optional GPL
> dependency, and thus be able to generate BSD and GPL binaries, depending
> on whether the optional dependency was used. Right?!?

Yes.

Peter Bex scripsit:

> This would be useful, but not general enough.  There's not just the
> virality of the GPL to consider. There may also simply be incompatible
> licenses.  For the GPL, FSF maintains a list of free software licenses
> that are incompatible with it:
> http://www.gnu.org/licenses/license-list.html#GPLIncompatibleLicenses
> 
> There are probably similar lists for the BSD license, but I don't know
> any offhand.

It's generally agreed that the 3-clause and 2-clause BSD licenses, as
well as the MIT license, are so non-restrictive that they are compatible
with every license.  Note that whereas the GPL-family licenses provide
access to the source code, the BSD-family licenses presuppose it: they
grant rights to people who have the source already.  You could attach
a BSD-type license to a binary blob, but the result would of course not
be free or open source, since there is no source.

> Also note that the LGPL is incompatible with the GPL in that you cannot
> link a LGPL library or program to a GPL library(!)

That's definitely false.  The whole point of the LGPL (2.1 or 3) is that
you can use an LGPLed library in a program which, as a whole, is under
almost any license (barring such perverse licenses as "You may use this
library only in programs that don't link to an LGPLed library").

The FSF's incompatibility page has to do with *incorporating* code under
one license into a code base that is under another license, not to the
permitted uses of libraries under the LGPL.

However, it is true that the GPL2 and GPL3 conflict, because the GPL2
wants the linked binary to be GPL2, whereas the GPL3 wants it to be GPL3.
Most GPL2 programs are in fact GPL2+ ("version 2 or later"), so this
isn't much of a problem in practice, but we should distinguish between
2-only and 2+.  This is a "hard" conflict where the binary cannot be
distributed at all, as opposed to a "soft" conflict as between GPL and
BSD-family, where the binary must be distributed under the GPL.

> I think if we build a license checking feature into chicken-install,
> it should handle incompatible licenses in general.

I agree.  I think the incompatibilities should be expressed as an external
rules file, however.

Alaric Snell-Pym iterum scripsit:

> Also, I think that chicken-install should not *forbid* license clashes,
> merely *warn* about them. License clashes are generally a problem for
> people wanting to distribute binaries, and not an issue at all for
> people just hacking around at home, right?

Technically, no (because linking creates a derivative work); in
practice, yes.  The GPL explicitly restricts only copying for the sake of
distribution to other parties (calling "conveying" in GPL3), and permits
these activities within the scope of a single individual or company.
So I agree that a warning is appropriate.

I am not a lawyer; this is not legal advice, but it's not the unauthorized
practice of law either.  Your mileage may vary, especially outside
the U.S.

-- 
We do, doodley do, doodley do, doodley do,        John Cowan <address@hidden>
What we must, muddily must, muddily must, muddily must; 
Muddily do, muddily do, muddily do, muddily do,    http://www.ccil.org/~cowan
Until we bust, bodily bust, bodily bust, bodily bust.  --Bokonon