Open source, closed source, and the value of code

[Richard Gaskin]

While doing some research on Xanadu and Memex this weekend I came across
this video of Bill Atkinson which seemed relevant to some of our recent
threads here about the value of code:

"HyperCard was always an authoring environment, it
was never just browsing. I didn't separate the guys
who consume the information from they guys who create
it. I was open source before open source was cool,
because you could open up any HyperCard stack, any
button, and look at what it does inside.

"The primary requirement of the HyperTalk language was
that it be readable by somebody that can look at it
and see what was going on - 'Oh, on mouseUp, go to
next card' - somebody could see that and maybe modify
it a little bit.

"Every HyperCard stack that you got had buttons and
things in it and people learned from each other. It
was kind of an open source programming environment
because people exchanged HyperCard stacks. It was
sort of Github before Github."

As we explore the relative merits of different licenses here, both
proprietary and open source, I think it's helpful to remember how most
of us got started: we got a stack from a friend or a user group CD or
from our local Wildcat BBS, we studied it, and we tweaked it.

Much of our learning came from experimenting with other people's stacks,
and the ones we found especially useful were often useful because we
could tailor them to fit our specific needs.

It isn't possible for any single code base to address all possible use
cases. And it isn't practical to rewrite every code base from scratch
just to get the other 10% of functionality we need from it.

Imagine how small the Web might be today if not for open source, if
every Web server had to be written entirely from scratch every time
someone needed a small change, or pay tens of thousands of $$ to some
company and wait months for the enhancement to be released.

The Web is rich and diverse because most of it is free and open, from
the browser engines that render it to the router OSes that deliver it to
the databases that store it to the applications that serve it.

Consider the world's most popular programming languages, as ranked on
the TIOBE index:
http://www.tiobe.com/tiobe_index

Nearly every one of them is open source, and the few that aren't remain
on the list only for historical reasons no new tool could reproduce, and
they aren't growing. With dev tools, growth is in open source.

There's still a vast range of opportunities for proprietary software for
end-users, but for tools and infrastructure the growth of open source is
both undeniable and unstoppable.

Better still, the relationship between the two is largely symbiotic:
much of the funding for FOSS projects comes from companies who earn at
least part of their revenue from closed source, and they're able to earn
that money by building their companies around tools and infrastructure
provided by the open source world.

Both proprietary and open source software are growing, rapidly, with no
sign of slowing in the foreseeable future.

And LiveCode is dual-licensed, able to play a valuable role for each.

When you're running a business that pays the bills from per-user
licenses, LC's Indy and other commercial licenses are among the smallest
expenses a company will have, even at the new rates.

But if you're not running a business, perhaps ask yourself: what is in
the code that's more valuable closed than open?

I've never written anything that any reasonably smart person couldn't
reproduce if they really wanted to. The value of my products isn't in
the code alone, but in a complete solution that includes documentation,
support, and strong relationships with customers that put them in the
driver's seat of feature development. Sometimes I write some nice code,
but if I'm being honest with myself I have to admit I'm not exactly
splitting the atom. :)

When code is shared many good things result. The very least that
happens is that some young soul learns from it, and gets inspired to go
on to make great things. After all, learning from other people's
HyperCard stacks is how most of us here got started.

For consultants, sharing code builds a reputation as a source of solutions.

For businesses, sharing code opens the door for enhancements from others
so your app can grow in capabilities beyond your own developer resources.

I met Ryan Sipes of the Mycroft AI project at the SoCal Linux Expo a few
weeks ago, and he says that what confirmed his hunch that taking his
product open source was a good idea what when he got his first pull
request just 20 minutes after putting it on Github:
<https://www.linux.com/news/software/applications/878287-mycroft-linuxs-own-ai/>


Open source isn't for everyone, and even when it is there are many
licenses for many goals.

But when the goal is sharing, GPL is a very good choice because it
ensures the chain of sharing can't be broken; no one can hoard the code,
everything distributed gets shared back to the community from which the
original work came so everyone can enhance it even further.

If you're building a business around per-user license fees, LC offers a
solution for that.

But if you're just having fun, sometimes the fun can be multiplied
through sharing.

All code that does something useful has value. But the value is only
sometimes optimally exploited through sale, and other times through
community enhancement and knowledge sharing.

[RM]

Whichever way one cuts things, the most widely used programming
languages such as PASCAL and C++
are as FREE as the air. As long as a language remains Unfree it is
unlikely to be adopted widely.
While Runtime Revolution / Livecode have, until comparatively recently,
only had a closed source version of their programming environment, they
have almost always had a "cheap way in" in the form of a
lines-of-code-limited version, or a stacks-only-version; and had they
not they wouldn't have got as far as they did before they released their
open source version.

At the moment I cannot entirely understand what the 'problem' is. There
is a FREE version of Livecode
which to all intents and purposes is a very large subset of an Unfree
version. The FREE version is so
powerful that any "hobbyist" (a very, very fuzzy category if ever there
was: a 'hobbyist' is a bit like the boy who buys a small box of Lego
bits . . .) should be fully satisfied.

Richmond.

[William Prothero]

Richmond:
I also find it hard to appreciate the seriousness of the problem. Seems like much ado about very little.
Best,
Bill

Whichever way one cuts things, the most widely used programming languages such as PASCAL and C++
are as FREE as the air. As long as a language remains Unfree it is unlikely to be adopted widely.
While Runtime Revolution / Livecode have, until comparatively recently, only had a closed source version of their programming environment, they have almost always had a "cheap way in" in the form of a lines-of-code-limited version, or a stacks-only-version; and had they not they wouldn't have got as far as they did before they released their open source version.
At the moment I cannot entirely understand what the 'problem' is. There is a FREE version of Livecode
which to all intents and purposes is a very large subset of an Unfree version. The FREE version is so
powerful that any "hobbyist" (a very, very fuzzy category if ever there was: a 'hobbyist' is a bit like the boy who buys a small box of Lego bits . . .) should be fully satisfied.
Richmond.
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Robert Mann]

hi folks, what is this fuss about?

First : no. The allegation about hypercard forcing the open source path on
all usage is not true. There was a command to protect a stack ("protect" of
course!) . And some interesting pieces of software were sold as protected
stacks.

And it is precisely that positioning which is about to be abandoned by
livecode and why i think it's going backwards (with LESS) rather than going
forward (with MORE).

What the fuss is NOT :
1) I never questioned the Open Source version of Livecode. it's fantastic
and needed.
2) I never questioned the Commercial version. Again it's great and helps
going forward.

What I questionned is that we're going to be missing an intermediate
tool/license that would allow somebody to close SOME of his work at a
reasonable cost for a hobbyist. Just as was originally designed in
Hypercard.

Now most reactions are : if it is to play around just don't bother and
distribute as open sourced. Ok guys.
But things are not just that "idealistically" simple. Sometimes you just do
not know yet. And wish to try out something. Because some people just do not
know everything in advance.

And on a deeper level, please, do pay attention that it is our whole
copyright system which is being thus challenged.
-- would you find it "ok" that everything you write with your open sourced
word processor be absolutely open sourced? Whatever you write? even if it is
your next brilliant patent?
-- same question for the various open sourced "tools" that allow to edit
pictures, drawings, videos and so on.

The fuss about is that in the present state of the license applicable to
open sourced livecode,
whatever you "write" with live code, if "given" "shared" to anybody else,
then becomes open sourced.
THe frontier between the tool itself (its modules etc) and the "day to day"
work you can produce with it have been blurred. Fine if that is what was
really wanted! But did we really all mean that???

Actually it would be interesting to precise what rights get open sourced in
a stack :
-- do all the media incorporated in a stack become open sourced when shared?
-- what about the copyright on the layout of the application ?
-- what about the writing of the documentation included?
-- what about the logo of the company/individual included?
-- what about the trade marks eventually?

What happens if you incoportate in a stack a specific copyright protection
for some elements.
There would be a kind of conflict there.

That is why, I thought it would not be a bad idea to keep a door opened for
some protection on some cases even for individuals indies etc. that will not
pay 999$ every year.

And if you think these question over copyrights and so on are just a do
about nothing, for most of us it is, clearly, but for Disney who managed to
extend the copyright period by another 25 years and more in effect it is
vital. A largest part of our economy will now more and more rely on these
rights.

Last : are there other computer programming languages that are open sourced
and that impose on all programs written with it to be open sourced same
way??

best to all,
Robert




--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701662.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Richard Gaskin]

Robert, I appreciate your thorough thoughts on this. You covered a lot
of ground, and you seem to have your mind well made up on open source
license options so I won't try to convince you of anything here, just
providing some links and background info for others who may share

Post by Robert Mann
First : no. The allegation about hypercard forcing the open source
path on all usage is not true.

I don't think anyone was claiming that. HyperCard was very clearly
released under proprietary license with specific terms and conditions.

Bill Atkinson's commented I quoted seemed more to reflect a good
appreciate for open process and for sharing in general, but in that
video he expressed so opinions about GPL or any other open source
license specifically.

Post by Robert Mann
What I questionned is that we're going to be missing an intermediate
tool/license that would allow somebody to close SOME of his work at a
reasonable cost for a hobbyist. Just as was originally designed in
Hypercard.

Originally HyperCard was given away for free with every Mac.

Indeed, once it became a product under Claris it proved difficult for it
to sustain itself economically.

FWIW, LC has experimented with a wide range of price points over the
years, including many that match price points suggested in recent
related threads here. If they had produced the sort of results hoped
for we wouldn't be having this conversation today.

Post by Robert Mann
And on a deeper level, please, do pay attention that it is our whole
copyright system which is being thus challenged.
-- would you find it "ok" that everything you write with your open sourced
word processor be absolutely open sourced? Whatever you write? even
if it is your next brilliant patent?
-- same question for the various open sourced "tools" that allow to
edit pictures, drawings, videos and so on.

According to the authors of the GPL, copyright of data output by a
program is different and separate from copyright of code:
<http://www.gnu.org/licenses/gpl-faq.en.html#GPLOutput>

Post by Robert Mann
The fuss about is that in the present state of the license applicable
to open sourced livecode, whatever you "write" with live code, if
"given" "shared" to anybody else, then becomes open sourced.

That is a distinguishing feature of the GPL and other related licenses.
And as Matt pointed out earlier this morning, there are many other
open source licenses as well, such as the MIT/X11 license he's using,
which differ in terms of downstream responsibilities.

Matt chose to obtain an Indy license so he can use MIT/X11 for the work
he produces from it.

Choosing the GPL-governed Community Edition means choosing GPL.

We have many options to choose from, so only those who choose the
GPL-governed edition are obliged to the terms they've chosen.

Post by Robert Mann
Actually it would be interesting to precise what rights get open
-- do all the media incorporated in a stack become open sourced when shared?
-- what about the copyright on the layout of the application ?
-- what about the writing of the documentation included?
-- what about the logo of the company/individual included?
-- what about the trade marks eventually?

Trademarks are very different from copyright. They require separate
filing, and have different enforcement requirements as well.

Regarding copyright of media incidental to a work, for the distinction
between code and output see the GPL FAQ link above.

Post by Robert Mann
What happens if you incoportate in a stack a specific copyright
protection for some elements.
There would be a kind of conflict there.

If those elements are code there may be a conflict, or not, if the
license of those elements allows it and is compatible with the GPL.

There are several questions in the FAQ I linked to above which cover a
wide range of circumstances relating to such circumstances.

Post by Robert Mann
And if you think these question over copyrights and so on are just
a do about nothing, for most of us it is, clearly, but for Disney who
managed to extend the copyright period by another 25 years and more
in effect it is vital.

It is true that the US government has allowed a single corporate to
revise its copyright law. Whether allowing such a practice is useful
for the general public has been the subject of much debate both in the
US and abroad, and is - thankfully - beyond the scope of this list. :)

Post by Robert Mann
A largest part of our economy will now more and more rely on these
rights.

Yes, the "founding fathers" of the United States drafted the
Constitution with explicit provisions for providing for protection of
copyrights because they believed intellectual property was valuable.

The Berne Convention which makes the GPL and all other distribution
agreements possible has been signed by more than two-thirds of the
world's nations.

Protecting copyright is generally considered valuable so that creators
of original works have the right to choose the terms of the distribution
of those works. Whether they choose an open source license or a
proprietary one is up to them.

Post by Robert Mann
Last : are there other computer programming languages that are open
sourced and that impose on all programs written with it to be open
sourced same way??

Using the TIOBE index ( <http://www.tiobe.com/tiobe_index>) as a guide,
we can look at several there:

Java: mixed somewhat like LC, with a proprietary version and a
GPL-governed OpenJDK.

C, C++: my understanding is these are open specifications; tools
implementing those specifications vary, but among the most
popular compilers is GCC, the Gnu C Compiler from the same
folks who wrote the GPL.

Python, PHP: both open source, but under their own unique terms.
Their licenses are generally considered more "permissive" than
GPL in that they have no "copyleft" provisions (downstream
requirements for adhering to the same level of openness they
offer), but it's worth noting that the Wordpress, Drupal, and
Joomla projects are among the world's most popular systems
built on PHP and all three explicitly define all themes,
modules, and other add-ons as "derivative works" per the GPL
and require GPL for such works:
<https://www.drupal.org/about/licensing>

VB.net: Historically proprietary, with a subset recently release as
open source under MIT license.

Delphi: Proprietary, though a GPL-governed variant is available
through the Lazarus project.

Ruby: Open source under BDSL

Swift: Mostly open source now (language only, I don't believe any of
the Cocoa framework needed for effective use of it on iOS is
included in that) under Apache v2 license.

R: Dual-licensed under MIT or GPLv2

Groovy: Like most projects stewarded under Apache, uses Apache v2

Scratch: dual-licensed under MIT or GPLv2.

There are a lot more listed there, too many to cover here but each has
its own license info that can be found if interested.

For a broad view of FOSS license adoption this chart has a breakdown
showing license popularity by project count:
<http://redmonk.com/sogrady/2014/11/14/open-source-licenses/>

While MIT and Apache are growing in popularity, GPL's family of licenses
(v2, v3, AGPL and LGPL) continue to dominate.

[Roger Guay]

I couldn’t agree with you more, Robert. Plus, I will point out again, that this is another potential revenue source for LiveCode.

Cheers,

Roger

Post by Robert Mann
What I questionned is that we're going to be missing an intermediate
tool/license that would allow somebody to close SOME of his work at a
reasonable cost for a hobbyist. Just as was originally designed in
Hypercard.

[RM]

Post by Roger Guay
I couldn’t agree with you more, Robert. Plus, I will point out again, that this is another potential revenue source for LiveCode.
Cheers,
Roger

That, now, makes sense. A sort of halfway house.

There was (amidst the plethora of purchasing plans that have come and
gone) a way to
have a month's licence; so one could develop one's stack using the
Community version
and then purchase a month's worht of commercial to hive off protected
standalones; whether that is still available I just don't know having
stuck with the Community version right from when it was released.

Richmond.

Post by Roger Guay

Post by Robert Mann
What I questionned is that we're going to be missing an intermediate
tool/license that would allow somebody to close SOME of his work at a
reasonable cost for a hobbyist. Just as was originally designed in
Hypercard.

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Monte Goulding]

