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

[Brian Granger]

Just for reference:

http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL

But, mind you, I don't think that everyone agrees with this
interpretation and it this (as far as I know) has not been tested in
court.

This is one of the problems I have with the GPL though - it is
complicated enough that I am not sure what it says exactly.

Cheers,

Brian

On Thu, Apr 10, 2008 at 6:37 AM, Alceste Scalas <alceste@REDACTED> 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".
>
>
>
>  >  "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/
>
>  _______________________________________________
>
>
> erlang-questions mailing list
>  erlang-questions@REDACTED
>  http://www.erlang.org/mailman/listinfo/erlang-questions