Dear All,
Andreas asked me to post some details of how people can contribute to 3.11, 4.0, 4.1+.
What version are we doing again? ========================
I don't know about you but I am a bit confused about what the plans are for the next version of squeak. Essentially, the re-licensing effort has been deemed by the board to have version 4.0. With a new "clean" v4 sources file. This version of squeak will be essentially the same, feature-wise, as 3.10.2, it may have LPF, it may not. (LPF packages are licence clean)
Following this 3.11 will be re-targeted to this 4.0 image and will probably be released as 4.1 soon after.
How can I be involved in the re-licensing effort? ==================================
Start by joining the folks on irc #squeak and read matthews emails. Matthew, Ken and others are thrashing out the details there.
The deliverable of the re-licence effort will be a series of changesets, uploaded and discussed on mantis. So here is the clever thing:
***** Installer squeaksource project: 'Installer'; installQuietly: 'Installer-Core'. (Installer mantis bugsAll select: [ :bug | ((bug status = 'testing' or: [ bug status = 'resolved']) and: [ bug fixedIn = '4.0' ] ]) do: #ensureFix. *****
[ken - please could you add the 4.0 version to the available selection list]
The code above will (soon) load the current set of published re-licensed code into your 3.10+ image, for you to test.
How do I contribute code to the re-licensing effort? ====================================
1) Pick/find something to work on in discussion with Matthew. 2) Post a mantis entry, describing your sub-task, soliciting discussion there. 3) Make that entry a child of http://bugs.squeak.org/view.php?id=6989 so that the list of relicencing tasks is managed together. 4) When you have a changeset to deliver, upload it to the mantis entry. note: please use files in the following naming convention: M1234-SomeChangeSetName.1.cs having the bug number as a prefix is tidier. If you dont, dont worry, Installer will name changesets according to this convention anyway.
5) Add a script in a note, as in this example http://bugs.squeak.org/view.php?id=6988 4) Set the status to "testing" and the fixed in field to "4.0"
How do we test? ============ Using a 3.10.2 image, open a Transcript window and run the code snippet marked ***** above. If you are blessed, this will give you a result we shall call 4.0-test-alpha.
[an alternative version of ***** is provided for you, in Installer]
To update Installer. Installer squeaksource project: 'Installer'; installQuietly: 'Installer-Core'.
To view list:
mantis := Installer mantis.
(mantis bugsTesting: '4.0') explore. "issues in status testing" (mantis bugsRelease: '4.0') explore. "issues in status resolved i.e. signed off having passed testing"
To install: (mantis bugsTesting: '4.0') do: #ensureFix. "issues in testing" (mantis bugsRelease: '4.0') do: #ensureFix. "issues in status resolved i.e. signed off having passed testing"
The next step - Signing off? ==================== When a consensus is reached as to the effectiveness and validity of your proposed changesets. Matthew will switch the status to "resolved", and the issues marked as resolved may be loaded via:
(Installer mantis bugsRelease: '4.0') do: #ensureFix.
The release 4.0 =========== The release will be generated by loading the above fixes, and performing a short script + SmalltalkImage current cleanUpAllExcept: #(ChangeSet)
===== I hope you find these instructions clear, if not feel free to ask questions, and join us in irc #squeak
best regards
Keith
Last Sunday, we officially started accepting patches for Squeak 4.0 [1]. Squeak 4.0 will be 3.10.2 + relicense, and so will be MIT.
=========== The Short Version ===========
We are currently awaiting legal advice from the Software Freedom Law Center [3]. It is recommended that you avoid contributing to the relicensing effort pending further notice
=========== The Long Version ===========
There are several reasons we are doing the relicense in the first place. In order from most important to least, these are the reasons: 1. To be able to join the Software Freedom Conservancy [2] and the associated Software Freedom Law Center [3] 2. To avail the fears of corporations who are hesitant to use Squeak due to the SqueakL license 3. To permit the inclusion of squeak into Linux distributions; most importantly, Debian
I will note that this is the priority list ONLY for the squeak.org release, as overseen by the Squeak Leadership Team [4]. EToys 4.0 [5], which was overseen by Viewpoints Research Institute [6] and the Squeakland Foundation [7], had a different set of priorities in their relicense effort, namely:
- Allow EToys to be distributed with the One Laptop Per Child (OLPC [8]) XO laptop, under an accepted open-source license
It is not clear right now that the relicense that was acceptable to VPRI, the Squeakland foundation, and One Laptop Per Child is acceptable to the Software Freedom Law Center. The central issue is this:
--- The Truth about the relicense ---
We can never be 100% certain that all code in squeak is legitimately covered by the MIT license, even though we will be declaring it as such after the release of Squeak 4.0. Thus, all we can due is minimize the risk of lawsuit. However, there is an inherent cost to doing the relicense. Those responsible for the relicense must choose how much work they are willing to do before deeming the risk of lawsuit acceptable and declaring the code to be under the MIT license.
After review of the relicensing work done on EToys 4.0 by Yoshiki Ohshima, Ken Causey and I have found that VPRI and Squeakland have apparently taken the following stance regarding the license of EToys 4.0:
--- The VPRI Stance ---
Individual contributions consisting of less than 1 line of code were not rewritten, and were illegitimately relicensed under MIT. This is considered acceptable risk by VPRI, and cut down the cost of the relicense, perhaps significantly.
However, the Software Freedom Law Center has declared their stance differently, in all their previous contacts with the Squeak Leadership Team, through Craig Latta:
--- The SFLC Stance ---
Every line of code must be audited, and rewritten or removed if it is not in compliance with the MIT license.
This is the minimal risk stance that is achievable. However, two things are unclear:
--- Remaining Questions ---
1. Is the SFLC stance overkill? Would SFLC accept a Squeak 4.0 relicensed using the VPRI stance to be "acceptable risk"? 2. If not, is appealing to the SFLC a cost the Squeak community, and specifically, the volunteers who do the relicense, are willing to bear?
Randal Schwartz is currently contacting SFLC to determine the answer to the first question.
Until Randal gets a response, Ken Causey and I recommend that nobody work on the relicense until we have more information from SFLC.
[1] Squeak 4.0 request for contributions: http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/133862.... [2] Software Freedom Conservancy http://conservancy.softwarefreedom.org/ [3] Software Freedom Law Center http://www.softwarefreedom.org/ [4] Squeak Leadership Team http://squeak.org/Foundation/ [5] EToys 4.0 http://lists.laptop.org/pipermail/etoys/2008-December/002849.html http://www.vpri.org/pdf/tr2009001_etoys4olpc.pdf [6] Viewpoints Research Institute http://vpri.org/ [7] The Squeakland Foundation http://vpri.org/pipermail/squeakland/2009-January/004449.html [8] One Laptop Per Child http://laptop.org/en/
Thanks Matthew, great email.
Depending on the results of the discussion with SFLC you can look forward to another detailed email discussing rewriting/auditing procedures. Hopefully that won't be delayed too long.
Ken
On Sun, 2009-02-15 at 14:57 -0500, Matthew Fulmer wrote:
Last Sunday, we officially started accepting patches for Squeak 4.0 [1]. Squeak 4.0 will be 3.10.2 + relicense, and so will be MIT.
=========== The Short Version ===========
We are currently awaiting legal advice from the Software Freedom Law Center [3]. It is recommended that you avoid contributing to the relicensing effort pending further notice
<snip>
Matthew -
Has anyone considered licensing those one-liners from VPRI in good faith? I.e., instead of saying "this is code of unknown heritage" say "this is code contributed by VPRI in EToys 4 under MIT license". Period. I don't know if this works for the lawyers but it might be worth a try.
Cheers, - Andreas
Matthew Fulmer wrote:
Last Sunday, we officially started accepting patches for Squeak 4.0 [1]. Squeak 4.0 will be 3.10.2 + relicense, and so will be MIT.
=========== The Short Version ===========
We are currently awaiting legal advice from the Software Freedom Law Center [3]. It is recommended that you avoid contributing to the relicensing effort pending further notice
=========== The Long Version ===========
There are several reasons we are doing the relicense in the first place. In order from most important to least, these are the reasons:
- To be able to join the Software Freedom Conservancy [2] and the associated Software Freedom Law Center [3]
- To avail the fears of corporations who are hesitant to use Squeak due to the SqueakL license
- To permit the inclusion of squeak into Linux distributions; most importantly, Debian
I will note that this is the priority list ONLY for the squeak.org release, as overseen by the Squeak Leadership Team [4]. EToys 4.0 [5], which was overseen by Viewpoints Research Institute [6] and the Squeakland Foundation [7], had a different set of priorities in their relicense effort, namely:
- Allow EToys to be distributed with the One Laptop Per Child (OLPC [8]) XO laptop, under an accepted open-source license
It is not clear right now that the relicense that was acceptable to VPRI, the Squeakland foundation, and One Laptop Per Child is acceptable to the Software Freedom Law Center. The central issue is this:
--- The Truth about the relicense ---
We can never be 100% certain that all code in squeak is legitimately covered by the MIT license, even though we will be declaring it as such after the release of Squeak 4.0. Thus, all we can due is minimize the risk of lawsuit. However, there is an inherent cost to doing the relicense. Those responsible for the relicense must choose how much work they are willing to do before deeming the risk of lawsuit acceptable and declaring the code to be under the MIT license.After review of the relicensing work done on EToys 4.0 by Yoshiki Ohshima, Ken Causey and I have found that VPRI and Squeakland have apparently taken the following stance regarding the license of EToys 4.0:
--- The VPRI Stance ---
Individual contributions consisting of less than 1 line of code were not rewritten, and were illegitimately relicensed under MIT. This is considered acceptable risk by VPRI, and cut down the cost of the relicense, perhaps significantly.However, the Software Freedom Law Center has declared their stance differently, in all their previous contacts with the Squeak Leadership Team, through Craig Latta:
--- The SFLC Stance ---
Every line of code must be audited, and rewritten or removed if it is not in compliance with the MIT license.This is the minimal risk stance that is achievable. However, two things are unclear:
--- Remaining Questions ---
1. Is the SFLC stance overkill? Would SFLC accept a Squeak 4.0 relicensed using the VPRI stance to be "acceptable risk"? 2. If not, is appealing to the SFLC a cost the Squeak community, and specifically, the volunteers who do the relicense, are willing to bear?Randal Schwartz is currently contacting SFLC to determine the answer to the first question.
Until Randal gets a response, Ken Causey and I recommend that nobody work on the relicense until we have more information from SFLC.
[1] Squeak 4.0 request for contributions: http://lists.squeakfoundation.org/pipermail/squeak-dev/2009-February/133862.... [2] Software Freedom Conservancy http://conservancy.softwarefreedom.org/ [3] Software Freedom Law Center http://www.softwarefreedom.org/ [4] Squeak Leadership Team http://squeak.org/Foundation/ [5] EToys 4.0 http://lists.laptop.org/pipermail/etoys/2008-December/002849.html http://www.vpri.org/pdf/tr2009001_etoys4olpc.pdf [6] Viewpoints Research Institute http://vpri.org/ [7] The Squeakland Foundation http://vpri.org/pipermail/squeakland/2009-January/004449.html [8] One Laptop Per Child http://laptop.org/en/
On Sun, 2009-02-15 at 12:33 -0800, Andreas Raab wrote:
Matthew -
Has anyone considered licensing those one-liners from VPRI in good faith? I.e., instead of saying "this is code of unknown heritage" say "this is code contributed by VPRI in EToys 4 under MIT license". Period. I don't know if this works for the lawyers but it might be worth a try.
Cheers,
- Andreas
Personally I'm not comfortable with that.
But there is an additional wrinkle in that the methods version in eToys 4.0 does not represent the latest versions in 3.10.2-7179 in every case. I'm not sure where, but we forked off earlier than this. For example in my 'How to rewrite a license restricted method' email: eToys uses version 4 as the current version whereas 3.10.2-7179 uses 5. Minor in this case, but perhaps problematic in others.
Ken
Mathew, and others, are you interested in using the closure compiler and VM extensions I've done at Qwaq in 4.0? These provide ANSI closures with no peformance degradation and a very small (5 bytecode) increment to the VM.
Eliot
"Eliot" == Eliot Miranda eliot.miranda@gmail.com writes:
Eliot> Mathew, and others, Eliot> are you interested in using the closure compiler and VM extensions I've Eliot> done at Qwaq in 4.0? These provide ANSI closures with no peformance Eliot> degradation and a very small (5 bytecode) increment to the VM.
(Wearing my Leadership Team hat for a moment...)
My initial thought is that I want 3.10.2 and 4.0 to be as close as possible, differing only in license-mandated issues, so that SFC will have as little work as possible to do to assist us with the verification.
However, I *would* like those extensions in a release soon. I imagine that shortly after we get 4.0 released and stabilized, the 3.11 work will be folded in to make 4.1, and your changes can go in then as well. The exact incorporation process is up to the Release Team though.
On Sun, Feb 15, 2009 at 6:02 PM, Randal L. Schwartz merlyn@stonehenge.comwrote:
"Eliot" == Eliot Miranda eliot.miranda@gmail.com writes:
Eliot> Mathew, and others, Eliot> are you interested in using the closure compiler and VM extensions I've Eliot> done at Qwaq in 4.0? These provide ANSI closures with no peformance Eliot> degradation and a very small (5 bytecode) increment to the VM.
(Wearing my Leadership Team hat for a moment...)
My initial thought is that I want 3.10.2 and 4.0 to be as close as possible, differing only in license-mandated issues, so that SFC will have as little work as possible to do to assist us with the verification.
However, I *would* like those extensions in a release soon. I imagine that shortly after we get 4.0 released and stabilized, the 3.11 work will be folded in to make 4.1, and your changes can go in then as well. The exact incorporation process is up to the Release Team though.
Works for me. When and if the VM is no longer backwards-compatible (e.g. the Stack VM) one can move to 5.0. However, I would recommend getting the VM changes into the 4.0 VM as this will make migrating to image-level closures much easier. I believe (John, can you confirm) that John's latest Mac 3.8 beta VMs have included the closure bytecodes.
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
On 15-Feb-09, at 6:06 PM, Eliot Miranda wrote:
Works for me. When and if the VM is no longer backwards-compatible (e.g. the Stack VM) one can move to 5.0. However, I would recommend getting the VM changes into the 4.0 VM as this will make migrating to image-level closures much easier. I believe (John, can you confirm) that John's latest Mac 3.8 beta VMs have included the closure bytecodes.
Well I've not done that (yet) was waiting on Eliot for the latest VM changes before christmas. Then I've been distracted by an iPhone application.
I recall David T and I last discussed the issues around the source code changes and how it cheerfully upgrades your image, which then makes it un-run-able on the raft of VMs one has on one's machine, but I recall we thought we could tie the image version change on save to only happen if in fact the image *uses* the closure bytes code.
If one can think up a change set for that, point out the other required changes then I look into assembling a 4.0 macintosh and iPhone VM.
-- = = = ======================================================================== John M. McIntosh johnmci@smalltalkconsulting.com Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
On Sun, Feb 15, 2009 at 06:18:15PM -0800, John M McIntosh wrote:
On 15-Feb-09, at 6:06 PM, Eliot Miranda wrote:
Works for me. When and if the VM is no longer backwards-compatible (e.g. the Stack VM) one can move to 5.0. However, I would recommend getting the VM changes into the 4.0 VM as this will make migrating to image-level closures much easier. I believe (John, can you confirm) that John's latest Mac 3.8 beta VMs have included the closure bytecodes.
Well I've not done that (yet) was waiting on Eliot for the latest VM changes before christmas. Then I've been distracted by an iPhone application.
I recall David T and I last discussed the issues around the source code changes and how it cheerfully upgrades your image, which then makes it un-run-able on the raft of VMs one has on one's machine, but I recall we thought we could tie the image version change on save to only happen if in fact the image *uses* the closure bytes code.
Right, Eliot's bytecode changes are fully backward compatible, so they can be added to VMMaker without breaking anything. The image version numbering change needs to be left out for now, but that's a small issue that can be the subject of separate discussion.
Eliot, if you can confirm that the bytecode changes are ready for release, and that the license is <whatever>, then I'll volunteer to add your bytecode bootstrap changes to the Squeaksource VMMaker project and make whatever minor changes are needed to avoid the image numbering glitch.
Dave
On Sun, Feb 15, 2009 at 6:57 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Feb 15, 2009 at 06:18:15PM -0800, John M McIntosh wrote:
On 15-Feb-09, at 6:06 PM, Eliot Miranda wrote:
Works for me. When and if the VM is no longer backwards-compatible (e.g. the Stack VM) one can move to 5.0. However, I would recommend getting the VM changes into the 4.0 VM as this will make migrating to image-level closures much easier. I believe (John, can you confirm) that John's latest Mac 3.8 beta VMs have included the closure bytecodes.
Well I've not done that (yet) was waiting on Eliot for the latest VM changes before christmas. Then I've been distracted by an iPhone application.
I recall David T and I last discussed the issues around the source code changes and how it cheerfully upgrades your image, which then makes it un-run-able on the raft of VMs one has on one's machine, but I recall we thought we could tie the image version change on save to only happen if in fact the image *uses* the closure bytes code.
Right, Eliot's bytecode changes are fully backward compatible, so they can be added to VMMaker without breaking anything. The image version numbering change needs to be left out for now, but that's a small issue that can be the subject of separate discussion.
Eliot, if you can confirm that the bytecode changes are ready for release, and that the license is <whatever>, then I'll volunteer to add your bytecode bootstrap changes to the Squeaksource VMMaker project and make whatever minor changes are needed to avoid the image numbering glitch.
OK, I'll have this done by end of business Tuesday 17th.
Dave
On Sun, Feb 15, 2009 at 08:42:53PM -0800, Eliot Miranda wrote:
On Sun, Feb 15, 2009 at 6:57 PM, David T. Lewis lewis@mail.msen.com wrote:
Eliot, if you can confirm that the bytecode changes are ready for release, and that the license is <whatever>, then I'll volunteer to add your bytecode bootstrap changes to the Squeaksource VMMaker project and make whatever minor changes are needed to avoid the image numbering glitch.
OK, I'll have this done by end of business Tuesday 17th.
Thanks, I'll add it to the SqueakSource VMMaker project by this weekend, Sunday 22.
Dave
On Sun, Feb 15, 2009 at 6:57 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Feb 15, 2009 at 06:18:15PM -0800, John M McIntosh wrote:
On 15-Feb-09, at 6:06 PM, Eliot Miranda wrote:
Works for me. When and if the VM is no longer backwards-compatible (e.g. the Stack VM) one can move to 5.0. However, I would recommend getting the VM changes into the 4.0 VM as this will make migrating to image-level closures much easier. I believe (John, can you confirm) that John's latest Mac 3.8 beta VMs have included the closure bytecodes.
Well I've not done that (yet) was waiting on Eliot for the latest VM changes before christmas. Then I've been distracted by an iPhone application.
I recall David T and I last discussed the issues around the source code changes and how it cheerfully upgrades your image, which then makes it un-run-able on the raft of VMs one has on one's machine, but I recall we thought we could tie the image version change on save to only happen if in fact the image *uses* the closure bytes code.
Right, Eliot's bytecode changes are fully backward compatible, so they can be added to VMMaker without breaking anything. The image version numbering change needs to be left out for now, but that's a small issue that can be the subject of separate discussion.
I've fixed the image numbering version issue. The VM has a variable holding the version number which is initialized to teh standard version. If the create-closure bytecode is evaluated it changes to the new version. Hence the VM can safely be used for both old and new and will not change the image version unless it should be changed.
Eliot, if you can confirm that the bytecode changes are ready for
release, and that the license is <whatever>, then I'll volunteer to add your bytecode bootstrap changes to the Squeaksource VMMaker project and make whatever minor changes are needed to avoid the image numbering glitch.
They're ready for your and John's review. See Name: VMMaker-eem.114 Author: eem Time: 18 February 2009, 5:42:18 pm UUID: 169887e2-d54c-43a6-9042-eabfcaa08146 Ancestors: VMMaker-dtl.113 in http://squeaksource.com/VMMaker. There's a verbose version comment describing the changes. It omitted to mention that in the version of Monticello I'm using class variables appear in alphabetical order and hence there are some artificial changes in class definitions.
The license is the new Squeak license because I am the author of these changes and have informed Yoshiki that I assent to the new Squeak licencing scheme. Sorry for being so inarticulate; I'm not sure what the right form of words is for this :/
Best Eliot
P.S. John and David, thanks for your help today, and apologies for the delay.
Dave
Eliot,
Excellent, thanks for committing this directly to the SqueakSource project. I'm short of time now but look forward to building a VM with closure bytecodes this weekend.
(subject line changed, and CC to vm-dev list)
Dave
On Wed, Feb 18, 2009 at 05:50:33PM -0800, Eliot Miranda wrote:
On Sun, Feb 15, 2009 at 6:57 PM, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Feb 15, 2009 at 06:18:15PM -0800, John M McIntosh wrote:
On 15-Feb-09, at 6:06 PM, Eliot Miranda wrote:
Works for me. When and if the VM is no longer backwards-compatible (e.g. the Stack VM) one can move to 5.0. However, I would recommend getting the VM changes into the 4.0 VM as this will make migrating to image-level closures much easier. I believe (John, can you confirm) that John's latest Mac 3.8 beta VMs have included the closure bytecodes.
Well I've not done that (yet) was waiting on Eliot for the latest VM changes before christmas. Then I've been distracted by an iPhone application.
I recall David T and I last discussed the issues around the source code changes and how it cheerfully upgrades your image, which then makes it un-run-able on the raft of VMs one has on one's machine, but I recall we thought we could tie the image version change on save to only happen if in fact the image *uses* the closure bytes code.
Right, Eliot's bytecode changes are fully backward compatible, so they can be added to VMMaker without breaking anything. The image version numbering change needs to be left out for now, but that's a small issue that can be the subject of separate discussion.
I've fixed the image numbering version issue. The VM has a variable holding the version number which is initialized to teh standard version. If the create-closure bytecode is evaluated it changes to the new version. Hence the VM can safely be used for both old and new and will not change the image version unless it should be changed.
Eliot, if you can confirm that the bytecode changes are ready for
release, and that the license is <whatever>, then I'll volunteer to add your bytecode bootstrap changes to the Squeaksource VMMaker project and make whatever minor changes are needed to avoid the image numbering glitch.
They're ready for your and John's review. See Name: VMMaker-eem.114 Author: eem Time: 18 February 2009, 5:42:18 pm UUID: 169887e2-d54c-43a6-9042-eabfcaa08146 Ancestors: VMMaker-dtl.113 in http://squeaksource.com/VMMaker. There's a verbose version comment describing the changes. It omitted to mention that in the version of Monticello I'm using class variables appear in alphabetical order and hence there are some artificial changes in class definitions.
The license is the new Squeak license because I am the author of these changes and have informed Yoshiki that I assent to the new Squeak licencing scheme. Sorry for being so inarticulate; I'm not sure what the right form of words is for this :/
Best Eliot
P.S. John and David, thanks for your help today, and apologies for the delay.
Dave
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
David T. Lewis -
Eliot Miranda -
John M McIntosh -
Keith Hodges -
Ken Causey -
Matthew Fulmer -
merlyn＠stonehenge.com