[squeak-dev] Glorp license
knight at acm.org
Mon Mar 8 22:29:25 UTC 2010
At 03:30 PM 2010-03-08, Ken Causey wrote:
>On Mon, 2010-03-08 at 14:54 -0500, Alan Knight wrote:
>> Fortunately, Glorp doesn't have all that many distinct contributors,
>> and I do have a reasonable number of signatures already. I've been
>> thinking about changing the license for a while, but it's a lot of
>> work, and not much fun. Any advice from those involved with doing this
>> for Squeak appreciated.
>> Alan Knight [|], Engineering Manager, Cincom Smalltalk
>> knight at acm.org
>> aknight at cincom.com
>Perhaps you could ask specific questions? I don't understand where you
>perceive there is a lot of work required. Please feel free to correct
>any misunderstandings on my part. Also all of the below is my opinion
>synthesized from various sources and opinions.
>1. You have code under license A with X contributors.
>2. You solicit to all contributors to have the license changed to
>license B and request written/signed agreements to this effect.
>3. You receive agreements from Y contributors.
>4. Assuming Y < X you then have to decide for yourself what the risk is
>that the one of the remaining contributors is likely to later object to
>the license change. If you deem the risk is too great:
> 4a. How much code in the latest release is from the non-signing
>contributors? Note you need to count all versions of code and later
>versions are 'tainted' by earlier contributors unless you can clearly
>state that later versions were written without simply copying the
>previous versions. Given there is some such code, you could remove and
>or replace it. Best practice is to write a comment describing what the
>method should do and writing the new version referencing only that
>documentation. Tests are of course handy to verify the implementation.
> 4b. If there is just too much left to rewrite then you go back to
>step 2 and iterate until you are comfortable at step 4 or give up as an
>5. Assuming you have gotten past step 4 and are personally comfortable
>with the result but Y < X is still true, write up a specific 'intent to
>relicense' notice stating a specific date that a new relicensed version
>will be released and do everything you can to ensure that all
>contributors have seen it. This is intended to give them an explicit
>opportunity to disagree. This is relevant 'due diligence' if a
>complaint is received later.
>6. If no one disagreed then you issue the new release under license B.
I guess my perception of it being onerous stems from a couple of things
- The steps you outlined sound like a lot of work to me. Probably the largest amount is in the resolution of the phrase "X contributors" to a distinct set. And then figuring out how to contact them all.
- I have faith in the legal system's ability to make things more complicated than it seems they ought to be.
But that sounds like a good recipe. Thanks.
Alan Knight [|], Engineering Manager, Cincom Smalltalk
knight at acm.org
aknight at cincom.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev