Indy Users Can't Use Community Code, Share Code or Buy Cod

[deadparrotsoftware]

My objective here is to be told we are wrong, and posted here because the answers affect all LiveCode users, possibly even the future of LiveCode. It is a legitimate concern and question, and we like to see some public elucidation. (This has been discussed on the email list, including by users whom are lawyers. The questions and information are disturbing).

I have simple questions, but first a preamble: Six months ago, we decided to embrace LiveCode. I stupidly did not actually read the EULA, and committed time, money and resources to LiveCode. We are Indy. We contributed to efforts such as Infinite LiveCode.

We even went further: we informed the 14,572 programmers using our other software tools we would be converting our tools to LiveCode (Ironically, I received over 156 negative emails about that announcement, revolving mostly about the expense of LiveCode and the licensing). I even have meetings scheduled with our county school board to discuss using LiveCode as part of their STEM initiative. So we have invested a lot in LiveCode, but have concerns.

All of that is on hold for the moment. Based on how the LiveCode EULA reads to us (I have added extracts from the EULA below), I have simple questions:

1) Does LiveCode, as it appears, consider any product or code created with LiveCode a "derivative work" of LiveCode and thus under the control of your license?

[Such as not being able to sell our created code or have others resell our Apps]

2) Does LiveCode consider it a violation for Indy users to use/include ANY code/widgets/stacks/cards etc. created by others - whether purchased from them, or 'released' by them - AND a violation to use/include any code/widgets/stacks/cards etc. that were created using the Community Edition?

3) Specifically, does LiveCode EULA

...prohibit sharing code/widgets/stacks/cards - snippets or otherwise, between community users and Indy business users ?
...prohibit using any code/widgets/stacks/cards created by others (in any edition)?
...prohibit dual licensing?
...prohibit Indy users from using ANYTHING created on the Community Edition?
...prohibit Indy from doing what we want with code/widgets/stacks/cards we create - OUR intellectual property?
...prohibit Indy users from using any code/widgets/stacks/cards created by sub-contractors/work for hire?

(Could you imagine anyone ever using JAVA if Sun Microsystems had such a restrictive license?)

4) Does LiveCode intend to keep these restrictions as is?

I would like a simple yes/no answer to these questions - not looking for debate about why, or debate if the EULA license is even enforceable, or if it's allowed under current Copyright Law, etc., etc.

If the answer to these questions is "yes," the restrictions will affect all of us. And the future of LiveCode becomes not a matter of their vision or the innovation, but one crippled by overly-restrictive licensing issues. I would hate to see that, much less see our commitment to LiveCode become a mistake. The best, most innovative tool in the world is useless if using it is excessively restrictive and legal nightmare.


Sid​ B.​


​VP, Marketing
Dead Parrot Software Inc.

​Some excerpts from the EULA:​

​From Section 1​

​ ...Licensed Edition does not include access to the LiveCode engine source code found in the Community Edition. This Licensed Edition is not compatible with the terms of the GPL and such software may not be incorporated or utilized with this Licensed Edition...

[You can not use ANY code, stacks, cards, widgets, etc. created on the Community Edition EVEN IF created by you. THEY chose the "incompatible GPL" license for the community edition. Could have used MIT2, LGPL, etc.]

...create derivative works based upon these Restricted Files. [the LiveCode files] Using any of the Restricted Files with an edition of LiveCode other than the one it was distributed in is also prohibited. This exclusion includes but is not limited to prohibiting you from using the Licensed Edition to build a standalone using or incorporating GPL code....

[Again, You can not use ANY code, stacks, cards, widgets, etc.]

From Section 2

The general purpose of the restrictions in this section is...intended to prevent conferring on holders of any other LiveCode license, including the Community Edition, the ability to create software equivalent to what can be normally only be created by holders of this Licensed Edition...

[convoluted, but you can not create code/widgets for the Community Edition if you are Indy]
​
From Section 3

...You are prohibited from using the Licensed Edition to build standalone applications for others where You are not the author of the application...

[No sub-contractors, work for hire programmers, etc. for code OR for widgets]

...You are prohibited from using the Licensed Edition to password protect or otherwise secure LiveCode stacks substantially created by anyone other than You...