I believe the monthly subscription was dropped at the time of the open source release for exactly those reasons. Funnily enough LiveCode developers need to pay the bills too so need to avoid enabling people to game the system. One of the issues of course is that there really might only be a handful of users that can't afford Indy and can't or won't use Community.

Sent from my iPhone

There was (amidst the plethora of purchasing plans that have come and gone) a way to
have a month's licence; so one could develop one's stack using the Community version
and then purchase a month's worht of commercial to hive off protected standalones; whether that is still available I just don't know having stuck with the Community version right from when it was released.

[Roger Guay]

Do you include those who might want to publish to the Mac App Store and IOS in your estimate?

Roger

Post by Monte Goulding
One of the issues of course is that there really might only be a handful of users that can't afford Indy and can't or won't use Community.

[Monte Goulding]

Roger if you are suggesting you would be happy with Community if you could publish GPL apps to Apple's stores then that's probably something to take up with Apple.

Sent from my iPhone

Post by Roger Guay
Do you include those who might want to publish to the Mac App Store and IOS in your estimate?

[Roger Guay]

Monty,

I’ve tried to be clear about this. I am not complaining, nor am I upset with anyone. I have only good wishes and intentions for LC and users of LC. I’ll get along with whatever LC brings to my future. But you know better than I, that Apple is not going to be moved. So why not make lemonade out of this lemon: Once more, I point out that this might be a good new revenue stream for LC!!! Does it hurt anyone?

Roger

Post by Monte Goulding
Roger if you are suggesting you would be happy with Community if you could publish GPL apps to Apple's stores then that's probably something to take up with Apple.
Sent from my iPhone

Post by Roger Guay
Do you include those who might want to publish to the Mac App Store and IOS in your estimate?

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Monte Goulding]

Post by Roger Guay
Once more, I point out that this might be a good new revenue stream for LC!!! Does it hurt anyone?

I guess it could hurt everyone that depends on the platform if it undercut the Indy license too much. One thing we know for sure is that with the Indy price rise being staged effectively over a couple of years since the first rise that the company is being more than fair with its current user base by giving them the opportunity to lock in current prices for the long term.

Whether as the price of Indy rises a space is created for some kind of Indy Lite remains to be seen. However, I might suggest it would be difficult to find the right mix of features for it… Should it have no code protection but still allow proprietary licenses? Perhaps it should be royalty based or only allow free apps? Maybe it should have splash screens on standalones? Maybe individual platform licenses? What about a set fee per platform per standalone build? Maybe everything that can be easily removed from LC could be an addon at extra cost (database, xml, widgets etc)?

So many options that even if the company had something in this space it still won’t meet everyones needs.

Cheers

Monte

[Matt Maier]

Maybe they could sell one-time exceptions. Like, give Livecode $100 and you
can compile one version of one app closed source. So many options.

Post by Roger Guay

Post by Roger Guay
Once more, I point out that this might be a good new revenue stream for

LC!!! Does it hurt anyone?
I guess it could hurt everyone that depends on the platform if it undercut
the Indy license too much. One thing we know for sure is that with the Indy
price rise being staged effectively over a couple of years since the first
rise that the company is being more than fair with its current user base by
giving them the opportunity to lock in current prices for the long term.
Whether as the price of Indy rises a space is created for some kind of
Indy Lite remains to be seen. However, I might suggest it would be
difficult to find the right mix of features for it… Should it have no code
protection but still allow proprietary licenses? Perhaps it should be
royalty based or only allow free apps? Maybe it should have splash screens
on standalones? Maybe individual platform licenses? What about a set fee
per platform per standalone build? Maybe everything that can be easily
removed from LC could be an addon at extra cost (database, xml, widgets
etc)?
So many options that even if the company had something in this space it
still won’t meet everyones needs.
Cheers
Monte
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[J. Landman Gay]

Post by Roger Guay
Once more, I point out that this might be a good new revenue stream
for LC!!! Does it hurt anyone?

Well, it could hurt the company if everyone suddenly decides they're a
hobbyist. But let's take the thought experiment a little farther. What
restrictions would you (anyone) put on a "hobbyist" license to
differentiate it from the regular Indy license? It would have to prevent
people from gaming the system.

[Roger Guay]

Well, what I suggested a few posts back was a license for non-profits and give-away apps. But, I completely understand if that turns out to be difficult to police. I’m only trying to help here!

Roger

Post by Roger Guay
Once more, I point out that this might be a good new revenue stream
for LC!!! Does it hurt anyone?

Well, it could hurt the company if everyone suddenly decides they're a hobbyist. But let's take the thought experiment a little farther. What restrictions would you (anyone) put on a "hobbyist" license to differentiate it from the regular Indy license? It would have to prevent people from gaming the system.
--
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[J. Landman Gay]

I know you're a supporter Roger, I didn't mean to imply criticism. I was
just curious what people would think a fair licensing scheme would
include. I guess I did miss your original suggestion. I also wonder how
a hobbyist license should be enforced, or if it should just be an honor
system.

Post by Roger Guay
Well, what I suggested a few posts back was a license for non-profits
and give-away apps. But, I completely understand if that turns out to
be difficult to police. I’m only trying to help here!
Roger

On Feb 29, 2016, at 7:45 PM, J. Landman Gay

Post by Roger Guay
Once more, I point out that this might be a good new revenue
stream for LC!!! Does it hurt anyone?

Well, it could hurt the company if everyone suddenly decides
they're a hobbyist. But let's take the thought experiment a little
farther. What restrictions would you (anyone) put on a "hobbyist"
license to differentiate it from the regular Indy license? It would
have to prevent people from gaming the system.

[Monte Goulding]

Post by J. Landman Gay
I know you're a supporter Roger, I didn't mean to imply criticism.

For the record so did I and neither did I ;-)

Post by J. Landman Gay
I was just curious what people would think a fair licensing scheme would include. I guess I did miss your original suggestion. I also wonder how a hobbyist license should be enforced, or if it should just be an honor system.

I’m curious too.

Cheers

Monte

[Roger Guay]

My apologies to you and Monte, if I sounded too defensive.

I do hope that this idea of a non-profit/give-away app license will not be summarily dismissed. It just might be a benefit to all of us.


Cheers,

Roger

I know you're a supporter Roger, I didn't mean to imply criticism. I was just curious what people would think a fair licensing scheme would include. I guess I did miss your original suggestion. I also wonder how a hobbyist license should be enforced, or if it should just be an honor system.

Post by Roger Guay
Well, what I suggested a few posts back was a license for non-profits
and give-away apps. But, I completely understand if that turns out to
be difficult to police. I’m only trying to help here!
Roger

On Feb 29, 2016, at 7:45 PM, J. Landman Gay

Post by Roger Guay
Once more, I point out that this might be a good new revenue
stream for LC!!! Does it hurt anyone?

Well, it could hurt the company if everyone suddenly decides
they're a hobbyist. But let's take the thought experiment a little
farther. What restrictions would you (anyone) put on a "hobbyist"
license to differentiate it from the regular Indy license? It would
have to prevent people from gaming the system.

--
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Alejandro Tejada]

Hi all,

I have read most of this message thread,
so please pardon me if someone has
proposed this before:

Why not publish your Apps for iOS
using a Publisher Partner?

Maybe an iOS Publisher Partner
selected among our very own
LiveCode fellow developers.

if not:
https://www.quora.com/I-have-an-awesome-iOS-game-which-game-publisher-should-I-work-with
https://sensortower.com/blog/the-top-ios-app-publisher-rankings

What advantages and problems
do you foresee with this?

Thanks in advance

Al



--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701706.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[stephen barncard]

Post by Alejandro Tejada
Why not publish your Apps for iOS
using a Publisher Partner?
Maybe an iOS Publisher Partner
selected among our very own
LiveCode fellow developers.

I don't think that's allowed in the ELUA

Stephen Barncard - Sebastopol Ca. USA -
mixstream.org

[Ludovic Thebault]

Post by Alejandro Tejada
Hi all,
I have read most of this message thread,
so please pardon me if someone has
Why not publish your Apps for iOS
using a Publisher Partner?
Maybe an iOS Publisher Partner
selected among our very own
LiveCode fellow developers.

+1

And it is already possible to put your stack and resources files on the
web to let anybody compile the app with their proper version of
Livecode Community and put it on their iOS device with Xcode.

PS : it could be great to add an functionality to the standalone
settings of the community version : produce automatically the "source
code files" and GPL agreement when the standalone is created.

[Robert Mann]

Hi that is surely one way of helping "hobbyist" :: suggesting they get help
from a pro.. and give 'em some work! !?

But that is not the point I made.

As a former publisher of BOOKS, the point I made is :

what are the rules??
What protection (rules) applies to WHAT?
What can we do/not do with the the OS version?

And whouhou!!! boys.. that does not seem to be a clear !!
Of course, that started because of the price leap announced,
but it is a much deeper question :

• What can we/or can't we do with the Open Source version
• Where does the commercial version step in

So far, the Q/A on live code site that give examples only deals with the
CODE and not the content.
Robert






--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701718.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Mark Wilcox]

Post by Robert Mann
• What can we/or can't we do with the Open Source version
• Where does the commercial version step in
So far, the Q/A on live code site that give examples only deals with the
CODE and not the content.

The GPL requires that if you distribute your work, you distribute with
it everything needed to make it work under a license compatible with the
GPL. You also have to be able to modify the code and still have a
working version.

It is possible to ship a GPL program with proprietary assets, as long as
they are not essential to its function. Something some games have done
is ship a GPL version with a single working level and assets for other
levels remain proprietary. This is usually where someone has cloned a
game using the original assets - they say if you own the original you
can use theirs with the official assets. This is clearly not in the
spirit of the GPL but that kind of workaround does happen.

Designs can be registered but they are not subject to copyright law in
the same way as text/code is almost globally, so the GPL cannot really
say anything definitive about those. IANAL but I suggest you'd have a
hard time prosecuting someone for using your design if you'd released
open source code that implemented it. There is a similar debate about
patents... and much discussion on that in the open source community.

[Monte Goulding]

Post by Alejandro Tejada
Why not publish your Apps for iOS
using a Publisher Partner?
Maybe an iOS Publisher Partner
selected among our very own
LiveCode fellow developers.

We discussed this during the original Kickstarter and I believe the discussion led to a clause in the commercial license that we could not build standalones for people unless we had done work to the value of at least an Indy license. Something like that anyway…. The idea being it would be more logical for the Community user to get their own license rather than work around the GPL by using a build service. I would hope that if someone is discovered running a build service they would have their license cancelled promptly.

On the whole this conversation seems to have steered in the direction of “How do we deliver proprietary apps while using the GPL version”. I’m hoping we can steer it back because such a discussion does the platform and the generous terms with which we can use it a disservice. The simple answer to all these issues is to use Community if you want to distribute under the GPL and use Indy or above if you want to distribute under any license you choose. If you aren’t sure it probably means you need Indy.

Cheers

Monte

[RM]

Post by Monte Goulding

Post by Alejandro Tejada
Why not publish your Apps for iOS
using a Publisher Partner?
Maybe an iOS Publisher Partner
selected among our very own
LiveCode fellow developers.

We discussed this during the original Kickstarter and I believe the discussion led to a clause in the commercial license that we could not build standalones for people unless we had done work to the value of at least an Indy license. Something like that anyway…. The idea being it would be more logical for the Community user to get their own license rather than work around the GPL by using a build service. I would hope that if someone is discovered running a build service they would have their license cancelled promptly.
On the whole this conversation seems to have steered in the direction of “How do we deliver proprietary apps while using the GPL version”. I’m hoping we can steer it back because such a discussion does the platform and the generous terms with which we can use it a disservice. The simple answer to all these issues is to use Community if you want to distribute under the GPL and use Indy or above if you want to distribute under any license you choose. If you aren’t sure it probably means you need Indy.
Cheers
Monte

If by a "Publisher Partner" you mean getting someone who owns a licence
to the Commercial version
of Livecode to build you stacks from your standalones, that (while
possibly not being illegal) seems
sneaky and under-hand.

I suppose someone will try this trick sooner or later . . .

Possibly one way of preventing this is for a stack made using the
Community version to, somehow, encode the Mac address of the machine it
was manufactured on, and if someone tries to generate standalones using
a licensed commercial version of Livecode on a machine with a different Mac
address the whole thing would lock up [i.e. that Commercial version
would instantly stop working].

Richmond.

[Peter TB Brett]

Post by RM
If by a "Publisher Partner" you mean getting someone who owns a licence
to the Commercial version
of Livecode to build you stacks from your standalones, that (while
possibly not being illegal) seems
sneaky and under-hand.
I suppose someone will try this trick sooner or later . . .

That "someone" would be violating the terms and conditions of their Indy
(or Business) license.

If they were *lucky*, they would promptly find that they didn't have
their license any more.

Needless to say, anyone trying such a thing will be viewed with
_extreme_ displeasure.

Peter

[Monte Goulding]

That "someone" would be violating the terms and conditions of their Indy (or Business) license.
If they were *lucky*, they would promptly find that they didn't have their license any more.
Needless to say, anyone trying such a thing will be viewed with _extreme_ displeasure.

Yes and I’d be surprised if distributing via a build service would be allowed by the GPL work-for-hire clause either which would mean the distribution to the build service would need to be GPL so in this instance I think both would be violating the terms of their license. IANAL….

Cheers

Monte

[Robert Mann]

The price rise in the commercial license has led me to try understand the
Opens SOurce License, although I had always in my mind to keep with a
commercial license ideally.

And that leads to big surprises. I'll be doing a little bit of homework on
that.

*Question 1 :: is there somewhere a kind of WIKI place for live code whereI
could start up open a license subject/page to be amended in a more
structured and constructive way than that list???*

Question 2 :: In that spirit, Peter TB Brett, it would be a contribution if
could you throw in the source/ref of the terms & conditions of the indy
license that forbids to provide the service described by J L. just above
consisting in accompanying an author in the realm of iOs app publishing.

Behing the great idea of a Open SOurce, it is surpassing to find so much
barriers being built around it.
And that does not seem totally realistic and respectful either.

I find it hard and really surprising that such a service is not provided by
somebody because I would find it really useful. Thinking about it, I
actually have one project I worked upon that would greatly benefit from such
a service as I just do not have time to dig and try out myself the iOs
publishing. Frankly it just is not a thing you just do once as a hobbits to
my view.

On the indy side, i find it very intriguing that you can invest into a tool
and be so tightly regulated as to what you can or not do.

So far to go into the iOs model, you need :
-- to do it yourself (if calling help from an indy is banned!)
-- invest in the tool 1000 bucks, plus..
-- invest time in trying out things with a stange spread out documentation
here and there.
-- deal with mister apple and the niceties & subtleties one regularly see in
the forum..

Mumm.. sounds great!!




--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701775.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Peter TB Brett]

Hi Robert,

The situation is quite simple:

1) The Open Source edition of LiveCode is licensed under the GNU General
Public License, version 3. This says that if you distribute works
derived from the Open Source edition of LiveCode (which we interpret to
include stack files), then you must do so under the same license.

2) The Apple App Store terms and conditions are incompatible with the
GPL v3. So you can't distribute apps created with the Open Source
edition of LiveCode via the Apple App Store without violating the
copyright of LiveCode.

Whether your program gets from the Open Source edition of LiveCode to
the App Store by one or more intermediate people is immaterial.

