Licensing AGAIN [was: Sharing FontLab Plugin]
Richard Gaskin
ambassador at fourthworld.com
Fri Jul 22 10:02:25 EDT 2016
Kay C Lan wrote:
...
> <peter.brett at livecode.com> wrote:
>> Apple's walled garden is not a fertile pasture for growing Free
>> Software.
>> If you want to make Free Software apps for mobile devices, target
>> Android.
>
> Hmm, I think this is a common misconception of the situation. Apple is
> more than happy to distribute OSS. I think VLC is an important case to
> consider. Apple was more than happy to distribute it and many of the
> code contributors were more than happy for Apple to do that. It was a
> few zealots at the FSF who pointed out it was not legally possible
> under GPL v2.
I don't think there's a bad guy here. The Apple's TOS and the GPL are
simply incompatible.
Just as it was possible to resolve the VLC situation by choosing a
different license, it's also possible for Apple to choose to remove the
download limits to bring it on par with Android.
The GPL predates the Apple app store by decades; it certainly wasn't
written with the app store in mind. Each org has its own reasons for
preferring their terms as they've written them. I believe they do so
because they reflect the organization's goals, and not all orgs have the
same goals.
Baking soda and vinegar are both useful things, each fine on its own.
Just don't try to store them in the same container. :)
> As Richard has stated, it's very important to consider which OSS
> license is right for you, some (MIT, BSD, MPL v2.0) offer you the
> freedom to do what you want, like distribute via Apple, whilst others,
> notably those from the FSF (GPL), are less permissive and the
> constraints are actively enforced in court.
>
> I think a blog post on this topic would be engaging, a License Guide
> that lived in the LC Dictionary helpful, using plain English and a
> infographic/matrix.
What features of MPL or BSD interest you?
There are so many licenses that it may be quite a task to outline them
all. And the ROI for the effort would be minimal, since the only
license relevant for the Community Edition is the GPL, and almost
everyone using the proprietary Indy or Business Editions does so because
they want a custom proprietary license, which can vary so broadly it
would be beyond the achievable scope of such a document.
The most common middle ground is MIT, so if we were to draft such an
outline that was both useful and achievable it may well include little
more than the summary I posted here the other day:
<http://lists.runrev.com/pipermail/use-livecode/2016-July/229194.html>
Venturing beyond those may represent a significant effort, and one with
diminishing returns. For the very small number of developers using the
proprietary editions and who have specific reasons to want neither a
custom proprietary license nor the MIT license, so many good
descriptions of licenses exist across the Web that personally I'd be
hard-pressed to decide which features I'd ask the team to set aside to
replicate that documentation. In my 20 years in this community I've
seen only two such cases, and both found existing materials satisfying
to help them make their license decision.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode
mailing list