[No code sharing or using Community addition code or sub-contactors or work for hire, etc.]

This clause is intended to prevent you from conferring the ability to others to distribute closed-source applications, including stacks, without [them] purchasing a license.

[ no one can resell or distribute products you create, even with your permission or license]

​There are other sections equally...unsettling.​

[FourthWorld]

None of the users in this user-to-user support forum act as counsel for LiveCode Ltd. If you're replying to a thread from another discussion venue, you may want to reply to that original discussion. Or better yet, you can get an authoritative response quickly by sending questions about LiveCode Ltd.'s EULA directly to the good folks there at support AT livecode.com.

As for your STEM initiatives, we have several projects in the EDU Outreach section of these forums which may help, all using the open source edition of LiveCode to encourage free sharing and modification for everyone.
http://forums.livecode.com/viewforum.php?f=107

If I can be of help with your open source educational initiatives drop me a PM and I'd be happy to see what I can do for you.

[deadparrotsoftware]

True Richard, but LiveCode does monitor these forums, and this affects everyone. Besides, on the email list I was never given permission for my post (2 days ago) to appear by the moderator and got no reply as yet from LiveCode.

Our interpretation stems from OUR counsel. His advice was to avoid committing to LiveCode.

Also, the EULA implies the open source users can not share code the way educational classes and groups would, and that school groups could not publish an App. But I do appreciate the info on existing initiatives.

Sid B.

[FourthWorld]

True Richard, but LiveCode does monitor these forums...

Support staff periodically take time away from their the email and phone support queue licensees pay for to lend a hand here when they can, but this forum's purpose is for user-to-user support.

...and this affects everyone.

In theory yes, but in practice perhaps not as much as one might think.

Many open source projects have a small number of members of their community who post a large number of questions about intellectual property policy. We see these in the Wordpress and Ubuntu forums and others, and LiveCode is no exception. This is especially understandable with LiveCode given that most of its current audience has little if any prior experience with open source.

The salient thing is that the questions raised in that thread involve fairly specialized use cases, things we don't normally see in daily work. In fact, every participant in that thread noted that their work involves delivery of proprietary software, and they have appropriate licenses for their team members so they're already set.

The basic principle is pretty straightforward: the open source edition is for making open source software, and the proprietary editions are for making proprietary software.

That simple guidance has been working well for thousands of LiveCode developers for many years, GPL advocates and proprietary publishers alike.

The hypothetical questions are interesting, and I believe they merit addressing, perhaps as additions to the FAQ on the site which currently handles many related questions:
https://livecode.com/resources/support/ask-a-question/

But we haven't seen anything yet which has prevented anyone from doing what they need to do.

We have occasionally seen users of the proprietary editions which have unusual licensing needs, and as noted in that thread they've been able to discuss their needs with LiveCode Ltd. and reach a good arrangement that works well.

On the open source side, LC's interpretation of the GPL is very similar to that of the Wordpress, Drupal, and Joomla projects, all of which explicitly regard all plugins, modules, and even themes as "derivative works" which inherit the rights and responsibilities of the GPL:
https://wordpress.org/about/license/

Of course all of those projects have no proprietary option at all, so while some participants in that thread questioned the collective judgment of those other projects, most of the questions related to explorations of mixing license types defined by each license as incompatible with the other.

Everyone agreed that standalones are a clear-cut case, and that the GPL is a good fit for a dual-licensed projects like LiveCode. The relatively few remaining issues focused around the subset of the subset of cases which involve transfer of ownership of a non-standalone work to a licensee of a proprietary edition of LiveCode. This is among the things the team aims to provide guidance on after their conference in a couple weeks. Anyone with a more time-sensitive need for guidance is encouraged to contact the company to discuss it.

Perhaps the best part of that discussion was that everyone expressed strong appreciation for the unique value LiveCode provides. They recognize that it's very expensive to produce (indeed I haven't seen another tool that offers its feature set on as many platforms), and company and community alike seek solutions which work well for the continuance of the platform.

For comparison, consider the Xojo EULA (which, like LC, has had its share of license discussions in its forums): they have no Android version, no open source option, and their EULA contains many restrictions not found in LiveCode's:
http://www.xojo.com/download/eula.php