LiveCode Ltd. have not built any barriers around the Open Source
edition; the only one that matters was constructed by Apple.

I recommend acquiring an Android phone.

Peter

Post by Robert Mann
The price rise in the commercial license has led me to try understand the
Opens SOurce License, although I had always in my mind to keep with a
commercial license ideally.
And that leads to big surprises. I'll be doing a little bit of homework on
that.
*Question 1 :: is there somewhere a kind of WIKI place for live code whereI
could start up open a license subject/page to be amended in a more
structured and constructive way than that list???*
Question 2 :: In that spirit, Peter TB Brett, it would be a contribution if
could you throw in the source/ref of the terms & conditions of the indy
license that forbids to provide the service described by J L. just above
consisting in accompanying an author in the realm of iOs app publishing.
Behing the great idea of a Open SOurce, it is surpassing to find so much
barriers being built around it.
And that does not seem totally realistic and respectful either.
I find it hard and really surprising that such a service is not provided by
somebody because I would find it really useful. Thinking about it, I
actually have one project I worked upon that would greatly benefit from such
a service as I just do not have time to dig and try out myself the iOs
publishing. Frankly it just is not a thing you just do once as a hobbits to
my view.
On the indy side, i find it very intriguing that you can invest into a tool
and be so tightly regulated as to what you can or not do.
-- to do it yourself (if calling help from an indy is banned!)
-- invest in the tool 1000 bucks, plus..
-- invest time in trying out things with a stange spread out documentation
here and there.
-- deal with mister apple and the niceties & subtleties one regularly see in
the forum..
Mumm.. sounds great!!
--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701775.html
Sent from the Revolution - User mailing list archive at Nabble.com.
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Robert Mann]

indeed.. I do have an android phone!!

And I read the GNU license for good,
and the FAQ's for good,
and some discussions

1) my personal conclusion reading these is that the assumption you make
about stack files falling under GPL is.. questionable, but.. arguable,
particularly if there are elements of interfaces buttons so on that would
link to the engine. And the more intricated these become e.g. with widgets,
the more linked this will be.

But, if the stack file contains only code, I doubt that can fall onto GPL.
The language itself is not copyrightable so a piece of code really is an
"output" of an editor program and as such is not covered by GPL so long I
can read!

Arguably, code dispersed in interface objects "sections" can also be
regarded as a kind of organization of code and thus treated as output of the
editor's program and thus not covered by the GPL.

2) are you saying do I rightly understand? that in order to be published by
apple a program has to be written FROM scratch up in a commercial version???
So that one cannot start up to write code in OS version and later switch to
commercial???? Are there any.. markers in the code?

In practice I really wonder if Apple would trace back the origin of the
origin of a code and make sure it was not "written" with GPL covered
program. if it did, I wonder what they say about all those lines written in
EMACS.

To me that argument is kind of "tiré par le cheveux" as we say in french.
(something like.. stretched out?).

I love my android phone...




--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701790.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Matt Maier]

Post by Robert Mann
indeed.. I do have an android phone!!
And I read the GNU license for good,
and the FAQ's for good,
and some discussions
1) my personal conclusion reading these is that the assumption you make
about stack files falling under GPL is.. questionable, but.. arguable,
particularly if there are elements of interfaces buttons so on that would
link to the engine. And the more intricated these become e.g. with widgets,
the more linked this will be.
But, if the stack file contains only code, I doubt that can fall onto GPL.
The language itself is not copyrightable so a piece of code really is an
"output" of an editor program and as such is not covered by GPL so long I
can read!

If you sit down at a text editor and write a string of characters that the
Livecode engine happens to understand then you can put whatever copyright
license terms you want on it. So, I supposed in theory (disclaimer: IANAL)
if you wrote absolutely everything in plain script, and never included the
engine, you would still be able to apply your own license terms. But that
script can't be interpreted by anything other than the Livecode engine, so
you wouldn't be able to use it for anything. The value is in the engine,
which someone else wrote and allowed you to use as long as you follow their
rules. Since the rules they chose are the GPL, it's safe to assume there
isn't a legally sound way around it. The best you could hope for is a murky
grey area.

Post by Robert Mann
Arguably, code dispersed in interface objects "sections" can also be
regarded as a kind of organization of code and thus treated as output of the
editor's program and thus not covered by the GPL.
2) are you saying do I rightly understand? that in order to be published by
apple a program has to be written FROM scratch up in a commercial version???
So that one cannot start up to write code in OS version and later switch to
commercial???? Are there any.. markers in the code?

The number of question marks indicates that you're working your way through
the mourning process.
https://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model#Stages
There are whole cadres of lawyers who live in fear of the day they walk
into work and their boss calls them into a meeting because a random coder
accidentally included a piece of GPL software somewhere in the company's
proprietary product. GPL is not practical, it is idealistic. The authors
consider it a social movement. So it's not so much Apple's policy, it's
that the GPL is incompatible with anything vaguely proprietary, and of
course Apple is crazy proprietary.

Post by Robert Mann
In practice I really wonder if Apple would trace back the origin of the
origin of a code and make sure it was not "written" with GPL covered
program. if it did, I wonder what they say about all those lines written in
EMACS.
To me that argument is kind of "tiré par le cheveux" as we say in french.
(something like.. stretched out?).
I love my android phone...
--
http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701790.html
Sent from the Revolution - User mailing list archive at Nabble.com.
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Monte Goulding]

I don't think that's true. The Wordpress plugin author doesn't use Wordpress to actually type out the code yet it is still covered by the GPL.

Sent from my iPhone

Post by Matt Maier
So, I supposed in theory (disclaimer: IANAL)
if you wrote absolutely everything in plain script, and never included the
engine, you would still be able to apply your own license terms.

[Monte Goulding]

Robert did you read the quote I sent yesterday from the horses mouth? I very much doubt it would be profitable for anyone to take a different position than LiveCode Ltd on whether a stackFile is considered a plugin and therefore covered by the GPL. I have to say that I myself was unsure of this point and the quote from Mark was in response to my questioning. If you choose take a different position than the company my only advice would be to take legal council on the matter before you go ahead and test the waters.

Cheers

Monte

Sent from my iPhone

Post by Robert Mann
But, if the stack file contains only code, I doubt that can fall onto GPL.
The language itself is not copyrightable so a piece of code really is an
"output" of an editor program and as such is not covered by GPL so long I
can read!
Arguably, code dispersed in interface objects "sections" can also be
regarded as a kind of organization of code and thus treated as output of the
editor's program and thus not covered by the GPL.

[Richard Gaskin]

Post by Robert Mann
1) my personal conclusion reading these is that the assumption you
make about stack files falling under GPL is.. questionable, but..
arguable, particularly if there are elements of interfaces buttons
so on that would link to the engine. And the more intricated these
become e.g. with widgets, the more linked this will be.
But, if the stack file contains only code, I doubt that can fall
onto GPL. The language itself is not copyrightable so a piece of
code really is an "output" of an editor program and as such is not
covered by GPL so long I can read!
Arguably, code dispersed in interface objects "sections" can also be
regarded as a kind of organization of code and thus treated as output
of the editor's program and thus not covered by the GPL.

A license is a way to express the wishes of a creator of an original
work over how the work may be used and/or distributed.

The GPL is one embodiment people can choose to express a desire to share
their work under the condition that works derived from it are shared
similarly.

The intent is pretty straightforward, and can become complex only when
one invests time seeking ways to comply only with the letter of the
license while obviating the intentions of the creator of the work.

While possibly survivable in court depending on the specific
circumstances, where the GPL has been tested in court it has prevailed,
and where it hasn't such pursuits are at best generally considered uncool.

When pondering edge cases not yet tested in court, my own personal
decision is to err on the side of honoring the creator's intentions.

I wrote a note here a couple years ago about such an edge case with
regard to the Joomla project, and if these sorts of things are of
interest you may find the links included there useful, esp. the one for
the Drupal project with regard to their interpretation of derivative works:
<http://lists.runrev.com/pipermail/use-livecode/2013-December/196463.html>

Post by Robert Mann
2) are you saying do I rightly understand? that in order to be
published by apple a program has to be written FROM scratch up
in a commercial version???
So that one cannot start up to write code in OS version and later
switch to commercial???? Are there any.. markers in the code?

"Commercial" is not relevant here; the GPL expresses no opinion about
cost. The distinction is "proprietary", which may be non-commercial
just as GPL-governed works may be sold.

As Mark Waddingham explained earlier, the issue with Apple's app store
is that it limits the number of downloads of an app by an account, and
in the view of the authors of the GPL this conflicts with the GPL's
freedom granted to the user.

The code needs to be licenses in ways that do not include GPL-governed
elements. Whether sold or not sold as part of a commercial venture is
not a part of this.

A license is a way to express the wishes of a creator of an original
work over how the work may be used and/or distributed.

If you wish to apply a license to your media separate from your stack
files, LiveCode provides many ways to do that and doing so may clarify
the relationship between them.

The owners of the copyright here has expressed their intentions with the
GPL unambiguously with regard to stacks.

What others choose to do is up to them. And no matter that I tend to
interpret software licenses conservatively in accordance with
commonly-acceepted conventions, I'm not an attorney and nothing I've
written can be construed as legal advice.

For me life is much simpler: when I want to share with downstream
provisions for sharing I choose GPL, if not I choose something else.

This lets me spend more time on code.

[Robert Mann]

Thanks for your piper mail link. I found your article very informative (and a
breeze to read!).

I'll retain that what's actually written in the GPL license.. is like toilet
paper
What counts is the creators position... Fine.

And that'll close the subject of the status of the stack files for me too.
//

== Remains to be cleared the position vis a vis content (audio, video, text,
images) what is the position of the creators? Can it be clarified? Did they
mean that all content be, in their interpretation, included in the GPL? Is
that written up somewhere in a specific proviso or just "thought" ?

== And lastly, the kafkaesque position vis a vis the use of both tools for
the same code. In practice, can I code part of an application in the
community and part of it in the closed IDE. If not, please do precise if
there are markers somewhere that are used to track the IDE used.

Many thanks, I hope we can close this (long!) thread soon with practical
answers to these questions.
Robert



--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701803.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Monte Goulding]

Mark Waddingham covered this in his post:

Whilst the GPL can be used to cover content there are more (GPL compatible) suitable ones. The main problem with applying the GPL to content is deciding what constitutes the 'source code'. Indeed, I believe there is an FAQ on the FSF site about such things but I can't find it at the moment (slow internet connection on a train!). Generally the Creative Commons style licenses are far better for content - you just need to pick a variant which is definitely compatible with the GPL (CC/0, for example).

Sent from my iPhone

Post by Robert Mann
== Remains to be cleared the position vis a vis content (audio, video, text,
images) what is the position of the creators? Can it be clarified? Did they
mean that all content be, in their interpretation, included in the GPL? Is
that written up somewhere in a specific proviso or just "thought" ?

[Richard Gaskin]

Post by Robert Mann
== And lastly, the kafkaesque position vis a vis the use of both
tools for the same code. In practice, can I code part of an
application in the community and part of it in the closed IDE.

The GPL is a distribution license; it doesn't affect anything you do in
your home or office, and only comes into play when software is distributed.

In fact, one of the nice features of the GPL is that it very explicitly
states that if you share software under that license you can't restrict
the use of the software in any way. This freedom is often
under-appreciated but very powerful, as it prevents any form of
discrimination and allows everyone to study and learn from code, and to
modify it for themselves however they like.

So here we're only looking at cases where you distribute something to
others.

And since the application needs an engine to bind to in order to run,
the license of the engine used at build time would determine the license
options.

Kevin's said here before that you can freely use the Community Edition
to develop in, and would only truly need to acquire a license for the
proprietary engine when you're ready to deploy the app and wish to do so
under a license other than GPL.

For other questions the FAQ has some good info - see "Can you give me
some examples of where I do and don’t need a commercial license?"
<https://livecode.com/resources/support/ask-a-question/>

Post by Robert Mann
If not, please do precise if there are markers somewhere that
are used to track the IDE used.

Markers are for enforcement, and enforcement is only needed when there
is circumvention.

I have no interest in circumventing the intentions of the copyright
owner of LiveCode, so it's never occurred to me to look for markers.

[Robert Mann]

Ok, fine.. that is.. somehow more "logical" !!

So that leads to 2 practical consequences :

1) what seems to be important is the timing of making publicly available
some code :
-- if you "release" some code under GPL for testing out an app
-- and than later on turn to the closed IDE to produce a closed version in
view of a commercial development
..if I get it right, you're done! bad choice :: GPL infringement!

2) if you do not make it public, than when you're ready, you're free to turn
for help to an indie/pro developer to finish it up and prepare it for iOS
launch under whatever license suites you.

Conclusion :: with the community version, be secretive if in view of any
commercial application and only share code you really wish to.. share!
There will be NO return.

So that closes that issue for me //



--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701816.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Monte Goulding]

Post by Robert Mann
2) if you do not make it public, than when you're ready, you're free to turn
for help to an indie/pro developer to finish it up and prepare it for iOS
launch under whatever license suites you.

I refer you to clauses 5 b, d, f and h of the LiveCode License Agreement for Indy and Business. This sentence in 5b is particularly relevant "For the avoidance of doubt, You may not use the Licensed Edition to create or distribute Created Software for other users who are using the Community Edition of LiveCode.”

Here’s all of clause 5 for your reading pleasure:

5. NO COMPETITION

a) The clauses in this section are intended to prevent you from using the Licensed Edition to release Created Software or engage in activity using the Licensed Edition, that is directly damaging to our business. Such damage may result from any activity that reduces, or negates, the requirement for other users of any edition of LiveCode, including the Community Edition, to purchase a Licensed Edition in order to enjoy the same benefits that you enjoy under this agreement.

b) The ability to create and distribute Created Software is intended for You to use with applications You have created or been substantially involved in developing. You are prohibited from using the Licensed Edition to build standalone applications for others where You are not the author of the application, or confer on others the ability to build standalone applications by any means whatsoever. For the avoidance of doubt, You may not use the Licensed Edition to create or distribute Created Software for other users who are using the Community Edition of LiveCode. This clause is intended to prevent You from providing any facility or service which would reduce or eliminate the requirement for other LiveCode users, including users of the Community Edition, to purchase a Licensed Edition to distribute their own Created Software.

c) You are prohibited from creating or distributing Created Software to be used and marketed as a generic rapid application development tool. Any Created Software that does not involve any sort of script editing will not be considered prohibited.

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

e) You are prohibited from creating or distributing Created Software with the primary purpose of being used as a generic Player application for Created Software built with any edition of LiveCode. This clause is intended to prevent you from conferring the ability to others to distribute closed-source applications, including stacks, without purchasing a license.

f) Irrespective of the specific exclusions listed in this section, you may not invent, contrive or enter into any form of business that utilizes your Licensed Edition to reduce or eliminate the need for any other entity to purchase a Licensed Edition. Selling licenses is the core of our business and you accept that your use of the Created Software will not be used, intentionally or otherwise, to undermine that business.

g) Irrespective of the clauses above, any Created Software that you produce that requires the end user to purchase a Licensed Edition of the LiveCode Software will never be considered as being prohibited.

