[erlang-questions] A PropEr announcement

[Richard Carlsson]

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 
the FAQ).

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.

     /Richard