Rather than get too concerned about specific sentences in isolation, it may be helpful to review the LiveCode EULA in its entirety. There we find the limitations rather reasonable for both self-publishing and contracting (indeed, I'm among the many developers who earns my living from contract work):
https://livecode.com/eula/

The challenge with tools like LiveCode, Xojo, and a few others is that they're so powerful they make it fairly easy technically to deliver a product that directly competes with them. Of course that wouldn't be in the interests of either the company or the developers who rely on them, but rather than simply use a different file format for the proprietary version, LiveCode seeks to address this in its licensing, keeping the feature set as rich and productive as they can. The restrictions in the EULA are there to aim for an appropriate balance between developer freedom and vendor sustainability, and one could argue that LiveCode manages this in a less restrictive way than Xojo and perhaps others.

Besides, on the email list I was never given permission for my post (2 days ago) to appear by the moderator and got no reply as yet from LiveCode.

I don't understand, as apparently you're already subscribed to that list and have successully posted there in the past, e.g.:
http://lists.runrev.com/pipermail/use-l ... 27095.html

Our interpretation stems from OUR counsel. His advice was to avoid committing to LiveCode.

True, distributing software under the GPL may not provide an ideal business model for all companies.

But it's worth noting that Wordpress, Drupal, and Joomla are all distributed under the GPL as well, yet have thriving aftermarkets for add-ons even though all three explicitly regard all plugins, modules, and even themes as "derivative works" which inherit the GPL:
https://wordpress.org/about/license/

The GPL expresses no opinion about cost, only about preserving the right of the recipient of the work to copy, modify, and share the software. This works well for some companies, but not others.

Your counsel can advise on how it fits your specific business model better than I can.

Also, the EULA implies the open source users can not share code the way educational classes and groups would, and that school groups could not publish an App. But I do appreciate the info on existing initiatives.

Happy to help if I can.

FWIW, I've learned from experienced educators in our community like Tore Nielsen and others that while iOS deployment seems initially seductive as part of a curriculum, in practice the mechanics of deployment are so cumbersome (they often challenge most adult professionals to the point of pulling their hair out <g>) that kids burn out on it pretty quickly and get back to making and sharing software on their laptops.

Since the GPL is only incompatible with the terms of the Apple app store, and poses no imepedence for delivery to any of the many other platforms LiveCode supports, the Community Edition has proven a good fit for many EDU contexts.

In fact, the freedom to copy, modify, and share work under the GPL can be a real boon for educators, allowing them to expand on works by others for a more rapid proliferation of courseware than is often seen under licenses that have less of an explicit focus on sharing.

[deadparrotsoftware]

Richard,

I disagree - I think license restrictions affect everyone. The EULA - not I - specifically stats that code created on the open source edition (for whatever purpose) is not to be used by Indy's - even if the author "releases" it. That you can not use code you didn't author, etc., etc. etc. Those are BIG deals. They affect anyone who has been developing with LiveCode, especially anyone who wants to do anything commercial. And the EULA was reviewed in it's entirety, because we DO create and publish Apps for others, we sell code, we may ed up selling widgets and stacks. All of that is affected by this EULA. You might want to revisit the EULA with your lawyer.

[BTW: The Xojo license does NOT have those sort of "sharing code" restrictions, though it has others (they don't have an open source edition, so that doesn't apply, and they could care less if you created all the code in your App all by yourself, as long as the person publishing, and owning, the App has a Xojo license. We asked them too, because we have 3 commercial products written in Xojo, for us, by a sub-contractor).]

There are several different "open source" licenses besides GPL that I suspect would have worked better, as far as their stated "conflict" goes.

I am a subscriber to the livecode discussion email list, but my post about this - basically the same as here - went to "moderator," but never published.

Emails to LiveCode were also never answered on this subject.

But as I said, I believe these questions need to be answered by LiveCode - not in debates back and forth between us.

What we can do, what we can NOT, delineated In English, not legal-con. Because if the interpretation/explanation our guy gave us is correct, then LiveCode has crippled it's own innovation with ridiculous restrictions. Frankly, I hope that is wrong.

Sid

[FourthWorld]

Emails to LiveCode were also never answered on this subject.

I can't speak for what may have happened to that email, but if you'd like to send your email to me privately I'll be happy to steward it to an appropriate person within the company.

One the rest, it seems we agree on some points and not on others. Happens. Like the vast majority of developers who've been enjoying professional work with LiveCode for many years, the EULA is satisfying for my needs and those of my clients, and the GPL is satisfying for those projects where sharing software freely is the primary goal.

[deadparrotsoftware]

Yes we do - but our responses, are not the responses that matter on this subject.

And I thought as you about the EULA, till I got the phone call that said "you need to stop and reconsider this based on what I have read". Hence my quest for . . . elucidation.

I appreciate the offer to help. I should be able to use normal channels though, and will try again. If that fails . . .

Sid

[richmond62]

I don't know what a lot of this "fluff" is about.

1. I make stacks using the Open Source version which I share both 'here' (the Forums) and 'there' (https://www.facebook.com/RMLCclasses/ among other places): nobody
has told me I'm doing anything wrong.

2. Before the advent of the Open Source version of Livecode a very large number of our community shared stacks left-right-and-centre without so much as
a raised eyebrow from the Livecode people: these were, obviously, generated from Commercial versions of Livecode/Runtime Revolution.

3. If I use somebody else's code from a stack they have made available freely online it is only good manners that I give them some sort of credit.

4. As far as I understand the nature of Open Source software, it is for "pinching", modifying and redistributing; and that includes in a commercial setting, although stuff that is licensed under
any of the copyleft things has also to have its source code made available so that people can play with that, modify and redistribute it should they so choose.

5. To illustrate this look at Linux distributions; there are FREE ones, semi-Free ones, and completely commercial ones: they would all be
"completely lost" without the Open Source Linux kernel.

HOWEVER: I could be 100% wrong and totally deluded; so revert to Livecode so they can give you a definitive ruling.

[richmond62]

Come to think of things:

1. I have a license for Indy Livecode.

2. I use the Community version (Open Source) 90% of the time.

Sharing a stack generated from any form of Livecode should be the same unless there is functionality in that stack that is available, say,
in the Indy version and not in the Community version.

[deadparrotsoftware]

Richmond62,

What you have been doing is the same thing we ALL do in development environments. To share and reuse code is normal, even essential. We all assume that we can do so, as we have been for years. YET, the EULA says "...This Licensed Edition is not compatible with the terms of the GPL and such software may not be incorporated or utilized with this Licensed Edition..."

You are correct: even the most restrictive "open source licenses" allow for "commercial" use as long as you make whatever open code that was used available to users (i.e., include access to THAT portion of your APP code) - even if the rest of the code is proprietary. We HAVE products that have incorporated some GPL code - So I personally don't even see the "GPL Conflict" they say is there. Or why, if true, with so many different GPL license (ver 2, ver 3, LGPL, BSD, MIT, etc.) available, select one that is "incompatible"? YET, the EULA says: " ...prohibiting you from using the Licensed Edition to build a standalone using or incorporating GPL code...." . That is not "fluff"

We DO have commercial Apps in Apple that were actually created by sub-contractors, and so we are not the "authors" - and thus would be in VIOLATION to publish - IF we had used LiveCode - based on clauses like "...prohibited from using the Licensed Edition to password protect or otherwise secure LiveCode stacks substantially created by anyone other than You... "

We write Apps for others (some published by them, some by us), we do - and could - use sub-contractors (and would have NO idea which version of LiveCode they actually used), we sell source, we share source, etc. All of which is affected by the EULA. But you have little gotchas like
"...You are prohibited from using the Licensed Edition to build standalone applications for others where You are not the author of the application..."

And there are other issues, so the "fluff" comes when a lawyer looks at the EULA and tells you "there are problems here you are not aware of". I stupidly did not read the EULA at first, and should have known better since we have been burned in the past by such hidden/sleeping issues when a legal letter arrived!

This started, when we posted to the 14000+ programmers that use our software making tools that we were committing to LiveCode, and we got nearly 200 negative emails mostly revolving around cost and license issues - "LiveCode is expensive" "They are greedy and always asking for money" "There license is ridiculous" - and even had dozens of programmers send us quotes from the EULA itself. Which is why I asked a friend, a copyright lawyer, to give us an opinion. The advice was to walk away from LiveCode.

We don't want to do that. We are hoping we are wrong here, and trying to confirm that. LiveCode is a great innovation, but won't grow in acceptance if these licenses restrictions are what we fear they are, and are not changed. Developers just won't sit still for being told "even if you are a paying commercial user, you can't use code you didn't write yourself, or include ANY open source code in your Apps, or blah blah blah" - even if being able to track that to enforce it is somewhat problematic. There are too many other choices - and they, are getting better and growing fast.

Sid

[richmond62]

"...You are prohibited from using the Licensed Edition to build standalone applications for others where You are not the author of the application..."

Well: I know why that one is; it's so, for the sake of argument, I don't set up what we could call a "Standalone Farm", where I charge you a modest fee for
lobbing me code you have written using the Open Source version, I then password protect the stacks and hive off standalones for whatever platforms
you require; thereby completely undercutting Livecode and obviating the need for you to have a Commercial license.

Some of the other phrases sound a bit odd:

" ...prohibiting you from using the Licensed Edition to build a standalone using or incorporating GPL code...."

Until I reflected on the probable fact (hey, I have a Philosophy degree) that a stack authored on my behalf by my son using the GPL version does not
in and of itself contain GPL code, so he can send it to me to add as a substack to my killer app.

A lot of this is a bit silly as well, as, for the sake of argument, my Devawriter Pro, which was authored for its first 4 years on Livecode versions 4.0 and 4.5
"crossed the lines" the other day, and I had to do lots and lots of fairly tedious search & replace operations to rejig the code for Livecode 7.1.4 and/or 8.1.

I chose to use the Community version of Livecode 7.1.4 because I had spent some time "buggering about with" the Find & Replace stack of the IDE (revSearch) so
it served my requirements better: I couldn't be bothered to crack open my Indy version of Livecode 7.1.4 and rejig the revSearch stack there all over again.

I then transferred my Devawriter Pro source code over to my Indy version to do the standalone builds so people with poky noses cannot poke their noses
into my code.

Now when I opened my stacks in the Indy version of LC 7.1.4 there wasn't socking great notices splattered all over the stacks saying: this has its origins
on the GPL version of Livecode: and why should there be forbye?

I understand " ...prohibiting you from using the Licensed Edition to build a standalone using or incorporating GPL code...."
to mean that one cannot build a standalone using the Indy version that has a stack taken from within the LC GPL IDE bound up in it as a substack.

For instance; I could "rip-off" my modded revSearch stack from the GPL version, bind it onto a stack of mine as a substack; port it over to the Indy version
and pump out a standalone; that would contain GPL code; and that would be naughty.

[jacque]

I don't know the specific legalities, and the LC team should feel free to correct me, but I do know the company, its team, and am confident of the intentions of the license. That is simply to prevent Indy users from compiing closed-source software for others who have not paid for the feature set.

1) Does LiveCode, as it appears, consider any product or code created with LiveCode a "derivative work" of LiveCode and thus under the control of your license?

[Such as not being able to sell our created code or have others resell our Apps]

You may create and distribute stacks freely with a single exception noted below. That is clear because not only does LC support the user Sample Stacks online area specifically to allow this, but also has always encouraged sharing by everyone. The restrictions would apply, I believe, if you want to use features in the stacks that are not available in the OSS version -- primarily at this point, password protection. You can still distribute those, but only if you own an Indy license (which you'd need anyway in order to implement password protection.) However, users of the Community edition could not distribute work that includes your protected stack because it violates the GPL.

2) Does LiveCode consider it a violation for Indy users to use/include ANY code/widgets/stacks/cards etc. created by others - whether purchased from them, or 'released' by them - AND a violation to use/include any code/widgets/stacks/cards etc. that were created using the Community Edition?

3) Specifically, does LiveCode EULA

