--- On Mon, 1/10/11, David Bovill <[email protected]> wrote:
> Hi Jan _ I don't quite get the exact
> nature of the private public
> distinction you are making - si the source code visible, or
> are you
> referring to a license distinction. From a casual reading
> it looks a bit
> like there is a contradiction in there somewhere - but that
> most of what you
> want can be got with dual licensing.
>
Hi David,
Maybe I was throwing a few too many things onto a single pile :-)
Often library stacks use 'script local' variables to store data, and 'private'
commands and functions to hide the innards. Example:
##
--> constants and local variables
local sSmurfsA -- internal smurf data array
--> event handlers
on libraryStack
p_qrtSmurf_LoadCoreData
pass ibraryStack
end libraryStack
--> public handlers
command qrtSmurf_DoSmurf pSmurfName
-- does something important based on pSmurfName and sSmurfsA
end qrtSmurf_DoSmurf
command qrtSmurf_UpdateSmurf pNewSmurfData
-- does some sanity checking and then modifies sSmurfsA
put line 3 of pToSmurfData into sSmurfsA[tIndex]["intelligence"]
end qrtSmurf_UpdateSmurf
command qrtSmurf_XYZ pX, pY, pZ
-- does some sanity checking and calls private commands to do the work
p_qrtSmurf_ABC pX, pY, p_qrtSmurf_BCD(pY, pZ)
end qrtSmurf_XYZ
--> private handlers
private command p_qrtSmurf_LoadCoreData
-- does all sort of things to fill the sSmurfsA variable
end p_qrtSmurf_LoadCoreData
private command p_qrtSmurf_ABC pX, pY
-- no sanity checks ; subject to change in newer versions
end p_qrtSmurf_ABC
private function p_qrtSmurf_BCD pY, pZ
-- no sanity checks ; subject to change in newer versions
end p_qrtSmurf_BCD
##
Outside of the script, you cannot access the 'script local' variables or call
the 'private' handlers, as they are properly encapsulated. Only the rest of the
handlers that are meant for 'public' use are not tagged 'private' and offer the
official API of the library. All the rest is internal and subject to change.
Now it may sound far-fetched, but suppose some enterprising individual says
"Hmm, I really like that open source Smurf library, and I'm going to make some
money - but I don't want to share back my extensions"
What he can do, is take the library, remove the 'private' qualifier from the
handlers that he needs access to, and add a few more commands and handlers to
read/write the sSmurfsA variable as he sees fit.
Then he wraps this modified version of Quartam Smurf Library, writing ACME
Smurf Library with a few new commands and functions, using the now exposed
handlers and variables to inject data. Meanwhile, the heavy lifting is still
done by Quartam Smurf Library.
And now he can even charge for his ACME Smurf Library. As long as he's sharing
the 'cracked open' version of Quartam Smurf Library. From my reading of the
more liberal FOSS licenses, there is nothing you can do: he's 'sharing his
changes' to the Quartam Smurf Library, but morally he is clearly abusing it.
The only option then becomes mucking around the internals in every release, to
give the abuser a tough time, and meanwhile try to catch up with the extras he
implemented but doesn't want to share. An annoying cat-and-mouse game...
The LGPL license is rather close to what I'm looking for, as it does allow
using the LGPL-ed library in commercial work, as long as you keep it external
from the main program, allowing the user to re-link to a newer version of the
library.
Unfortunately, that's where the problem comes in for LiveCode Web plugin
revlets: the stack and its substacks all become part of a single package that
can't be taken apart by the end-user to re-link it with a newer version of the
library. So technically, this would be a violation of the license.
And for some advocates of the xGPL license series, that doesn't offer a real
solution for the grey area of LiveCode Server either: as the end-user only has
the finished html product, their freedom is limited. Frankly, I don't care so
much about that as long as the changes to the library are shared and available,
and the license documentation and copyright requirements are upheld.
So it looks like there's no readily available FOSS license that covers these
concerns; and would it even be feasible to enforce a different license per
LiveCode deployment options?
I'm not aiming to be a PITA for open source advocates. I'm willing to share,
but want it done 'right' so that everyone can enjoy the benefits of my work,
and hopefully contributors will join in to make it even better.
Surely I can't be the only one in the community scratching their heads about
these sort of FOSS license details?
Thanks in advance for all your feedback,
Jan Schenkel.
=====
Quartam Reports & PDF Library for LiveCode
www.quartam.com
=====
"As we grow older, we grow both wiser and more foolish at the same time." (La
Rochefoucauld)
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
