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
>> http://www.cincom.com/smalltalk
>
>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
>impossible job.
>
>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.
>
>Ken

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
http://www.cincom.com/smalltalk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100308/bf80db38/attachment.htm