[erlang-questions] A PropEr announcement
Thu Jun 16 11:44:13 CEST 2011
On 2011-06-16 03:18, James Churchman wrote:
> Is this a fact or a stated FSF opinion? seems counter intuitive that
> something that writes to an api ( even if it's dynamically linked ) can
> be considered an alteration of derived work, as what is to stop someone
> producing an identical api with the same, or indeed a different set of
> behaviour, does the existence of this "new" api now change things.
> Better still what if it targets an intermediate api. In that case if all
> calls in your code go to notgplmodule:do() which is a dual licensed
> opensource project, which calls gplv3 code, what happens then??
Here's a good summary of the FSF's thoughts about combined works, from
the GPL FAQ:
"Where's the line between two separate programs, and one program with
two parts? This is a legal question, which ultimately judges will
decide. We believe that a proper criterion depends both on the mechanism
of communication (exec, pipes, rpc, function calls within a shared
address space, etc.) and the semantics of the communication (what kinds
of information are interchanged).
If the modules are included in the same executable file, they are
definitely combined in one program. If modules are designed to run
linked together in a shared address space, that almost surely means
combining them into one program.
By contrast, pipes, sockets and command-line arguments are
communication mechanisms normally used between two separate programs. So
when they are used for communication, the modules normally are separate
programs. But if the semantics of the communication are intimate enough,
exchanging complex internal data structures, that too could be a basis
to consider the two parts as combined into a larger program."
By this reasoning, it is for example not sufficient separation to use
two Erlang processes and use message passing to avoid direct linkage -
the connection is still too "intimate".
Using an intermediate/wrapper API doesn't work either; the linked
combination of the GPL code, the wrapper code, and your code, becomes a
single larger work, and the GPL will apply to all of it (also covered in
An API in itself (a list of function names, type signatures and other
calling conventions) cannot to my knowledge be copyrighted, because it's
simply not considered a "work" that can be protected by copyright laws -
it's too trivial. The question is: if your code is written to use a
particular API (like the one in your wrapper example), can you
reasonably claim that your code is not designed to use a particular
implementation of that API? I.e., do there exist any real alternatives?
The (very) little I know of law is that courts tend to throw out
reasoning that is pretty obviously only trying to create a smokescreen,
like "I wasn't being paid, I just happened to pick up a bunch of dollars
dropped by someone who turned out to be the guy who asked me to do him a
favour yesterday." If the only existing, working, implementation of your
neat wrapper API, is one that just forwards calls to some GPL'ed
library, the "intermediate API" argument won't hold. But reversely, if
you do write a program targeting an API with several available
implementations, then if one of those happens to be a GPL'ed library, it
doesn't affect your code, because it wasn't designed to use that library
specifially, and it's up to your users if they choose that
implementation. (I know I've seen a good summary of this stuff once, but
I can't seem to find a reference right now.)
So, if there was once just one implementation, using GPL, of a
particular API, and someone does a clean-room implementation of that
same API but under a different license like MIT, then as far as I can
tell, that does change the situation, at least as long as the non-GPL
implementation is somehow available to the users of your code. I.e., I
don't think you can create an alternative and buggy implementation, lock
it up in your vault, and then claim that your program isn't necessarily
designed to use that GPL'ed library that actually works.
It's of course also possible for the author of a library to use the GPL
with an exception that says something like "as long as you as a user
just call these API functions, the GPL licensing doesn't affect your own
code even if you link with this library". But if there is no such
exception, you won't get around the GPL by a simple wrapper. Using
separate OS processes and pipes for communication _might_ be enough, but
probably not if you're marshalling complex data structures in an obvious
attempt to get around the GPL.
More information about the erlang-questions