h) In the event that either you or LiveCode Ltd determines that your software, or a service you provide, is in violation of any of the clauses above, you must withdraw the Created Software or service immediately. It is agreed that engaging in such competition with the LiveCode product could cause irreparable harm and injury and LiveCode Ltd will be entitled, in addition to any other rights and remedies it may have at law or in equity, to an interdict, injunction or other similar relief enjoining or restraining you from doing or continuing to distribute such Created Software or provide such competing service.

[Robert Mann]

OUps!! that IS DAMN CLEAR! By Jove!!

So ok.. fine.. as one could rephrase the situation :

2) if you do not make it public, than when you're ready, you're free to

a) buy a closed commercial license

and THEN
b) turn for help to an indie/pro developer to finish it up and prepare it
for iOS launch under whatever license suites you.

So basically, all clients of any indie developer have to buy/get their own
license for their product.
Tough, but Ok It's best to know in advance.

Well, that closes that subject for me // thanks everybody.
(i'll try to make a summary of that discussion, issues and solutions to make
good use of this NRJ)



--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701822.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Monte Goulding]

Post by Robert Mann
So basically, all clients of any indie developer have to buy/get their own
license for their product.

No as far as I’m aware clients only need to get their own license if they are also a developer. If the clients aren’t involved in the application other than brief, testing, artwork etc and aren’t using LC then they are unlikely to need a license. I often recommend it though if there is a good tester on the client end it is often helpful for them to have LiveCode available.

Cheers

Monte

[Peter TB Brett]

Post by Robert Mann
== And lastly, the kafkaesque position vis a vis the use of both tools for
the same code. In practice, can I code part of an application in the
community and part of it in the closed IDE. If not, please do precise if
there are markers somewhere that are used to track the IDE used.

Frankly, as long as you never give the application to anyone else, you
can use whatever edition(s) of the IDE you like. The GPL does not
restrict *use* -- it only restricts distribution.

Peter

[Richard Gaskin]

Post by Robert Mann
Behing the great idea of a Open SOurce, it is surpassing to find
so much barriers being built around it.

As Peter explained, for most use cases it's not all that deep.

But for edge cases all licenses can be complex, open source and
proprietary alike.

The only reason some folks think proprietary licenses are simple is
because they don't read them. :)

Consider the EULA for Apple's proprietary Final Cut Pro:

The features and even the name imply that it might be an excellent
choice for a wide range of uses that can include professional work. And
indeed I know may pros who've used it; I'm sure many others here do too.

But did they write a fairly hefty check to the MPEGLA patent consortium
to be legally able to do so?

The Final Cut Pro EULA includes:

12. MPEG-2 Notice. To the extent that the Apple Software contains
MPEG-2 functionality, the following provision applies: ANY USE OF
THIS PRODUCT OTHER THAN CONSUMER PERSONAL USE IN ANY MANNER THAT
COMPLIES WITH THE MPEG-2 STANDARD FOR ENCODING VIDEO INFORMATION
FOR PACKAGED MEDIA IS EXPRESSLY PROHIBITED WITHOUT A LICENSE UNDER
APPLICABLE PATENTS IN THE MPEG-2 PATENT PORTFOLIO, WHICH LICENSE
IS AVAILABLE FROM MPEG LA, L.L.C., 250 STEELE STREET, SUITE 300,
DENVER, COLORADO 80206.

13. MPEG-4 Notice. This product is licensed under the MPEG-4 Systems
Patent Portfolio License for encoding in compliance with the MPEG-4
Systems Standard, except that an additional license and payment of
royalties are necessary for encoding in connection with (i) data
stored or replicated in physical media which is paid for on a title
by title basis and/or (ii) data which is paid for on a title by
title basis and is transmitted to an end user for permanent storage
and/or use. Such additional license may be obtained from MPEG LA,
LLC. See http://www.mpegla.com for additional details.

Additional use licenses and fees are required for use of information
encoded in compliance with the MPEG-4 Visual Standard other than the
personal and non-commercial use of a consumer (i) in connection with
information which has been encoded in compliance with the MPEG-4
Visual Standard by a consumer engaged in a personal and
non-commercial activity, and/or (ii) in connection with MPEG-4
encoded video under license from a video provider. Additional
information including that relating to promotional,internal and
commercial uses and licensing may be obtained from MPEG LA, LLC.
See http://www.mpegla.com.

<http://store.apple.com/Catalog/US/Images/finalcutpro.htm>


Any license can be complex, and all are worth reading.

At least most open source licenses are standardized, so you only need to
read one or two to understand the terms for thousands of software
packages.

But every proprietary license can be unique, requiring us to go through
them all with each version of each package to see what details may lie
within.

[Robert Mann]

Thanks Richard.. that one a good example of.. "leonine" clause as we say in
France...
as we say :: El diabolo hides in small details.

Coming back to Livecode OS I'm really surprised that nobody seem to have
considered stacks as being not only programs but multimedia interactive
media, and the related legal stuff like copyright of these sources.

That is the basic in any book publishing see :
https://authorservices.wiley.com/permissions%20guidelines%20for%20authors%20pdf.pdf
https://copyright.lib.utexas.edu/ccmcguid.html

And the GPL inclusion of these elements cannot be governed by the GPL
license which only covers CODE.

Again if live code see it or interpret it differently please do say so.
Thanks.




--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701796.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Richard Gaskin]

Post by Robert Mann
Coming back to Livecode OS I'm really surprised that nobody seem to have
considered stacks as being not only programs but multimedia interactive
media, and the related legal stuff like copyright of these sources.

https://authorservices.wiley.com/permissions%20guidelines%20for%20authors%20pdf.pdf

Post by Robert Mann
https://copyright.lib.utexas.edu/ccmcguid.html
And the GPL inclusion of these elements cannot be governed by the GPL
license which only covers CODE.
Again if live code see it or interpret it differently please do say so.

I suppose if your goal was to write LiveCode scripts and publish them as
a printed volume for your coffee table that might make a very good analogy.

More commonly code is used to execute instructions on a computer, and
for that it needs to intimately co-mingle in memory with the LiveCode
engine.

My earlier post I'd linked to previously was perhaps a bit long - let me
share the most relevant portion from the Drupal License FAQ page:

"If I write a module or theme, do I have to license it under
the GPL?
Yes. Drupal modules and themes are a derivative work of Drupal.
If you distribute them, you must do so under the terms of the
GPL version 2 or later."
<https://drupal.org/licensing/faq/#q7>

The sole copyright owners of LiveCode have expressed their intention
that stack files are considered "derivative works", and choosing the GPL
to express that intention seems in line with the collective counsel at
the Wordpress, Joomla, and Drupal projects.

If you're able to convince counsel on those projects to change their
interpretation of the GPL please let us know.

Post by Robert Mann
So far : I have both a commercial and a a Community Edition (yes no
more open source!),
and I can write on one and then open and keep writing on the other.
I mean, there is no way to identify the tool used!!!

Yes, as with proprietary software it's often physically possible to
circumvent international copyright law with unauthorized distribution,
just as it's possible to sell a stolen television at a pawn shop.
Indeed, a few Wifi router vendors have found themselves in court for
using a modified Linux kernel for which they did not share their source.
Piracy comes in many forms.

But I believe there's a mandate on this list to avoid discussions that
might promote illegal activity, so I'll not pursue this further beyond
noting this:

The proprietary engine is not a binary copy of the Community Edition
engine, as it contains code to encrypt stacks. As such, while nothing
can stop someone from pirating any software, if found it would be
trivial to demonstrate in court which engine was used.

Post by Robert Mann
Besides, dual licensing of the same work is fine. That one leaves
me.. dead in kafka"s chaos!!

Again, not all that deep: under the nearly-globally-recognized Berne
Convention, the creator of an original work has ownership of that work
at the moment of creation, and has sole authority over how that work may
be used and/or distributed.

If you wish to write something similar to LiveCode from your own C
source, you would own the work and have sole authority over its
distribution terms, which may be under a single license, or a dozen, as
you choose.

But when you create a work derived from another's, your ownership is
limited to the portions you created, and may have further limitations
depending on the terms of the software used to develop and run the work.

LiveCode stack files can be distributed under a wide range of possible
licenses when created with the proprietary-licensed LiveCode engine,
provided of course the terms of whichever license you choose are
compatible with the terms of the LiveCode proprietary EULA.

For example, the MetaCard IDE was released under MIT License by the
original inventor of the engine, Dr. Scott Raney, and many of us
contributed to its maintenance and enhancement for years.

But you do not have source code to the proprietary engine, so it would
not be possible to use any license that requires you to distribute the
complete source code for an application.

If your original work is a stack file and it was made with the
proprietary LC engine, you could conceivably make it available under MIT
license, Apache, and your own proprietary license as well, and let your
users choose the license they feel best meets their needs.

But if you want to include the engine, you'll need the source.

And the source is only publicly available under one license, the GPL.

[Robert Mann]

RE : issue : does livecode consider that all illustrative material & text etc
in a stack to their view fall under GPL

<< I suppose if your goal was to write LiveCode scripts and publish them as
a printed volume for your coffee table that might make a very good analogy.
No, in my case I've got a project that is related to "publishing" some music
practice apps.
So cards that contain audio elements, and copyright material like songs,
music scores
and also pictures, videos & texts (subject to copyright).

So all coding would be available to all of course. But these copyrighted
elements will not be GPL compatible because as simple as it is french law
does not allow an author to push away his copyrights.

Hence the question above. Does livecode "interprets" all contents as being
per se GPL work when "attached" to a stack in the community version?

And I'm sure that the answer will interest more than one person. And for me
I just have to know where I put my feet. it' not just for the sake of making
a fuss about something, and I thank you for.. getting the feel of the air on
the subject. We have to know that.





--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701814.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Monte Goulding]

Post by Robert Mann
So all coding would be available to all of course. But these copyrighted
elements will not be GPL compatible because as simple as it is french law
does not allow an author to push away his copyrights.

Perhaps you are confused between copyright and licensing here? The copyright owners of the content (if they are not you) need to license the content to you under a GPL compatible license so that you can then include their work in your GPL compatible application. They and you still retain copyright but the license permits the receiver to modify and redistribute the work.

Cheers

Monte

[Richard Gaskin]

Post by Robert Mann
RE : issue : does livecode consider that all illustrative material
& text etc in a stack to their view fall under GPL

I had thought Mark Waddingham had addressed that. When media is related
to the functionality, such as an icon, that would seem reasonable to
expect that it be included as part of the governed work.

If the media is incidental to the app, or more clearly if it's even
physically external to the app, you should be able to remove it if you
don't want to share that, in the same way that you can make a word
processor and you're not obliged to include the poetry you typed with it
while you were working on it.

Post by Robert Mann
in my case I've got a project that is related to "publishing" some
music practice apps.
So cards that contain audio elements, and copyright material like
songs, music scores and also pictures, videos & texts (subject to
copyright).

Ah, at last something specific and concrete! Thank you. The
abstractions had become boggling.

Why not just do what other apps do and separate your content from your
functionality. Then you can share your app as a functional thing with
content that's interchangeable. This may also just be a useful way to
architect, allowing you to build one system that can accommodate any
number of titles.

Post by Robert Mann
So all coding would be available to all of course. But these
copyrighted elements will not be GPL compatible because as simple
as it is french law does not allow an author to push away his
copyrights.

The French have made some of the finest films in the world, and I'm able
to know this because they were distributed here. The creators of the
works retain copyright even as they offer specific rights with regard to
distribution to others.

No distribution license is a transfer of copyright. Not in film, not in
software.

Post by Robert Mann
1) what seems to be important is the timing of making publicly
-- if you "release" some code under GPL for testing out an app
-- and than later on turn to the closed IDE to produce a closed
version in view of a commercial development
..if I get it right, you're done! bad choice :: GPL infringement!

A choice is license is not in itself either "good" or "bad"; we choose
our licenses according to our goals. When the goal is to share, the GPL
can be a good choice.

But this is not about timing, but of distributed material: if you
distribute the GPL-governed engine, it's governed by the GPL.

What you do in your own home is your own business; what we're discussing
here is distribution, and it matters less when you distribute than what
you distribute.

[Robert Mann]

RE : issue of including copyrighted media into a stack.

<< The creators of the
works retain copyright even as they offer specific rights with regard to
distribution to others.

No distribution license is a transfer of copyright. Not in film, not in
software. >>

So.. did my homework again, here come the details :

If livecode's wants that all stacks and content made with the Community
version be fully GPL3 compatible,
all media used in a stack must be under a CC BY-SA 4.0 type license, which
is directly compatible with GPLv3.

In my case, media would only be in NC (non commercial copyleft) thus, not
GPL3 compatible.
And worse, some audio work would even not be in CC but under "SACEM" rules
which is rather restricted and some other work under standard copyright not
CC. So definitively not GPL3 compatible.

So i'll just ask the boss I think. But interesting for all to know what can
be done and what cannot be done with the community version.







--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701826.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[J. Landman Gay]

Post by Robert Mann
If livecode's wants that all stacks and content made with the Community
version be fully GPL3 compatible,
all media used in a stack must be under a CC BY-SA 4.0 type license, which
is directly compatible with GPLv3.

I have been trying to follow this thread, not always successfully, but
common sense tells me:

If your app stores media files separately on disk, they are not part of
the app. They are just files that are loaded into the app. So if you
have artwork, audio, video, etc. they can be stored on disk and licensed
separately in whatever way you want.

The app itself, if developed with the community version, would have to
be GPL. Other people who download your app could re-distribute it, alter
it, and re-use it under the same GPL conditions. But they couldn't
redistribute your media files as long as those files are licensed under
their own, more restrictive license.

Does that sound right to all you guys who read up on this stuff?

[Monte Goulding]

Post by J. Landman Gay
Does that sound right to all you guys who read up on this stuff?

I believe any media or other content (whether separate files or not) distributed with the application and/or required to make it function fully would need to be licensed in a GPL compatible license.

Cheers

Monte

[J. Landman Gay]

Post by Monte Goulding

On 2 Mar 2016, at 4:35 PM, J. Landman Gay
Does that sound right to all you guys who read up on this stuff?

I believe any media or other content (whether separate files or not)
distributed with the application and/or required to make it function
fully would need to be licensed in a GPL compatible license.

Two hypotheticals:

