Open source, closed source, and the value of code

Robert Mann rman at free.fr
Thu Mar 3 13:30:45 EST 2016


<< I believe any media or other content (whether separate files or not)
distributed with the application and/or required to make it function fully
would need to be licensed in a GPL compatible license.>>

Hi Monte, I believe (!)  that this belief is kind of a key issue in
attempting to identify the scope of GPL for livecode stacks and their
content.

I invite all of you (all) to , put on the legal hat for a while and walk
into the following story :

GPL is a very special kind of automatic contract that is attached to a piece
of work and which describes what the receiver of that piece of work can or
not do with it.

As such it is a very special contract in the world of contracts because it
does not require the agreement of the receiver, which is "implied" by the
act of receiving. So it is not the strongest type of contract.

Now and this is key to understand : a contract is itself a piece of work
that exist within a certain legal framework namely "the law" (the legal
codes etc & jurisprudence).

In that framework, there is a hierarchy of codes : from constitution at the
top to applications provisions down the road. it's kind of like in Object
programming. Except that you don't ask; Top objects set the law. Whatever
you try to do at the lower level.

Contracts that you can write must obey to the general rules. Some of these
rules are "imperative" no matter what the intent of a contractor may be
there are things that they just cannot do.

Among these, lies copyright. Copyright is a strong piece of legal meat which
has imperative laws that no one can circunvent. And that is particularly the
case in France/Europe which has a strong implementation of droits d'auteurs.
Anglos saxon copyright is much weaker on some points.

Copyrights has been structured according to various protected activities
from "fine art" painting, music, writing to "less fine art" like photo
graphics, sounds and lastly to "coding". Each of these activities/objects
have some special variations of rules which have organized themselves over
centuries.

A GPL license can set rules regarding it's own original object like "thou
shall re-distribute me, in whole or in part, with the same rights you
received". This can be symbolized by :
I received package CODE-A, i must re-distribute CODE-A with the same rights
i received.

The GPL license has extended the law in enforcing that all direct derivated
work be treated at par-level to the main body of work received, without
limit in time or scope or locality.
I received package CODE-A + I add package CODE-B which is of the same nature
than package A, namely CODE, and strongly interconnected to A, than I have
to re-distribute with same rights as CODE-A.

I say stretched out already because one strong legal principle that have
evolved over centuries is the principle that you should not engage futures
for an un-limited scope. Put into other words : a contract I make with any
publisher that all my future work will have to be signed with him without
time limit is VOID by law. e.i not acceptable.

So in the GPL case, this principle is clearly put aside (there is no time
limit or territorial limit) and this has been accepted, I guess lawers try
to be practical somehow.

But GPL license will not be able to act by magic on something else like a
picture, which is of a different legal nature governed by its own set of
legal rules which are "imperative" to the GPL.

That would be an extension of the extension, reaching limits of the existing
set of legal fundamentals.

I received package CODE-A + I add package CODE-B [of same nature &
intimitaly interconnected]
+ I add package IMAGE-C [of a different nature, somehow connected, but not
intimately]
=>  than I have created a COMPOUND package legally because CODE and IMAGE
are not governed by the same legal set of rules.  All the code part A+B is
governed by GPL fine, but all the IMAGE-C part is governed by whatever
copyright or CC or else.

Now the FFS (and it seems livecode counsels) tries to blow away the
difference between CODE and IMAGES and so on (including all media types and
all activities protected) and impose a kind of over-ruling of CODE over
everything else. Is that defendable? wise?

I do not think this would be wise because it would only favor even more the
big big super firms in asserting their rights over everything in that world.
It seems a good thing to me to keeps things separated.
Alphabet already nearly owns the alphabet some way. 

So far, they got a clear first ruling against that in the wordpress case.
And javascript clarified the case with a specific extension making it clear
that an HTML page that calls a javascript function is not regarded as
derivated art of javascript! (the case would have been very difficult to
defend). Livecode could well do the same.

I hope that these precisions will help all of us better grasp the legal
background of the issue of how GPL applies to Livecode stacks and their
contents.

Robert

Of course, that is no legal device and just the point of view of a
"bienveillant" and honorable member of that list delivered here as "food for
thoughts" in accordance with the objectives of that list.


Monte Goulding-2 wrote
>> On 2 Mar 2016, at 4:35 PM, J. Landman Gay <

> jacque@

> > wrote:
>> 
>> Does that sound right to all you guys who read up on this stuff?
> 
> I believe any media or other content (whether separate files or not)
> distributed with the application and/or required to make it function fully
> would need to be licensed in a GPL compatible license.
> 
> Cheers
> 
> Monte
> _______________________________________________
> use-livecode mailing list

> use-livecode at .runrev

> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701951.html
Sent from the Revolution - User mailing list archive at Nabble.com.




More information about the use-livecode mailing list