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

[Alceste Scalas]

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".


>  "What does it mean to say a license is “compatible with the GPL?”
>    - It means that the other license and the GNU GPL are compatible; you
>      can combine code released under the other license with code released
>      under the GNU GPL in one larger program.
> 
>      All GNU GPL versions permit such combinations privately; they also
>      permit distribution of such combinations provided the combination is
>      released under the same GNU GPL version. The other license is compatible
>      with the GPL if it permits this too."
> 
> Note: "provided the combination is released under the same GNU GPL version".
> *Not* just any "GNU GPL-compatible licenses" as you wrote.

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.


> The EPL is not GPL-compatible, and Erlang modules are dynamically linked,
> so it is not possible to use GPL:ed Erlang modules if you want to distribute
> the result. LGPL should be ok for Erlang code, however.

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.

The GNU GPL FAQ suggests a different conclusion about GNU GPL'ed Erlang
modules:

        If a programming language interpreter is released under the GPL,
        does that mean programs written to be interpreted by it must be
        under GPL-compatible licenses?
        
                [...]
                [W]hen the interpreter is extended to provide “bindings”
                to other facilities (often, but not necessarily,
                libraries), the interpreted program is effectively
                linked to the facilities it uses through these bindings.
                So if these facilities are released under the GPL, the
                interpreted program that uses them must be released in a
                GPL-compatible way. The JNI or Java Native Interface is
                an example of such a binding mechanism; libraries that
                are accessed in this way are linked dynamically with the
                Java programs that call them. These libraries are also
                linked with the interpreter. If the interpreter is
                linked statically with these libraries, or if it is
                designed to link dynamically with these specific
                libraries, then it too needs to be released in a
                GPL-compatible way.

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.


> > Under the copyright law, a program that depends/links to a library
> > *is* a derived work,
> 
> Which "the copyright law"? Quote, please.
>
> > Unlike the GNU GPL, the GNU LGPL does *not* require that the derived
> > product is released "as a whole" under compatible licensing terms
> 
> No, in fact the LGPL quite explicitly says what a derived work is: [...]

D'oh, you're right.  I did not check the license, and remembered it
wrong...

Regards,

alceste
-- 
Alceste Scalas <alceste@REDACTED>
CRS4 - http://www.crs4.it/