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 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode