Summary: Open source, closed source, and the value of code

[Mark Wilcox]

I've hesitated to wade in on this but I think LiveCode's "official"
interpretation of the GPL is wrong and also a mistake. I thought that
there was a policy of encouraging those that produce libraries for other
developers to also dual-license them - I didn't realise that was only
supposed to be allowed for those with a commercial license.

I am not a lawyer. However, I did work for an open source foundation
(The Symbian Foundation - sadly a very short-lived one) and spent lots
of time studying the relevant technical and legal issues and talking to
our in house copyright and software licensing expert lawyer. I was the
person that wrote the licensing FAQs.

Also relevant to what I'm about to say:
1) I've consulted for Intel, Microsoft, Amazon, Google and (also now
almost dead but not because of my advice) BlackBerry on developer
ecosystem issues.
2) I'm a lifetime license holder from the original open source
Kickstarter campaign - I want LiveCode to succeed.
3) I don't actively use LiveCode... just try new bits occasionally. I'm
still waiting (since that original Kickstarter) for what has become v8
and hoping it's good!


First the legal... I really don't believe the GPL can apply to script
only stacks and probably not stackfiles either, just because they were
created with the community version. The case for standalones is much
stronger and I think LiveCode is pretty safe there.

A few points:
> The most critical thing to remember is that it is the *intent* of the 
> GPL that actually matters and not the current text of any particular 
> version. The simple reason for that is if the GPL is ever tested in 
> court and the outcome is not favourable or contradicts any 
> interpretation the FSF have made of it then the FSF will produce a new 
> version which closes any loopholes which have been exposed in the court 
> case.

Legally it is the text that matters and it's not at all certain that all
loopholes can be closed. The FSF are doing something quite ingenious but
they're attempting to extend copyright law in a way it was never
intended to go. Any license they can come up with is fundamentally
constrained by what constitutes a derivative work and what is or is not
fair use.

> The intent of the GPL is clear - it is fundamentally about building an 
> ecosystem of software where everyone has the right to contribute to it. 
> Nothing more, nothing less. It is not an economic force (and thus has 
> nothing to do with money) it is a creative force. It is about ensuring 
> that if I receive a piece of software then I also have the right to 
> modify and adapt that software and distribute any such modifications.

Creating and distributing scripts or stackfiles with LiveCode does not
in any way interfere with the rights or ability of others to modify,
adapt and distribute LiveCode itself. The key distinctions from the
Joomla and WordPress plugin scenarios (where there are already plenty of
IP lawyers who'd disagree strongly with the FSF) are:
1) The GPL is designed to protect programs, not programming languages.
It specifically contains language that excludes "Standard Interfaces"
which are in common use amongst a programming language community. Given
it's a language that predates the company and has existed under more
permissive licenses in the past it'd be hard to claim it as exclusively
LiveCode's IP anyway.
2) The PHP code (which is the only part covered by GPL according to the
FSF, not CSS or images) in WordPress or Joomla plugins can only by
executed in the context of WordPress or Joomla respectively and those
are only available under the GPL. In the case of LiveCode scripts/stacks
they can be executed in the context of a non-GPL program - the
commercial LiveCode engine.

> Absolutely every piece of software is derived from a set of files which 
> can be considered the 'source code' - whether that be actual 
> source-code, artwork, music, prose, or whatever - which is then 
> processed using some set of tools to produce something that you can 
> actually run and use - this is always 100% crystal clear.

If it's absolutely 100% crystal clear what the 'source code' is when it
comes to the GPL and it includes things like artwork, then why would the
FSF even exclude the images and CSS from inclusion in WordPress and
Joomla plugins licensing under GPL? It's because the plugin case is a
real stretch for the GPL - we're talking original creative work that
would be usable in another non-GPL covered environment (see point 2 in
the previous section).

> The point here is very subtle but I do believe it is happily 
> covered by the standard notions of 'derivative work' and there is a 
> simple acid test: could you have written the content of your 
> script-only-stack text file without using the ideas, notions and 
> existence of LiveCode?

This is not at all the standard notion of 'derivative work' in copyright
law. The law in many large countries (including the US, which I believe
is LiveCode's biggest market) explicitly does not cover "ideas and
notions", it only covers "fixed representations in a tangible medium" -
i.e. bits of text and images.

Second, the ecosystem aspects...

So, if I'm a supporter of LiveCode and I've already paid for a lifetime
license, why risk pulling apart potential revenue streams for the
company by attacking their GPL stance? Basically because I think it's a
mistake to put any kind of restriction (even freedom preserving
restrictions) on developers sharing code amongst one another. If
LiveCode want to make money from developers selling libraries or
extensions to one another then the way to do that is make sure their
marketplace is the best place to discover such libraries and take a cut.

I think it's a mistake to restrict developers sharing code in whatever
way they see fit because of this:
> we are close to releasing LiveCode 8 which we hope will be as transformative 
> for the LiveCode ecosystem as the explosion in VBX/OCX controls were to 
> the Visual Basic world.

The transition from hobbyist to professional often starts by making
something useful for yourself and deciding other people might want to
benefit from it too. If you share the ethos of the FSF then you might
release that under the GPL - but then it's useless for the commercial
developer population that actually pay for LiveCode. So what would be
better for the community is either sharing that under a very permissive
license (which is very public spirited but not everyone will see why
they should), or keeping it proprietary and selling it for a small
amount of money. Given the size of the LiveCode commercial ecosystem and
developer ecosystem in general, there is clearly not a huge business to
be made selling libraries and extensions to other developers (Monte
would no doubt attest to this). Most hobbyists creating libraries
probably couldn't easily justify the license cost given they have to
maintain their library and spend time on support once they start selling
it commercially. I believe it'd be better for the whole LiveCode
ecosystem (and probably a bit less hypocritical) if LiveCode officially
allowed community edition users to keep their own work proprietary when
not distributed in combination with the engine but also encouraged them
to follow their own model and dual license under GPL and commercial
terms so that everyone in the community can benefit.

That's my informed but certainly not definitive take. Certainly rather a
lot more than 2 cents worth, so thanks for reading if you got to the
end.

Mark