[erlang-questions] A PropEr announcement

[Edmond Begumisa]

Aaaaa ... the all to common Legislature vs Judiciary problem.

* Legislators make laws.
* These laws are made sufficiently vague (usually due to "legislative  
compromise" or plain incompetence)
* Courts have to interpret vagueness, judges make precedents to do so.
* Legislators then complain that judges are making their own laws...

"Not their mandate! The Judiciary should only enforce laws that *we*  
make," they scream.

Maybe engineers should make laws that pertain to engineering! Heck, maybe  
engineers should be on the bench for enforcing those laws!

- Edmond -

On Thu, 16 Jun 2011 22:59:23 +1000, Joe Armstrong <erlang@REDACTED> wrote:

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


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/