Licensing AGAIN [was: Sharing FontLab Plugin]

[Mark Wilcox]

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