Trying to make economic sense of open sourcing livecode

[Dr. Hawkins]

So many thoughtful responses . . . I'll try to put all my thoughts in
one spot (and will inevitably fail . . .)
On Fri, Feb 1, 2013 at 4:48 PM, Richard Gaskin
<ambassador at fourthworld.com> wrote:
> If you want to share the code with the community, and do so in a way that
> requires other derivative works to be similarly shared, you can use the
> GPL-licensed version of LiveCode for that.

Generally, using a GPL licensed tool doesn't turn the developed code
into GPL code.

OTOH, gcc isn't quite GPL, having exceptions to reach this end, as
some of its own code ends up in the output.

My initial impression is that a compiled, stand-alone stack would be
full of code from the compiler, and would thus be "infected" by GPL
terms.

Then again, it might be possible to ship a non-GPL stack that was
password protected that would be run by the GPL or non-GPL engine,
although it might be impossible to handle the decryption in a way that
doesn't make available a key that gives effective access to the
source--the engine is going to need the key, and if the engine is GPL,
it's trivial to put a single line in to print the key on receipt . . .

The infection of the stand alone generated by the GPL compiler could
well be the key that lets the commercial version thrive.

It would also allow would-be developers a step in, developing
initially with the GPL version, seeing if the project is possible, and
then buying the commercial license.

This also plays into the app store issues--if the license infects the
stand-alone with the GPL, it would indeed keep it out of the store.

Other thoughts:

--on writing a feature:  the GPL wouldn't stop anyone from writing and
*using* a feature without releasing the code; he just couldn't ship
the binary to anyone else without making the source available.

--licensing:  Needs to be dual-licensed, and to stay in control of the
trademark/name and open source project.  A patch won't make it into
the named OSS version of the software without being maed available to
RunRev for inclusion in the commercial version.  Authors not willing
to do so would have to maintain their own fork (e.g., NeoOffice), with
the overhead/effort involved in that.

also from Richard:

>The other examples you noted weren't dual-licensed.  I think a
>good example here would be MySQL.

Netscape and OpenOffice were both dual-licensed, and only code offered
to both would be put into the named projects.


-- 
Richard E. Hawkins, Esq.
(702) 508-8462