Licensing AGAIN [was: Sharing FontLab Plugin]

JB sundown at pacifier.com
Fri Jul 22 18:04:32 EDT 2016


Around a year or so ago I read Apple was thinking
of making xCode open source.  If they do then it
seems like they could incorporate Livecode open
source to develope similar features in xCode.  With
their money, attorneys, and laws in different countries
they can pretty much use what they want.  They need
to simplify their interface whatever path they take.

John Balgenorth


> On Jul 22, 2016, at 10:32 AM, Kevin Miller <kevin at livecode.com> wrote:
> 
> Hi folks,
> 
> We do review our licensing from time to time and I will at some point look
> again at whether we can clarify this further or introduce changes that
> make it clearer to our end users. Iąm not a lawyer and until this stuff
> gets tested in court it seems hard to say what will and wonąt stand up.
> 
> A few comments on the statements below though. Firstly, the article Mark
> helpfully references is based on USA law. LiveCode is based in the UK.
> There isnąt the same concept of łfair use˛ over here, and various other
> aspects of copyright law are different. It would be hard to say that the
> statements in that article, if correct in the USA (and as I say they
> havenąt been tested) would apply here.
> 
> Secondly, LiveCode is very different from Wordpress. Stacks are executable
> binaries that incorporate aspects of the engine. That's even more the case
> now when they start to use and include widgets. There isnąt a good
> comparison with other text based languages. I personally doubt our script
> only components are GPL, but as Iąve said this hasnąt been tested in court
> and its not up to me.
> 
> GPL does not alter the copyright assignment of the work that you create.
> Nor does it kick in at all on work on your own machine, it only applies at
> the point you distribute. When it applies, it simply requires that your
> work be distributed with certain additional freedoms. That does not remove
> your copyright, it just adds some rights for other people. You can change
> that any time by buying a commercial license.
> 
> If all stacks were not GPL, then there would be far less need for
> standalones any more. Just build a commercial product and ship it, let the
> user install the IDE to run it. Maybe fork the source to add in password
> protection. That impact wouldnąt apply as quickly to iOS but it would take
> another chunk of our revenue away overnight on all other platforms. Which
> means less features for you, less bug fixes, less engineers and less
> progress on the platform. There are other ways to encourage commercial
> license use (e.g. by adding features) but we arenąt there yet to the
> extent we would need to be. Maybe when we get further down that path this
> sort of change might start to stack up economically. In the mean time it
> is surely in everyoneąs interests that we are strong and healthy.
> 
> Mark Iąm very happy to sit down with you (and anyone else) over a whisky
> and debate all of this. If we can find a clearer license that continues to
> bring in sufficient revenue for our core team to develop the platform and
> grows our community even better, Iąd be truly delighted. In order to have
> that debate, you would need to be more aware of the actual economics of
> our specific situation and that not something we can do on list. As yet I
> havenąt come up with a better license combination for where we are today
> and its not for lack of thought on the subject.
> 
> Kind regards,
> 
> Kevin
> 
> Kevin Miller ~ kevin at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> 
> 
> 
> 
> On 22/07/2016, 02:52, "use-livecode on behalf of Mark Wilcox"
> <use-livecode-bounces at lists.runrev.com on behalf of
> mark at sorcery-ltd.co.uk> wrote:
> 
>> On Fri, Jul 22, 2016, at 03:38 AM, Richard Gaskin wrote:
>>> Mark Wilcox wrote:
>>> 
>>>> My concern around LiveCode over-reaching with their derivative
>>>> work claims (which are significantly stronger than those made
>>>> by WordPress and Drupal)
>>> 
>>> In what way(s)?
>> 
>> OK, it's not wise to pull too hard on this thread, because LiveCode does
>> potentially have an issue with people distributing stackfiles
>> commercially, separate from a copy of the engine.
>> 
>> That said, several noteworthy points exist in this regard:
>> 1) First, the Software Freedom Law Centre - which tends to be rather
>>  biased in attempting to push copyright law interpretations in a way
>>  that strengthen's copyleft licenses - has only given an opinion on
>>  WordPress themes, not plugins. That analysis suggested that the PHP
>>  code in themes was essentially trivial, just calling a fixed set of
>>  APIs to enable the CSS and images to be used in the right places.
>>  It's debatable but not unreasonable to suggest that the PHP code in
>>  themes is subject to the GPL. The SFLC specifically said that the CSS
>>  and images were not subject to the GPL.
>> 
>> 2) A core WordPress contributor, Mark Jaquith, publicly stated at the
>>  time of the SFLC statement on themes that the same argument applied
>>  to plugins as well. He has since reconsidered that opinion and isn't
>>  so convinced about themes any more either (see his comment on this
>>  blog:
>> 
>> https://enriquesthoughts.wordpress.com/2014/01/05/wordpress-is-gpl-must-yo
>> ur-plugin-be-as-well/
>>  - specifically:
>> "Very well argued. My thinking on this matter has evolved since I wrote
>> my post, 3+ years ago. The thing about the GPL is that it is a legal
>> hack. For it to work, it relies on legal concepts like what constitutes
>> a derivative work. And while some plugins could unambiguously be
>> derivative works, I no longer think they must necessarily be so, and I
>> suspect the majority would not be considered derivative works (by a US
>> court, at least). Same goes with themes with the caveat that themes are
>> more likely to contain code lifted from WordPress, so they might veer
>> towards derivation more often than plugins do."
>> Proprietary WordPress plugins are extremely common and largely
>> tolerated. Proprietary themes do still exist but are slightly more
>> frowned upon.
>> 
>> 3) Drupal modules/plugins are frequently designed to modify the way that
>>  Drupal works. That does create some reasonable case for them being
>>  derivative works. The reality is probably that some Drupal plugins
>>  are derivative and some are not.
>> 
>> 4) LiveCode is basically claiming that anything written in the language
>>  is derivative. There is no precedent for this anywhere. Also, large
>>  parts of the language itself are not really owned by LiveCode, it has
>>  been previously released under more permissive licenses. Effectively
>>  by creating a language, you create a new form of expressing creative
>>  works. It is almost certainly not possible to copyright everything
>>  expressed in a language. Add to this that the language is "English-
>>  like" and a lot of the time LiveCode are trying to claim copyright
>>  over English words... likely to be laughed out of court.
>> 
>> 5) One of the most critical elements in a court's decision on whether or
>>  not any use of a copyrighted work is "fair use" is the degree of
>>  transformative nature of the work. The LiveCode engine is a general
>>  purpose runtime designed to execute arbitrary programs, on its own it
>>  doesn't "do" anything. The same broadly applies to any APIs it
>>  provides. It would be very easy to argue that creating almost any app
>>  that has a useful specific function is highly transformative of the
>>  engine code.
>> 
>> 6) All is not lost for LiveCode in (5) because distributing a standalone
>>  would involve a direct copying of the entire engine, which would very
>>  likely override the transformative nature of the use in almost every
>>  conceivable case. However, the amount of LiveCode owned copyrightable
>>  material in a stackfile is likely very small and the amount in a
>> script-
>>  only stack almost non-existent.
>> 
>> 7) No-one can know the actual position for certain because this has
>>  never been tested in court.
>> 
>>>> I'd really hope to see a more enlightened policy here
>>> 
>>> Apparently some clarification would be useful.
>> 
>> Don't try to force the GPL on stackfiles created with the community
>> edition, only standalones. Encourage dual licensing or permissive
>> licensing. Allow the community edition users to create valuable code
>> that can also benefit commercial users. Even encourage them to dual
>> license and sell that without getting a commercial license (we're not
>> talking about a big market LiveCode would lose out on here). By all
>> means suggest that anyone building a successful business around this
>> practice should buy a license to support LiveCode but don't try to force
>> them to do so with GPL FUD.
>> 
>> Frankly, even with a commercial license, the idea that someone else
>> owns copyright over the essence of my own creative works is
>> abhorrent. My instinctive reaction to a tool vendor that claims that
>> is not to use the tool at all. What if LiveCode the company fails? I
>> understand very deeply the complexity and costs involved in creating
>> such a tool and want to see LiveCode succeed commercially. I just
>> think this is a terribly user-hostile way of going about it with a
>> very unsound legal basis.
>> 
>> Mark
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
> 





More information about the use-livecode mailing list