<br><br><div class="gmail_quote">On Thu, Jun 16, 2011 at 11:44 AM, Richard Carlsson <span dir="ltr"><<a href="mailto:carlsson.richard@gmail.com">carlsson.richard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 2011-06-16 03:18, James Churchman wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Is this a fact or a stated FSF opinion? seems counter intuitive that<br>
something that writes to an api ( even if it's dynamically linked ) can<br>
be considered an alteration of derived work, as what is to stop someone<br>
producing an identical api with the same, or indeed a different set of<br>
behaviour, does the existence of this "new" api now change things.<br>
Better still what if it targets an intermediate api. In that case if all<br>
calls in your code go to notgplmodule:do() which is a dual licensed<br>
opensource project, which calls gplv3 code, what happens then??<br>
</blockquote>
<br></div>
Here's a good summary of the FSF's thoughts about combined works, from the GPL FAQ:<br>
<br>
"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).<br>

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

 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."<br>
</blockquote><div><br>What a load of complete and utter nonsense - what does "are intimate enough mean" etc.<br><br>What about systems that are non-deterministic? If I send a message to a black box<br>and it tosses a dice to see if it will reply then surely this is not an "intimate communication"<br>
<br>Black box abstract says that two systems are identical if their observed I/O behavior is identical.<br>But if I open the black box and discover either one or two communicating things inside then<br>the law is *different* since in the one case I do not have to consider the intimacy of the relationship and the<br>
other I do.<br><br>The basic idea in object-oriented programming is *independent* objects communicating by <br>message passing. Would a lawyer in a court of law have to decide if a collection of communicating objects<br>constituted one program or many - what happens when you put them all in the same address space<br>
like smalltalk - is this one program or two thousand small programs each with it's own license.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<br>
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".<br></blockquote><div><br>No if you send a process it might on good day if it feels like it send a reply.<br>
<br>Image two nodes one in Sweden the other on the moon with flaky communication - sometimes a reply<br>to a message would be received sometimes not - anyway in the absence of a formal proof one would never <br>know if a message will be returned unless you can solve the halting problem.<br>
<br><br>/Joe<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
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).<br>

<br>
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?<br>

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

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

<br>
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.<br>
<font color="#888888">
<br>
    /Richard</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>