...prohibit sharing code/widgets/stacks/cards - snippets or otherwise, between community users and Indy business users ?
...prohibit using any code/widgets/stacks/cards created by others (in any edition)?
...prohibit dual licensing?
...prohibit Indy users from using ANYTHING created on the Community Edition?
...prohibit Indy from doing what we want with code/widgets/stacks/cards we create - OUR intellectual property?
...prohibit Indy users from using any code/widgets/stacks/cards created by sub-contractors/work for hire?

No. LC wants to become the widest, most used software in the industry. It developed widgets and its new builder language to enable that. It encourages wide distribution of user-created tools for that purpose. I know this because I"ve talked to Kevin Miller about it, and he would like to see thousands of widgets distributed everywhere. Dual licensing is fine, and for those of us who sell on the LC Marketplace, we have received emails suggesting that we dual-ilcense our products so that they are available for everyone regardless of the user's license. You can freely distribute your products, sell them, give them away, whatever you want.

...Licensed Edition does not include access to the LiveCode engine source code found in the Community Edition. This Licensed Edition is not compatible with the terms of the GPL and such software may not be incorporated or utilized with this Licensed Edition...

[You can not use ANY code, stacks, cards, widgets, etc. created on the Community Edition EVEN IF created by you. THEY chose the "incompatible GPL" license for the community edition. Could have used MIT2, LGPL, etc.]