1. I create a viewer app to display my original artwork as part of my
job-seeking resume. The viewer seems useful so I decide to distribute it
to others so they can make their own resumes. I include at least some of
my artwork in the distribution so that potential users can see how the
app works, but I don't want them to use my artwork in their own resumes.
I decide to license my artwork restrictively, but the viewer app is GPL.
I would think separate licensing in that case would be okay. The app
doesn't depend on my particular artwork, it only needs something to
display. (I know I could include media that is public domain instead,
but that's not the point.)

2. I create an app that teaches the history of medieval art. The artwork
is mostly public domain, but some of the illustrations, maps, whatever
are my own creations. The stack doesn't work without the media, and the
text in the app describes it. In that case I need to license everything
as GPL because the app isn't functional without the supporting files.

Yes?

[Monte Goulding]

1. I create a viewer app to display my original artwork as part of my job-seeking resume. The viewer seems useful so I decide to distribute it to others so they can make their own resumes. I include at least some of my artwork in the distribution so that potential users can see how the app works, but I don't want them to use my artwork in their own resumes. I decide to license my artwork restrictively, but the viewer app is GPL. I would think separate licensing in that case would be okay. The app doesn't depend on my particular artwork, it only needs something to display. (I know I could include media that is public domain instead, but that's not the point.)
2. I create an app that teaches the history of medieval art. The artwork is mostly public domain, but some of the illustrations, maps, whatever are my own creations. The stack doesn't work without the media, and the text in the app describes it. In that case I need to license everything as GPL because the app isn't functional without the supporting files.
Yes?

I think wiser heads than mine need to answer this for 1.

Cheers

Monte

[Robert Mann]

Spot on! Thanks Jacqueline, That is exactly the choice I have :

1. make a viewer of a special kind of media aggregate with the community
version under GPL
& deliver these media aggregate in a separate file under whatever license.
(plus i'll document that format so that others can produce such content)

--> I can crunch in a specialized in house editor
--> content will be more "industrialized" not as rich visually,
just like an app instead of the original hypercard spirit mix of app + book.
--> not ok for iOs distribution

2. create fully contained mixed apps+content in the spirit oh hypercard, non
GPL, with livecode commercial edition.
--> ok for iOs distribution

to which I add :

3. have a tier party do the viewer ready for iOs and let me concentrate on
the in house editor.
--> ok for iOs distibution

4. switch to web service for distribution which is something I do "master"
thanks to revIgniter bootcamp and some in house development i've done in
that view.
--> ok for wider usage/distribution
--> if third parties/individuals wish to produce content, I can either open
source the in house editor or sell it with a commercial version.

5. see in the future if live code HTML5 can help produce better quality
content for the web, that would match the quality of interaction we once
upon a time had with hypercard stacks!

And the winner is : number 4 (the web app path) considering that for kids,
having to install one more app on a phone is to my point of view not ideal.
Also dealing with separate content is subject of problems on my android
phone.

So as conclusion, the "evolution" from the hypercard time is internet, web
pages, web apps.
bye bye stacks.

So that is it for the issue number 3 for me // many thanks all and I hope it
can help others have a clearer view of the impact of licensings schemes in
their plans.
RObert





--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701848.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Robert Mann]

<< I believe any media or other content (whether separate files or not)
distributed with the application and/or required to make it function fully
would need to be licensed in a GPL compatible license.>>

Hi Monte, I believe (!) that this belief is kind of a key issue in
attempting to identify the scope of GPL for livecode stacks and their
content.

I invite all of you (all) to , put on the legal hat for a while and walk
into the following story :

GPL is a very special kind of automatic contract that is attached to a piece
of work and which describes what the receiver of that piece of work can or
not do with it.

As such it is a very special contract in the world of contracts because it
does not require the agreement of the receiver, which is "implied" by the
act of receiving. So it is not the strongest type of contract.

Now and this is key to understand : a contract is itself a piece of work
that exist within a certain legal framework namely "the law" (the legal
codes etc & jurisprudence).

In that framework, there is a hierarchy of codes : from constitution at the
top to applications provisions down the road. it's kind of like in Object
programming. Except that you don't ask; Top objects set the law. Whatever
you try to do at the lower level.

Contracts that you can write must obey to the general rules. Some of these
rules are "imperative" no matter what the intent of a contractor may be
there are things that they just cannot do.

Among these, lies copyright. Copyright is a strong piece of legal meat which
has imperative laws that no one can circunvent. And that is particularly the
case in France/Europe which has a strong implementation of droits d'auteurs.
Anglos saxon copyright is much weaker on some points.

Copyrights has been structured according to various protected activities
from "fine art" painting, music, writing to "less fine art" like photo
graphics, sounds and lastly to "coding". Each of these activities/objects
have some special variations of rules which have organized themselves over
centuries.

A GPL license can set rules regarding it's own original object like "thou
shall re-distribute me, in whole or in part, with the same rights you
received". This can be symbolized by :
I received package CODE-A, i must re-distribute CODE-A with the same rights
i received.

The GPL license has extended the law in enforcing that all direct derivated
work be treated at par-level to the main body of work received, without
limit in time or scope or locality.
I received package CODE-A + I add package CODE-B which is of the same nature
than package A, namely CODE, and strongly interconnected to A, than I have
to re-distribute with same rights as CODE-A.

I say stretched out already because one strong legal principle that have
evolved over centuries is the principle that you should not engage futures
for an un-limited scope. Put into other words : a contract I make with any
publisher that all my future work will have to be signed with him without
time limit is VOID by law. e.i not acceptable.

So in the GPL case, this principle is clearly put aside (there is no time
limit or territorial limit) and this has been accepted, I guess lawers try
to be practical somehow.

But GPL license will not be able to act by magic on something else like a
picture, which is of a different legal nature governed by its own set of
legal rules which are "imperative" to the GPL.

That would be an extension of the extension, reaching limits of the existing
set of legal fundamentals.

I received package CODE-A + I add package CODE-B [of same nature &
intimitaly interconnected]
+ I add package IMAGE-C [of a different nature, somehow connected, but not
intimately]
=> than I have created a COMPOUND package legally because CODE and IMAGE
are not governed by the same legal set of rules. All the code part A+B is
governed by GPL fine, but all the IMAGE-C part is governed by whatever
copyright or CC or else.

Now the FFS (and it seems livecode counsels) tries to blow away the
difference between CODE and IMAGES and so on (including all media types and
all activities protected) and impose a kind of over-ruling of CODE over
everything else. Is that defendable? wise?

I do not think this would be wise because it would only favor even more the
big big super firms in asserting their rights over everything in that world.
It seems a good thing to me to keeps things separated.
Alphabet already nearly owns the alphabet some way.

So far, they got a clear first ruling against that in the wordpress case.
And javascript clarified the case with a specific extension making it clear
that an HTML page that calls a javascript function is not regarded as
derivated art of javascript! (the case would have been very difficult to
defend). Livecode could well do the same.

I hope that these precisions will help all of us better grasp the legal
background of the issue of how GPL applies to Livecode stacks and their
contents.

Robert

Of course, that is no legal device and just the point of view of a
"bienveillant" and honorable member of that list delivered here as "food for
thoughts" in accordance with the objectives of that list.

Post by Monte Goulding

On 2 Mar 2016, at 4:35 PM, J. Landman Gay &lt;
Does that sound right to all you guys who read up on this stuff?

I believe any media or other content (whether separate files or not)
distributed with the application and/or required to make it function fully
would need to be licensed in a GPL compatible license.
Cheers
Monte
_______________________________________________
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your
http://lists.runrev.com/mailman/listinfo/use-livecode

--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701951.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Matt Maier]

Post by Robert Mann
<< I believe any media or other content (whether separate files or not)
distributed with the application and/or required to make it function fully
would need to be licensed in a GPL compatible license.>>
Hi Monte, I believe (!) that this belief is kind of a key issue in
attempting to identify the scope of GPL for livecode stacks and their
content.
I invite all of you (all) to , put on the legal hat for a while and walk
GPL is a very special kind of automatic contract that is attached to a piece
of work and which describes what the receiver of that piece of work can or
not do with it.
As such it is a very special contract in the world of contracts because it
does not require the agreement of the receiver, which is "implied" by the
act of receiving. So it is not the strongest type of contract.

To add to the discussion, for what it's worth, there are good reasons that
proponents of copyleft (like the FSF who wrote the GPL) insist that it's
enforced by copyright law, not contract law. While legal systems do differ
in that some don't distinguish between licenses and contracts, the
distinction is important for copyleft.

In general, a contract has to be bargained, and consideration exchanged,
before it exists, and it only exists between the two parties. Then, if a
contract if violated, you generally can only sue to be made whole, so you
have to be able to show damages. Copyright, on the other hand, exists
instantly and forever, is implicitly accepted by everyone no matter how far
removed from the licensor they end up, and if it's violated you can have
the court take action without showing damages. Additionally, copyright law
is much more homogeneous globally.

So, for FOSS, copyright is a far more attractive legal structure. In the US
court cases where copyleft was upheld judges even cited in their written
opinion that FOSS would be effectively impossible under contract law.

[Richard Gaskin]

Post by Robert Mann
GPL is a very special kind of automatic contract that is attached
to a piece of work and which describes what the receiver of that
piece of work can or not do with it.
As such it is a very special contract in the world of contracts
because it does not require the agreement of the receiver, which
is "implied" by the act of receiving.

All works, software or otherwise and regardless whether the license is
open source or proprietary, must include its license terms if the person
distributing it wants others to use it at all.

The only safe interpretation of a work distributed with no license is
that it has no license.

Software under proprietary license includes a license, as does software
under open source license.

There's nothing all that special about the GPL in this regard, nor are
its terms merely "implied". The recipient has the license with the
software, and it's a good idea to read it, as is expected with any
software, even proprietary packages.



As for the rest of your post, I'm not an attorney. And while my own
layman's understanding of GPL terms more closely reflects Mark Wilcox's,
I've been unable to convince anyone at Drupal, Wordpress, Joomla, or the
FSF that all of them are wrong with regard to their common
interpretation of "derived works".

As I wrote here back in Dec of '13 and have referred to since, a clear
definition distinguishing "derivative work" from "mere aggregation" is,
in the words of the FSF themselves, "a legal question, which ultimately
judges will decide."

And given the vast and ever-growing variety of ways code can co-mingle,
a single definition for all possible cases may even elude a judge if
this definition is ever needed in court.

It's more than I could claim to offer legally-binding advice to others
on. "I'm just a humble caveman programmer. The ways of your attorneys
frighten and confuse me." :)

So for myself, I tend to interpret all licenses, GPL, proprietary, or
any other, in the narrowest terms which limit my rights as severely as
could be reasonably interpreted, so that the odds of my running afoul of
any possible future definition are as narrowly contained as they can
practically be.

If I need something that isn't clear, I'll sometimes write the creator
of the work to have them clarify their intentions in writing. And other
times I just write my own code. I made my own CMS because Drupal offers
no way to deliver proprietary plugins without annoying that community. I
like Drupal folks; it does me no good to annoy them.

This is just my personal policy, but it lets me get a day's work done
and sleep at night.

Others may have different goals. It's possible to spend one's time
poking and prodding around the edges of what's written to find out where
the boundaries might be, how much we might be able to get away with even
if it differs from what we know the author intended. We can choose to
spend our time lots of ways.

I'm not an attorney and can offer no legal advice, and unless someone
here is licensed to practice law in your jurisdiction and willing to do
so, your query may be best taken up with a lawyer licensed as such in
your area.

[Robert Mann]

I shall too, for myself, just apply the rules stated directly or indirectly
by livecode. These were not, at all, as crystal clear as it seemed.
And that is precisely why I took time to research, clarify and exchange
here.

[ Actually, there was a last issue raised, still un-cleared : I still do not
know if the principle of a distributing a community reader app designed to
manipulate a separate data file gathering various medias that would not be
GPL compatible, is something that is "in line" or "not in line" with
livecode's policy. Any clue? ]

Appart from that, I mean apart from me, I mean for the community, I do very
much share Mark Wilcox's point of view and think it is a good thing to raise
question and issues, for the common good of livecode/hypertalk heritage.

To make it clear, I am not a would be potential thief, trying to make my way
at the border of the livecode GPL license to hack the license. Let's really
do away with that kind of thing, please! I won't need to consult a lawyer as
far as I am concerned. That is not the point.

I just do point out that in the course of my research clarification and
exchanges here, I have the strong impression that the notion of "derivative
work" was wrongly understood.

I happen do have some legal background in law since I graduated in law both
in France and in the UK and completed that with a post grad in Advanced
computer sciences (that was called "artificial intelligence at that
time..!). I have dealt with copyright & licensing matters as a publisher for
15 years. Recently I did a lot of research/writing in the patent & design
patents realm, copyright, applied arts, and derivative work in order to
protect some important innovations in the field of musical instruments.

The notion of derivative work predates GPL. And there has been rulings.
Criterias have been set. And I just could not make "converge" in my little
head the point of view I got from livecode and these items of knowledge I
had gathered elsewere concerning the notion of derivative work. The puzzle
did not fit.

I would not bother and take the time to say so, if I did not "love" this
precious Hypertalk heritage, and If I did not feel too (very much like Mark
Wilcox) that sticking to that discussable interpretation is something I see
as dangerous for the livecode community.

For the one who have time to spare for that issue, I strongly suggest
reading this article I came accross : it explains very precisely in an easy
language, the impression I got something was wrong in the air.

I fully adhere to the conclusion that in effect, sticking that expansive
notion of derivative work on everything (and in our case on stacks & their
media content) is very much reducing the freedom of authors and is not a
good move. I'll set up an illustrative stack in my hobbyist time to show
why this is si with a very concrete "real" self explaining example.

https://www.law.washington.edu/lta/swp/law/derivative.html Enjoy! Robert




--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4702006.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Mark Wieder]

Post by J. Landman Gay
I have been trying to follow this thread, not always successfully, but

Heh.
Common sense in a discussion of legal things.

Yesterday I was handed an nda to sign. There was a clause (yes, I
actually do read these things) that started "Neither party will publicly
disclose the existence of this document..." I recoiled, this caused a
huddle of half a dozen people for several minutes, the company lawyer
came over and sheepishly crossed out the paragraph, and we went on.

[Richard Gaskin]

Post by Mark Wieder
Yesterday I was handed an nda to sign. There was a clause (yes,
I actually do read these things) that started "Neither party will
publicly disclose the existence of this document..." I recoiled,
this caused a huddle of half a dozen people for several minutes,
the company lawyer came over and sheepishly crossed out the
paragraph, and we went on.

Good lawyer.

I know a lot of developers starting out who get timid about asking for
contract changes. I had the good fortune of cutting my teeth in that
area under an excellent manager who taught me about doing contract
review with our clients' corporate counsel with this:

"Their job is to ask for the world. Your job is to ask for half of it
back."

[Robert Mann]

yap.. in that respect.. with all respect to live code and every team member..
I honestly earnastly was astonished by the virulence of the clause
forbidding any tier to take a community work and turn it into a commercial
application.

I sort of "naively" believed that there was quite a good positive ecosystem
between community hobbyist or a specially updated desktop only hobiist
version because things have become so complex that to fine tune a hobbits
app into an iOS app a guy who already is experienced in bringing an app to
IOs could well be a very good thing.

But then it's.. none of my business...
I just needed to know where to stand on.



--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701870.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Matt Maier]

Robert, as you conduct your research you should also learn about the
difference between Free Software and Open Source Software. In brief, Free
Software does special things for moral reasons; it is "right" that software
be liberated. Open Source Software does special things for pragmatic
reasons; it is "useful" that software be easy to use without asking
permission.

In both cases, you leverage copyright law. You cannot get away from
"restrictions" and still do Free or Open Source Software. The licenses are
used to restrict licensees from closing off the source of the software (to
a greater or lesser extent).

The GNU General Public License (GPL) is not an Open Source license, it is a
Free license. For reference, here is the Free Software Foundation's stance
on Open Source
http://www.gnu.org/philosophy/open-source-misses-the-point.html
"...a license designed specifically to protect freedom for all users of a
program."

The GNU has a lot of restrictions because it's specifically designed to
prevent anyone who uses Free software from acting in a way contradictory to
the ideals of the Free software movement. If you want the software, then
you have to follow the terms of the license. If you don't follow all of the
terms, you lose your license and open yourself to litigation. This threat
has teeth because Free software licenses have been upheld in court. The
restrictions are the point.

