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

[Richard Carlsson]

David-Sarah Hopwood wrote:
> 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.

Yes, I think there can be very little doubt that the Erlang/OTP runtime
system and the included standard library modules are not affected by
compiling and running GPL:ed modules, or packaging the OTP distribution
with GPL:ed code, any more than a JVM+libraries would be affected by
being shipped  along with a GPL Java application.

Hence, the compatibility of GPL with the EPL as used in the runtime
system and libraries is simply not an issue. But if some people are
using the EPL for their own Erlang projects, and want to call GPL:ed
modules, any (in)compatibility would have to be considered.

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

As long as the Erlang/OTP runtime is just a general infrastructure that
the GPL code happens to run on, I think it is fairly clear that they are
not considered to be combined (but I'm no lawyer either).

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

Quite. And a linked-in port driver, providing e.g. a Qt-binding or
somesuch, which is published (the driver code) under GPL, would force
Erlang modules that depend on the port driver to also be GPL:ed.

     /Richard