| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Finally, you can manage your Google Docs, uploads, and email attachments (plus Dropbox and Slack files) in one convenient place. Claim a free account, and in less than 2 minutes, Dokkio (from the makers of PBworks) can automatically organize your content for you.

View
 

LicenseAuditing

Page history last edited by PBworks 12 years, 9 months ago

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

 

This is based on my understanding as of 26 March 2008. It needs to be reviewed by someone more knowledgable --Matthew Fulmer

 

What is a license-clean image?

A license-clean image is an image where all contributions satisfy the following two constraints:

 

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.

Comments (0)

You don't have permission to comment on this page.