Relicense Policies and Assuptions
Last updated at 2:31 am UTC on 26 August 2009
Fill this in and submit it to the SFC
Policy
- Insert Squeak 4.0 rewriting policy here
Etoys Policy
- Insert email from Yoshiki here
Pharo Policy
- Insert email from Adrian here
Core assuptions regarding the creation of the Audit
Things we are pretty sure about:
Adapted from http://installer.pbworks.com/LicenseAuditing
What is a license-clean image?
- A license-clean image is an image where all contributions satisfy the following two constraints:
- the copyright license of the contribution is explicitly defined
- that copyright license is either the Apache license 2.0 or the MIT license
- What does that mean?
- A contribution is a change made by one author to one method.
- The author of a contribution determines the copyright license of his/her contribution
- If the contribution is part of Squeak 1.1, the copyright license is explicitly Apache 2, and the contribution is CLEAN
- If the contribution has an explicit license of MIT, it is CLEAN
- If the author signed the contributor agreement, and the contribution was made before November 2006, the copyright license is explicitly MIT, and the contribution is CLEAN
- If the contribution was made after November 2006, and does not have an explicit license, it is UNCLEAN even if made by a signing contributor. This is because the effective dates on the all of the contributor agreements are after November 2006.
- Otherwise, the license of the contribution is too hard to determine, or is Squeak-L, and the contribution is UNCLEAN
- A Method is license-clean if and only if every single contribution that makes it up is license-clean
- A Method is not necessarily license-clean only because the last contribution is clean (because the author stamp belongs to a signer)
- If a method has the same source code as a license-clean method, it might as well be clean, since the method could be replaced with the license-clean method with no change in functionality
- Pharo contributions are under an explicit license of MIT and are therefore CLEAN
Things we are not sure about
- The Etoys relicense may or may not be acceptable. Documentation on the process is very vague
- The Pharo relicense may or may not be acceptable. I have heard it was done completely cleanroom, which would make it valid if there were any documentation. It also built on the Etoys relicense, which may or may not be a problem
- The Etoys relicense has methods with no author initials or timestamps. Why?
15:28 <kencausey> !Number methodsFor: 'mathematical'!
15:28 <kencausey> reciprocal
15:28 <kencausey> in contrast to
15:28 <kencausey> !Number methodsFor: 'truncation and round off' stamp: 'yo 8/22/2008 16:48'!
15:28 <kencausey> integerPart
Things we know are wrong but assumed anyway
Should fill in why these are wrong, and why we went with them anyway
- The source code on ftp.squeak.org is the complete history of all methods in the image
- Missing versions between 1.1 and 1.31, missing updates in 3.9 and 3.10, patch revisions prior to image inclusion are missing
- The author initials in the method headers, where available, are authoritative
- Patches written by someone then tweaked by a release team member prior to inclusion bear no hint of the original author
- We know this happened a lot in early versions with Dan Ingalls
- Patches accepted after November 2006 are license clean
- We assume that since the relicense was big news, everybody who contributed after the signature collection began submitted their patches under the intent of not disrupting the relicense
- We assume this for patches that were authored before November 2006 as well, if they were accepted after November 2006 (this is the hardest assumption to justify)