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