Glorp license (was: Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!)

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
> [hidden email]
> [hidden email]
> 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