[erlang-questions] A PropEr announcement
Fri Jun 17 05:08:42 CEST 2011
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 <> wrote:
> On Thu, Jun 16, 2011 at 11:44 AM, Richard Carlsson <
> > 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
>>> 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
>> GPL FAQ:
>> "Where's the line between two separate programs, and one program with
>> 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
>> together in a shared address space, that almost surely means combining
>> into one program.
>> By contrast, pipes, sockets and command-line arguments are
>> mechanisms normally used between two separate programs. So when they are
>> used for communication, the modules normally are separate programs. But
>> the semantics of the communication are intimate enough, exchanging
>> 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
> 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
> 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
> 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
> 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
>> 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
> Image two nodes one in Sweden the other on the moon with flaky
> - 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
>> 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
>> 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
>> claim that your code is not designed to use a particular implementation
>> that API? I.e., do there exist any real alternatives?
>> The (very) little I know of law is that courts tend to throw out
>> that is pretty obviously only trying to create a smokescreen, like "I
>> being paid, I just happened to pick up a bunch of dollars dropped by
>> 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
>> 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
>> 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
>> to use that library specifially, and it's up to your users if they
>> that implementation. (I know I've seen a good summary of this stuff
>> but I can't seem to find a reference right now.)
>> So, if there was once just one implementation, using GPL, of a
>> API, and someone does a clean-room implementation of that same API but
>> a different license like MIT, then as far as I can tell, that does
>> 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
>> 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
>> 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,
>> won't get around the GPL by a simple wrapper. Using separate OS
>> and pipes for communication _might_ be enough, but probably not if
>> marshalling complex data structures in an obvious attempt to get around
>> erlang-questions mailing list
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
More information about the erlang-questions