This section is talking about the engine source code, not the scripts in your stacks. The Indy engine is not GPL, it has additional code that is closed-source, and you cannot use an Indy edition to build OSS standalones because of that. If you want to create OSS software you will need to build it using the Community edition, which is compatible. This is not a very restrictive thing, since you can simply run your same stacks through the Community standalone builder for OSS distribution.

The general purpose of the restrictions in this section is...intended to prevent conferring on holders of any other LiveCode license, including the Community Edition, the ability to create software equivalent to what can be normally only be created by holders of this Licensed Edition...

[convoluted, but you can not create code/widgets for the Community Edition if you are Indy]

No, the key phrase here is "equivalent to". You can create stacks, widgets, etc. for any user. What you are forbidden to do is include capabilities that are not included in the OSS edition. So, you could not create password-protected stacks for users of the OSS engine. Since the rest of the feature set is identical (ignoring the Business license, which includes yet more unique features) anything non-passworded you produce with Indy will be equivalent to anything that can be produced with OSS. Widgets and scripts are equivalent in either edition so are allowed. Basically, at present, just about all capabilities are equivalent. The intent here is to prevent you from setting up a shop that provides Indy-level features for users who don't want to buy a license themselves. If they want passworded stacks they need their own license.

​

...You are prohibited from using the Licensed Edition to build standalone applications for others where You are not the author of the application...

