Squeakfoundation March 2003

squeakfoundation@lists.squeakfoundation.org

27 participants
66 discussions

Re: Sublicensing seems possible
by goran.hultgren＠bluefish.se 04 Apr '03

04 Apr '03

Hi guys! (This response is crossposted to the SqF-list in order to move this thread over there, so in responses - ****skip squeak-dev****, ok?) First of all - I agree wholeheartedly with what Daniel's postings. Daniel wrote (short snippet): > It seems to me sublicensing with: > - current indemnification -> such a clause, > - export -> complying with law, and > - no mention nor inclusion of non-free fonts > > *could* present something that DFSG, OSI, and certainly I would be happy > with. Just as happy as with BSD. If we agree that's a desired result, > and legally workable, we should then present it to Debian (and maybe > Apple). Yes, sounds perfect to me. Andrew was hesitant about sublicensing though - I would like to hear more on that. And I would still like to hear an explanation on sublicensing as a concept. Having said that, I am still waiting for responses (both from Andrew and you others of course) to my other questions, but I will just have to wait a bit longer I assume. :-) Cees de Groot <cg(a)cdegroot.com> wrote: > [We should be moving this thread to SqF, as this whole issue is killing > the squeak-dev list...]. True. Done. > The Apple guy responded positively to the idea of sublicensing. I've Ok, now again - what IS sublicensing? Consider me a complete idiot here. > asked him for permission to share our email exchange with others, which > I assume I'll get later today. He indicated that for Apple to look > positively at the sublicensing thing we'd need to come up with something > that only deviates minimally from SqueakL, just enough to fix it up for > DFSG/OSI/... wherever we want to head.=20 > > So, can we decide as a community that this is OK, a cleaned-up SqueakL? > If yes, it is probably time for some legal guys to take over :-) Sure, I would really like to see Andrew picking up this ball if he is ok with it. Andrew? We would still of course need to build a complete concensus about the proposed actions - but I think we are getting there - these threads have moved us quite a bit forward I think. This should probably be done on the SqF-list and then, when we have agreed on something we can present it on squeak-dev and see the reactions. regards, Göran

8 20

Debian-legal on squeak
by Daniel Vainsencher 28 Mar '03

28 Mar '03

