Licensing AGAIN [was: Sharing FontLab Plugin]

[Richard Gaskin]

Mark -

Thank you for taking the time to write up your views on the distinctions 
between LiveCode Ltd's interpretation of the GPL and those of the 
Drupal, Wordpress, and Joomla projects.  I'm quoting it here in its 
entirety because I believe it's worth a second read; IMO it represents 
some of the most cogent thinking on the subject we've seen, well 
expressed in the spirit of fostering a healthy ecosystem for everyone.

There is one difference between LC and Drupal/Wordpress/Joomla which is 
inherent though, rather than interpretive:  LC is offered under dual 
license, while the others are not.

Of course that only affects the questions specific to mixing license 
types, but those seem to comprise the majority of this discussion here.

In this morning's Community meeting Peter and I spent the bulk of our 
time reviewing both sets of questions, those relating to GPL 
interpretation and those relating to possible mixing of the license 
types, and many other considerations as well.  It was one of our longer 
meetings, in which we reviewed the specific examples Kay, 
Bramanathaswami, and others have presented.

Peter, Kevin, Mark Waddingham, and the rest of the core team have the 
same goal as everyone here:  an earnest embracing of open source while 
also making sure the project remains sustainable for the benefit of both 
open source and proprietary developers alike.

They recognize that further guidance would be useful, but as a practical 
matter the conference planning is very much a key demand on their time 
right now, since we're just a couple weeks from kickoff of their biggest 
annual event.

So the plan at the moment is to review the use-cases presented in light 
of precedent established by other GPL-governed projects, and to provide 
guidance on how that applies to the position LC is in with its dual 
licensing, sometime soon after the conference.

This has been a useful discussion, touching on specifics that are 
important to all of us.  So far, in my own view I haven't seen anything 
that can't be resolved to everyone's satisfaction, so I'm hopeful that 
once the core team has the conference behind them we'll be in a good 
position to reach a set of guidelines that will be productive for all.

In the meantime, Mark Waddingham's earlier suggestion may suffice for now:

If your project's goal is to share source code the GPL-governed 
Community Edition can be a good choice, and for any other goals the 
proprietary license as we've always had is available as well.

If there's a pressing circumstance requiring immediate action with 
regard to licensing, please write to support AT livecode.com and they 
may be able to work out special licensing considerations for your 
use-case, as they've done with their EULA terms for developers facing 
unusual circumstances in the past.

-- 
  Richard Gaskin
  LiveCode Community Liaison
  richard at livecode.org



Mark Wilcox 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-your-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