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

[Richard Carlsson]

Alceste Scalas wrote:
> Il giorno gio, 10/04/2008 alle 13.39 +0200, Richard Carlsson ha scritto:
>> Yes, and they mean that *if* you distribute the work, *including* the GPL
>> parts, then *all* parts, including those that come under non-GPL (but
>> compatible) licenses, must be made available *under the GPL*. (Assuming
>> all involved licenses allow the combination to be made.)
>>
>> Hence, the only way a license can be GPL-compatible is if it allows
>> redistribution under GPL.
> 
> Yes.  Maybe we were trying to say the same thing.
> 
> There is one point that I wanted to clarify, though (based on the wrong
> GNU GPL assumptions that started this sub-thread): the GNU GPL does
> *not* require you to license (or re-license) your code under the GNU GPL
> itself.  If your code is under a MIT-like license, it won't be
> "infected".

This is only true in the completely uninteresting (for this discussion)
case when you *do not distribute* the combined work. As soon as you do,
however, you *must* make the whole work available under the GPL. If some
parts are (only) distributed under an incompatible license (that does
not allow re-licensing or adds restrictions), they *cannot* be combined
and distributed. (I suppose that it is allowed to combine them for
personal or company-internal purposes, but I can't be bothered to
research that point right now.)

If you are a software company, and one of your employees by sheer
ignorance uses GPL software in your product, and you ship that product,
then the only way you can avoid violating the GPL is to publish all
your source code for that product. It is most definitely "viral" in
that sense. If you don't want people to see your code, you need to
be fairly careful about using free software.

(I'm not condoning any particular behaviour here, just describing
some realities of software companies. There are many reasons, good
and bad, for not wanting to show your code to the world.)

> Yes, it refers to the combination "as a whole".  But, as I wrote, its
> parts taken alone may be covered by different, GNU GPL-compatible
> licenses.  If program "bar" is under MIT and depends on the GNU GPL'ed
> "libfoo", then "bar + libfoo" must be distributed complying with the
> terms of the GNU GPL.  This fact, however, does not require to
> change/infect the license of "bar" taken alone.

That is entirely uninteresting, because it *does* force you to
distribute "bar" under the GPL (when you ship it with libfoo).
Once you've done that, it is officially free software, and anyone
can keep using and modifying that source code (under the GPL).

But it does not force the copyright owner of "bar" to publish that work
only under the GPL from now on, that much is true; and if he modifies
"bar" to "bar2" which does not use libfoo, then bar2 does not have to be
GPL:ed if it is distributed. But this is really of minor interest.
The main thing is that if you don't *want* your code to be licensed
under GPL at all, then you *cannot* link it with GPL software.

> But Erlang does *not* derive/depend on GNU GPL'ed modules: it just has
> the capability to load them and make them available to Erlang programs.
> [...]

Anyhow, the text you quoted does not apply here (the Erlang interpreter
is not published under GPL), but the paragraphs that followed is just as
valid for Erlang as for Perl or Java:

   "Another similar and very common case is to provide libraries with the
   interpreter which are themselves interpreted. For instance, Perl comes
   with many Perl modules, and a Java implementation comes with many Java
   classes. These libraries and the programs that call them are always
   dynamically linked together.

   A consequence is that if you choose to use GPL'd Perl modules or Java
   classes in your program, you must release the program in a
   GPL-compatible way, regardless of the license used in the Perl or Java
   interpreter that the combined Perl or Java program will run on."

A language interpreter and its runtime system and libraries are not
affected by the code running under it, just like an operating system
(Windows does not violate the GPL just because you run Gimp on it),
but the modules being interpreted are considered as programs being
linked to each other.

 > Thus, you *can* develop GNU GPL'ed Erlang modules, or modules that
 > link to GNU GPL libraries, and load them on the Erlang VM.  But the
 > Erlang programs that actually link/depend on them must be released
 > under a GNU GPL-compatible license.

Just so. But the status of the Erlang/OTP distribution in relation
to the code that runs on it was never much questioned here.

     /Richard