Hey, THAT's a good idea. This is now a squeakf thread. If you really think this is too much fun to miss, you know where we are. There, now people can enjoy Jecel et al without this mess. People, please answer the legal parts of the "Closure compiler"-derived threads on squeakfoundation, not on squeak-dev. About sublicensing - have you read the CPL version of indemnification I mentioned? sounds reasonable enough to me that maybe the DFSG guys will accept it, and it seems to provide pretty good protection to Apple (and the rest of us). I marked out the relevant parts at - http://tai42.xs4all.nl:8099/http://www.opensource.org/licenses/cpl.php If this was the main issue Debian Legal was bugged about, this could help. Andrew? Daniel All the issues raised by debian-legal - Issues in http://lists.debian.org/debian-legal/2000/debian-legal-200008/msg00117.h tml) ******************** I`m not sure we can honor the preamble: PLEASE READ THIS SOFTWARE LICENSE AGREEMENT "LICENSE" CAREFULLY BEFORE DOWNLOADING THIS SOFTWARE. BY DOWNLOADING THIS SOFTWARE YOU ARE AGREEING TO BE BOUND BY THE TERMS OF THIS LICENSE. IF YOU DO NOT AGREE TO THE TERMS OF THIS LICENSE, DO NOT DOWNLOAD. The questions is wether this kind of licenses is binding or just void. ******************** Which we could change to "if you do not agree, do not use". Would this solve the problem? ******************** 2. Permitted Uses and Restrictions. This License allows you to copy, install and use the Apple Software on an unlimited number of computers under your direct control. You may modify and create derivative works of the Apple Software ("Modified Software"), however, you may not modify or create derivative works of the fonts provided by Apple ("Fonts"). You may distribute and sublicense such Modified Software The "Fonts" is clearly non-free. Can the package use fonts not provided by Apple? ******************** Remove the fonts before we sublicense, remove that part. ******************** 6. Export Law Assurances. You may not use or otherwise export or reexport the Apple Software except as authorized by United States law and the laws of the jurisdiction in which the Apple Software was obtained. Doesn`t this alone makes it non-free? I think we have discussed it several times what it means when licenses explicite referes to some laws which "isn`t DFSG-free". I think that it makes the license non-free, but I don`t remember what we have agreed on. ******************** Issues raised at the FSF list, not Debian, just for reference, and it case it might have merit http://mail.gnu.org/archive/html/savannah-hackers/2002-11/msg00115.html ******************** The fonts are definately not Free Software. The choice of law clause is also incompatible. -- -Dave Turner Free Software Licensing Guru This is not legal advice. If you need legal advice, see a lawyer. (I guess he's talking about the following -) Controlling Law and Severability. If there is a local subsidiary of Apple in the country in which the Apple Software License was obtained, then the local law in which the subsidiary sits shall govern this License. Otherwise, this License shall be governed by the laws of the United States and the State of California. If for any reason a court of competent jurisdiction finds any provision, or portion thereof, to be unenforceable, the remainder of this License shall continue in full force and effect. ******************** The real hell raiser (because it's so funny) http://lists.debian.org/debian-devel/2001/debian-devel-200106/msg00003.h tml ******************** Choice of language (the clause saying that if you live in quebec, the agreement is still in english) ******************** At http://lists.debian.org/debian-legal/2001/debian-legal-200105/msg00170.h tml ******************** If the Modified Software contains modifications, overwrites, replacements, deletions, additions, or ports to new platforms of: (1) the methods of existing class objects or their existing relationships, or (2) any part of the virtual machine, then for so long as the Modified Software is distributed or sublicensed to others, such modified, overwritten, replaced, deleted, added and ported portions of the Modified Software must be made publicly available, preferably by means of download from a website, at no charge under the terms set forth in Exhibit A below. I think this puts the whole package in non-free. This precludes CD manufacturers from selling binary CD's and then providing the source on a separate CD that you have to pay a reasonable duplication fee for. ******************** I don't understand how this makes it *un*free. It does mean any user can change, because This may be irrelevant because Squeak always includes source, Cees de Groot <cg(a)cdegroot.com> wrote: > > --Boundary_(ID_KlDN0GcL6O4UOGY1GCzXyQ) > Content-type: multipart/signed; boundary="=-e1meIsI0QoRt4nNTfh4D"; > protocol="application/pgp-signature"; micalg=pgp-sha1 > > > --=-e1meIsI0QoRt4nNTfh4D > Content-Type: text/plain > Content-Transfer-Encoding: quoted-printable > > [We should be moving this thread to SqF, as this whole issue is killing > the squeak-dev list...]. > > The Apple guy responded positively to the idea of sublicensing. I've > asked him for permission to share our email exchange with others, which > I assume I'll get later today. He indicated that for Apple to look > positively at the sublicensing thing we'd need to come up with something > that only deviates minimally from SqueakL, just enough to fix it up for > DFSG/OSI/... wherever we want to head.=20 > > So, can we decide as a community that this is OK, a cleaned-up SqueakL? > If yes, it is probably time for some legal guys to take over :-) > > Regards, > > Cees > > --=-e1meIsI0QoRt4nNTfh4D > Content-Type: application/pgp-signature; name=signature.asc > Content-Description: This is a digitally signed message part > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.1 (GNU/Linux) > > iD8DBQA+g1EP8wOTf+CYnosRAni4AJ9XEKGAYXYIi5KSRMbQQ3xRKDqGaACbBtDa > rIVGkI8YkePo3BhfqO1qkpE= > =EssR > -----END PGP SIGNATURE----- > > --=-e1meIsI0QoRt4nNTfh4D-- > > > --Boundary_(ID_KlDN0GcL6O4UOGY1GCzXyQ) > MIME-version: 1.0 > Content-type: text/plain; charset=us-ascii > Content-transfer-encoding: 7BIT > > > > --Boundary_(ID_KlDN0GcL6O4UOGY1GCzXyQ)--

