The overriding goal of Squeak 4.0 is to get a license-clean image.

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

How to do it

As of 27 March 2008, we have two high-level plans for relicensing the image:

Plan A: Clean KernelImage

During meetings two and three, we decided on a plan centered around KernelImage, and discussed it's feasability in meeting four. Pavel wrote an email about this plan, just after meeting 3

The Plan

1. Start with the current KernelImage (it is named kernel.image, and is part of the ImagePack)
2. Do a license audit to determine which methods are not license-clean
3. Organize a two-phase clean-room rewrite

The Numbers

The following analysis was done on 24 March 2008, during meeting 4. From Pavel's initial audit, kernel image has:

1. 6899 methods in total
2. 1009 methods whose latest source code is the same as the source code in Squeak 1.1. These methods are, for all practical purposes, license clean.
3. At least 322 methods whose author stamp shows an author who has not signed the contributor agreement. These methods are not license-clean, and must be rewritten
4. 4568 methods which do not fall into either of the above two categories. These methods require a full background investigation to determine whether all their makeup contributions are clean. Thus, we need a database with the full history of all these methods.
5. As an additional complication, the audit was done for an image derived from Squeak 3.10, which has contributions dating later than November 2006. The audit probably needs to be redone for an image derived from 3.8.1 or 3.9, where all contributions made by signers have an explicit license.

Timeline

1. Without doubt, there are 322 methods that need to be rewritten. I estimate this will take 2-3 months. This rewrite can, in theory, be done in parallel with everything else that needs to be done
2. Without doubt, we need a full history of at least the 4568 methods of unknown cleanliness. Maurice Rabb says this can be done by "late April", or in one month. Progress on these methods would stall until this was done
3. It is anyone's guess how many of the 4568 methods are dirty and need to be rewritten. It will probably take another 2-3 months at least
4. All things considered, July or August 2008 is the earliest this could possibly be done by

Plan B: Use Spoon

This was conceived as as alternative to Plan A, which seems like an awfully lot of work:

1. Build a history database
2. Wait for Spoon to be released, doing other work (bug fixes, vm improvements, ui improvements, i18n support, a build server) in the meantime
3. Audit it and fix problems

This has a number of advantages over Plan A:

1. Spoon has an order-of-magnitude fewer methods to audit an maybe rewrite than KernelImage
2. It is not unlikely that every single contribution made to spoon belongs to a single author (Craig Latta)
3. Spoon includes a history database mechanism (naiad) which has explicit support for computing licenses of methods and contributions

How does this schedule?

1. Craig says that spoon will be ready by "the solstice" (20 June 2008)
2. an audit and possible rewrite would take much less time with spoon.
3. Therefore we may reasonably expect to have a license-clean release out by August, using this plan.

Conclusion

Plan B seems like the smarter choice currently.