Creative Common Copyright Notice in Standalones

[Jan Schenkel]

--- On Mon, 1/10/11, David Bovill <david at vaudevillecourt.tv> 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)