[No sub-contractors, work for hire programmers, etc. for code OR for widgets]

Again, the intent is prevent you from setting up shop and building protected standalones for anyone who doesn't want to buy their own license. You can't become a standalone factory for code you didn't write yourself. If you are a subcontractor or work for hire, you have written the code yourself even though someone else may own it. LC is well aware that the majority of its professional users do work for hire and in no way desires to cut off our livelihoods.

There may be some unanswered questions here on whether only the actual developer needs a license, or both the developer and the client, or whether the developer can use the client's license.

...You are prohibited from using the Licensed Edition to password protect or otherwise secure LiveCode stacks substantially created by anyone other than You...

[No code sharing or using Community addition code or sub-contactors or work for hire, etc.]

No, this is again a prohibition against building password protected stacks for people who don't have a right to build those themselves. It's the same intent -- no standalone factories allowed.

This clause is intended to prevent you from conferring the ability to others to distribute closed-source applications, including stacks, without [them] purchasing a license.

[ no one can resell or distribute products you create, even with your permission or license]

Again no. It prevents you from building protected software for others who don't have a license to do that themselves. If you have an Indy license, you can build standalones from code that is (substantially but not necessarily wholly) your own, distribute however and to whomever you please, sell it or give it away, whatever you want. You can sell it to someone else who will in turn sell it. What you cannot do is give them the ability to distribute closed-source software that you compiled for them if they wrote the code and they don't own a license.