It doesn't help that Livecode always uses the term "Open Source" when
referring to the Community Edition. This could easily (and does) lead
people to assume the Community Edition has an Open Source license. It
doesn't, so if you're looking for pragmatic terms, rather than idealistic
terms, you're going to be confused.

With respect to your Question 2, the Indy license doesn't have to
specifically forbid a service where someone with a freer license compiles
code on your behalf. You can't build an actual Livecode application without
using the IDE, so if you used the Community IDE your application must
adhere to the GPL. The whole point of the GPL is to prevent "free" software
from being changed into "proprietary" software.

As for Apple, they don't want hobby developers releasing apps into their
system. Apple has zero interest in letting anyone play or experiment in
their closed ecosystem. Android is the Wild West you're looking for.
Or...maybe Windows phone? They might be desperate or ambivalent enough.

Post by Robert Mann
The price rise in the commercial license has led me to try understand the
Opens SOurce License, although I had always in my mind to keep with a
commercial license ideally.
And that leads to big surprises. I'll be doing a little bit of homework on
that.
*Question 1 :: is there somewhere a kind of WIKI place for live code whereI
could start up open a license subject/page to be amended in a more
structured and constructive way than that list???*
Question 2 :: In that spirit, Peter TB Brett, it would be a contribution if
could you throw in the source/ref of the terms & conditions of the indy
license that forbids to provide the service described by J L. just above
consisting in accompanying an author in the realm of iOs app publishing.
Behing the great idea of a Open SOurce, it is surpassing to find so much
barriers being built around it.
And that does not seem totally realistic and respectful either.
I find it hard and really surprising that such a service is not provided by
somebody because I would find it really useful. Thinking about it, I
actually have one project I worked upon that would greatly benefit from such
a service as I just do not have time to dig and try out myself the iOs
publishing. Frankly it just is not a thing you just do once as a hobbits to
my view.
On the indy side, i find it very intriguing that you can invest into a tool
and be so tightly regulated as to what you can or not do.
-- to do it yourself (if calling help from an indy is banned!)
-- invest in the tool 1000 bucks, plus..
-- invest time in trying out things with a stange spread out documentation
here and there.
-- deal with mister apple and the niceties & subtleties one regularly see in
the forum..
Mumm.. sounds great!!
--
http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701775.html
Sent from the Revolution - User mailing list archive at Nabble.com.
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Robert Mann]

But.. but.. ???????

<< With respect to your Question 2, the Indy license doesn't have to
specifically forbid a service where someone with a freer license compiles
code on your behalf. You can't build an actual Livecode application without
using the IDE, so if you used the Community IDE your application must
adhere to the GPL. The whole point of the GPL is to prevent "free" software
from being changed into "proprietary" software. >>

This seems kind of absurd.; and yes totally.. unrealistic!!

So far : I have both a commercial and a a Community Edition (yes no more
open source!),
and I can write on one and then open and keep writing on the other.
I mean, there is no way to identify the tool used!!!

Besides, dual licensing of the same work is fine. That one leaves me.. dead
in kafka"s chaos!!




--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701800.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Richard Gaskin]

Post by Matt Maier
Robert, as you conduct your research you should also learn about the
difference between Free Software and Open Source Software. In brief,
Free Software does special things for moral reasons; it is "right"
that software be liberated. Open Source Software does special things
for pragmatic reasons; it is "useful" that software be easy to use
without asking permission.

While that accurately reflects the motivations of Richard Stallman and
others who create and promote "Free software" as they've described in
their own writings, motivations are separate from outcomes. Whether I
buy flowers for my wife because I think she's pretty or because I'm
trying to apologize, either way the florist makes $60. :)

It's fully possible for others to enjoy the same outcomes without the
same philosophical motivation.

All carp are fish, but not all fish are carp, and not all who choose the
GPL are quite as religious about it as others, or see it as any sort of
moral imperative at all.

For myself, and many I know, the GPL is a purely practical means to an
end: a good choice when one wants to share code both directly and also
downstream.

I participate in many software projects, and some of the choose GPL. As
much as I admire Mr. Stallman personally and professionally I disagree
with his view of a moral imperative in choosing GPL. But that
disagreement doesn't prevent me from choosing it myself, or having
enjoyed his company over dinner. Vive le difference.

Like the classical Chinese painting "Three Men at Tiger Brook", we can
travel together even if we're adhere to different philosophies.

Post by Matt Maier
The GNU General Public License (GPL) is not an Open Source license,
it is a Free license. For reference, here is the Free Software
Foundation's stance on Open Source
http://www.gnu.org/philosophy/open-source-misses-the-point.html
"...a license designed specifically to protect freedom for all users
of a program."

...

Post by Matt Maier
It doesn't help that Livecode always uses the term "Open Source" when
referring to the Community Edition. This could easily (and does) lead
people to assume the Community Edition has an Open Source license. It
doesn't, so if you're looking for pragmatic terms, rather than
idealistic terms, you're going to be confused.

With all due respect to both yourself and Mr. Stallman, what you wrote
there is correct in terms of his very specific language preferences but
not necessarily reflective of common usage.

We have a bug in the English language: we have only "free", but Latin
has "gratis" distinct from "libre".

So when we refer to "free software", we often have to add
"free-as-in-freedom" or "free-as-in-beer" to distinguish what we mean.

It's quite true that Mr. Stallman has said many times that he feels Eric
Raymond's efforts to promote "open source" are misleading, and perhaps
even "immoral", and strongly prefers "free" to distinguish GPL-governed
works.

It's also true that when I say "Ubuntu" Mr. Stallman would prefer (and
not entirely without good reason) that I say "Ubuntu GNU/Linux".

But that's what happens with language: where phrases are cumbersome
they evolve into more casual colloquial forms over time.

Today "open source" is often used to describe all software whose source
is both available to the recipient of the software and where
modification is explicitly allowed.

It can sometimes be more correct to distinguish between GPL-style
licenses and other more permissive licenses, but in common usage the
more frequent distinguishing phrase is "copy-left" for GPL-style terms,
those with strong downstream inheritance.

The bigger distinction is between proprietary licenses on the one hand
and the full range of free/open licenses on the other. So while the
distinction between "free" and "open" licenses can be useful in specific
contexts, I see no mistake in using "open source" as a more generic
superset of free/open licenses. Indeed, I see it used that way every
day by a wide range of authoritative writers (no doubt to the annoyance
of Mr. Stallman, but hey, colloquialism happens).

[Matt Maier]

Unless Livecode modified the GPL it's still a Free software license,
written and interpreted by the FSF. Calling it Open Source is more
colloquial, and clearly doesn't cause problems in the vast majority of
cases. But, in this case, the inaccuracy is causing the confusion.

It's worth noting that most of the repositories in Github don't have any
license at all. That's not colloquial, that's just lazy, but that also
doesn't cause a problem in the vast majority of cases. Still, when there is
a problem the only way to resolve it is to be more specific.

I feel like it's important for people working through the nuances of FOSS
to understand the intent behind the different licenses. It can be
disorienting to think that everybody is just sharing stuff and then to run
into the seemingly harsh restrictions of the Free software subset. Open
Source is pretty inviting. Free places stick limits on who is invited. It's
confusing to people who haven't studied it because "open source" literally
means open up the source from which the object was derived. However,
"free/libre" doesn't mean make it as free as possible, it means make it
impossible for anyone to ever make it un-free. So the "free/libre" label
actually brings along MORE restrictions.

Livecode picked a Free software license for the Community edition,
signaling that they want their community to adhere to the intent of Free
software. Part of the reason (not the whole reason, but part of it) I
upgraded to Indy was so that I could cast off the restrictions imposed by
the intent of Free software.

Post by Richard Gaskin

Post by Matt Maier
Robert, as you conduct your research you should also learn about the
difference between Free Software and Open Source Software. In brief,
Free Software does special things for moral reasons; it is "right"
that software be liberated. Open Source Software does special things
for pragmatic reasons; it is "useful" that software be easy to use
without asking permission.

While that accurately reflects the motivations of Richard Stallman and
others who create and promote "Free software" as they've described in their
own writings, motivations are separate from outcomes. Whether I buy
flowers for my wife because I think she's pretty or because I'm trying to
apologize, either way the florist makes $60. :)
It's fully possible for others to enjoy the same outcomes without the same
philosophical motivation.
All carp are fish, but not all fish are carp, and not all who choose the
GPL are quite as religious about it as others, or see it as any sort of
moral imperative at all.
For myself, and many I know, the GPL is a purely practical means to an
end: a good choice when one wants to share code both directly and also
downstream.
I participate in many software projects, and some of the choose GPL. As
much as I admire Mr. Stallman personally and professionally I disagree with
his view of a moral imperative in choosing GPL. But that disagreement
doesn't prevent me from choosing it myself, or having enjoyed his company
over dinner. Vive le difference.
Like the classical Chinese painting "Three Men at Tiger Brook", we can
travel together even if we're adhere to different philosophies.

Post by Matt Maier
The GNU General Public License (GPL) is not an Open Source license,
it is a Free license. For reference, here is the Free Software
Foundation's stance on Open Source
http://www.gnu.org/philosophy/open-source-misses-the-point.html
"...a license designed specifically to protect freedom for all users
of a program."

...

Post by Matt Maier
It doesn't help that Livecode always uses the term "Open Source" when
referring to the Community Edition. This could easily (and does) lead
people to assume the Community Edition has an Open Source license. It
doesn't, so if you're looking for pragmatic terms, rather than
idealistic terms, you're going to be confused.

there is correct in terms of his very specific language preferences but not
necessarily reflective of common usage.
We have a bug in the English language: we have only "free", but Latin has
"gratis" distinct from "libre".
So when we refer to "free software", we often have to add
"free-as-in-freedom" or "free-as-in-beer" to distinguish what we mean.
It's quite true that Mr. Stallman has said many times that he feels Eric
Raymond's efforts to promote "open source" are misleading, and perhaps even
"immoral", and strongly prefers "free" to distinguish GPL-governed works.
It's also true that when I say "Ubuntu" Mr. Stallman would prefer (and not
entirely without good reason) that I say "Ubuntu GNU/Linux".
But that's what happens with language: where phrases are cumbersome they
evolve into more casual colloquial forms over time.
Today "open source" is often used to describe all software whose source is
both available to the recipient of the software and where modification is
explicitly allowed.
It can sometimes be more correct to distinguish between GPL-style licenses
and other more permissive licenses, but in common usage the more frequent
distinguishing phrase is "copy-left" for GPL-style terms, those with strong
downstream inheritance.
The bigger distinction is between proprietary licenses on the one hand and
the full range of free/open licenses on the other. So while the
distinction between "free" and "open" licenses can be useful in specific
contexts, I see no mistake in using "open source" as a more generic
superset of free/open licenses. Indeed, I see it used that way every day
by a wide range of authoritative writers (no doubt to the annoyance of Mr.
Stallman, but hey, colloquialism happens).
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Richard Gaskin]

Post by Matt Maier
Unless Livecode modified the GPL it's still a Free software license,
written and interpreted by the FSF. Calling it Open Source is more
colloquial, and clearly doesn't cause problems in the vast majority of
cases. But, in this case, the inaccuracy is causing the confusion.

I think the confusion in this long thread is evidently broader that just
the specific downstream aspects of the GPL. :)

But yes, the distinction is sometimes useful. For myself, acknowledging
how broadly "open source" is used to describe the superset, when I need
to distinguish GPL-like provisions I tend to use "copy-left".

I'm from California. Here we say "soda", while my friends from Iowa say
"pop". When discussing the differences between Glenlivet and Pepsi,
whether I refer to the Pepsi as "soda" or "pop" is the smaller concern.
Either way, the reader knows they'll be able to drive after polishing
off a bottle. :)

Post by Matt Maier
It's worth noting that most of the repositories in Github don't have
any license at all. That's not colloquial, that's just lazy, but that
also doesn't cause a problem in the vast majority of cases.

Au contraire, mon ami - it's been a problem for years:
<http://www.zdnet.com/article/github-improves-open-source-licensing-polices/>

That is, it's a problem if the code is useful. If the code is trivial
nobody cares, but when it does something useful then having no declared
license is a poison pill for both use and contribution. No sane person
would commit their business to using code that has no disclosed license
terms.

That's an ongoing challenge with online venues like mailing lists and
forums, and for myself when there's no declaration I only use code where
I know the person who posted it and have a reasonably good understanding
of their intentions.

When I don't know the poster's intentions I follow the old rule, "when
in doubt leave it out."

Post by Matt Maier
I feel like it's important for people working through the nuances
of FOSS to understand the intent behind the different licenses. It
can be disorienting to think that everybody is just sharing stuff
and then to run into the seemingly harsh restrictions of the Free
software subset. Open Source is pretty inviting. Free places stick
limits on who is invited. It's confusing to people who haven't
studied it because "open source" literally means open up the source
from which the object was derived.

Definitely every bit as valuable to study as the proprietary licenses we
encounter. All legal documents require time to review and asses, and
discuss their implications.

I won't hold it against if you use "free", but I'll still use "copy-left".

Just fergawsakes call it "Ubuntu GNU/Linux!" :)

Post by Matt Maier
However, "free/libre" doesn't mean make it as free as possible,
it means make it impossible for anyone to ever make it un-free.
So the "free/libre" label actually brings along MORE restrictions.

That last sentence is an excellent example of why study is useful:

What you refer to as "restrictions" the authors of the GPL call "freedoms".

Both are descriptive, and indeed describe the same things, so who am I
to say which is best?

I try to use value-neutral terms when discussing such things, sometimes
using phrases like "downstream provisions".

I have no problem with "requirements" myself, but I am more apt to use
"freedom" than "viral": if nothing else "freedom" is not an inherently
offensive word (kinda nice, actually) but many have expressed that they
find "viral" offensive when it's applied to GPL terms, connoting a
disease while many who choose it feel it's a cure.

I just try to be respective of local cultures in my travels.

[Roger Guay]

This doesn’t capture my part in this conversation. Personally, I am unconcerned about protecting my code/projects and I’m very happy to publish using the GPL license. But . . . BIG BUT . . . Apple won’t accept GPL, and I cannot afford the ever increasing price of the commercial license as a hobbyist. OTOH, I appear to be in a very small minority, so I’m done here!

Thanks and cheers,

Roger

Post by Monte Goulding
On the whole this conversation seems to have steered in the direction of “How do we deliver proprietary apps while using the GPL version”. I’m hoping we can steer it back because such a discussion does the platform and the generous terms with which we can use it a disservice. The simple answer to all these issues is to use Community if you want to distribute under the GPL and use Indy or above if you want to distribute under any license you choose. If you aren’t sure it probably means you need Indy.

[J. Landman Gay]

Post by Monte Goulding

On 1 Mar 2016, at 5:05 PM, Alejandro Tejada
Why not publish your Apps for iOS using a Publisher Partner?
Maybe an iOS Publisher Partner selected among our very own LiveCode
fellow developers.

We discussed this during the original Kickstarter and I believe the
discussion led to a clause in the commercial license that we could
not build standalones for people unless we had done work to the value
of at least an Indy license. Something like that anyway…. The idea
being it would be more logical for the Community user to get their
own license rather than work around the GPL by using a build service.
I would hope that if someone is discovered running a build service
they would have their license cancelled promptly.

