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

[David-Sarah Hopwood]

Alceste Scalas wrote:
> 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?

Erlang/OTP isn't released under the GPL, so this FAQ answer does not apply.
(Note that for the Java Native Interface example, Sun's main implementations
of the JVM are currently released under GPLv2.)

To answer Brian Granger's point that started this subthread:
 > The biggest problem is that GPL code can't be used in open source BSD
 > style projects (the GPL would require releasing the resulting work
 > under the GPL license).  Perfect example:  Erlang is not GPL.  Thus
 > Erlang cannot be distributed with code that links to or uses GPL code:
 > readline and FFTW begin examples.

a more relevant FAQ answer is the following one:

> I'm writing a Windows application with Microsoft Visual C++ (or Visual Basic)
> and I will be releasing it under the GPL. Is dynamically linking my program
> with the Visual C++ (or Visual Basic) run-time library permitted under the GPL?
> 
>     The GPL permits this because that run-time library normally accompanies
>     the compiler or interpreter you are using. The run-time libraries here
>     are “System Libraries” as GPLv3 defines them, and as such they are not
>     considered part of the Corresponding Source. GPLv2 has a similar exception
>     in section 3.

The GPLv3 definition of "System Libraries"
<http://www.gnu.org/licenses/gpl-3.0.html> is:

   The “System Libraries” of an executable work include anything, other than
   the work as a whole, that (a) is included in the normal form of packaging
   a Major Component, but which is not part of that Major Component, and (b)
   serves only to enable use of the work with that Major Component, or to
   implement a Standard Interface for which an implementation is available to
   the public in source code form. A “Major Component”, in this context,
   means a major essential component (kernel, window system, and so on) of
   the specific operating system (if any) on which the executable work runs,
   or a compiler used to produce the work, or an object code interpreter used
   to run it.

An Erlang/OTP runtime is clearly "an object code interpreter used to run"
the program, therefore it is a Major Component of the program. So there is
no problem with linking parts of GPLv3-licensed Erlang programs, such as
drivers, with the relevant components of Erlang/OTP that they need to be
linked with, even when Erlang/OTP is not acting as a pure interpreter for
those programs.

Also, GPL code can be distributed with a copy of the Erlang/OTP runtime
if the result is only an "aggregate" of the code and the runtime (although
this is a slightly grey area because it could be argued in some cases that
they have been "combined [...] such as to form a larger program").

However, if a GPL-licensed program required a patch to Erlang/OTP in order
to work correctly, for example, it would not be legal to distribute the
patched Erlang/OTP source with the program.

IANAL, HTH.

-- 
David-Sarah Hopwood