I now have completed a first version of a reimplementation of WeakKeyDictionary, with the objective of improving performance (both computation and memory consumption). The entire change with a discussion can be seen at
http://bugs.squeak.org/view.php?id=6348
In essence, this introduces two changes: - when values are finalized or keys removed from the dictionary, it is not always rehashed anymore. Instead, the dictionary just releases the value, and marks the association as expired. Expired associations can then be reused if a new value is to be inserted under the same has. Rehashing is only done when so many entries have expired. Expired entries don't count towards the size of the dictionary, and aren't reported when iterating over the dictionary. - WeakKeyAssociation was rewritten to be a weak class, with a fixed slot for the value, and a weak slot for the key (currently, it has two fixed slots, with the key slot referring to a WeakArray of length 1).
In some measurements involving large (10000 keys) or many (10000) small weak key dictionaries, this new implementation improves performance by a factor of 4..5, when measuring finalization time. The second change saves 8 bytes per association (on a 32-bit machine).
Regards, Martin
2007/3/18, "Martin v. Löwis" martin@v.loewis.de:
I now have completed a first version of a reimplementation of WeakKeyDictionary, with the objective of improving performance (both computation and memory consumption). The entire change with a discussion can be seen at
http://bugs.squeak.org/view.php?id=6348
In essence, this introduces two changes:
- when values are finalized or keys removed from the dictionary, it is not always rehashed anymore. Instead, the dictionary just releases the value, and marks the association as expired. Expired associations can then be reused if a new value is to be inserted under the same has. Rehashing is only done when so many entries have expired. Expired entries don't count towards the size of the dictionary, and aren't reported when iterating over the dictionary.
- WeakKeyAssociation was rewritten to be a weak class, with a fixed slot for the value, and a weak slot for the key (currently, it has two fixed slots, with the key slot referring to a WeakArray of length 1).
In some measurements involving large (10000 keys) or many (10000) small weak key dictionaries, this new implementation improves performance by a factor of 4..5, when measuring finalization time. The second change saves 8 bytes per association (on a 32-bit machine).
Could you attach the code for these stress tests to the bug?
Cheers Philippe
Regards, Martin
On Sun, Mar 18, 2007 at 03:51:34PM +0100, "Martin v. L?wis" wrote:
I now have completed a first version of a reimplementation of WeakKeyDictionary, with the objective of improving performance (both computation and memory consumption). The entire change with a discussion can be seen at
Martin,
This would be a welcome improvement!
Note also http://bugs.squeak.org/view.php?id=2910 which is also related to this problem. (How do you add a "relationship" in Mantis?)
Dave
David T. Lewis schrieb:
This would be a welcome improvement!
Note also http://bugs.squeak.org/view.php?id=2910 which is also related to this problem. (How do you add a "relationship" in Mantis?)
I had indeed seen this before. On a first quick review, I agreed with your analysis that the patch is right; on a closer look, I agree with Andreas: it seems that the patch drops associations with nil keys on the floor, which it shouldn't do.
In any case, my patch would also address this problem: on removal, no rehashing is done at all. Instead, it just clears the association of the to-be-removed key, and then stops; the association will get only discarded when the entire dictionary gets reorganized.
Regards, Martin
Martin v. Löwis wrote:
In essence, this introduces two changes:
- when values are finalized or keys removed from the dictionary, it is not always rehashed anymore. Instead, the dictionary just releases the value, and marks the association as expired. Expired associations can then be reused if a new value is to be inserted under the same has. Rehashing is only done when so many entries have expired. Expired entries don't count towards the size of the dictionary, and aren't reported when iterating over the dictionary.
That's an interesting approach. I would expect this to impact the time it takes to insert/find elements in the dict, no? Like: wd := WeakKeyDictionary new. 1 to: 100 do:[:i| wd at: i put: i]. 1 to: 99 do:[:i| wd removeKey: i]. After this point I'd expect the operations to be slower since we have about a hundred expired elements in the dict. Nothing that a good #rehash can't fix of course, but I'm wondering if at some point the WKD shouldn't recognize the ratio of expired/free/used slots and act accordingly. In any case, it's definitely an improvement.
- WeakKeyAssociation was rewritten to be a weak class, with a fixed slot for the value, and a weak slot for the key (currently, it has two fixed slots, with the key slot referring to a WeakArray of length 1).
Hah! Finally ;-) When I wrote the weak dicts I was concerned about the usage of associations for literal bindings in code and whether any such weak associations might be used for this purpose (the problem is that the VM accesses those directly and not having the right values in the right slots will give you "interesting" results). However, that concern never even remotely materialized so it's basically a waste of perfectly good resources. Thanks for cleaning that part up.
Cheers, - Andreas
That's an interesting approach. I would expect this to impact the time it takes to insert/find elements in the dict, no? Like: wd := WeakKeyDictionary new. 1 to: 100 do:[:i| wd at: i put: i]. 1 to: 99 do:[:i| wd removeKey: i]. After this point I'd expect the operations to be slower since we have about a hundred expired elements in the dict.
It strongly depends on the operations now. The lookup for the only remaining key (100) will not be slower, since that key is not colliding.
The next invocation of fullCheck will see that there are way too many expired entries in the dictionary, and rehash it. So the very next insertion may be slightly slower, but all subsequent insertions and other operations will have the same performance - in this specific use case, the new code just saved a hundred rehash operations.
Nothing that a good #rehash can't fix of course, but I'm wondering if at some point the WKD shouldn't recognize the ratio of expired/free/used slots and act accordingly.
Ah, it does: if 4*expired > array size, it rehashes (in fullCheck). The precise percentage may be debatable, and it may be an option to also consider the relationship of expired and tally, but it will definitely rehash from time to time (and growing will drop expired entries, too).
It might also be useful to add a fullCheck into removeKey:, so that in above example it won't end up with with 99 expired associations, but only one. With rehashing as implemented in the patch, this would cause the dictionary to shrink (as it uses essentially the implementation of Dictionary>>rehash); in turn, the loop would do 7 rehashes, at 41, 21, 14, 9, 6, 4, 3 expired elements.
With rehashing similar to the original one (i.e. one that keeps the size), a fullCheck on remove, in above example, would rehash every 40 removals (given that the dictionary will have 160 slots), so you would end up with 20 expired elements after the loop.
Regards, Martin
Martin v. Löwis wrote:
The next invocation of fullCheck will see that there are way too many expired entries in the dictionary, and rehash it.
Oh, it does! I didn't notice that. In this case, my point is of course moot.
Nothing that a good #rehash can't fix of course, but I'm wondering if at some point the WKD shouldn't recognize the ratio of expired/free/used slots and act accordingly.
Ah, it does: if 4*expired > array size, it rehashes (in fullCheck). The precise percentage may be debatable, and it may be an option to also consider the relationship of expired and tally, but it will definitely rehash from time to time (and growing will drop expired entries, too).
Right. Wasn't careful enough reading the code. Nevermind ;-)
Brief Q: You didn't explicitly specify what license those changes are under. Would you be amendable to using MIT-style license for it? (it would allow me to use the code trivially in Croquet)
Cheers, - Andreas
On Mar 19, 2007, at 7:50 , Andreas Raab wrote:
Brief Q: You didn't explicitly specify what license those changes are under. Would you be amendable to using MIT-style license for it? (it would allow me to use the code trivially in Croquet)
In case this hasn't been clear to everybody yet - we require MIT licensing for anything that people might want to go into official Squeak nowadays.
- Bert -
Bert Freudenberg schrieb:
On Mar 19, 2007, at 7:50 , Andreas Raab wrote:
Brief Q: You didn't explicitly specify what license those changes are under. Would you be amendable to using MIT-style license for it? (it would allow me to use the code trivially in Croquet)
In case this hasn't been clear to everybody yet - we require MIT licensing for anything that people might want to go into official Squeak nowadays.
So how do you deal with the requirement that the license is put in all copies?
Regards, Martin
On Mar 19, 2007, at 10:58 , Martin v. Löwis wrote:
Bert Freudenberg schrieb:
On Mar 19, 2007, at 7:50 , Andreas Raab wrote:
Brief Q: You didn't explicitly specify what license those changes are under. Would you be amendable to using MIT-style license for it? (it would allow me to use the code trivially in Croquet)
In case this hasn't been clear to everybody yet - we require MIT licensing for anything that people might want to go into official Squeak nowadays.
So how do you deal with the requirement that the license is put in all copies?
We require a written note that allows us to use the contributions under MIT. Since this is rather new we need to figure out the exact details still, but there is a form you need to print out and sign and send in. I think Craig might know best.
MIT was chosen because it is compatible to basically everything. Squeak 1.1 was relicensed by Apple under the Apache License 2.0 just last year. With this Apache base and all the MIT contributions we have a completely free system. And if there was a replacement for the Squeak kernel down the road (Spoon, Pepsi, whatever) the MIT parts can be moved over with ease. Also, the major new systems built on Squeak (like Croquet, Tweak, Seaside, etc.) are MIT licensed.
- Bert -
Bert Freudenberg schrieb:
MIT was chosen because it is compatible to basically everything. Squeak 1.1 was relicensed by Apple under the Apache License 2.0 just last year. With this Apache base and all the MIT contributions we have a completely free system. And if there was a replacement for the Squeak kernel down the road (Spoon, Pepsi, whatever) the MIT parts can be moved over with ease. Also, the major new systems built on Squeak (like Croquet, Tweak, Seaside, etc.) are MIT licensed.
As a contributor, I don't mind that choice. Still, the MIT license requires that "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.", so I'm curious how this requirement will be executed.
Will the licenses all be collected in a class comment of some class?
Regards, Martin
Martin v. Löwis skrev:
Bert Freudenberg schrieb:
MIT was chosen because it is compatible to basically everything. Squeak 1.1 was relicensed by Apple under the Apache License 2.0 just last year. With this Apache base and all the MIT contributions we have a completely free system. And if there was a replacement for the Squeak kernel down the road (Spoon, Pepsi, whatever) the MIT parts can be moved over with ease. Also, the major new systems built on Squeak (like Croquet, Tweak, Seaside, etc.) are MIT licensed.
As a contributor, I don't mind that choice. Still, the MIT license requires that "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.", so I'm curious how this requirement will be executed.
Will the licenses all be collected in a class comment of some class?
Regards, Martin
Should we not have a class License and method licenseMIT ? I think we have been sloppy with distributing the license with Squeak in the past. I can't recall any download wich include the Squeak License or any other for that sake.
Karl
karl skrev:
Martin v. Löwis skrev:
Bert Freudenberg schrieb:
MIT was chosen because it is compatible to basically everything. Squeak 1.1 was relicensed by Apple under the Apache License 2.0 just last year. With this Apache base and all the MIT contributions we have a completely free system. And if there was a replacement for the Squeak kernel down the road (Spoon, Pepsi, whatever) the MIT parts can be moved over with ease. Also, the major new systems built on Squeak (like Croquet, Tweak, Seaside, etc.) are MIT licensed.
As a contributor, I don't mind that choice. Still, the MIT license requires that "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.", so I'm curious how this requirement will be executed.
Will the licenses all be collected in a class comment of some class?
Regards, Martin
Should we not have a class License and method licenseMIT ? I think we have been sloppy with distributing the license with Squeak in the past. I can't recall any download wich include the Squeak License or any other for that sake.
We could even add a comment tag for the compiler so it will only compile the methods which refer to the MIT license. I'm not sure how to do that....
Karl
Should we not have a class License and method licenseMIT ? I think we have been sloppy with distributing the license with Squeak in the past. I can't recall any download wich include the Squeak License or any other for that sake.
Reviewing the Squeak license, it appears that it includes no requirement to actually include the license in the software, so not including it wasn't a license violation (although "sloppy" may still apply). This is different with the MIT license: it explicitly requires inclusion with the software. Given that the MIT license is a template, so each contributor will provide her own version of it, this gives a long list of licenses to include.
Regards, Martin
Martin v. Löwis skrev:
Should we not have a class License and method licenseMIT ? I think we have been sloppy with distributing the license with Squeak in the past. I can't recall any download wich include the Squeak License or any other for that sake.
Reviewing the Squeak license, it appears that it includes no requirement to actually include the license in the software, so not including it wasn't a license violation (although "sloppy" may still apply). This is different with the MIT license: it explicitly requires inclusion with the software. Given that the MIT license is a template, so each contributor will provide her own version of it, this gives a long list of licenses to include.
Well it says: 'The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.'
So it should be enough to have one license in the image ? Maybe all packages/modules should be dependent on a License module ? Patches and bugfixes, I don't know, depends on how substantial they are ?
Licenses are a source of endless discussions :-)
Karl
On 19-Mar-07, at 10:52 AM, karl wrote:
So it should be enough to have one license in the image ?
I'd say a reference to the license in the image, a copy of it in the sources file (hell it can be a class comment, that would put it in both places), and a page on squeak.org as well.
Contributions must be offered within the scope of the license and I imagine we'd have to ask any new contributors to sign & mail the same agreement most of us already have sent in.
What about VM & plugin code? Does that have to be the same licence? I think it ought to be but maybe there is something more appropriate.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A computer scientist is someone who fixes things that aren't broken.
All,
I thought this was already figured out. Viewpoints is collecting a distribution agreement from all authors of squeak code. Once that is done Squeak will be re-licensed under MIT.
Do these distribution agreements allow VPRI to distribute Squeak without a copy of the license that includes the names of all authors, or does MIT require that all authors be listed?
If this has not been figured out then we really need to settle this issue now before Viewpoints finishes. Does the agreement we signed for VPRI allow the transfer of distribution rights to SqF? Or does SqF need to take the MIT version and then get new distributions agreements for all new contributions in order to be able to distribute the next version of Squeak under MIT? Is VPRI planning to continue supporting our record keeping needs with regards to licensing in which case the official distribution of Squeak will come from them instead of SqF?
Can we make this the number one priority of the new SqueakFoundation board? We should be getting and following real legal advice not guessing and if something needs to be put in place to accept new contributions then that should be done now. This is defiantly one of those places where a simple defined policy can save a huge amount of work later.
Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists
From: tim Rowledge
On 19-Mar-07, at 10:52 AM, karl wrote:
So it should be enough to have one license in the image ?
I'd say a reference to the license in the image, a copy of it in the sources file (hell it can be a class comment, that would put it in both places), and a page on squeak.org as well.
Contributions must be offered within the scope of the license and I imagine we'd have to ask any new contributors to sign & mail the same agreement most of us already have sent in.
What about VM & plugin code? Does that have to be the same licence? I think it ought to be but maybe there is something more appropriate.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim A computer scientist is someone who fixes things that aren't broken.
Hi Ron--
I thought this was already figured out.
Yes, that's right.
Viewpoints is collecting a distribution agreement from all authors of squeak code. Once that is done Squeak will be re-licensed under MIT.
That's correct.
Do these distribution agreements allow VPRI to distribute Squeak without a copy of the license that includes the names of all authors, or does MIT require that all authors be listed?
Under the agreement[1], the contributor grants Viewpoints a license to distribute contributor's software, subject to the MIT license (which is cited specifically by its location at the Open Source Initiative website[2]). The text of the MIT license on that site is as follows:
***
Copyright (c) <year> <copyright holders>
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
***
Note that "Software" is defined as "software and associated documentation files". It will suffice to have a licensing file, along with the snapshot and virtual machine files, that has those notices in it.
Does the agreement we signed for VPRI allow the transfer of distribution rights to SqF?
The MIT license clearly grants that permission to anyone who obtains the Software ("the right to use, copy, modify, merge, publish, distribute, sublicense, and/or sell").
Is VPRI planning to continue supporting our record keeping needs with regards to licensing...
From my correspondence with Viewpoints' representative in this matter, Kim Rose, it's my understanding that they do.
...in which case the official distribution of Squeak will come from them instead of SqF?
Given the extremely fluid transitive granting of permission afforded by the MIT license, this need not be the case. If you'd like a declaration from Viewpoints that what the Squeak Foundation releases is "official", I'd be happy to ask for one.
Can we make this the number one priority of the new SqueakFoundation board?
As far as I'm concerned, this has been the first priority of the Squeak Foundation board since I joined it. Of course, progress on this issue requires the cooperation of people outside the board, so it can seem excruciatingly slow at times. Please bear with us.
We should be getting and following real legal advice not guessing...
That's what we're doing. I'm in contact with Viewpoints' legal counsel, via Kim Rose, and with counsel at the Software Freedom Law Center.
...and if something needs to be put in place to accept new contributions then that should be done now.
Yes, that's what we're doing.
This is definitely one of those places where a simple defined policy can save a huge amount of work later.
Yes indeed.
I hope this was clear.
thanks,
-C
[1] http://netjam.org/squeak/SqueakDistributionAgreement.pdf [2] http://www.opensource.org/licenses/mit-license.php
Copyright (c) <year> <copyright holders>
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
So in this license agreement, what <year> and <copyright holders> will be listed?
Regards, Martin
Hi Martin--
...what <year> and <copyright holders> will be listed?
The <year> field will be a list of every year in which accepted contributions were created. The <copyright holders> field will be a list of all the contributors who wrote an accepted contribution made available via [1].
thanks again,
-C
[1] http://netjam.org/squeak/SqueakDistributionAgreement.pdf
Craig Latta schrieb:
...what <year> and <copyright holders> will be listed?
The <year> field will be a list of every year in which acceptedcontributions were created. The <copyright holders> field will be a list of all the contributors who wrote an accepted contribution made available via [1].
Ok, so all contributors *will* be listed. Thanks for clarifying.
Martin
Hello, all -
Just to say I am traveling today/tomorrow. Will be back in office and will discuss with Yoshiki at that time to understand what action, if any, is necessary on VPRI's behalf.
It was my understanding, after we had completed the process of transfer to the MIT-license, VPRI would stop tracking code contributions to the Squeak code base.
More to come, if necessary upon my return. cheers, Kim
At 9:38 PM +0100 3/19/07, Martin v. Löwis wrote:
Copyright (c) <year> <copyright holders>
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
So in this license agreement, what <year> and <copyright holders> will be listed?
Regards, Martin
Kim Rose writes:
It was my understanding, after we had completed the process of transfer to the MIT-license, VPRI would stop tracking code contributions to the Squeak code base.
I understand; the Squeak Foundation will be happy to continue that task.
thanks all,
-C
Kim
what would be important is to get a list of the person who sign the agreement and this way the harvesting team can check and ask contributors to sign the agreement before harvesting their code.
Stef
On 20 mars 07, at 00:02, Kim Rose wrote:
Hello, all -
Just to say I am traveling today/tomorrow. Will be back in office and will discuss with Yoshiki at that time to understand what action, if any, is necessary on VPRI's behalf.
It was my understanding, after we had completed the process of transfer to the MIT-license, VPRI would stop tracking code contributions to the Squeak code base.
More to come, if necessary upon my return. cheers, Kim
At 9:38 PM +0100 3/19/07, Martin v. Löwis wrote:
Copyright (c) <year> <copyright holders>
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
So in this license agreement, what <year> and <copyright holders> will be listed?
Regards, Martin
Hi Stef--
Kim, what would be important is to get a list of the person who sign the agreement and this way the harvesting team can check and ask contributors to sign the agreement before harvesting their code.
We do have this information; I keep up-to-date with Viewpoints about it. Please check http://netjam.org/squeak/contributors for updates.
It seems like we could avoid some communication overhead for Kim and Viewpoints by being a bit more coordinated. :) Please just ask me if you've got a question about licensing stuff. I'm in communication with all parties, and I'm on top of it.
thanks again!
-C
Craig Latta replied to Ron:
We should be getting and following real legal advice not guessing...
That's what we're doing. I'm in contact with Viewpoints' legalcounsel, via Kim Rose, and with counsel at the Software Freedom Law Center.
Ok - so one of those two has seen the actual contribution form that was sent, and the rest of the detailed plan, and confirmed it has the legal effect we are after? I ask because as a layman I had the following uncertainties about it:
******** A couple of comments about the agreement in case you send out more in the future: 1. It is not very explicit about what contributions I agree to license under the MIT license. Those in a released squeak-dev image? those ever released in any kind of public image? those ever sent to the mailing list? 2. In the same vein, it does not specify which contributions in a temporal sense: only past contributions? all future contributions? the text suggests to me that past contributions are meant, but this is implicit. If so, the text should include either a particular date or allow me to enter one. ********
Have these been considered by the board and counsel? If they are moot, I would be grateful for an explanation.
Thanks, Daniel
A couple of comments about the agreement in case you send out more in the future:
- It is not very explicit about what contributions I agree to license
under the MIT license.
As a layman, my understanding is that you aren't licensing anything under the MIT license. Instead, under the agreement in
http://netjam.org/squeak/SqueakDistributionAgreement.pdf
you are giving a license to Distributor (VPRI) to relicense your contribution under (*) the MIT license. The MIT license grants rights explicitly to "any person"; the agreement grants rights only to Distributor.
Regards, Martin
Hi Martin, your comment is correct, but does not address my questions at all.
1. Does the agreement mean that everything I ever write in Squeak is redistributable by VPRI? or is it limited to the effective date? neither is what we want. Therefore: 2. Has a lawyer looked at this agreement, and agreed that, in conjunction with the other actions planned by the board, it has the legal effect we want?
Note that I signed the agreement, and am more worried that it grants too few rights to VPRI, rather than too many.
Daniel Vainsencher
Martin v. Löwis wrote:
A couple of comments about the agreement in case you send out more in the future:
- It is not very explicit about what contributions I agree to
license under the MIT license.
As a layman, my understanding is that you aren't licensing anything under the MIT license. Instead, under the agreement in
http://netjam.org/squeak/SqueakDistributionAgreement.pdf
you are giving a license to Distributor (VPRI) to relicense your contribution under (*) the MIT license. The MIT license grants rights explicitly to "any person"; the agreement grants rights only to Distributor.
Regards, Martin
Hi Daniel--
Ron wrote:
We should be getting and following real legal advice not guessing...
I responded:
That's what we're doing. I'm in contact with Viewpoints' legal counsel, via Kim Rose, and with counsel at the Software Freedom Law Center.
You responded:
Ok - so one of those two has seen the actual contribution form that was sent, and the rest of the detailed plan, and confirmed it has the legal effect we are after?
Yes, they both have.
You continue:
A couple of comments about the agreement in case you send out more in the future...
We certainly intend to send out more agreements, since there are still contributors we haven't been able to contact yet. However, I think it's extremely unlikely that the agreement will change; we want everyone to sign the same agreement and getting everyone to sign anything is very difficult, simply due to logistics.
It is not very explicit about what contributions I agree to license under the MIT license.
The agreement specifies code contributed to Squeak in the past by the contributor. According to Viewpoints legal counsel, who wrote the agreement, this is sufficiently explicit. So...
Those in a released squeak-dev image?
Yes.
Those ever released in any kind of public image?
Yes.
Those ever sent to the mailing list?
Yes.
In the same vein, it does not specify which contributions in a temporal sense...
Yes it does. It specifies code contributed to Squeak in the past by the contributor. So...
Only past contributions?
Yes.
All future contributions?
No, and I think this is as it should be. What we're trying to do here is establish appropriately permissive license terms for what we had up to this point. After that, under those permissive terms, any entity (such as the Squeak Foundation) is at liberty to take that body of code and make releases under the terms they prefer (subject to the modest requirements of the MIT license cited in the agreement).
Going forward, I advocate requiring an explicit licensing statement from each contributor for each future contribution, and that the terms be those of the MIT license. It won't be hard, and, let's face it, if we did otherwise we would continue to chew up large amounts of time discussing licensing.
The text suggests to me that past contributions are meant, but this is implicit.
I think it's quite explicit, by the simple use of the past tense ("Supplier has contributed source code").
If so, the text should include either a particular date or allow me to enter one.
It did, in the first sentence ("Effective Date"). And it's not merely allowing you to enter the date, it's a requirement, along with your name and address.
Have these been considered by the board and counsel?
Yes.
If they are moot, I would be grateful for an explanation.
They're not moot, and I hope I've given a thorough and clear explanation all the same. (Please accept my apologies if it was *too* thorough :).
thanks again,
-C
Craig Latta wrote: [snip]
What we're trying to do here is establish appropriately permissive license terms for what we had up to this point. After that, under those permissive terms, any entity (such as the Squeak Foundation) is at liberty to take that body of code and make releases under the terms they prefer (subject to the modest requirements of the MIT license cited in the agreement).
Is there any code that has been included in the current Squeak releases (or otherwise contributed) after the effective dates of their contributors?
Going forward, I advocate requiring an explicit licensing statementfrom each contributor for each future contribution, and that the terms be those of the MIT license. It won't be hard, and, let's face it, if we did otherwise we would continue to chew up large amounts of time discussing licensing.
Sounds good to me. Is this the opening shot of a(nother) squeak-dev "what will we do with future licenses" debate on the topic, or will the board decide this issue? Actually, I think the position you advocate has been consensus for quite a while, but maybe I'm wrong.
If they are moot, I would be grateful for an explanation.
They're not moot, and I hope I've given a thorough and clearexplanation all the same. (Please accept my apologies if it was *too* thorough :).
Your answer was clear, and quite informative. Would you Curious that you should choose a style of communication which induces you to apologize in advance :)
Daniel
Hi,
Is there a compiled VM that works under WinCE.Net (4.2 or 5, Intel PXA255) with serial port and network support?
Thanks
Tansel
Hi Daniel--
Is there any code that has been included in the current Squeak releases (or otherwise contributed) after the effective dates of their contributors?
Almost certainly, since we have yet to receive agreements from all contributors. However, that's irrelevant: we're creating the basis upon which code is eligible for releases 3.10-final and later.
Is this the opening shot of a(nother) squeak-dev "what will we do with future licenses" debate on the topic, or will the board decide this issue?
The board will decide this issue; currently I believe we are in unanimous agreement that it should operate as I described.
Actually, I think the position you advocate has been consensus for quite a while, but maybe I'm wrong.
I think that's right.
...I hope I've given a thorough and clear explanation all the same. (Please accept my apologies if it was *too* thorough :).
Your answer was clear, and quite informative. Curious that you should choose a style of communication which induces you to apologize in advance :)
(:
Well, I think it's more an aspect of the topic, from past experience. Some people just get tired of it, or don't like more than a certain level of detail. Since I'm trying to go into exhaustive detail, it seems like the probability of annoying those people is high. :)
thanks again,
-C
karl schrieb:
Well it says: 'The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.'
So it should be enough to have one license in the image ?
Not sure. You certainly need to include the individual copyright notices (*), just including one copy of the permission should be enough.
Maybe all packages/modules should be dependent on a License module ? Patches and bugfixes, I don't know, depends on how substantial they are ?
Licenses are a source of endless discussions :-)
I read the book of Larry Rosen, and his opinion is that software engineers should stick to software. Licenses is the field of lawyers. So if in doubt, ask the foundation's lawyer, and he will tell you what to do (although you may need to learn how to ask a lawyer first :-)
Regards, Martin
(*) E.g. Copyright (c) 2007 Martin v. Löwis in the patch that triggered this discussion.
On Sun, 18 Mar 2007 23:53:21 -0800, Bert Freudenberg bert@freudenbergs.de wrote:
On Mar 19, 2007, at 7:50 , Andreas Raab wrote:
Brief Q: You didn't explicitly specify what license those changes are under. Would you be amendable to using MIT-style license for it? (it would allow me to use the code trivially in Croquet)
In case this hasn't been clear to everybody yet - we require MIT licensing for anything that people might want to go into official Squeak nowadays.
A cursory Google suggests that "MIT licensing" might mean a number of things. If it's this:
http://www.opensource.org/licenses/mit-license.php
Then it would seem that MIT licensing means you can do (or not do) just about anything with the code, as long as the MIT license accompanies whatever you do?
===Blake===
On Mar 19, 2007, at 11:22 , Blake wrote:
On Sun, 18 Mar 2007 23:53:21 -0800, Bert Freudenberg bert@freudenbergs.de wrote:
On Mar 19, 2007, at 7:50 , Andreas Raab wrote:
Brief Q: You didn't explicitly specify what license those changes are under. Would you be amendable to using MIT-style license for it? (it would allow me to use the code trivially in Croquet)
In case this hasn't been clear to everybody yet - we require MIT licensing for anything that people might want to go into official Squeak nowadays.
A cursory Google suggests that "MIT licensing" might mean a number of things. If it's this:
http://www.opensource.org/licenses/mit-license.php
Then it would seem that MIT licensing means you can do (or not do) just about anything with the code, as long as the MIT license accompanies whatever you do?
As I understand it, yes.
- Bert -
Andreas Raab schrieb:
Brief Q: You didn't explicitly specify what license those changes are under. Would you be amendable to using MIT-style license for it? (it would allow me to use the code trivially in Croquet)
Sure - I just added a license file. See also my other response; I wonder where all the license files are kept in Squeak.
I would be willing to give the Squeak Foundation (as well as Apple Computer, Inc., if necessary) the irrevocable and perpetual right to make and distribute copies of the Software, as well as to create and distribute collective works and derivative works of the Software, under any other OSI-approved open source license (thus eliminating my own MIT-style license from the license stack).
Regards, Martin
squeak-dev@lists.squeakfoundation.org
-
"Martin v. Löwis" -
Andreas Raab -
Bert Freudenberg -
Blake -
Craig Latta -
Daniel Vainsencher -
David T. Lewis -
karl -
Kim Rose -
Philippe Marschall -
Ron Teitelbaum -
stephane ducasse -
Tansel -
tim Rowledge