Hi people!

"Davide Arrigo" davide.arrigo@gmail.com wrote:

Hi Hilaire

.....

...

As a free software activist and developer, I always get political difficulty to promote Squeak because of its licence. For me it is already free but most of the free software community and my friend do not share this point of view. It is really a problem because most people get stuck to the licence problem and they can't discover all the great stuff coming with Squeak and Smalltalk.

... I'm totally agree with you, I didn't understood why the Squeak License is too different from the other from opensource and free software movement. In my opinion is better to rethinking this licensing politics to promote Squeak and grow in the opensource community. Squeak is an amazing tool as educational environment, it's a great occasion.

Now, if you would be more familiar with all twists and turns in the history of Squeak and know what parts of Squeak have been made by whom etc, then you would probably be aware of the following:

1. Most Squeakers would really like to have Squeak under a BSD/MIT-ish license. So it is not that we don't *want* to. Licensing is being discussed yearly in very long threads and things are exlained over and over again. Check archives.

2. Squeak 3.9 consists of code from: a) Apple (available today under Squeak-L or APSL2 which is nice). I am guessing about 20% of the code. b) Disney (under Squeak-L). I am guessing at least 40%-60% of the code. c) Probably (just a guess) several hundreds of individuals (available under Squeak-L and in some cases also MIT) d) A few other organisations I am guessing (available under Squeak-L and possibly also MIT).

3. In order to change the license of Squeak 3.9 to APSL2 we would need to: a) Get all parties b-d above to agree to do that. I am guessing c) and d) would be doable (even though c) is a major undertaking to get done properly) - but the really tricky one is b).

4. In order to change the license of Squeak 3.9 to MIT we would need to: a) Get all parties a-d above to agree to do that. Since we just went through this discussion with Apple and I think MIT was on the table as an option, I do not think it would either be wise nor successful to try to get it under MIT now that we just managed to get it under APSL2.

5. There are also other licensees of the original Smalltalk-80 code that might be an interesting option (Craig, Dan or Alan knows more).

IMHO changing the license of Squeak 3.9 *in full* (and doing it only in part is not interesting) is *very hard* if not impossible. Again the big hurdle is b) above. I know Alan has presented a different view on b), but AFAIK it is still clear that Disney owns that code and in order to change the license of it we need Disney to do it.

Sooo.... IMHO it boils down to a big RESTART of Squeak and doing that *just* for licensing is quite silly. BUT... there are other technical reasons for our community to take on such a task anyway so perhaps it is acually doable. Now, let's dream a little :) :

Step 1. Say Ian makes the Magic only he can do and presents his remarkable "Id" with "Pepsi" etc after the summer and squeak-dev goes bonkers of joy. This latest work from Ian is all MIT licensed AFAIK and could make a compelling new base for us to build something ENTIRELY NEW and very exciting on. I have toyed with hist Idst-5.1 from his website and it is very cool stuff. I have also exchanged some emails with Ian and I look forward to some kind of posting from him about this but that is Ian's ball of course.

Step 2. The other VM guys agree that the regular "old" Squeak VM scheme has reached its limit and perhaps 3.9 will not be the base of Grand 4.0 but instead goes into "maintenance mode" and is followed by 3.10, 3.11 with only smaller modifications and enhancements. And stays Squeak-L as today. The VM group decides to adopt Ian's work (Id etc) as the base for a new Squeak and a Team is formed to try to get the low level pieces in place. This is hard technical work and will take a while.

Step 3. A small clean kernel "image" is produced which is MIT licensed. Perhaps we can use Spoon as a base, or perhaps we can use Smalltalk-80 from one of the other original licensees and get it under MIT (Craig?) or perhaps we just write something from scratch (unsure of the code Ian has in Idst for example). It is then brought into graphical life with Tweak as the UI framework and Toolbuilder to make backporting tools from Squeak 3.9 easier.

Step 4. More tools are brought over from old Squeak into the New Squeak. It gets inhabitable. At this point the "general Squeaker" can also join. Up until this step we need dedicated people - because it will not be a pleasant place to live in. Only MIT code should of course be let into the "base" image.

Step 5. Eventually porting begins of the top level pieces from the Squeak world. Seaside, KomHttpServer/Swazoo etc.

And tada, life is nice. A dream? Something doable? I dunno. What I do know is that it would take a few years to pull off all those steps and that it would take *lots* of stamina from Step 1 to Step 4. Before this New Squeak is inhabitable we can only rely on a handful of really talented Squeakers and VM guys to get us to Step 4 - and they are typically busy with lots of other projects.

But generally I think the time is right for us to "burn the disk packs!". We have several technical pieces lined up (Spoon, Id/Pepsi, Exupery), we have several high profile projects (Croquet, Sophie etc) in need, we have a community that is strong and an elected board that should be capable of pulling of reasonable organisation of it all. And we have burned ourselves enough times on the "let's get this cleaned up...". It just too hard work.

regards, Göran

PS. All the above is *my* perception of things and there may be several factual omittings or errors. :)

Marcus Denker a écrit :

On 14.06.2006, at 17:44, Hilaire Fernandes wrote:

...

I am proposing for 4 or 5 days meeting, taking place after the daily conferences. The meeting could last for two hours, 17:00-19:00.

As a matter of facts, which experts are ready to join such a meeting?

I would be interested.

That's nice Marcus to hear that from you as you are a major contributor to Squeak. Other people have expressed interest but will not be able to attend the meeting (Graig and Tim). Other people attending the meeting have shown absolutely *NO INTEREST* in the matter, it is sad :( Let's discuss a bit more on the mailing list and see how things evolve...

Hilaire

Cees De Groot a écrit :

On 6/24/06, Hilaire Fernandes hilaire@ext.cri74.org wrote:

...