One more thing, which Kevin mentioned on the mailing list. The license is governed by the laws of Scotland. Your attourney is presumably in the US (I'm assuming here.) If that's true, then the advice you were given may not be completely applicable in another country. Regardless, I do know what the intent of the license is -- to prevent users from obtaining features they haven't paid for. It is not intended to restrict distribution of your own software, or restrict inclusion of other freely-available scripts or widgets (since those are "equivalent" in any edition.)

This is my common sense interpretation based on discussion I've had with the team. Some of it may be technically off base, and I hope they will correct me if so, but I am sure that what I've outlined is consistent with the intent.

[deadparrotsoftware]

jacque,

I appreciate your input, and as you have presented is probably the way it SHOULD be interpreted, and what it should actually mean. Unfortunately, according to the lawyer, it could also be interpreted as I have outlined, albeit briefly. And there's the rub.

The wording is vague, potentially misleading and subject to many interpretations - hence our wanting to see it simplified and clarified by LiveCode, not you or I. the EULA reads like an attempt to prevent piracy, cheating etc. - which you can't actually prevent with a license - and increase sales of the commercial editions by putting unreasonable restrictions on the use of the open license, especially for anything serious. It is not written well, from a legal standpoint, especially for Indy users.

The "normal" GPL v3.0 license (and others) does not conflict or prohibit commercial use of open code, and frankly, there should be no restrictions on commercial users (stated or intended) to use and publish Apps with both the open code and commercial code, for themselves, for anyone (why would one want to pay for it otherwise?).

Again, for us to debate is interesting - you would be amazed the number of different interpretations I have seen in the last week! - but what we need is elucidation from LiveCode. And frankly, it should be published so that anyone considering liveCode sees, and knows.

[richmond62]

I don't know if any of the Livecode staff are reading this.

But, surely, the sensible thing would be to write to Heather with your questions and request a ruling.

Oh; and it might be a good idea to leave out "Buy Cod" as Livecode are not, as far as I know, in the fish industry :/

[FourthWorld]

the EULA reads like an attempt to prevent piracy, cheating etc. - which you can't actually prevent with a license

Yes, given that piracy is an attempt to use a software outside of the terms of its EULA, by definition that's true for all software. The EULA expresses the intentions of the copyright holder, allowing the recipient to determine if those terms fit their needs. But by itself, no EULA can prevent actions by those who may attempt to thwart the intentions of the copyright holder, just as no door lock can prevent a burglar from entering through a window.

The "normal" GPL v3.0 license (and others) does not conflict or prohibit commercial use of open code

The GPLv3 license included with LiveCode Community Edition is the same GPLv3 you'll find with any other project that uses it.

The GPL expresses no opinion about price, as Kevin and others have noted many times. In discussions relating to the GPL the word "free" refers not to price but to freedom ("libre", as opposed to "gratis"), the specific freedoms granted in the license allowing recipients of the work to copy, modify, and redistribute the work.

As Richard Stallman reminded me over dinner one night, he used to charge a fee for floppy disks containing his GNU utilities. Nothing in the GPL restricts or requires pricing at all.

The key provision of the GPL, and indeed the reason why so many free/libre software advocates choose it, is that any recipient of a software distributed under it has the right to also have the source code for it, and has the freedom to modify that source code and redistribute their modified versions by any means and at any price they like, or at no price if they prefer. The GPL also notes that the recipient has the responsibility to maintain these freedoms downstream, providing source code to recipients of any derivative works, and granting their recipients the same freedoms, so that the chain of sharing is unbroken and the software can proliferate for everyone to use and enhance as they see fit, so long as that use conforms to the terms of the GPL required to remain attached to it.

Again, for us to debate is interesting - you would be amazed the number of different interpretations I have seen in the last week! - but what we need is elucidation from LiveCode.

Agreed. There are wildly differing opinions about intellectual property all over the Internet, so when one seeks to employ the fruits of another's labor, if questions arise it's best for the recipient of a copyrighted work to seek answers from the copyright owner.

While you're waiting to hear back from LiveCode Ltd., you may want to write to the Wordpress team as well. On their License page they note:

Part of this license outlines requirements for derivative works, such as plugins or themes. Derivatives of WordPress code inherit the GPL license.

https://wordpress.org/about/license/

Given their interpretation that all plugins and themes must be distributed under the GPL, any site that attempts to impose restrictions on modifying or redistributing any Wordpress plugin would appear to contradict the terms of Wordpress' license.

If their reply to you is any different from their published opinion, please let us know how that works out.