If memory serves, the LC team has (had?) a service that would build for
iOS for you as well as help with all the back-end Apple certification,
etc. Is that still around?

[Richard Gaskin]

Post by J. Landman Gay
If memory serves, the LC team has (had?) a service that would build
for iOS for you as well as help with all the back-end Apple
certification, etc. Is that still around?

Post by Robert Mann
What I questionned is that we're going to be missing an intermediate
tool/license that would allow somebody to close SOME of his work at a
reasonable cost for a hobbyist. Just as was originally designed in
Hypercard.

Originally HyperCard was given away for free with every Mac.
Indeed, once it became a product under Claris it proved difficult for it
to sustain itself economically.
FWIW, LC has experimented with a wide range of price points over the
years, including many that match price points suggested in recent
related threads here. If they had produced the sort of results hoped
for we wouldn't be having this conversation today.

[RM]

This is when you see why Jail-breaking iPhones and iPads is not
necessarily a bad thing.

Richmond.

Post by Roger Guay
Monty,
I’ve tried to be clear about this. I am not complaining, nor am I upset with anyone. I have only good wishes and intentions for LC and users of LC. I’ll get along with whatever LC brings to my future. But you know better than I, that Apple is not going to be moved. So why not make lemonade out of this lemon: Once more, I point out that this might be a good new revenue stream for LC!!! Does it hurt anyone?
Roger

Post by Monte Goulding
Roger if you are suggesting you would be happy with Community if you could publish GPL apps to Apple's stores then that's probably something to take up with Apple.
Sent from my iPhone

Post by Roger Guay
Do you include those who might want to publish to the Mac App Store and IOS in your estimate?

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Roger Guay]

Yes, but unnecessary with the current Community Version. You can “publish” to your own (and other select) devices w/o jail-breaking them.

Roger

This is when you see why Jail-breaking iPhones and iPads is not necessarily a bad thing.
Richmond.

Post by Roger Guay
Monty,
I’ve tried to be clear about this. I am not complaining, nor am I upset with anyone. I have only good wishes and intentions for LC and users of LC. I’ll get along with whatever LC brings to my future. But you know better than I, that Apple is not going to be moved. So why not make lemonade out of this lemon: Once more, I point out that this might be a good new revenue stream for LC!!! Does it hurt anyone?
Roger

Post by Monte Goulding
Roger if you are suggesting you would be happy with Community if you could publish GPL apps to Apple's stores then that's probably something to take up with Apple.
Sent from my iPhone

Post by Roger Guay
Do you include those who might want to publish to the Mac App Store and IOS in your estimate?

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Matt Maier]

[disclaimer: I'm not a lawyer and this is not legal advice]

I sympathize with your confusion. There is inherent confusion around the
differences between "sharing" and "free/open source." In the former case,
it's just something people do. In the latter case, it is a legal standard.

Livecode Community uses the GPL http://www.gnu.org/licenses/gpl-3.0.en.html
This is important primarily because your standalones include the Livecode
engine. Livecode owns the copyright on the engine because their programmers
wrote it and assigned their copyright to the corporation. Leaving it at
that means that nobody else has any right to anything with regards to the
Livecode engine. In order to facilitate things like community, and
learning, and customer development, Livecode is giving you (us) a license
to use the engine provided certain conditions are followed. In this case,
the GPL is a viral license in that you are only given a license to use the
code if the binary you produce with it also uses the GPL (or compatible)
license. Those are the terms under which Livecode is comfortable allowing
you to use their intellectual property.

It's worth mentioning that the language itself doesn't work the same way.
If you open up a text editor, and write down words which the Livecode
engine might happen to understand, then you still own the full copyright on
those words. You can do anything you want with them. So the copyright on
the source of a script-only stack belongs to you. If you compile it into
the standalone then it must be licensed GPL.

That means there's a gray area around something like distributing a
Livecode-compiled binary under the GPL (source must be provided) and also
providing one or more encrypted scripts which that application can decrypt
and access if it needs to. As I understand it, the GPL blocks distribution
of a GPL-licensed executable that *requires* closed-source libraries to
run, but does allow the copyright holder to write in a specific exception
if they want to. The gray area refers to an optional library that *enhances*
(like a plug-in) the GPL-licensed application. I think that is merely
discouraged, but not actually blocked.

So it might be worth asking Livecode if they'd be willing to add an
exception to their GPL license allowing "hobbyists" to distribute a
closed-source library that is not compiled into the GPL-licensed
standalone. That would allow "hobbyists" to keep some of their code secret.
Maybe Livecode could even charge a different amount for that license.

[Disclaimer: Again, I'm not a lawyer and this is not legal advice.]

Post by Robert Mann
hi folks, what is this fuss about?
First : no. The allegation about hypercard forcing the open source path on
all usage is not true. There was a command to protect a stack ("protect" of
course!) . And some interesting pieces of software were sold as protected
stacks.
And it is precisely that positioning which is about to be abandoned by
livecode and why i think it's going backwards (with LESS) rather than going
forward (with MORE).
1) I never questioned the Open Source version of Livecode. it's fantastic
and needed.
2) I never questioned the Commercial version. Again it's great and helps
going forward.
What I questionned is that we're going to be missing an intermediate
tool/license that would allow somebody to close SOME of his work at a
reasonable cost for a hobbyist. Just as was originally designed in
Hypercard.
Now most reactions are : if it is to play around just don't bother and
distribute as open sourced. Ok guys.
But things are not just that "idealistically" simple. Sometimes you just do
not know yet. And wish to try out something. Because some people just do not
know everything in advance.
And on a deeper level, please, do pay attention that it is our whole
copyright system which is being thus challenged.
-- would you find it "ok" that everything you write with your open sourced
word processor be absolutely open sourced? Whatever you write? even if it is
your next brilliant patent?
-- same question for the various open sourced "tools" that allow to edit
pictures, drawings, videos and so on.
The fuss about is that in the present state of the license applicable to
open sourced livecode,
whatever you "write" with live code, if "given" "shared" to anybody else,
then becomes open sourced.
THe frontier between the tool itself (its modules etc) and the "day to day"
work you can produce with it have been blurred. Fine if that is what was
really wanted! But did we really all mean that???
Actually it would be interesting to precise what rights get open sourced in
-- do all the media incorporated in a stack become open sourced when shared?
-- what about the copyright on the layout of the application ?
-- what about the writing of the documentation included?
-- what about the logo of the company/individual included?
-- what about the trade marks eventually?
What happens if you incoportate in a stack a specific copyright protection
for some elements.
There would be a kind of conflict there.
That is why, I thought it would not be a bad idea to keep a door opened for
some protection on some cases even for individuals indies etc. that will not
pay 999$ every year.
And if you think these question over copyrights and so on are just a do
about nothing, for most of us it is, clearly, but for Disney who managed to
extend the copyright period by another 25 years and more in effect it is
vital. A largest part of our economy will now more and more rely on these
rights.
Last : are there other computer programming languages that are open sourced
and that impose on all programs written with it to be open sourced same
way??
best to all,
Robert
--
http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701662.html
Sent from the Revolution - User mailing list archive at Nabble.com.
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[Robert Mann]

Thanks all for these precise links references (Richard & Matt in particular),
I was able to sort of clarify the source of what I felt a problem.
And will share that. [Disclaimer: I'm not a lawyer and this is not legal
advice.]

[See :: conclusion at the end :: call for an education stack on Livecode
Open source version Licensing issues, from a broader perspective than
strictly code]

Basically, I though the GPL applied to STACKS. What do you think?
Well, hum... seems I got it wrong!

the fuzz came from that quote of the FAQ on livecode site :

Can I sell the open source software I create with the open version of
LiveCode?

Yes. You are free to sell or commercialize anything you create under any
business model you choose. For example you could sell your application, or
give it away for free and charge for service and support. You must include
the complete source code for your software with any software you sell and
you cannot prevent a customer redistributing that source code. // To protect
your intellectual property you need a commercial license for LiveCode.//

Problem : a stack is more than pure code.
And that applies particularlily to the stack/hypercard paradigm that was
made to make books, presentations, etc : be a media presenter.
And in a media presenter, the value is often the various "sources" content
and not the code (go next ! go back...)

So to make it short ::
-- NO : a commercial license DOES NOT protect your intellectual property in
a stack, it only protects the (original) code in it.
-- YES : with the Open Source Stack, you can sell staks AND forbid anyother
third party to re-sell that stack if it includes content you wish to keep an
eye upon. The GPL license only applies to CODE, not to the STACK as a whole.

In particular, should one really want to protect some work of art, drawings,
text, audio :: these sources can be encrypted and decrypted at viewing,
making it more difficult to copy the files elsewhere;
[although technically where do you put the key ??]

0) So far, I frankly have'nt a clue whether a stack in itself, ei, the file
structure, is within the GPL or not. it's not what one could call "code".
It could be what is called a framework. Who "owns" it? I wonder!

1) Technically, legally, contractually, the Open SOurce GPL license applies
only to the code within the stack.
http://programmers.stackexchange.com/questions/297102/licensing-for-artistic-work-used-inside-gplv3-licensed-software

2) The source files (images, sounds, videos, texts) are not covered. That
means that basically these elements are protected separately by their
corresponding copyrights. [& same for brand names, logos of course]

3) The same rules seem to apply to the outputs produced : not covered by he
GPL license. So if the output incoporates some copyright work of art, it is
protected by copyright.

4) It seems the FSF foundation suggest to dual license the artwork under GPL
license too, but that is not automatic.

???, QUESTION :: has Livecode adapted the license to include all artworks
text etc within a stack into the GPL??
*** I do not have that impression, but we'd better validate that!! ***

5) What about the application LAYOUT? Again, that is protectable as a
DESIGN, and should not be covered by the GPL license.

7) For completeness, there is kind of a paradox regarding intepreters/and
scripts. Which in the case of livecode is related to the possibility to
compile too.
-- It seems (as mentionned in matt maier's post) that when you write a
script in a stack and distribute that stack file, the GPL does not apply,
treating that file as "content" rather than program. Hence you retain full
copyright.
But that is a very theoratical right, since code is exposed and it would be
very difficult to enforce any such rights.. particularly if used in a
commercial closed application!

-- it's only if you "bind" that code within an executable that GPL steps in
and that your code is open sourced by rule and you have to provide access to
the actual code.

6) Finally it is not totally clear if combining an open source stack that
exchanges with a closed source program of any kind besides, is within or out
of the scope of the GPL.

-- GPL & livecode say :: no way,
-- but GPL elsewhere and lawyers say maybe... let's see in court!

The issue seems discussable both from a technical, legal and ethical point
of views. It kind of depends how the two communicate, how really
(in)dependant the processes are and what the intention is.

it seems that :: if the independant software just adds some quality or
another function, without being central to the working of the main app, it
should stand up.

e;g. an installer application is admitted as being a separate application,
adding some necessary function to a main application that is otherwise
autonomous.

This could allow to keep some elements of control over a portion of code
elsewhere.
That could be a tricky loophole or get by door license wise and a potential
danger to mothership.
-- e.g. if a closed pluggin is made with an older commercial version by a
guy one who cannot anyway afford the new price scheme every year, fine
but... to be used wisely if ever.

This is a very similar conclusion to matt Maier

Post by Matt Maier

Post by Matt Maier
The gray area refers to an optional library that *enhances*

(like a plug-in) the GPL-licensed application. I think that is merely
discouraged, but not actually blocked.

Post by Matt Maier

Post by Matt Maier
So it might be worth asking Livecode if they'd be willing to add an

exception to their GPL license allowing "hobbyists" to distribute a
closed-source library that is not compiled into the GPL-licensed
standalone. That would allow "hobbyists" to keep some of their code secret.
Maybe Livecode could even charge a different amount for that license.

*==> Such a move seems quite a good idea to me too :: it would allow to
control positively the possible loophole that already IS there, it is a gray
area. And stretch out a hand to hobbyists, who are basically willing to play
the game if they do not feel... messed about!*

Any other views?


-------------------------------------------------------------------
Also,
it would be a good idea to make a simple stack
"your open source livecode explained to the brainies!"
Licensing Facts & ISSUES for your CODE and all other COMPONENTS & SOURCES.

So that these issues are more clear to all of us.

I'd be happy to participate actively if and only of
-- somme other folks participate too, say min of 3 !? (to validate the
content)
-- and motherships agrees on the principle to include it in the Open Source
Ressources menu for easy consultation once content is approved,
(otherwise, why bother!?)
-------------------------------------------------------------------------