4 4

Re: [Squeakfoundation]Debian-legal on squeak
by Daniel Vainsencher 28 Mar '03

28 Mar '03

I didn't intend to request re-discussion of every single problem again - I think some have clear solutions. For example, the export clause, which is non-free, IIUC, by applying to non-US people a law that generally doesn't apply to them, can be converted into something like "comply with the law", which is probably silly, but also not prejudicial. Actually, I missed the objection to the indemnfication clause there, because I couldn't find the precise mail in which the objection was raised (though I've seen it sometime today). Anyway, that's a shopping list we need to find solutions to/be certain enough they aren't serious (for example, the language complaint is not serious). Daniel Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > > > ******************** > > 6. Export Law Assurances. You may not use or otherwise export or > > reexport the Apple Software except as authorized by United States law > > and the laws of the jurisdiction in which the Apple Software was > > obtained. > > > > Doesn`t this alone makes it non-free? I think we have discussed it > > several times what it means when licenses explicite referes to some > > laws which "isn`t DFSG-free". I think that it makes the license > > non-free, but I don`t remember what we have agreed on. > > ******************** > > > To the best of my understanding this is implicit no matter what you put > in your license. Federal law stands whether you mention it or not. If > the existence of this condition makes something non-free then there's a > lot of software that is non-free; for example rather a lot of Gnu code > that was written in the US. > http://www.eff.org/CAF/law/software-export-law has lots of stuff that > seems related including specific mention of software with encryption > capabilities; Squeak may well count (DESPlugin, MD5Plugin etc). > > -- > Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim > Strange OpCodes: BW: Branch on Whim > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

Final steps for harvesting
by Doug Way 27 Mar '03

27 Mar '03

