[erlang-questions] A PropEr announcement

[Joe Armstrong]

On Thu, Jun 16, 2011 at 11:44 AM, Richard Carlsson <
carlsson.richard@REDACTED> wrote:

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

What a load of complete and utter nonsense - what does "are intimate enough
mean" etc.

What about systems that are non-deterministic? If I send a message to a
black box
and it tosses a dice to see if it will reply then surely this is not an
"intimate communication"

Black box abstract says that two systems are identical if their observed I/O
behavior is identical.
But if I open the black box and discover either one or two communicating
things inside then
the law is *different* since in the one case I do not have to consider the
intimacy of the relationship and the
other I do.

The basic idea in object-oriented programming is *independent* objects
communicating by
message passing. Would a lawyer in a court of law have to decide if a
collection of communicating objects
constituted one program or many - what happens when you put them all in the
same address space
like smalltalk - is this one program or two thousand small programs each
with it's own license.


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

No if you send a process it might on good day if it feels like it send a
reply.

Image two nodes one in Sweden the other on the moon with flaky communication
- sometimes a reply
to a message would be received sometimes not - anyway in the absence of a
formal proof one would never
know if a message will be returned unless you can solve the halting problem.


/Joe



>
> 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
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110616/47ed1624/attachment.htm>