Other people attending the meeting have shown absolutely *NO INTEREST* in the matter, it is sad :(

I don't know. It might also be an indicator that the licensing "issues" are largely just perceived, or deemed to be PR stuff, or whatever. But not a real actual stumbling block to actual Squeak practicioners.

I totally agree with you. The licensing "issues" does not prevent Squeak to be a free software, it is just preventing Squeak to enter mainstream in the free software community.

Hilaire

I am frowarding this answer from Chao-Kuei Hung as I am not sure it will get in the Squeak-dev mailing list.

Hilaire

洪朝貴 a écrit :

On Sun, Jun 25, 2006 at 01:23:26PM +0200, Hilaire Fernandes wrote:

...

Cees De Groot a crit :

...

On 6/24/06, Hilaire Fernandes hilaire@ext.cri74.org wrote:

...

Other people attending the meeting have shown absolutely *NO INTEREST* in the matter, it is sad :(

I don't know. It might also be an indicator that the licensing "issues" are largely just perceived, or deemed to be PR stuff, or whatever. But not a real actual stumbling block to actual Squeak practicioners.

I totally agree with you. The licensing "issues" does not prevent Squeak to be a free software, it is just preventing Squeak to enter mainstream in the free software community.

Hilaire

+1

I have been pushing Dr. Geo I into junior and senior high schools here in Taiwan. It was such a pleasure to know that Hilaire is releasing Dr. Geo II using LGPL. But for the moment I have to hold back the push for Dr. Geo II because it is built with Squeak, whose license issue is just about to be resolved yet. As Hilaire has frequently urged me to try, there must be a lot more other very interesting and useful tools in education built with Squeak just like Dr. Geo II.

Personally I wouldn't care the "small license bug" (as Hilaire calls it) when I demonstrate things to my nieces and nephews. When it comes to promoting the software publicly, it is totally different. As a long time FS advocate who have made peripheral contributions such as the "Software Category Drawing" on the gnu site, I would constantly get into defensive position about the license issue if I were to promote software with this license bug. The worst part is that the defense would be against the FS community, the force that built my reputation and strength. Political thinking? Yes, but practical nontheless. You chose to pursue Squeak because of practical considerations (in the technical sense) , and I chose not to because of the very same reason (in the political sense).

With high respect to the squeak community I plead your attention to the license issue. Now that the old version becomes free, I personally believe that it is only a matter of time that the entire thing becomes free and that major distributions start packaging this nice software in a few years. I will be glad to help rewrite some less important components whose authors can no longer be contacted for a change of license, and release it as LGPL or less retrictive license as the squeak community sees appropriate. (Good at geometry/algorithms/regexp, OK at OOP and many languages, no smalltalk experience.) When the license issue is comfortably resolved, I will then go back to the political arena and start a major push here in Taiwan ;-) BTW I believe there are many FS advocates around the world who hold more or less similar attitude. It would be beneficial to the squeak community and to the world at large if the squeak community announces the decision to move towards a "bug-free" license and call for participation to accelarate the transition.

Best Regards,

As Craig said, we (SqF Board) are going to discuss various approaches with Dan Ravicher July 5th. We'll have a more informed idea of what is possible after that conversation, I hope. However, at the moment I think there are two realistic approaches:

• Take Squeak 1.1 and declare that the new main line of development;
• Do a license check on the Spoon code and declare that the new main

line of development. In both cases, we'd start with a "deficient" Squeak and work upwards. The third option, sort out the mess that's 3.9 (licensing-wise), seems to be not very viable. It's a lot of work to start with, and the outcomes are unsure.

You don't expect that's possible to take bootstrapped 3.9 kernel image (http://www.squeaksource.com/KernelImage.html) and make it clean from the licensing perspective? I don't think that it's more complicated than Spoon checking.

-- Pavel

Cees De Groot a écrit :

On 6/26/06, Pavel Krivanek squeak1@continentalbrno.cz wrote:

...

You don't expect that's possible to take bootstrapped 3.9 kernel image (http://www.squeaksource.com/KernelImage.html) and make it clean from the licensing perspective? I don't think that it's more complicated than Spoon checking.

Well, Spoon's kernel image is so small, you can see all of it running at once :). But I don't see either project precluding the other, in fact.

How small is that 3.9 image, code wise?

One of the proposal (from Tim) -- to check with the laywer I guess -- was to relicensed all the SqL code under APLS2.0. If possible, it will not be that paintfull to migrate from 3.9 and it will get use a ready to use image. Of course it is not incompatible with the Spoon track.

I also proposed a semi automatic way to do that: any code copyright owner not willing to see his code relicensed to APSL2.0 should say so before a given dead line.

Hilaire

Oops, my previous message counted authorship in a 3.7u1 image. Here are the counts for 3.9 full the counts. Congratulations to Andreas for surpassing the "undated" entries. :)

7420->''ar'' 3809->''(undated)'' 3452->''sw'' 2231->''stephaneducasse'' 2193->''yo'' 2134->''dgd'' 1947->''RAA'' 1900->''di'' 1774->''nk'' 1685->''sd'' 1344->''jm'' 1291->''tk'' 1018->''al'' 975->''cwp'' 959->''md'' 894->''mir'' 674->''gk'' 662->''brp'' 648->''len'' 518->''ls'' 505->''avi'' 466->''sma'' 425->''ab'' 407->''dvf'' 392->''NS'' 350->''JMM'' 348->''bf'' 346->''ajh'' 270->''hpt'' 237->''sr'' 225->''rr'' 223->''wiz'' 223->''lr'' 184->''rw'' 183->''tak'' 164->''apb'' 142->''tlk'' 138->''asm'' 138->''sps'' 133->''rbb'' 117->''raok'' 100->''acg'' 100->''th'' 99->''jrp'' 91->''BG'' 88->''tpr'' 88->''hmm'' 87->''gm'' 86->''laza'' 84->''tao'' 81->''dew'' 80->''MPW'' 80->''gh'' 79->''fbs'' 75->''tfei'' 75->''dtl'' 72->''hg'' 64->''LC'' 62->''nb'' 58->''zz'' 57->''mk'' 57->''svp'' 55->''dao'' 51->''aoy'' 50->''RAH'' 46->''kfr'' 46->''KLC'' 45->''miki'' 43->''sbw'' 42->''SqR'' 41->''KR'' 39->''mu'' 39->''mpw'' 38->''reThink'' 35->''fc'' 34->''mdr'' 33->''panda'' 32->''efc'' 30->''SD'' 30->''jdr'' 30->''jcg'' 29->''jmv'' 28->''bkv'' 27->''TBn'' 26->''JW'' 25->''Tsutomu'' 25->''JF'' 25->''jf'' 25->''em'' 25->''jws'' 25->''bolot'' 23->''stp'' 23->''mjr'' 22->''CdG'' 21->''bvs'' 20->''DSM'' 20->''sac'' 20->''wod'' 19->''nice'' 19->''GL'' 18->''djp'' 18->''mx'' 18->''RCS'' 17->''rhi'' 17->''JWS'' 17->''st'' 17->''ads'' 17->''TAG'' 16->''TPR'' 16->''FBS'' 16->''sumim'' 16->''jdl'' 15->''6/9/97'' 15->''bp'' 15->''hh'' 14->''ikp'' 14->''dwh'' 14->''btr'' 13->''mga'' 12->''dc'' 12->''ka'' 12->''BP'' 11->''pk'' 11->''dd'' 11->''jhm'' 11->''rww'' 11->''emm'' 11->''raa'' 10->''nop'' 10->''TBP'' 10->''DM'' 10->''tween'' 9->''jrm'' 9->''abc'' 9->''NDCC'' 9->''jla'' 9->''dns'' 8->''pnm'' 8->''mjg'' 8->''AFi'' 8->''ndCollectionsTests-Unordered'' 8->''tb'' 8->''PHK'' 7->''jam'' 7->''tbn'' 7->''jmb'' 7->''Noury'' 7->''tetha'' 7->''EP'' 7->''spfa'' 6->''nm'' 6->''TN'' 6->''pmm'' 6->''YE'' 6->''das'' 5->''6/7/97'' 5->''JMV'' 5->''r++'' 5->''ccn'' 5->''edc'' 4->''brp`'' 4->''jlb'' 4->''cmm'' 4->''wb'' 4->'''' 4->''BJP'' 4->''stephaneducassse'' 4->''TRee'' 3->''ac'' 3->''wdc'' 3->''sge'' 3->''bh'' 3->''ts'' 3->''DF'' 3->''6/5/97'' 3->''jsp'' 3->''jm '' 3->''go'' 3->''apl'' 3->''MAL'' 3->''pnm 8/23/2000'' 2->''MPH'' 2->''hk'' 2->''LEG'' 2->''programmatic'' 2->''dhhi'' 2->''ward'' 2->''sk'' 2->''mas'' 2->''MU'' 2->''6/8/97'' 2->''bmk'' 2->''dvf 6/10/2000'' 2->''rjf'' 2->''aka'' 2->''vb'' 2->''ak'' 2->''eat'' 2->''efo'' 2->''crl'' 2->''cm'' 2->''DSM 10/15/1999'' 2->''ASF'' 2->''es'' 2->''6/6/97'' 1->''Tbp'' 1->''dls'' 1->''mikki'' 1->''6/10/97'' 1->''de'' 1->''6/18/97'' 1->''KTT'' 1->''ykoubo'' 1->''AB'' 1->''los'' 1->''RvL'' 1->''vj'' 1->''jj'' 1->''tk

11/26/2004'' 1->''PH'' 1->''edt'' 1->''T2'' 1->''sn'' 1->''LB'' 1->''ssa'' 1->''tk 9/13/97'' 1->''rop'' 1->''rlf'' 1->''cbc'' 1->''TJ'' 1->''cds'' 1->''mist'' 1->''RJ'' 1->''rca'' 1->''pm'' 1->''EW'' 1->''mrm'' 1->''huma'' 1->''tk

11/29/2004'' 1->''drs'' 1->''je'' 1->''HilaireFernandes'' 1->''m'' 1->''to'' 1->''ich.'' 1->''MM'' 1->''ag'' 1->''Rik'' 1->''jwh'' 1->''HK'' 1->''6/13/97'' 1->''fcs'' 1->''mkd'' 1->''rpj'' 1->''RB'' 1->''mw'' '

-Lex

These numbers are not reliable. If you want more accurate numbers use 3.8 - 3.9 severely suffers from the underscore to colon-equals conversion which wrecked havoc on the author initials in the affected packages.

Cheers, - Andreas

Lex Spoon wrote:

Oops, my previous message counted authorship in a 3.7u1 image. Here are the counts for 3.9 full the counts. Congratulations to Andreas for surpassing the "undated" entries. :)

7420->''ar'' 3809->''(undated)'' 3452->''sw'' 2231->''stephaneducasse'' 2193->''yo'' 2134->''dgd'' 1947->''RAA'' 1900->''di'' 1774->''nk'' 1685->''sd'' 1344->''jm'' 1291->''tk'' 1018->''al'' 975->''cwp'' 959->''md'' 894->''mir'' 674->''gk'' 662->''brp'' 648->''len'' 518->''ls'' 505->''avi''

If the 3.9 team used Berts script it should have preserved the author and timestamp information; I had updated the script to preserve it..

--- Andreas Raab andreas.raab@gmx.de wrote:

These numbers are not reliable. If you want more accurate numbers use 3.8 - 3.9 severely suffers from the underscore to colon-equals conversion which wrecked havoc on the author initials in the affected packages.

Cheers,

• Andreas

Lex Spoon wrote:

...

Oops, my previous message counted authorship in a 3.7u1 image.

Here

...

are the counts for 3.9 full the counts. Congratulations to Andreas for surpassing the "undated" entries. :)

7420->''ar'' 3809->''(undated)'' 3452->''sw'' 2231->''stephaneducasse'' 2193->''yo'' 2134->''dgd'' 1947->''RAA'' 1900->''di'' 1774->''nk'' 1685->''sd'' 1344->''jm'' 1291->''tk'' 1018->''al'' 975->''cwp'' 959->''md'' 894->''mir'' 674->''gk'' 662->''brp'' 648->''len'' 518->''ls'' 505->''avi''

Am 29.06.2006 um 00:13 schrieb Andreas Raab:

Chris Muller wrote:

...

If the 3.9 team used Berts script it should have preserved the author and timestamp information; I had updated the script to preserve it..

I don't think this happened. I mean, I know how much work Stef is putting into 3.9 but I just don't think that he's written more code in 3.9 alone than, say Dan, has *ever* written for Squeak ;-) See here:

...

...

...

2231->''stephaneducasse'' 1900->''di''

I guess Stef used an earlier version that did not have the fix by Chris.

Anyhow, to get the actual list of contributors youl'd have to find the authors of *every* earlier version anyway, so for the problem at hand this is irrelevant (though it would be preferrable to have the initials intact). Also, if, say, a parameter was added to a method and the old one deleted, shouldn't it still be considered the same method? Or if it was simply renamed? We lose the history in both cases.

- Bert -

Am 30.06.2006 um 12:07 schrieb Lex Spoon:

By the way, what is the initials problem you are discussing?

Stef used a script to convert underscore-assignment to colon-equal- assignment. An earlier version of that script did not preserve the former author initials.

FixUnderscores-bf.8 is the one in the 3.9 repository (http:// source.squeakfoundation.org/39a.html) while the initials-fix is in FixUnderscores-cmm.10 (http://source.impara.de/underscore.html).

- Bert -

Ok I will use the new version of that script

Stef

Am 30.06.2006 um 12:07 schrieb Lex Spoon:

...

By the way, what is the initials problem you are discussing?

Stef used a script to convert underscore-assignment to colon-equal- assignment. An earlier version of that script did not preserve the former author initials.

FixUnderscores-bf.8 is the one in the 3.9 repository (http:// source.squeakfoundation.org/39a.html) while the initials-fix is in FixUnderscores-cmm.10 (http://source.impara.de/underscore.html).

• Bert -

Hi!

Lex Spoon lex@cc.gatech.edu wrote:

Oops, my previous message counted authorship in a 3.7u1 image. Here are the counts for 3.9 full the counts. Congratulations to Andreas for surpassing the "undated" entries. :)

7420->''ar''

And if you want to see more info:

(SMSqueakMap default accountForUsername: 'ar') nameAndEmail

regards, Göran

"Cees De Groot" cdegroot@gmail.com wrote:

For example, while Squeak Central has always stated that they were careful to separate proprietary code from public code during their stint at Disney, it was never stated that Disney was not the owner of the public code. So we have to assume they are, which means that for any of the work done by any SqC member during that time we'd need a license grant under the APSL from Disney, not the person who has his/her initials on the code.

Which brings us back to my post which (oddly I thought) went more or less totally uncommented:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-June/105229 .html

Was it too long to read? :)

regards, Göran

On 28 juin 06, at 10:02, Cees De Groot wrote:

On 6/28/06, goran@krampe.se goran@krampe.se wrote:

...

Was it too long to read? :)

No, it was too correct to need commenting :-).

A little quote from that mail:

...

But generally I think the time is right for us to "burn the disk packs!".

+1

The main problem is who would do that? Since we are not even able to harvest fixes. Now what we can do is to perform an audit of the assets we have and their status:

- NewCompiler (nearly there and could be APSL/MIT/Squeak-L) - Tweak ? - OmniBrowser - MC - YAXO

I have the impression that we cannot restart from scratch without a clear analysis of the current status.

stéphane ducasse ducasse@iam.unibe.ch writes:

The main problem is who would do that? Since we are not even able to harvest fixes. Now what we can do is to perform an audit of the assets we have and their status:

• NewCompiler (nearly there and could be APSL/MIT/Squeak-L)
• Tweak ?
• OmniBrowser
• MC
• YAXO

I have the impression that we cannot restart from scratch without a clear analysis of the current status.

There is a lot of existing Squeak content. There are 200 packages in the 3.7 stable package universe. It takes hours just to *read* this list. Imagine how long it would take to reproduce it all.

In fact, this would be a good threshold to keep in mind before starting over: how long will it take to get back to zero? Until you are back to zero, many people will want to continue with the current system.

-Lex

...

There is a lot of existing Squeak content. There are 200 packages in the 3.7 stable package universe. It takes hours just to *read* this list. Imagine how long it would take to reproduce it all.

Whoa. So far this is the first suggestion I've seen that we should worry about the licensing of anything other than the core image. The goal here is to be able to say that "Squeak is Open Source (tm)" and be able to have it included in OS distributions, or pitch it to customers on that basis. That code doesn't require that every bit of code in the Squeak universe comply. The packages on SM can be licensed however the authors choose, and it's up to them to manage the consequences of their choices.

I think Steph brought up those packages because they are or have been included in the core Squeak distribution at one time or another. They're also big chunks of code with few contributors and should thus be fairly easy to get relicensed.

Yes and also because I was thinking in terms of core functionality.

Stef

Lex Spoon a écrit :

Colin Putney cputney@wiresong.ca writes:

...

On Jun 30, 2006, at 5:47 AM, Lex Spoon wrote:

...

There is a lot of existing Squeak content. There are 200 packages in the 3.7 stable package universe. It takes hours just to *read* this list. Imagine how long it would take to reproduce it all.

Whoa. So far this is the first suggestion I've seen that we should worry about the licensing of anything other than the core image.

We agree, I think. The point is that if we try and restart the core image from scratch, then we would have a long way to go before getting back to Squeak's current functionality. It is more realistic to contact the existing contributors and verify that they agree to a relicense.

It is wise. Should the foundation propose a plan to do that?

Hilaire

So know I still wonder is the objective of Tweak is still to replace the morphic layer or did the objective changed?

Hilaire

Hilaire Fernandes a écrit :

Yeah, regarding code owned by Dysney, I guess Morph anbd Etoys count for a major part, right?

In the other hand, reading at the Tweak RoadMap, in particular:

---

Morphic+MVC Removal

Tweak 1.0 should have enough support to be able to drop Morphic and MVC from it; 1.1 should be complete enough to be able to do all programming activities in Tweak itself (ToolBuilder might affect this).

---

It looks like Morph and Etoys should be replaced step by step by Tweak. At least it will be a major move forward regarding the Squeak integration in the free software community...

Hilaire

I think that you raise an important question. Does it make sense that Sophie is based on Tweak in that case? Should people fork from Tweak (even before starting using it :)).

Stef

However, IIRC Andreas has stated at at least one occasion in unequivocally clear words that Tweak is primarily for his own projects (Croquet, Etoys(?)). In other words, he is not going to commit to spend time to work at Tweak for the community (knowing him, he might still do it, but we can't count on it ;-)).

Which means that for the Squeak community at large, Tweak is a take-it-or-leave-it deal. People can send patches and/or enhancements to Andreas, but he is likely to decide on accepting them only in the context of his work, and not primarily to do the community a favor.

(note: I'm totally fine with Andreas' position here. It is his code after all, he can do with it as he pleases. Just that people don't misunderstand why I bring up this issue)

Hilaire Fernandes writes:

Cees De Groot a écrit :

...

On 7/3/06, Hilaire Fernandes hilaire@ext.cri74.org wrote:

...

So know I still wonder is the objective of Tweak is still to replace the morphic layer or did the objective changed?

As far as I know, that's still the objective.

However, IIRC Andreas has stated at at least one occasion in unequivocally clear words that Tweak is primarily for his own projects (Croquet, Etoys(?)). In other words, he is not going to commit to spend time to work at Tweak for the community (knowing him, he might still do it, but we can't count on it ;-)).

Okay, I was not aware of that. It is sad if Tweak developers are not interested to get Tweak maintstream in Squeak. In this case (I hope it is not the case), bascicly there are only two options:

From my understanding, they were concentrating on their own

goals. There's a lot of work in getting a major package into mainstream Squeak, that work could be a distraction to them.

The Tweak developers are using Morphic for development tools, they might be tempted to co-operate by work on bringing Tweak's development tools up to Morphic tools levels.

If Squeak was a set of packages then licencing would be easier because we could deal with each package individually. Also the licencing of the core image would be less important because being small it would be easier to replace.

People could then work with a mostly cleanly licenced image with a few SqueakL packages that were externally loaded while boot-strapping a fully cleanly licenced image. GNU began development as a set of tools that ran under proprietary Unix.

Bryce

Chris Muller a écrit :

...

Okay, I was not aware of that. It is sad if Tweak developers are not interested to get Tweak maintstream in Squeak.

Shouldn't the responsibility of putting Tweak into mainstream Squeak be the responsibility of the mainstream Squeak development team if that's what they want?

I remember at least Steph said it will be interested to help to integrate Tweak in Squeak. But in the other hand this can only be done in sync with the developers of the framework, especially when it is about such an important framework as the GUI.

...

Without commitment of the lead developpers of Tweak to get it in Squeak, it is useless to send such patch and enhancement.

What makes you say that? I see no correlation..

Well, you may not want to base you work on framework you are not sure it is viable in the middle term or if you are not sure it will become mainstream in Squeak.

Hilaire

Am 06.07.2006 um 09:50 schrieb stéphane ducasse:

On 5 juil. 06, at 19:16, Chris Muller wrote:

...

...

Okay, I was not aware of that. It is sad if Tweak developers are not interested to get Tweak maintstream in Squeak.

Shouldn't the responsibility of putting Tweak into mainstream Squeak be the responsibility of the mainstream Squeak development team if that's what they want?

Chris, I think that you have a funny way to looking at us. If tweak guys do not want to participate why should we do that?

The question wasn't about participation but about responsibility.

I always said that I would like to help pushing Tweak (ie removing MVC....) but so far nothing.

Right. Because nobody from the Squeak community took on that task, yet, so there's nobody you could have "helped". Also, there was no "decision" yet that Tweak actually should replace Morphic. There are many cool features in Tweak, I personally like its ideas a lot, but there are also people who dislike it for various reasons. The first step would be that more people from the community actually try to do something serious in Tweak. Only then could you estimate if it is actually worth-while to switch to Tweak as the default UI.

Also, mind you, it took Morphic quite some time until it became the default UI. Several people worked full-time on it. That's also a reason why the "Tweak developers" don't take on such a task lightly.

...

...

Without commitment of the lead developpers of Tweak to get it in Squeak, it is useless to send such patch and enhancement.

What makes you say that? I see no correlation..

I let you guess. Read the mailing-lists and you will see.

Lighten up you french guys, you're gonna win the soccer world cup, right? ;-)

Seriously, if someone came up with the idea to switch to Qt (just to name some UI), would you expect the Qt developers to lead that effort?

- Bert -

On 6 juil. 06, at 17:23, Hilaire Fernandes wrote:

Bert Freudenberg a écrit :

...

Right. Because nobody from the Squeak community took on that task, yet, so there's nobody you could have "helped". Also, there was no "decision" yet that Tweak actually should replace Morphic. There are many cool features in Tweak, I personally like its ideas a lot, but there are also people who dislike it for various reasons. The first step would be that more people from the community actually try to do something serious in Tweak. Only then could you estimate if it is

People will not do serious things with Tweak as long as they do not have a middle term visibility about Tweak. Like it or not, this is how it work. An expression of interest from the Tweak developper to get Tweak mainstream in Squeak could of course change that. But it seems, as I learn it recently from other email of the thread, that it is not the case.

+1

...

actually worth-while to switch to Tweak as the default UI. Also, mind you, it took Morphic quite some time until it became the default UI. Several people worked full-time on it. That's also a reason why the "Tweak developers" don't take on such a task lightly.

It is understandable as resource is now tight. However it is not an excuse to not communicate, which seems to be the problem now.

+1

Tweak is developped with Squeak for Squeak, its integration mainstream in Squeak can only be done in collaboration with the Tweak developper. Steph suggested me a few days ago, to play with Tweak as a base for further development. I look at the tutorial, it was nice, I love many of the developer features comming with Tweak. Tweak introduced new paradigm as the annotation. This new features are changes to the core Squeak, IMHO to integrate thus core modifcation in Squeak a close collaboration is needed between the Tweak developer and the Squeak integrator. Without communication between both it is even not a good idea to try to do so, remember resources is tight for every one.

...

Lighten up you french guys, you're gonna win the soccer world cup, right? ;-) Seriously, if someone came up with the idea to switch to Qt (just to name some UI), would you expect the Qt developers to lead that effort?

Hum, I may say your are mixing two different problems.

One is integrating a framework written in Squeak into Squeak, were collaboration is needed between the framework and Squeak developers.

The second one is writting a Qt binding for Squeak, which is indeed abolutely not the problem of the Qt developers.

In the first one, you have to integrate in Squeak additionnal Squeak code, which can cause trouble. For example the framework did some needed modification in the core Squeak, and thus modification may need to be adjusted both in the framework and the core Squeak. In that case communication and collaboration between the Squeak and framework developpers is mandatory.

In the second case, writting a Qt binding. It is unlikely, no it is impossible, you will need to change the Qt library to get working binding. More likely collaboration with the VM developper will be needed.

See you in Berlin ;-)

Hilaire

Andreas Raab a écrit :

...

People will not do serious things with Tweak as long as they do not have a middle term visibility about Tweak. Like it or not, this is how it work. An expression of interest from the Tweak developper to get Tweak mainstream in Squeak could of course change that. But it seems, as I learn it recently from other email of the thread, that it is not the case.

Which email are you referring to?

For the history:

Here I reported I read on tweak.impara.de that Teak will replace Morph and Etoys, and wonder if it is still the objective http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-July/105646.html

Then Cees recalled me it may not that simple: http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-July/105653.html

Then Steph reported me he offered assistance to help integrate Tweak in Squeak.org, but did not get result on the offer.

I recall I am an outsider so I may have uncomplete picture. If so it will be fine the enlight me.

...

Tweak is developped with Squeak for Squeak, its integration mainstream in Squeak can only be done in collaboration with the Tweak developper. Steph suggested me a few days ago, to play with Tweak as a base for further development. I look at the tutorial, it was nice, I love many of the developer features comming with Tweak. Tweak introduced new paradigm as the annotation. This new features are changes to the core Squeak, IMHO to integrate thus core modifcation in Squeak a close collaboration is needed between the Tweak developer and the Squeak integrator. Without communication between both it is even not a good idea to try to do so, remember resources is tight for every one.

Right. I agree. So what kind of communication do you expect and where have we failed to provide an appropriate level of communication?

So what kind of communication do you expect

communication at the metalevel to get Tweak in Squeak.org

After 3.9, Squeak.org could enter in development cycle with the sole and unique objective to just get Tweak into Squeak.org. So roughtly, we can say next Squeak.org will just be Squeak.org3.9 + Tweak. No morphic removal or any other stuff, just to get Tweak in.

The benefice will be quadruple: - Tweak developer mays get more feedback from users - Squeak developers working on the browser and other Squeak IDE development tools could start working on Tweak version of these tools - People willing to develop Squeak application may fell more confortable to develop their next application with Tweak (I will) - Tweak developers will not have to maintain a separate Squeak version anymore.

It will be definitively a win-win situation.

You may say this is already possible today with your distribution of Tweak, but like it or not, it is not mainstream so not every one buy it (I am not because of the lack of visibility).

Then later step by step Morph could be removed, if not relicensable. Just a smooth process for the benefice of everyone.

Hilaire

Hilaire Fernandes wrote:

...

It will be definitively a win-win situation.

You may say this is already possible today with your distribution of Tweak, but like it or not, it is not mainstream so not every one buy it (I am not because of the lack of visibility).

I wish it were that simple (nice marketing job btw; if this were the first time I've seen this happening I'd probably buy the whole story line, hook, and sinker ;-)

Unfortunately, all technologies go through phases and Tweak is still in an "early adopters" phase. What that means is that essentially those users who are scared by something not being mainstream are probably not the right users to have at this point. There are at least three areas (graphics, object model and messaging model) that require some drastic simplifications and cleanup before it could be considered easy enough for mainstream use. Even though various parts have settled down by now (mostly by actually being used in various projects - Sophie, Croquet, and TinLizzie have been great forcing functions in the various areas) there is plenty of work left, some of which I'd say is critical before considering Tweak ready for mainstream use.

...

Then later step by step Morph could be removed, if not relicensable. Just a smooth process for the benefice of everyone.

If you've experienced similar processes before, they are *never* smooth. Every last one of the larger technologies that got integrated into Squeak caused major hickups, major frustrations, and for every last one there have been serious attempts to avoid/retract them late in the game. Sometimes these technologies had years of real use behind them. I wouldn't expect it to be any different this time, and quite bluntly, I'm not sure I have the energy to deal with the frustrations.

So now I have a very direct question for you Andreas, are you interested by this plan?

[ ] YES [ ] NO

No answer means, NO of course.

"This plan" being to add Tweak to 3.9? Depends. For the "basic" image the answer is No. That's simply because I will not knowingly add to that 20MB whopper that is euphemistically called a "basic" image today. For a "full" version (which really just means that it'll be loadable via SqueakMap) that's something we can talk about. Which is not quite a yes, but thus far I haven't even looked at what it means to get Tweak into 3.9 and I am willing to re-evaluate this option.

Cheers, - Andreas

On 7/7/06, Hilaire Fernandes hilaire@ext.cri74.org wrote:

Please do not try to turn it the other way. I am explaining a bit of how things can work in free software community development, it has nothing to do with marketing.

Err... that no money is transferred does not mean that marketing is out of the door... Marketing is *extremely* important in free software.

The problem is the lack of visibility about Tweak developer interested or not to get it mainstream in Squeak.org. One way to to get it visible is to hook it to Squeak.org, which is not the case right now.

Whos problem is that? Certainly not Andreas' problem, but it seems you're trying to make it his problem...

Hi Hilaire.

Its taken us quite a while, but one of the things I like to think we've learned as a community is that the right way to handle big changes is to start early, but have multiple stages. Andreas mentioned the idea of making Tweak into a package loadable into squeak-dev. This implies a whole lot of work, in fact in the past this stage has usually been something like half the work required for the integration of projects, so I wouldn't trivialize the proposal. It is good for the community because it allows people to try it out more easily. I think this is a better proposal than committing lots of people that have never seen Tweak into a "Squeak 3.10 is Tweak" plan.

Part of the process of making Tweak loadable would include identifying its prerequisites explicitly, and giving them, also, proper review and usage, a stage that would probably be at best rushed in an "all at once" plan.

Daniel

Hilaire Fernandes wrote:

...

"full" version (which really just means that it'll be loadable via SqueakMap) that's something we can talk about. Which is not quite a yes, but thus far I haven't even looked at what it means to get Tweak into 3.9 and I am willing to re-evaluate this option.

No Andreas, we cannot play that YES-NO game. We don't have time to waste resource on that sort of no answer position.

Best regards,

Hilaire

Am 07.07.2006 um 12:01 schrieb Hilaire Fernandes:

Hello Daniel,

Daniel Vainsencher a écrit :

...

Hi Hilaire. Its taken us quite a while, but one of the things I like to think we've learned as a community is that the right way to handle big changes is to start early, but have multiple stages. Andreas mentioned the idea of making Tweak into a package loadable into squeak-dev. This implies a whole lot of work, in fact in the past this stage has usually been something like half the work required for the integration of projects, so I wouldn't trivialize the proposal. It is good for the community because it allows people to try it out more easily. I think this is a better proposal than committing lots of people that have never seen Tweak into a "Squeak 3.10 is Tweak" plan.

Sorry we can't buy it:

-Getting Tweak in Squeak.org3.9 or -Getting Tweak in SqueakMap so it is loadable in Squeak.org3.9

is as far as I can see 99.99% of the same process.

Actually, no. The first is a political decision (of huge impact), the second a technical issue (and not a small one either).

IMHO, your insistence on getting Tweak into 3.9 is a red herring - Tweak is bootstrappable in a regular 3.8 image. If you actually wanted to get a feel for what is involved in getting Tweak up and running you could try that.

- Bert -

Am 07.07.2006 um 14:58 schrieb Hilaire Fernandes:

Bert Freudenberg a écrit :

...

Am 07.07.2006 um 12:01 schrieb Hilaire Fernandes:

...

-Getting Tweak in Squeak.org3.9 or -Getting Tweak in SqueakMap so it is loadable in Squeak.org3.9

is as far as I can see 99.99% of the same process.

Actually, no. The first is a political decision (of huge impact), the second a technical issue (and not a small one either).

Ok, so according to you there are no polical desire to get Tweak in Squeak.org.

Hilaire, it would be nice if you read what I write. I never said or implied that.

This is indeed really what a lot of us were felling.

I hope not.

I will stop replying to this thread as I think we already have all the element to evaluate the sitatuation regarding Tweak in Squeak.org.

Oh sure, you're free to do that. But it would be only fair if you do not base your "evaluation" on misrepresenting what others write.

Like, if you actually read what Andreas wrote, he offered to evaluate how much work it would be to port Tweak to 3.9. Guess who is going to have to do the hard work? Besides, I would very much prefer a discussion without threats and accusations.

- Bert -

On 7-Jul-06, at 6:48 AM, Bert Freudenberg wrote:

[snip]

Hilaire, it would be nice if you read what I write. I never said or implied that.

It certainly would; putting words into other people's mouths is neither polite nor hygenic. [snip]

Like, if you actually read what Andreas wrote, he offered to evaluate how much work it would be to port Tweak to 3.9. Guess who is going to have to do the hard work? Besides, I would very much prefer a discussion without threats and accusations.

Exactly. Demanding that other people do large amounts of work is rarely a good way of proceeding.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Do files get embarrassed when they get unzipped?

Lex Spoon wrote:

Hilaire is only asking what the status and expectations about a usable Tweak are. It took a lot of asking, and apparently the answer is that you have to go back and convert a 3.8 image to a Tweak one. This is different from Morphic, where Morphic was initially available in Squeak right beside MVC.

But what is your point, exactly? That Tweak is to blame for changes in 3.9 that render 3.9 incompatible with 3.8 to such an extent that Tweak doesn't work out of the box? Contrary to which other 3.8 based environments (iSqueak, Croquet, TinLizzie) run Tweak just fine.

And for the records, the reason why Morphic was initially available in Squeak right beside MVC was because the people who worked on it (SqC) had control over BOTH. Unfortunately, the same cannot be said about Tweak and 3.9 so unless your point is that you're screwed when you don't have control over parts that you depend on (to which I wholeheartedly agree), then I don't get the point you're trying to make.

Cheers, - Andreas

stéphane ducasse wrote:

No problem we are the bad guys to blame....

Stef (the random refactorer)

Honestly, Stef, if it isn't random then what is the strategy for these changes? Looking at the past Squeak versions, starting from 3.6 every version was just incompatible enough with previous versions such that it would break any serious user of the metaclass hierarchy (like Tweak). I think you will agree that it can't continue that way, that at some point we need to get back to what can be called a *stable* metaclass kernel with reliable APIs and when exactly will that point be reached?

Cheers, - Andreas

...

Lex Spoon wrote:

...

Hilaire is only asking what the status and expectations about a usable Tweak are. It took a lot of asking, and apparently the answer is that you have to go back and convert a 3.8 image to a Tweak one. This is different from Morphic, where Morphic was initially available in Squeak right beside MVC.

But what is your point, exactly? That Tweak is to blame for changes in 3.9 that render 3.9 incompatible with 3.8 to such an extent that Tweak doesn't work out of the box? Contrary to which other 3.8 based environments (iSqueak, Croquet, TinLizzie) run Tweak just fine.

And for the records, the reason why Morphic was initially available in Squeak right beside MVC was because the people who worked on it (SqC) had control over BOTH. Unfortunately, the same cannot be said about Tweak and 3.9 so unless your point is that you're screwed when you don't have control over parts that you depend on (to which I wholeheartedly agree), then I don't get the point you're trying to make.

Cheers,

• Andreas

Honestly, Stef, if it isn't random then what is the strategy for these changes? Looking at the past Squeak versions, starting from 3.6 every version was just incompatible enough with previous versions such that it would break any serious user of the metaclass hierarchy (like Tweak). I think you will agree that it can't continue that way, that at some point we need to get back to what can be called a *stable* metaclass kernel with reliable APIs and when exactly will that point be reached?

To improve software, it is required to break backward compatibility. Nobody is forcing you to move to a new version.

If updates to the base-framework don't enhance anything in the development process of your software, it is unnecessary to update. If I were you, I would stick with 3.6. Still waters run deep.

I have some legacy Seaside applications in ancient 3.6 images that run just fine. They rarely change. They simply run fine. I won't port them to 3.9 and a recent version of Seaside. These applications don't require anything more as it is available in 3.6. However, for new applications I take 3.9, I love Shout/eCompletion/OmniBrowser/Traits/Pragmas/ToolBuilder/... I like to keep up-to-date as long as it improves my productivity.

Lukas

On Jul 10, 2006, at 4:22 PM, Julian Fitzell wrote:

I'm not saying don't break compatibility, I'm just saying be aware every time that you are doing it. And the thought that there be a relatively stable API for a core set of classes that doesn't change without some forethought is perfectly reasonable, in my opinion. At least then, when compatibility is broken, detailed instructions could be provided on how to update your software in each case.

Here, here. I'll add an example of the kind of incompatibility that I, at least, am frustrated by.

I try to keep OmniBrowser compatible with Squeak 3.6 and later. Prior to 3.9, you can fetch a menu icon for delete operations by sending #deleteIcon to the class MenuIcons. In 3.9 you have to send #smallDeleteIcon. As far as I can tell, the change is completely gratuitous. The icon is small, yes, but there's no corresponding #largeDeleteIcon. #deleteIcon was just removed, it wasn't changed to call through to #smallDeleteIcon or even deprecated.

Apparently, I have to jump through some hoops to make menus work in Squeak 3.9 because somebody wanted to make the selectors more consistent. I'm all for progress, but this kind of thing is just irritating.

Colin

On Jul 10, 2006, at 7:06 PM, Wolfgang Eder wrote:

Hi, this example demonstrates the main reason why I think the "full" image is so important: If, at the point of this refactoring (or renaming, whatever), the author had your OmniBrowser loaded, it would have been no big deal to just make the required changes. Using the RB, you get most of these changes *for free*.

Actually, I suspect that this is exactly what was done. OmniBrowser is part of the Full 3.9 image, and it appears to have been refactored along with everything else in the full image. The break in compatibility is still a problem, though, for two reasons:

First, that refactored version of OmniBrowser only works in Squeak 3.9. It doesn't work in Squeak 3.6, 3.7 or 3.8. If all I cared about was compatibility with the latest release of Squeak, I wouldn't be complaining in the first place.

Second, it's just not feasible to have all the code in the Squeak world loaded into a single image. You can get a lot, I'm sure, but some packages conflict with other packages. If you rely on refactoring to mitigate API changes, you're going to break anything that isn't in your image when you make the change.

It's so much less work this way, compared to trying to find out what has changed, exactly, between newer versions.

I love refactoring. But it's not a solution to this problem.

Colin

Hi Stef,

on Tue, 11 Jul 2006 08:35:44 +0200, you wrote:

I think that having first class interface or tools to understand what is happening at the interface level is important.

And I think that interface is only a word instead of a discipline. For a Smalltalker any Smalltalk interface is highly dynamic but she can only master (achieve, use, etc) it by carfully coding her needs resp. obeying the other side's requirements (on and on, from release to release, as Andreas illustrated recently). Encapsulation etc does not help much when dealing with interfaces...

Is anybody out there considering interfaces as first class objects, for example negotiable where both sides can ask for and offer capabilities *before* they are used?

/Klaus

Stef

Hi Stef,

on Tue, 11 Jul 2006 14:27:24 +0200, you wrote:

I know I was thinking something in the vein of dynamic interfaces of Benny Sadeh (JOT) to check changes /dynamic changes.

Yes, JOT is a good approach but, because its J-mimicry suffers from the possibility to use reflection for offering (and for negotiating) an interface (sorry Mr. co-author ;-) What I have in mind is a single method on the class side which answers the *offered* interface in form of an intelligent object which is modeled analogue to Teachable, see draft at the bottom.

Hence I was interested in the application of Goya.

Here we go: tell me two system categories or two non-overlapping subsets of classes and, if the interface is covered somehow by TestCase(s), using Goya I can tell you who does what (re. my informal pres. in Bern).

/Klaus

=========draft==================

!MyObject class methodsFor: 'interface-negotiation'! interface | negotiable | " offer getter+setter for value named #attribute " negotiable := NegotiableInterface on: self " <= self is MyObject, a behavior ". negotiable offer: #attribute initialValue: nil. negotiable offer: #attribute: subDomain: Collection. ^ negotiable!!

...use...

interfaceOnMyObject := MyObject interface " <= this is analogue to #new but returns an interface instead of an instance ". self assert: (interfaceOnMyObject offers: #attribute forMeAs: #getter) description: 'bad interface' self assert: (interfaceOnMyObject offers: #attribute: forMeAs: #setter:) description: 'not allowed to change this value' " imagine the use of blocks for queries "

...etc

Hi!

Avi Bryant avi.bryant@gmail.com wrote:

On Jul 10, 2006, at 12:42 PM, Lukas Renggli wrote:

...

To improve software, it is required to break backward compatibility. Nobody is forcing you to move to a new version.

True. Though if few enough people are moving to new versions as they come out, it's not a very good sign.

Indeed, indeed. As I often say "remember the 3.3 branch". Noone moved in, because it was an uncomfortable image to move into, and thus it died (at least that was an important part).

Just as a data point: everything we do at Smallthought is based on a stripped 3.7 image. Every few months I download a 3.9 image and play with it for about 15 minutes, but the reality is that what happens in 3.9 simply doesn't affect us. If we're an exceptional case, it's probably not a big deal, but if it turns out that lots of others are doing the same thing, it would be worrying.

Avi

As a datapoint I work in 3.8. I will try to move to 3.9 when it seems fruititious - but I probably will not work in it until Seaside, Magma and a few other important pieces are stabilized in it.

My first job in that department would be to give KomHttpServer a 3.9 overhaul of course.

regards, Göran

"Philippe Marschall" philippe.marschall@gmail.com wrote:

...

As a datapoint I work in 3.8. I will try to move to 3.9 when it seems fruititious - but I probably will not work in it until Seaside, Magma and a few other important pieces are stabilized in it.

My first job in that department would be to give KomHttpServer a 3.9 overhaul of course.

Seaside and Kom work quite nicely in 3.9 today :)

Oh, good! :)

Philippe

regards, Göran

Thanks mike. We need to improve and build tools to help us controling changes. I can tell you that merging fixes of parts you believe you know is difficult so when you do not known this is terrible. Especially since I care not damaging the system.

Stef

On 11 juil. 06, at 09:19, Michael Rueger wrote:

...

...

True. Though if few enough people are moving to new versions as they come out, it's not a very good sign.

That is true, but also depends on what "coming out" means. We usually don't consider moving to a new version until the final release is out. I, for my part, am more than willing to go through some major efforts to port stuff to a new version, once it's out. But, and that is the same in other systems as well, if you have a running system in maintenance mode, you don't port it anyways. Fortran IV anyone?

Regarding backward compatibility: many moons ago I had to port a system with about 100 packages to a new ObjectWorks version and used the backward compatibility packages to make my life easier. So I thought. I would have saved a lot time and effort and gained a much more robust system if I hadn't done it.

New major Squeak versions come out about once a year, the last two gave us m17n and now traits. I think it is well worth the change in APIs.

And if the people doing the harvesting work made mistakes in refactoring, who is the flawless developer who is going to throw the first stone?

But then, I'm just the engineer...

Michael

As a datapoint I work in 3.8. I will try to move to 3.9 when it seems fruititious - but I probably will not work in it until Seaside, Magma and a few other important pieces are stabilized in it.

As a datapoint Magma will be ported to 3.9, but I have not had time to even look at that yet.

- Chris

Andreas Raab wrote:

Lukas Renggli wrote:

...

To improve software, it is required to break backward compatibility. Nobody is forcing you to move to a new version.

For starters, let's get our basic assumptions right: This discussion isn't about people who do *not* want to move to new versions. It's about people who *do* want and what expectations they can have. Otherwise I'd agree with your statement.

...

If updates to the base-framework don't enhance anything in the development process of your software, it is unnecessary to update. If I were you, I would stick with 3.6. Still waters run deep.

Well, if you were me, you would *want* to update. But you would have noticed that things got so inconsistently broken at the metaclass level that unless there are major pay-offs, it simply isn't worth the effort. That's what happened from 3.6 to 3.7. In 3.8 there was a major payoff - the m17n integration. That's why I then spent the time needed. For 3.9, from a Tweak POV there isn't that much interesting in there, so rather than going through the painful porting exercise yet again I'll probably spend my time on bootstrapping a stable (3.8-based) metaclass kernel which can be used in parallel to the 3.9 kernel. Which is not particularly nice but in the absence of any inclination towards stable APIs the only alternative that I can see.

...

I have some legacy Seaside applications in ancient 3.6 images that run just fine. They rarely change. They simply run fine. I won't port them to 3.9 and a recent version of Seaside. These applications don't require anything more as it is available in 3.6. However, for new applications I take 3.9, I love Shout/eCompletion/OmniBrowser/Traits/Pragmas/ToolBuilder/... I like to keep up-to-date as long as it improves my productivity.

You're totally missing my point. Let's take one example from your list: ToolBuilder. Let's say you've got some work that uses it, would you really expect that in each new Squeak version you have to spend major effort to port your code to the latest ToolBuilder version? Or wouldn't you rather expect that there is a stable API that can be used and that may be extended over time, or even broken, but if it's broken that you may get some notice about it beforehand? Or, in particular when the changes get really fundamental, that instead of modifying ToolBuilder in-place you get the offer to use either ToolBuilder (working the way it always did) and whatever the brand-new framework of the day is?

I'm curious but is my position in this discussion really so outrageous?

it sounds right to me. I would want to update to the newest just for bug fixes alone. And, I wouldn't want any surprises. If something is broken, it should be easy to state that somewhere so people can have a look before upgrading.

brad

Andreas Raab wrote:

You're totally missing my point. Let's take one example from your list: ToolBuilder. Let's say you've got some work that uses it, would you really expect that in each new Squeak version you have to spend major effort to port your code to the latest ToolBuilder version? Or wouldn't you rather expect that there is a stable API that can be used and that may be extended over time, or even broken, but if it's broken that you may get some notice about it beforehand? Or, in particular when the changes get really fundamental, that instead of modifying ToolBuilder in-place you get the offer to use either ToolBuilder (working the way it always did) and whatever the brand-new framework of the day is?

I'm curious but is my position in this discussion really so outrageous?

not for me I'm primarily a python developer which looks at squeak as a wonderful platform where implement multimedia apps for children. Unfortunately, it's difficult for me to understand what's new in each release and where will go the development from there... No (or minor) release docs, no code that comes from enhancements proposals (like PEPs) and that's discussed before actual inclusion in the release. And with each release you get the 90% of probability that if you try to filein a package or code developed for the release before the one you are running it will not run at all. Python has it's own big problems too (the code and naming style of its standard lib changes from module to module and big parts of that library are function oriented rather than object oriented), but it cares backward compatibility a lot... Important enhancements that will be enabled by default in the next stable version are available in the actual release by importing them from a special "future" module as old features considered "deprecated" are available in a number of releases since then. I consider the fact that squeak is always a "moving target" from an API POV one of its major drawbacks and one of the reasons why there is so little documentation about them, a fact that which i think keeps possible developers interested in squeak away from it.

my two cents,

Alberto

Hi Stef -

I'm actually way beyond where I want to discuss these issues. I've been trying to leave that stuff behind but when a message like Lex' comes in where it basically says that it's my fault that Tweak doesn't work in 3.9 (as if it were by my choice) it just annoys me to no end.

The question I was raising, however, was and is serious: What, if any, is the plan for the metaclass kernel? Are there, for example, any plans for major traits refactoring? If so, it'd be nice if a little bit of a strategy could be layed out so that, for example, I can plan accordingly.

Cheers, - Andreas

stéphane ducasse wrote:

Hi andreas

I will not state any related to our totally illness to do random refactorings but can you tell me what is so deeply broken in the metaclass kernel? I'm so idiot that I cannot even know it.

Stef

On 11 juil. 06, at 00:56, Andreas Raab wrote:

...

Lukas Renggli wrote:

...

To improve software, it is required to break backward compatibility. Nobody is forcing you to move to a new version.

For starters, let's get our basic assumptions right: This discussion isn't about people who do *not* want to move to new versions. It's about people who *do* want and what expectations they can have. Otherwise I'd agree with your statement.

...

If updates to the base-framework don't enhance anything in the development process of your software, it is unnecessary to update. If I were you, I would stick with 3.6. Still waters run deep.

Well, if you were me, you would *want* to update. But you would have noticed that things got so inconsistently broken at the metaclass level that unless there are major pay-offs, it simply isn't worth the effort. That's what happened from 3.6 to 3.7. In 3.8 there was a major payoff - the m17n integration. That's why I then spent the time needed. For 3.9, from a Tweak POV there isn't that much interesting in there, so rather than going through the painful porting exercise yet again I'll probably spend my time on bootstrapping a stable (3.8-based) metaclass kernel which can be used in parallel to the 3.9 kernel. Which is not particularly nice but in the absence of any inclination towards stable APIs the only alternative that I can see.

...

I have some legacy Seaside applications in ancient 3.6 images that run just fine. They rarely change. They simply run fine. I won't port them to 3.9 and a recent version of Seaside. These applications don't require anything more as it is available in 3.6. However, for new applications I take 3.9, I love Shout/eCompletion/OmniBrowser/Traits/Pragmas/ToolBuilder/... I like to keep up-to-date as long as it improves my productivity.

You're totally missing my point. Let's take one example from your list: ToolBuilder. Let's say you've got some work that uses it, would you really expect that in each new Squeak version you have to spend major effort to port your code to the latest ToolBuilder version? Or wouldn't you rather expect that there is a stable API that can be used and that may be extended over time, or even broken, but if it's broken that you may get some notice about it beforehand? Or, in particular when the changes get really fundamental, that instead of modifying ToolBuilder in-place you get the offer to use either ToolBuilder (working the way it always did) and whatever the brand-new framework of the day is?

I'm curious but is my position in this discussion really so outrageous?

Cheers,

• Andreas

Andreas Raab a écrit :

You're totally missing my point. Let's take one example from your list: ToolBuilder. Let's say you've got some work that uses it, would you really expect that in each new Squeak version you have to spend major effort to port your code to the latest ToolBuilder version? Or wouldn't you rather expect that there is a stable API that can be used and that may be extended over time, or even broken, but if it's broken that you may get some notice about it beforehand? Or, in particular when the changes get really fundamental, that instead of modifying ToolBuilder in-place you get the offer to use either ToolBuilder (working the way it always did) and whatever the brand-new framework of the day is?

I'm curious but is my position in this discussion really so outrageous?

No, you get a very good point. API change is the nightmare of software developer. You just fell frustrated to spend time to re-write already done things. I remember experiencing such frustration with pre-2.0 Gnome libraries. We may want to have cycle of stable API version of Squeak, inlcuded in the road-map.

Hilaire

On Tue, 11 Jul 2006 00:56:21 +0200, Andreas Raab wrote: ...

But you would have noticed that things got so inconsistently broken at the metaclass level that unless there are major pay-offs, it simply isn't worth the effort. That's what happened from 3.6 to 3.7. In 3.8 there was a major payoff - the m17n integration. That's why I then spent the time needed. For 3.9, from a Tweak POV there isn't that much interesting in there, so rather than going through the painful porting exercise yet again I'll probably spend my time on bootstrapping a stable (3.8-based) metaclass kernel which can be used in parallel to the 3.9 kernel. Which is not particularly nice but in the absence of any inclination towards stable APIs the only alternative that I can see.

I'm trying to understand the issue, broken at the metaclass level, and downloaded (and updated </phew>) Tweak3.8-6665 and begun browsing the code. Mind to give a handful of directions what to look for to find things broken at the metaclass level, thank you in advance.

Also, does "broken at the metaclass level" rather belong to the structural phenomena species or is it perhaps possible to specify an interface which makes your code, without changing anything except perhaps use of #new, adaptable to the various versions of metaclass level. I'm willing and able to write such an interface, and Tweak for me would be a large enough system for pulling out of the "proof of concept" corner a new kind of interface.

And, btw, is there ANYTHING (google was of no help) which documents what you've done to the compiler, for example a new syntax diagram and/or a COMPLETE list with "what is for what"?

I'm curious but is my position in this discussion really so outrageous?

Not at all :) It's all request-and-response and if Hilaire would have known the answers in advance then nobody else would have learned anything.

/Klaus

Cheers,

• Andreas

Kewl, very kewl. Thanks for taking the time.

/Klaus

On Thu, 13 Jul 2006 10:39:37 +0200, Andreas Raab wrote:

Klaus D. Witzel wrote:

...

And, btw, is there ANYTHING (google was of no help) which documents what you've done to the compiler, for example a new syntax diagram and/or a COMPLETE list with "what is for what"?

No there isn't, but fortunately it's not much ;-) Here you go:

a) Method Triggers: These are annotations which bind events to methods. Three forms exist:

<on: eventName> <on: eventName in: signaler> <ticking: frequency>

The first two bind specific events (potentially signaled in a field of the receiver) the latter binds the ticking event to a frequency.

b) "Remote" assignments: Simply a transformation of assignment to message form that allows you to write stuff like: foo color := Color white.

which gets translated into

foo color: Color white.

I like this a lot because it allows us to be precise about whether we think of changing an attribute or requesting a service.

c) Positional arguments: This is only used in Croquet right now and allows you to call methods with foo(a, b, c) syntax, e.g.,

opengl glVertex3f(0.0, 0.0, 0.0)

Very, very useful if you want to integrate an existing API.

Cheers,

• Andreas

Andreas Raab andreas.raab@gmx.de writes:

Lex Spoon wrote:

...

This is different from Morphic, where Morphic was initially available in Squeak right beside MVC.

But what is your point, exactly?

[...]

And for the records, the reason why Morphic was initially available in Squeak right beside MVC was because the people who worked on it (SqC) had control over BOTH.

I had no point. There are more people involved in Squeak now, and there is more going on, and so things are just more complicated now.

Distributions would help with this problem. I did a distribution for Squeak 3.7 [1], and I think the basic techniques would work fine for a 3.8-based distribution. A distributions approach would mean that the primary development groups only need to *generally* cooperate; distribution maintainers would then do all the little details needed to make all this different software coexist.

-Lex

[1] http://minnow.cc.gatech.edu/squeak/3835

Am 10.07.2006 um 13:32 schrieb Klaus D. Witzel:

On Mon, 10 Jul 2006 10:05:48 +0200, Lex Spoon lex@cc.gatech.edu wrote:

...

Hilaire is only asking what the status and expectations about a usable Tweak are.

Thank you Lex, that was overdue! All that Hilaire wants is confidence on which GUI will be available for the next to come project and/or customer. Not a bad question to ask a community.

Agreed, but it's not one with a simple yes/no answer like Hilaire demanded, either.

A very simplistic answer would be - yes, sure it will be available, because it is available now, it's MIT licensed, you can take the code and do anything with it that you like.

Is that a satisfying answer? I don't think so, but that's all you gonna get if you demand simple answers.

- Bert -

Hilaire

here is what I suggest the community (or the interested people could do).

- play with Tweak and report problems (now of course you can decide that you do not have the time and that the visibility is not there to do it) - try to load Tweak on 3.9 and report problems - take the latest 3.9 and report sucess of unloading/reloading package - help to migrate some of the tools to ToolBuilder (BTW roel shows me an excellent browser he is building)

Andreas I want to spend some time shrinking the image because right now this is not minimal that we have and I agree with you for the size.

Andreas Raab wrote: ....

"This plan" being to add Tweak to 3.9? Depends. For the "basic" image the answer is No. That's simply because I will not knowingly add to that 20MB whopper that is euphemistically called a "basic" image today. For a "full" version (which really just means that it'll be loadable via SqueakMap) that's something we can talk about. Which is not quite a yes, but thus far I haven't even looked at what it means to get Tweak into 3.9 and I am willing to re-evaluate this option.

Hi Andreas,

I think there are people who are interested in a system with Tweak that is useable as an universal basis for:

- a personal desktop system. - deploying a desktop application. That implies that special hardware should not be needed, that the resulting image is reasonably small and perhaps some flexibility in the UI look and feel. - server applications that are developed and run in an UI-image but can be shrunk down to a headless version if appropriate. - something else not covered directly by the above points but imaginable like e.g. a "browser-bootstrapped" application

Right now I guess there is some confusion or fear that you may target only the personal desktop system like you do e.g. with Croquet. Of course there is a road map at impara.de that looks promising, but I think a little more affirmation about the universality of the announced stand-alone Tweak and perhaps some updated temporal guidance would be helpful to get people really interested -as in- getting them starting a Tweak project.

Regards, Martin

Bert

I agree with you but this is not what I was implying. In the past certain people were not really giving the signal that they want participation from other people on their projects. So few people came to look at what they were doing.

Stef

If tweak guys do not want to participate why should we do that?

Well, I hope "do not want to" is not why; maybe they just "can't". Because whether Henrik would *want* to help integrate his font anti-aliasing is irrelevant. Our only choices were to reject the work or try to pull it in anyway without him (many thanks to Andrew Tween for looking at it). Its a tough situation but one I think we're better off accepting as a very real possibility. At least open-source stuff offers a remote chance of success..

And rejecting is a perfectly fair choice, "support" is a factor as much as any other in deciding to pull something into your project..

Regards, Chris

On Wed, Jun 28, 2006 at 09:57:20AM +0200, goran@krampe.se wrote:

Which brings us back to my post which (oddly I thought) went more or less totally uncommented:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-June/105229 .html

Was it too long to read? :)

No, it was a good and helpful post. IMHO, this comment from Tim is also worth reading in the interest of good old fashioned common sense:

http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-June/105363.html

I think that the last thing anyone here needs yet another opinion from yet another legally-uninformed person, so I won't try to comment on legal matters.

However, I would like to say that a great deal of progress can be made by focusing on *doing* the things that we *can* do to resolve the problem. For example, I personally would like to be able to send a letter or an email that clearly establishes that all Squeak code with the initials 'dtl' is hereby relicensed in whatever way the lawyers recommend. This will not solve the whole problem, but it will remove one small obstacle. If we all pitch in and remove as many obstacles as possible, the problem will get smaller, less scary, and ultimately easier to solve.

Dave

On Jun 26, 2006, at 6:18 AM, Hilaire Fernandes wrote:

Cees De Groot a écrit :

...

On 6/26/06, Pavel Krivanek squeak1@continentalbrno.cz wrote:

...

You don't expect that's possible to take bootstrapped 3.9 kernel image (http://www.squeaksource.com/KernelImage.html) and make it clean from the licensing perspective? I don't think that it's more complicated than Spoon checking.

Well, Spoon's kernel image is so small, you can see all of it running at once :). But I don't see either project precluding the other, in fact. How small is that 3.9 image, code wise?

One of the proposal (from Tim) -- to check with the laywer I guess -- was to relicensed all the SqL code under APLS2.0. If possible, it will not be that paintfull to migrate from 3.9 and it will get use a ready to use image. Of course it is not incompatible with the Spoon track.

I also proposed a semi automatic way to do that: any code copyright owner not willing to see his code relicensed to APSL2.0 should say so before a given dead line.

This sounds nice, but I'd like to have a lawyer OK it. Here's a hypothetical situation: if Disney doesn't speak up before the date, and they later decide that they don't want "their" code licensed under APSL2.0, would the argument that they missed the deadline stand up against their lawyers in court? Possibly, but not certainly; their lawyers are good at this stuff. If we're going to bother with this license change, we want to do it once, and to have absolutely no question about its legality.

Josh

Hilaire

Josh Gargus a écrit :

On Jun 26, 2006, at 6:18 AM, Hilaire Fernandes wrote:

...

Cees De Groot a écrit :

...

On 6/26/06, Pavel Krivanek squeak1@continentalbrno.cz wrote:

...

You don't expect that's possible to take bootstrapped 3.9 kernel image (http://www.squeaksource.com/KernelImage.html) and make it clean from the licensing perspective? I don't think that it's more complicated than Spoon checking.

Well, Spoon's kernel image is so small, you can see all of it running at once :). But I don't see either project precluding the other, in fact. How small is that 3.9 image, code wise?

One of the proposal (from Tim) -- to check with the laywer I guess -- was to relicensed all the SqL code under APLS2.0. If possible, it will not be that paintfull to migrate from 3.9 and it will get use a ready to use image. Of course it is not incompatible with the Spoon track.

I also proposed a semi automatic way to do that: any code copyright owner not willing to see his code relicensed to APSL2.0 should say so before a given dead line.

This sounds nice, but I'd like to have a lawyer OK it. Here's a hypothetical situation: if Disney doesn't speak up before the date, and they later decide that they don't want "their" code licensed under APSL2.0, would the argument that they missed the deadline stand up against their lawyers in court? Possibly, but not certainly; their

The main problem with post Squeak 1.1 code, is the code owned by Disney. This one for sure we don't want to keep it.

So we are back to the main idea of the Squeak migration meeting: to determine which classes need to be removed and rewritten.

A first step could be to determine which code is owned by Disney. But of course this will be only possible if people of that time speak up. But I am afraid the free software culture is something unknwown for this people. I am sorry to be rude, but personnaly for my own software development I really need Squeak to be part of the free software community.

So basicly, two options: - people help to dermine to identify Disney copyrighted owned code. We have a chance to do big clean up,

- people does not help to identify Disney copyrighted owned code. We go directly the Spoon way and just forget and delete about all the morph/etoys/etc. stuffs. Then we use other stuff as SqueakGTK+ effort to provide the UI. For sure, Squeak will be a much more developer/business Smalltalk system that way. It all depends on us.

Sound crazy right?

Hilaire

tim Rowledge a écrit :

For a long time now - I have no idea of the actual number of days/ months/years - the policy has been stated on SM that SqL is the only acceptable license for inclusion in base Squeak. Therefore I would claim that *every* bit of code submitted for a bugfix or base image extension is SqL since the author knows that it must be in order to be accepted.

As for Disney era code - well surely nobody thinks that Alan didn't thoroughly apprise Disney of the license conditions when negotiating the deal to work there? Likewise HP.

So I think it reasonable to claim that stuff in the base image is fairly safe. Further, if Apple have decided that some license is good enough for their purpose to replace the SqL then it seems that they consider this new license 'no less protective'.

It is understandable and the problem is not there. The problem is about relicensing SqL code owned by Disney.

Hilaire

On 26-Jun-06, at 11:29 AM, Cees De Groot wrote:

On 6/26/06, tim Rowledge tim@rowledge.org wrote:

...

Further, if Apple have decided that some license is good enough for their purpose to replace the SqL then it seems that they consider this new license 'no less protective'.

Sorry, but I can't go with you there.

[snip] Well, given all that you said (and accepting that it makes some sense), it's hard to imagine how we can do *anything* meaningful. Except a total restart from 1.1/Spoon and get everything imported after (onerous) paperwork from everyone that might plausibly be involved. Even then, what happens for the code from disney/hp/ interval/exobox/ibm/etc that was donated implicitly under SqL?

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IIB: Ignore Inquiry and Branch anyway

On 6/26/06, Cees De Groot cdegroot@gmail.com wrote:

On 6/26/06, Pavel Krivanek squeak1@continentalbrno.cz wrote:

...

You don't expect that's possible to take bootstrapped 3.9 kernel image (http://www.squeaksource.com/KernelImage.html) and make it clean from the licensing perspective? I don't think that it's more complicated than Spoon checking.

Well, Spoon's kernel image is so small, you can see all of it running at once :). But I don't see either project precluding the other, in fact.

How small is that 3.9 image, code wise?

471 class mirrors now, the original image contains 2096 classes. Version for Squeak 3.7 had 336 class mirrors. It needs still radical cleanup - above all there are many unnecessary methods.

-- Pavel

Ron Teitelbaum a écrit :

-1

It's more then PR.

I don't understand, can you elaborate?

Hilaire

Ron Teitelbaum

...

From: Cees De Groot Sent: Sunday, June 25, 2006 7:01 AM

On 6/24/06, Hilaire Fernandes hilaire@ext.cri74.org wrote:

...

Other people attending the meeting have shown absolutely *NO INTEREST* in the matter, it is sad :(

I don't know. It might also be an indicator that the licensing "issues" are largely just perceived, or deemed to be PR stuff, or whatever. But not a real actual stumbling block to actual Squeak practicioners.

To do it the formal way, will it not be better that such persons sign a paper where they declared to be the owner of clearly identified pieces of code and agree to release it under the XXX/YYY licence

Providing a model document will be the only needed things

The question is who should be the recipient of such documents. The Squeak Foundation seems to be out of sync (concern?) regarding the licence matter...

I do not know. In fact I'm not working on the license aspects, may be other members have more information than me.

I asked the foundation if we could get such a template but so far, I got no reaction.

Stef

Hilaire

stéphane ducasse a écrit :

...

The really first step that could be reused in any future is to develop a small application that let the user identify himself, and declare that all the code he sent to the mailing-list and that have been harvested is under MIT/BSD/Squeak-L.

Stef

On 14 juin 06, at 17:44, Hilaire Fernandes wrote:

...

While at the 14th International Smalltalk Conference 2006[1], I am proposing we set a meeting during all the week to establish a migration plan to get the next version of Squeak released under a licence compatible with the free software community (probably APSL2 in our case).

As a free software activist and developer, I always get political difficulty to promote Squeak because of its licence. For me it is already free but most of the free software community and my friend do not share this point of view. It is really a problem because most people get stuck to the licence problem and they can't discover all the great stuff coming with Squeak and Smalltalk.

Getting the next Squeak released under a free software licence, compatible with the free software community, will help us if we want our community to grow, and we all fell the potential for the growth is there. A bigger community will be a great benefice for all of us: more people writing great library frameworks, developers could get more support from the free software oriented corporations, a well known Squeak will open new business opportunity, educators will be more exposed to Squeak and they will produce more teaching materials. In fact we will just be able to take benefice of the great promotion machinery of the free software community. Anyway I am just repeating things you already know.

Back to the meeting idea. The only output of this meeting will be a migration plan, to establish wish bits need to be removed, rewritten, relicenced. It is more a meta-migration meeting than a migration meeting, but still it is a first step we need to work on. To establish a realistic migration plan, the helps of Squeak experts will be an absolute necessity. Great Squeakers as Marcus Denker, Stephane Ducasse, Adrian Leinhardt, Lukas Renggli, Mike Rueger (impara) will attend the International Smalltalk conference. We can take the opportunity of the physical presence of these experts to get great insights for a realistic migration plan.

I am proposing for 4 or 5 days meeting, taking place after the daily conferences. The meeting could last for two hours, 17:00-19:00.

As a matter of facts, which experts are ready to join such a meeting?

Hilaire

ADD R0,R1,R2,LSL #2

On 6/19/06, Craig Latta craig@netjam.org wrote:

...

I asked the foundation if we could get such a template but so far, I got no reaction.

    Yes you did, from Tim. It was also the weekend; perhaps it would be

reasonable to wait a bit longer before making accusations.

I haven't seen any mail on that subject - what's the Subject line?

Hi Stef--

The message of yours to which I was referring was 2B2901FA-76CB-4E71-A3EC-8DAC26B76AAB@iam.unibe.ch. The message of Tim's to which I was referring was 31F7AB2B-54C9-49AE-9466-F0E8DF7EFAE4@rowledge.org. Apparently you had a different message of yours in mind.

Regardless, from the above messages I assert that the board is discussing this issue. We have also scheduled live meetings via instant messaging, as you well know. I encourage you to bring up anything important to you at those meetings. If you think they should be held more often, you should say so. Carping about a lack of response from the board in public is simply unconstructive and rude.

Please, let's take this to private discussion.

thanks,

-C

Dear all,

May be we could refocus on the subject of the thread, then think about the details later.

So far only Marcus wrote he will participate to such a meeting. Graid said he would like but he cannot. I am curious to know what think the other.

Hilaire

Cees De Groot a écrit :

On 6/20/06, Hilaire Fernandes hilaire@ext.cri74.org wrote:

...

I am curious to know what think the other.

Whether such a meeting, without presence of legal council, would be effective, I don't know. It seems that the original proposal was eaten by gremlins, because I can't find it in my mailbox, so I might be drawing premature conclusions from the snippets that were quoted in various responses.

If you are interested by the issue, you check the archive, even if you cannot attend

Hilaire

tim Rowledge a écrit :

On 20-Jun-06, at 1:36 AM, Hilaire Fernandes wrote:

...

Dear all,

May be we could refocus on the subject of the thread, then think about the details later.

So far only Marcus wrote he will participate to such a meeting. Graid said he would like but he cannot. I am curious to know what think the other.

Sadly there's no chance I could join the meeting; time and money preclude it. To those that can make it I can only offer support from the sidelines along with the statement that any bit of code I've ever submitted can be considered to be under any license that is plausible for Squeak.

Tim you are pointing a very important point. After the announce of the change to APSL2.0 of Squeak1.1, we have to ask ourself which part of {Squeak3.8}{Squeak1.1} can be relicensed and probably much more important which part cannot be relicensed. The idea about a migration meeting is to determine as far as possible which parts are relicenceable and which parts are not. We need to draft a boundary between what we can keep and what we need to remove/rewrite/replace. And of course we have to considerer in one hand the VM part and in the other hand the Image part.

At the end, if we can just have a list of the packages and their license statute it will be very helpful to move Squeak toward a free software community compatible state :)

A friend of me, told me he is interested by Squeak, but he is not yet considering it because Squeak is not seen as free software by the free software community. In the other he's willing to help and to rewrite small part to help to move Squeak toward a free software community compatible state :)

For him, such a list of parts with needed care will be helpful. I guess other people may fell the same and join more easily in case we have a cleared road map toward freeness.

Hilaire

On 20-Jun-06, at 4:41 PM, tim Rowledge wrote:

[snip]blah-blah

I should add that there was no intent to blame Hilaire for any of the problem.

tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: Good grief

Hi Tim--

Five sizable companies I could name have had no problem with using Squeak under the baleful glare of the SqL.

For that micro-anecdote to be at all compelling, I think you'd better name them. :) In particular, I'd like to know which legal systems they were operating under.

-C

tim Rowledge a écrit :

On 20-Jun-06, at 12:25 PM, Hilaire Fernandes wrote:

...

Tim you are pointing a very important point. After the announce of the change to APSL2.0 of Squeak1.1, we have to ask ourself which part of {Squeak3.8}{Squeak1.1} can be relicensed and probably much more important which part cannot be relicensed.

I very much doubt that there are any parts that cannot be relicensed, if in fact it is even really neccesary. What would be wrong with taking the position that the original squeak license (which is quite adequately free in my opinion) has been rescinded and replaced by the APSL? I think that would be compatible with the SqL clause about

That would be great. If we can do that, well we have to do it and announce it publicy. Can we without the author agreement?

In case, we need to ask the auhors of each bits of Squeak, can we turn it the other way ? We propose that every code licenced under the SqL will be automaticaly relicenced by the community to the APSL2.0 the 31 of August 2006 (random date). If some authors do not agree with such relicensing, they will have to say so (and prove their are the code owner) before the 31 of August 2006, etc, etc.

relicensing so long as it is no less protective of Apple, since after all they have chosen this new license. Surely *any* code released under SqL can be declared as relicensed?

...

And of course we have to considerer in one hand the VM part and in the other hand the Image part.

I think we've pretty much always taken the approach that code offered for VM inclusion is SqL and that it becomes community property. I believe that anyone that offers a community some code for inclusion into a community project is implicity donating that code in its entirety. If they're not.. well they can just bugger off.

I truly can't understand this constant complaint about licensing. At one level it's a particularly obnoxious form of pseudo-intellectual

I agree with you but whatever we said the SqL has an (unjustified) non-free license label. In the other hand if we can distribute the whole Squeak under an acknowledged license by the free software community, then we can expect support from this community: which mean a lot of publicity around Squeak, more attracted developers and users and a growing community (given the Squeak quality it will not be difficult).

Several times it happens to several of us to get trouble to attend free software meeting to present Squeak. Of course we can conplain the organisators are blind, but it may be easier to see how we can evolove to by-pass these kinds of problems. Also we have this same kind of problem when distributing Squeak based software in free software distribution.

masturbation since most of the complainers are not even faintly qualified to offer real opinions and at another level it's pretty much completely irrelevant. These so-called 'free licenses' are legally untested, rarely take any consideration of differing national boundaries and legal systems and generally smack of smackhead barrackroom lawyering. Five sizable companies I could name have had no problem with using Squeak under the baleful glare of the SqL.

I agree, but I don't want the discussion to move there. My purpose was not to discuss about this aspect.

Hilaire

stéphane ducasse a écrit :

...

...

Tim you are pointing a very important point. After the announce of the change to APSL2.0 of Squeak1.1, we have to ask ourself which part of {Squeak3.8}{Squeak1.1} can be relicensed and probably much more important which part cannot be relicensed.

I very much doubt that there are any parts that cannot be relicensed, if in fact it is even really neccesary. What would be wrong with taking the position that the original squeak license (which is quite adequately free in my opinion) has been rescinded and replaced by the APSL? I think that would be compatible with the SqL clause about relicensing so long as it is no less protective of Apple, since after all they have chosen this new license. Surely *any* code released under SqL can be declared as relicensed?

you see tim this what I would like to know from the laywer we contacted ( do not remember his name).

Did you get any feedback from the laywer? How can we make progress regarding this proposal?

Hilaire