As discussed earlier, I think we are ready to start incorporating fixes & small enhancements from the SQFIXES page ( http://swiki.gsug.org:8080/SQFIXES/ ) into 3.6alpha, even though we still need to discuss the larger items which will make up 3.6. The process for entering and tagging submissions looks pretty good. I want to nail down the final steps of the process, so that we can start moving stuff into the update stream. For incorporating [FIX]es, we agreed that the fix needs to be approved by one Harvester. (Harvester meaning a Guide, a member of SqC, or a harvesting volunteer from the original list of harvesters. Hmm, I need to contact the people on that list to see who is still interested.) To make things clear, the harvester should use a special keyword (which we should agree on now) such as "[approved]" in the parentheses of the SQFIXES entry. That way I can do a simple search on the SQFIXES page to check for recently approved items. After an item has been approved, one thing that we still want is a chance for other harvesters (and perhaps anyone else) to note that the item is about to go into the update stream, and voice any last minute opposition or refinements. For example, "Wait a second, we don't want to just change frobozz like that... that could cause problems for this other doohickey." With the previous harvesting process, each harvester had to submit a .zip file of a bundle of harvested changes to a largish list of people, which provided a convenient sort of last-minute screening for things. In theory, we could do something similar with submitting bundles to this SqF list, but that seems a bit too heavyweight for me. Perhaps we should just allow a certain amount of time to pass (say, at least 3 days) after an item has been approved, before it gets added to the update stream. This will give people a chance to say "Hey wait a minute". However, this requires that harvesters do a reasonable job of tracking the SQFIXES page on a semi-regular basis to see what new stuff is about to go in, rather than having a summary conveniently arrive in an email. But I think this is probably workable. Another thing I should probably do is add one last tag/keyword to SQFIXES entries which are being added to the update stream. It could be ([update]) or something like that. (The 3 day delay could happen between [approved] and [update], or it could happen between adding the [update] tag and actually adding the fix to the update stream. Hmm, probably the former makes more sense.) Realistically, I may only incorporate things into the update stream once per week or so, so the delay could vary from 3-10 days or something like that. But that's still a pretty decent turnaround compared to what we have now. Yet one more issue is whether we want to have stricter standards for [ENH]ancements. We talked about requiring approval from two harvesters. Or perhaps approval from one harvester, plus an [et] from any other third party would suffice. Hmm. (I suppose one drawback of having stricter standards is that people might be tempted to call something a fix which is really more of an enhancement.) (I guess this post doesn't cover the issue of whether any of the [sl], [er], etc., tags should be mandatory before an item is approved by a harvester. Certainly any such tags should make it more likely that an item will be seriously looked at. I'd say we could probably get started incorporating stuff without requiring mandatory tags, and figure out which ones really need to be mandatory after going through the process for a little while. Probably [et] and [er] should be required, at least, although the harvester could supply those tags upon approval, if no one else does.) Anyway, we can try something like I outlined above. Does this all sound reasonable? The only thing I'm still not sure about is whether we want stricter standards for enhancements. - Doug Way p.s. Once this is sorted out, I do need to update the various harvesting web pages that Tim mentioned. And yes, a fancier harvesting system will be coming eventually, but probably not for a while.

1 1

Re: [Squeakfoundation]Final steps for harvesting
by Daniel Vainsencher 25 Mar '03

25 Mar '03

I think we should go with this process as outlined, without any additional rules for ENH nor making any specific tags mandatory. BUT - let all Harvesters note that we need this process to improve. And people are simply not fooled (for long) by mere statements, they track implemented policy. The extent to which we prefer simple stuff with proper tags, and require the tags to mean something, will determine community participation in the review process. The only reason to not require reviewers is because a submission is so simple and well prepared that its goodness is self evident. If you want to include something because you like the functionality, despite it not having enough tags or being as simple as it should, avoid the temptation to "just do it" - instead solicit reviewers on the list. Daniel Doug Way <dway(a)riskmetrics.com> wrote: > > As discussed earlier, I think we are ready to start incorporating fixes & > small enhancements from the SQFIXES page ( http://swiki.gsug.org:8080/SQFIXES/ > ) into 3.6alpha, even though we still need to discuss the larger items which > will make up 3.6. > > The process for entering and tagging submissions looks pretty good. I want to > nail down the final steps of the process, so that we can start moving stuff > into the update stream. > > For incorporating [FIX]es, we agreed that the fix needs to be approved by one > Harvester. (Harvester meaning a Guide, a member of SqC, or a harvesting > volunteer from the original list of harvesters. Hmm, I need to contact the > people on that list to see who is still interested.) > > To make things clear, the harvester should use a special keyword (which we > should agree on now) such as "[approved]" in the parentheses of the SQFIXES > entry. That way I can do a simple search on the SQFIXES page to check for > recently approved items. > > After an item has been approved, one thing that we still want is a chance for > other harvesters (and perhaps anyone else) to note that the item is about to > go into the update stream, and voice any last minute opposition or > refinements. For example, "Wait a second, we don't want to just change > frobozz like that... that could cause problems for this other doohickey." > > With the previous harvesting process, each harvester had to submit a .zip file > of a bundle of harvested changes to a largish list of people, which provided a > convenient sort of last-minute screening for things. In theory, we could do > something similar with submitting bundles to this SqF list, but that seems a > bit too heavyweight for me. Perhaps we should just allow a certain amount of > time to pass (say, at least 3 days) after an item has been approved, before it > gets added to the update stream. This will give people a chance to say "Hey > wait a minute". However, this requires that harvesters do a reasonable job of > tracking the SQFIXES page on a semi-regular basis to see what new stuff is > about to go in, rather than having a summary conveniently arrive in an email. > But I think this is probably workable. > > Another thing I should probably do is add one last tag/keyword to SQFIXES > entries which are being added to the update stream. It could be ([update]) or > something like that. (The 3 day delay could happen between [approved] and > [update], or it could happen between adding the [update] tag and actually > adding the fix to the update stream. Hmm, probably the former makes more > sense.) Realistically, I may only incorporate things into the update stream > once per week or so, so the delay could vary from 3-10 days or something like > that. But that's still a pretty decent turnaround compared to what we have > now. > > Yet one more issue is whether we want to have stricter standards for > [ENH]ancements. We talked about requiring approval from two harvesters. Or > perhaps approval from one harvester, plus an [et] from any other third party > would suffice. Hmm. (I suppose one drawback of having stricter standards is > that people might be tempted to call something a fix which is really more of > an enhancement.) > > (I guess this post doesn't cover the issue of whether any of the [sl], [er], > etc., tags should be mandatory before an item is approved by a harvester. > Certainly any such tags should make it more likely that an item will be > seriously looked at. I'd say we could probably get started incorporating > stuff without requiring mandatory tags, and figure out which ones really need > to be mandatory after going through the process for a little while. Probably > [et] and [er] should be required, at least, although the harvester could > supply those tags upon approval, if no one else does.) > > Anyway, we can try something like I outlined above. Does this all sound > reasonable? The only thing I'm still not sure about is whether we want > stricter standards for enhancements. > > - Doug Way > > > p.s. Once this is sorted out, I do need to update the various harvesting web > pages that Tim mentioned. And yes, a fancier harvesting system will be coming > eventually, but probably not for a while. > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

RE: [Squeakfoundation]Handling fixes/enhancements
by danielv＠netvision.net.il 24 Mar '03

24 Mar '03

Well, the idea is that as a harvester/Guide you can also add a comment "approved" when you think it's fit to go (based on whatever evidence has accumulated). Before you do that, you should review everything people actually said (open up all those mails) and maybe critique the content of what people said - that's the way we have to make sure things get reviewed in a way we can trust in the future. Basically, unless Doug decides to be extra suspicous (his prerogative) or someone else objects, that should be all it takes for Doug to roll it in as an update. Daniel Tim Rowledge <tim(a)sumeru.stanford.edu> wrote: > "Brent Vukmer" <bvukmer(a)blackboard.com> wrote: > > > Tim -- > > > > The "Commenting Bugs and Fixes" page is up-to-date ( and fairly clear thanks to Joshua Gargus ): http://minnow.cc.gatech.edu/squeak/3103 > It is indeed reasonably clear for the purpose of submitting bugs, fixes > etc but it doesn't help me much with my work as a harvester and guide. > I know I can simply post an approving comment with the [et] etc tags but > at some point there has to be a place where more happens. > > What is the status of a better set of tools for all this? > > tim > > -- > Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim > Use IF...ELSE IF...ELSE IF...ELSE... to implement multi-way branches. > _______________________________________________ > Squeakfoundation mailing list > Squeakfoundation(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/listinfo/squeakfoundation

1 0

RE: [Squeakfoundation]Handling fixes/enhancements (was Re:Possibleextra text for Welcome
by Brent Vukmer 24 Mar '03

24 Mar '03

The qualifier may make that comment sound snarky -- sorry, Joshua. s/fairly clear/*clear* -----Original Message----- From: Brent Vukmer Sent: Monday, March 24, 2003 3:22 PM To: Discussing the Squeak Foundation Subject: RE: [Squeakfoundation]Handling fixes/enhancements (was Re:Possibleextra text for Welcome Tim -- The "Commenting Bugs and Fixes" page is up-to-date ( and fairly clear thanks to Joshua Gargus ): http://minnow.cc.gatech.edu/squeak/3103 -----Original Message----- From: Tim Rowledge [mailto:tim@sumeru.stanford.edu] Sent: Monday, March 24, 2003 3:11 PM To: squeakfoundation(a)lists.squeakfoundation.org Subject: Re: [Squeakfoundation]Handling fixes/enhancements (was Re: Possibleextra text for Welcome I've just been trying to review the process for harvesting and reveiwing fixes. It all seems a bit confused right now. There's the sqfixes page(s)on http://209.143.91.36/super/415 and various pages pointed to from there but much is out of date. For a start I can hardly bundle up stuff I've reviewed and email it to SqC anymore can I? Perhaps I've missed stuff whilst I had my head down trying to update the VMMaker codebase? Given some fix or enh or whatever that I've reveiwed and would like to promote, what is the current best process? tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Don't sweat petty things....or pet sweaty things. _______________________________________________ Squeakfoundation mailing list Squeakfoundation(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation _______________________________________________ Squeakfoundation mailing list Squeakfoundation(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

RE: [Squeakfoundation]Handling fixes/enhancements (was Re: Possibleextra text for Welcome
by Brent Vukmer 24 Mar '03

24 Mar '03

Tim -- The "Commenting Bugs and Fixes" page is up-to-date ( and fairly clear thanks to Joshua Gargus ): http://minnow.cc.gatech.edu/squeak/3103 -----Original Message----- From: Tim Rowledge [mailto:tim@sumeru.stanford.edu] Sent: Monday, March 24, 2003 3:11 PM To: squeakfoundation(a)lists.squeakfoundation.org Subject: Re: [Squeakfoundation]Handling fixes/enhancements (was Re: Possibleextra text for Welcome I've just been trying to review the process for harvesting and reveiwing fixes. It all seems a bit confused right now. There's the sqfixes page(s)on http://209.143.91.36/super/415 and various pages pointed to from there but much is out of date. For a start I can hardly bundle up stuff I've reviewed and email it to SqC anymore can I? Perhaps I've missed stuff whilst I had my head down trying to update the VMMaker codebase? Given some fix or enh or whatever that I've reveiwed and would like to promote, what is the current best process? tim -- Tim Rowledge, tim(a)sumeru.stanford.edu, http://sumeru.stanford.edu/tim Don't sweat petty things....or pet sweaty things. _______________________________________________ Squeakfoundation mailing list Squeakfoundation(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation

2 1

Possible extra text for Welcome window in 3.4
by Doug Way 24 Mar '03

24 Mar '03

Scott mentioned awhile ago that he would be releasing a candidate image for 3.4gamma. I thought it might be helpful to at least have a mention of SqueakMap somewhere in one of the introductory windows of the image. So, here's a proposed paragraph blurb introducing SqueakMap. I thought it might be best located in the "Welcome to..." window, after the very first section but before the "Morphic" section. (The "*here*" link would be a DoIt link which would execute "TheWorldMenu openPackageLoader".) Or, it could go in ReadMe.txt or somewhere else, but I think the Welcome window might be best. Feel free to improve the wording, etc. (In theory, we could also have an introduction to the Guides, but I'm not sure that's as important. There's not really any mention of Squeak Central in the intro windows, anyway.) - Doug --------------------------------------- <bold>What's new in Squeak 3.4</bold> An exciting feature which has been made available in the 3.4 release is SqueakMap, a package catalog system for Squeak. As of this release, over 100 packages/applications have been added to SqueakMap by members of the Squeak community. You can easily browse and install these packages directly in Squeak by using the SqueakMap Package Loader, which is available from the "open..."/"Package Loader" menu (or, by clicking *here*). For more information on SqueakMap, see *http://minnow.cc.gatech.edu/squeak/squeakmap*.

5 16

Stable Snapshots
by Jimmie Houchin 24 Mar '03

24 Mar '03

Please pardon the outsider intrusion. :) While reading some of your discussions on releases I had this thought or perspective on timed releases. Squeak is a rapidly advancing system. Because of this it can be challenging to pin down a release due to a particular feature set. Features, apps, products, etc. are constantly being added and evolving. Maybe what is needed is merely a point in time where a 'snapshot' of the current development Squeak is stabilized. Similar to the Debian analogy. The more solid stuff moves up to become the stable snapshot and then stabilized for the timed release. Somewhat as a natural part of this and open source development would be that what makes into into the stable release is that which has received the developer mindshare or attention. This way the user community can keep up with current Squeak happenings while maintaining a relative sense of stability with their Squeak environment. However the implementation takes place it just seemed that the idea of a Stable Squeak Snapshot (3 S's :) is what were looking at for a timed release schedule. I think it fits Squeak better than a feature based release schedule. Not that features are bad, but the trigger needs to be pulled somewhere. :) Am I making sense here? Thanks. Jimmie Houchin PS. I too, like the tri-annual release.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

Squeakfoundation March 2003