[Disclaimer: I'm not a lawyer and this is not legal advice.]

Post by Matt Maier
[disclaimer: I'm not a lawyer and this is not legal advice]
I sympathize with your confusion. There is inherent confusion around the
differences between "sharing" and "free/open source." In the former case,
it's just something people do. In the latter case, it is a legal standard.
Livecode Community uses the GPL
http://www.gnu.org/licenses/gpl-3.0.en.html
This is important primarily because your standalones include the Livecode
engine. Livecode owns the copyright on the engine because their programmers
wrote it and assigned their copyright to the corporation. Leaving it at
that means that nobody else has any right to anything with regards to the
Livecode engine. In order to facilitate things like community, and
learning, and customer development, Livecode is giving you (us) a license
to use the engine provided certain conditions are followed. In this case,
the GPL is a viral license in that you are only given a license to use the
code if the binary you produce with it also uses the GPL (or compatible)
license. Those are the terms under which Livecode is comfortable allowing
you to use their intellectual property.
It's worth mentioning that the language itself doesn't work the same way.
If you open up a text editor, and write down words which the Livecode
engine might happen to understand, then you still own the full copyright on
those words. You can do anything you want with them. So the copyright on
the source of a script-only stack belongs to you. If you compile it into
the standalone then it must be licensed GPL.
That means there's a gray area around something like distributing a
Livecode-compiled binary under the GPL (source must be provided) and also
providing one or more encrypted scripts which that application can decrypt
and access if it needs to. As I understand it, the GPL blocks distribution
of a GPL-licensed executable that *requires* closed-source libraries to
run, but does allow the copyright holder to write in a specific exception
if they want to. The gray area refers to an optional library that *enhances*
(like a plug-in) the GPL-licensed application. I think that is merely
discouraged, but not actually blocked.
So it might be worth asking Livecode if they'd be willing to add an
exception to their GPL license allowing "hobbyists" to distribute a
closed-source library that is not compiled into the GPL-licensed
standalone. That would allow "hobbyists" to keep some of their code secret.
Maybe Livecode could even charge a different amount for that license.
[Disclaimer: Again, I'm not a lawyer and this is not legal advice.]
On Mon, Feb 29, 2016 at 12:31 PM, Robert Mann &lt;

Post by Matt Maier
hi folks, what is this fuss about?
First : no. The allegation about hypercard forcing the open source path on
all usage is not true. There was a command to protect a stack ("protect" of
course!) . And some interesting pieces of software were sold as protected
stacks.
And it is precisely that positioning which is about to be abandoned by
livecode and why i think it's going backwards (with LESS) rather than going
forward (with MORE).
1) I never questioned the Open Source version of Livecode. it's fantastic
and needed.
2) I never questioned the Commercial version. Again it's great and helps
going forward.
What I questionned is that we're going to be missing an intermediate
tool/license that would allow somebody to close SOME of his work at a
reasonable cost for a hobbyist. Just as was originally designed in
Hypercard.
Now most reactions are : if it is to play around just don't bother and
distribute as open sourced. Ok guys.
But things are not just that "idealistically" simple. Sometimes you just do
not know yet. And wish to try out something. Because some people just do not
know everything in advance.
And on a deeper level, please, do pay attention that it is our whole
copyright system which is being thus challenged.
-- would you find it "ok" that everything you write with your open sourced
word processor be absolutely open sourced? Whatever you write? even if it is
your next brilliant patent?
-- same question for the various open sourced "tools" that allow to edit
pictures, drawings, videos and so on.
The fuss about is that in the present state of the license applicable to
open sourced livecode,
whatever you "write" with live code, if "given" "shared" to anybody else,
then becomes open sourced.
THe frontier between the tool itself (its modules etc) and the "day to day"
work you can produce with it have been blurred. Fine if that is what was
really wanted! But did we really all mean that???
Actually it would be interesting to precise what rights get open sourced in
-- do all the media incorporated in a stack become open sourced when shared?
-- what about the copyright on the layout of the application ?
-- what about the writing of the documentation included?
-- what about the logo of the company/individual included?
-- what about the trade marks eventually?
What happens if you incoportate in a stack a specific copyright protection
for some elements.
There would be a kind of conflict there.
That is why, I thought it would not be a bad idea to keep a door opened for
some protection on some cases even for individuals indies etc. that will not
pay 999$ every year.
And if you think these question over copyrights and so on are just a do
about nothing, for most of us it is, clearly, but for Disney who managed to
extend the copyright period by another 25 years and more in effect it is
vital. A largest part of our economy will now more and more rely on these
rights.
Last : are there other computer programming languages that are open sourced
and that impose on all programs written with it to be open sourced same
way??
best to all,
Robert
--
http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701662.html
Sent from the Revolution - User mailing list archive at Nabble.com.
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode
[disclaimer: I'm not a lawyer and this is not legal advice]
I sympathize with your confusion. There is inherent confusion around the
differences between "sharing" and "free/open source." In the former case,
it's just something people do. In the latter case, it is a legal standard.
Livecode Community uses the GPL
http://www.gnu.org/licenses/gpl-3.0.en.html
This is important primarily because your standalones include the Livecode
engine. Livecode owns the copyright on the engine because their programmers
wrote it and assigned their copyright to the corporation. Leaving it at
that means that nobody else has any right to anything with regards to the
Livecode engine. In order to facilitate things like community, and
learning, and customer development, Livecode is giving you (us) a license
to use the engine provided certain conditions are followed. In this case,
the GPL is a viral license in that you are only given a license to use the
code if the binary you produce with it also uses the GPL (or compatible)
license. Those are the terms under which Livecode is comfortable allowing
you to use their intellectual property.
It's worth mentioning that the language itself doesn't work the same way.
If you open up a text editor, and write down words which the Livecode
engine might happen to understand, then you still own the full copyright on
those words. You can do anything you want with them. So the copyright on
the source of a script-only stack belongs to you. If you compile it into
the standalone then it must be licensed GPL.
That means there's a gray area around something like distributing a
Livecode-compiled binary under the GPL (source must be provided) and also
providing one or more encrypted scripts which that application can decrypt
and access if it needs to. As I understand it, the GPL blocks distribution
of a GPL-licensed executable that *requires* closed-source libraries to
run, but does allow the copyright holder to write in a specific exception
if they want to. The gray area refers to an optional library that *enhances*
(like a plug-in) the GPL-licensed application. I think that is merely
discouraged, but not actually blocked.
So it might be worth asking Livecode if they'd be willing to add an
exception to their GPL license allowing "hobbyists" to distribute a
closed-source library that is not compiled into the GPL-licensed
standalone. That would allow "hobbyists" to keep some of their code secret.
Maybe Livecode could even charge a different amount for that license.
[Disclaimer: Again, I'm not a lawyer and this is not legal advice.]
On Mon, Feb 29, 2016 at 12:31 PM, Robert Mann &lt;

Post by Matt Maier
hi folks, what is this fuss about?
First : no. The allegation about hypercard forcing the open source path on
all usage is not true. There was a command to protect a stack ("protect" of
course!) . And some interesting pieces of software were sold as protected
stacks.
And it is precisely that positioning which is about to be abandoned by
livecode and why i think it's going backwards (with LESS) rather than going
forward (with MORE).
1) I never questioned the Open Source version of Livecode. it's fantastic
and needed.
2) I never questioned the Commercial version. Again it's great and helps
going forward.
What I questionned is that we're going to be missing an intermediate
tool/license that would allow somebody to close SOME of his work at a
reasonable cost for a hobbyist. Just as was originally designed in
Hypercard.
Now most reactions are : if it is to play around just don't bother and
distribute as open sourced. Ok guys.
But things are not just that "idealistically" simple. Sometimes you just do
not know yet. And wish to try out something. Because some people just do not
know everything in advance.
And on a deeper level, please, do pay attention that it is our whole
copyright system which is being thus challenged.
-- would you find it "ok" that everything you write with your open sourced
word processor be absolutely open sourced? Whatever you write? even if it is
your next brilliant patent?
-- same question for the various open sourced "tools" that allow to edit
pictures, drawings, videos and so on.
The fuss about is that in the present state of the license applicable to
open sourced livecode,
whatever you "write" with live code, if "given" "shared" to anybody else,
then becomes open sourced.
THe frontier between the tool itself (its modules etc) and the "day to day"
work you can produce with it have been blurred. Fine if that is what was
really wanted! But did we really all mean that???
Actually it would be interesting to precise what rights get open sourced in
-- do all the media incorporated in a stack become open sourced when shared?
-- what about the copyright on the layout of the application ?
-- what about the writing of the documentation included?
-- what about the logo of the company/individual included?
-- what about the trade marks eventually?
What happens if you incoportate in a stack a specific copyright protection
for some elements.
There would be a kind of conflict there.
That is why, I thought it would not be a bad idea to keep a door opened for
some protection on some cases even for individuals indies etc. that will not
pay 999$ every year.
And if you think these question over copyrights and so on are just a do
about nothing, for most of us it is, clearly, but for Disney who managed to
extend the copyright period by another 25 years and more in effect it is
vital. A largest part of our economy will now more and more rely on these
rights.
Last : are there other computer programming languages that are open sourced
and that impose on all programs written with it to be open sourced same
way??
best to all,
Robert
--
http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701662.html
Sent from the Revolution - User mailing list archive at Nabble.com.
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Open-source-closed-source-and-the-value-of-code-tp4701649p4701702.html
Sent from the Revolution - User mailing list archive at Nabble.com.

[Monte Goulding]

Robert you may like to take the following snipped quote from Mark Waddingham into consideration in your analysis of how GPL applies to stackFiles:

I am not a lawyer, but it seems wise to at least provide some guidance in this case. Ultimately, it can only be guidance as we did not write the GPL and we do not define copyright law. We can just use our best judgement, our experience, our understanding of the GPL, and look to other use-cases of the GPL which are in existence in the same sphere as us.
It is our considered opinion and after much discussion over quite a long time that the following statement is definitely true:
If Wordpress and Drupal based on current advice from the FSF (who can be considered legal experts in this field - if somewhat biased) believe that their 'plugins' are derivative works of their systems then under the same considerations 'stackfiles' are derivative works of LiveCode.
Now, we firmly believe that the FSF are correct. Not only do we think it is a reasonable interpretation of derivative work, but it is indeed part of the very spirit of the GPL itself. Therefore:
If you use LiveCode Community to create or modify a stackfile to which you hold copyright and then choose to distribute it, then you must distribute it under the terms of the GPLv3. You cannot choose to license it under any other license whether it be more or less permissive than the GPLv3 (on whatever axis you wish to take).

My reading of this is that any content embedded in a stackFile should be licensed under the GPL. I could be wrong as I’m also not a lawyer! I would have thought that the spirit of the license that it applies to everything the application requires to function.

To be honest I’m unclear if there are grey areas about loading content at runtime from external files. It may be only OK to license differently under certain conditions like publicly documented file format reader/editors???? I don’t know about that but it would have seemed to be an easy workaround for Wordpress themes if it were possible to license the php part GPL and the images and CSS etc under some proprietary license. Like I said though, I’m not a lawyer!

Cheers

Monte

Post by Robert Mann
-- YES : with the Open Source Stack, you can sell staks AND forbid anyother
third party to re-sell that stack if it includes content you wish to keep an
eye upon. The GPL license only applies to CODE, not to the STACK as a whole.

[Mark Waddingham]

Usual IANAL terms apply :)

Post by Monte Goulding
My reading of this is that any content embedded in a stackFile should
be licensed under the GPL. I could be wrong as I’m also not a lawyer!
I would have thought that the spirit of the license that it applies to
everything the application requires to function.

Whilst the GPL can be used to cover content there are more (GPL
compatible) suitable ones. The main problem with applying the GPL to
content is deciding what constitutes the 'source code'. Indeed, I
believe there is an FAQ on the FSF site about such things but I can't
find it at the moment (slow internet connection on a train!). Generally
the Creative Commons style licenses are far better for content - you
just need to pick a variant which is definitely compatible with the GPL
(CC/0, for example).

Post by Monte Goulding
To be honest I’m unclear if there are grey areas about loading content
at runtime from external files. It may be only OK to license
differently under certain conditions like publicly documented file
format reader/editors???? I don’t know about that but it would have
seemed to be an easy workaround for Wordpress themes if it were
possible to license the php part GPL and the images and CSS etc under
some proprietary license. Like I said though, I’m not a lawyer!

There are no gray areas here. The GPL is self policing in terms of what
it requires of the distributor of a GPL licensed work. When you convey a
work under the GPL you have to ensure you can supply everything to the
receiver to enable them to reproduce the work with or without
modifications. If you attempt to ship (say) an app where the code is
under GPL but the content files are under a proprietary license you (as
distributor) are violating the GPL yourself as the receiver is then not
able to reproduce the work with any modifications they might wish to
make.

A similar situation (as far as I understand it) covers someone giving
you C source-code (say) for a compiled GPL app they are distributing,
but not providing the build files that they used to build it (the
receiver has to be able to recreate what they received); or using some
sort of code obfuscation process on any of the source files which they
distributed (the receiver has to be able to modify the code effectively
if they wish).

Warmest Regards,

Mark.

[Monte Goulding]

Thanks for clarifying Mark

Sent from my iPhone

Post by Mark Waddingham
There are no gray areas here.

[Erik Beugelaar]

Hi all,

I have read most of this message thread too and for me personal this discussion is not about licenses etc.
In my opinion this discussion fired up just because of MONEY (no news btw) and emotions (Apple/Hypercard/LiveCode).

Enterprise users of LC will not have any problem to pay up to 999$/year license costs or even more if it is benefitting their businesses.

So, it seems that a lot of users who bought LC before the community editions seems to be anxious to decide within a couple of months to pay again 499$/year locked license costs beside of the costs they maybe have spent already to follow academies and buying extensions in the past. Maybe because of feelings they miss all the new features of LC? I don’t know.
For me it is important if it is really so easy to develop new called widgets in LCB in the future. If it is like Xamarin that you will need to know both API’s of targeted platforms I just go on with native programming as I do now unfortunately.

For me personal I bought a complete license of 5.5 in 2012 I guess because of the ‘develop 10x faster’ slogan but this maybe the case if you develop only cross-platform DESKTOP applications which LC does very good but to develop cross-platform MOBILE apps with LC is for me another story beside of the nice IDE of LC.

To spent 999$ by the time I think the product 8.x is mature, I will take a look again if LC is a time killer in cross-platform MOBILE development and if so, I will not have any problem to pay 999$/year.

Kind regards,
Erik



Sent from Matwetwe <http://www.about.me/beugelaar>

Post by Mark Waddingham
Usual IANAL terms apply :)

Post by Monte Goulding
My reading of this is that any content embedded in a stackFile should
be licensed under the GPL. I could be wrong as I’m also not a lawyer!
I would have thought that the spirit of the license that it applies to
everything the application requires to function.

Whilst the GPL can be used to cover content there are more (GPL
compatible) suitable ones. The main problem with applying the GPL to
content is deciding what constitutes the 'source code'. Indeed, I
believe there is an FAQ on the FSF site about such things but I can't
find it at the moment (slow internet connection on a train!). Generally
the Creative Commons style licenses are far better for content - you
just need to pick a variant which is definitely compatible with the GPL
(CC/0, for example).

Post by Monte Goulding
To be honest I’m unclear if there are grey areas about loading content
at runtime from external files. It may be only OK to license
differently under certain conditions like publicly documented file
format reader/editors???? I don’t know about that but it would have
seemed to be an easy workaround for Wordpress themes if it were
possible to license the php part GPL and the images and CSS etc under
some proprietary license. Like I said though, I’m not a lawyer!

There are no gray areas here. The GPL is self policing in terms of what
it requires of the distributor of a GPL licensed work. When you convey a
work under the GPL you have to ensure you can supply everything to the
receiver to enable them to reproduce the work with or without
modifications. If you attempt to ship (say) an app where the code is
under GPL but the content files are under a proprietary license you (as
distributor) are violating the GPL yourself as the receiver is then not
able to reproduce the work with any modifications they might wish to
make.
A similar situation (as far as I understand it) covers someone giving
you C source-code (say) for a compiled GPL app they are distributing,
but not providing the build files that they used to build it (the
receiver has to be able to recreate what they received); or using some
sort of code obfuscation process on any of the source files which they
distributed (the receiver has to be able to modify the code effectively
if they wish).
Warmest Regards,
Mark.
--
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
http://lists.runrev.com/mailman/listinfo/use-livecode

[[-hh]]

Post by Monte Goulding

Post by Monte Goulding

Post by Monte Goulding
One of the issues of course is that there really might only be a handful
of users that can't afford Indy and can't or won't use Community.

Sent from my iPhone
Do you include those who might want to publish to the Mac App Store and
IOS in your estimate? Roger

Roger if you are suggesting you would be happy with Community if you
could publish GPL apps to Apple's stores then that's probably something
to take up with Apple.
Sent from my iPhone

Monte, Roger's question is clear. Why don't you answer it?
And show us the the data that's the base of your estimate?

Hermann

[Monte Goulding]

What estimate? I did say "might" as I really have no idea what y'all can afford :-)


Sent from my iPhone

Post by [-hh]
Monte, Roger's question is clear. Why don't you answer it?
And show us the the data that's the base of your estimate?

[[-hh]]

My email wasn't displayed, perhaps because a suspected iPhone?
No, No - I didn't sent this from anybody's iPhone ;-)

[Jim Lambert]

Whether I buy flowers for my wife because I think she's pretty or because I'm
trying to apologize, either way the florist makes $60.

Either way Tiffany is one lucky gal!

Jim Lambert

[Monte Goulding]

Post by Jim Lambert

Whether I buy flowers for my wife because I think she's pretty or because I'm
trying to apologize, either way the florist makes $60.

Either way Tiffany is one lucky gal!

Well.. it depends on what he’s apologising for ;-)

[Jim Lambert]

Post by Monte Goulding
Well.. it depends on what he’s apologising for ;-)

LOL!

JimL