Cees-

You raise an interesting set of issues I have had to pause to think about. I do however want to generally keep the discussion more on the concept of a list charter because that could be of use to anyone doing a Squeak project (say, the next version of Celeste) rather than the issue of whether this particular project was worth doing. But the details of that charter don't seem to interest anyone yet. Hopefully it may serve as a starting point should the issue of mailing list charters arise again in the future.

=== clean rooms ===

IANAL, but I would think from what little I know of how "clean room" work is done (i.e. give an API and functional spec to someone who has never seen a related implementation) that probably no one seriously participating on the Squeak list could participate in a true "clean room" reimplementation of a Smalltalk system. Unlike using a C compiler, using Smalltalk as a developer generally entails using a browser and having access to system code -- so all Smalltalk developers are "contaminated" by possibly having seen system level implementation code.

However, I feel if a new Squeak-ish system is developed using a newer approach (prototype-ish?), and all contributions are continually scrutinized by asking questions like: * "is this new?", * "is this grossly infringing?", * "is this feature present in all Smalltalks?", * "is this feature from a well documented public reference document (like ANSI or the blue book or a published paper)?", or * "is this feature from a compatibly license Smalltalk (perhaps PocketSmalltalk or the public domain Smalltalk)?", then perhaps something interesting and with a clearer title might emerge. Hopefully, any questionable parts that somehow snuck in from carelessness or ignorance could at least be identified, and then replaced, reworked, or worked around. People have already added a lot to Squeak on top of the core. I'm also hoping they might again make similar contributions to a newer base, but with a clearer contribution license this time if they had not licensed it clearly previously.

=== papers ===

It's an interesting idea to get formal papers signed (although that may have been not meant seriously). However, the question is who to send them to? Me? What if I get hit by a bus or lose interest? Who keeps them? The community should not have a single point of failure. Perhaps the Squeak Foundation could keep them (where? can they get lost or burned?). And even then, what should the papers say? With the charter outlined, the record of the users contribution to the list is itself proof of the validity of the contribution (assuming there is only one way to subscribe to the list). Presumably a monthly FAQ would remind list participants of their rights and responsibilities. Note, this does assume the charter and the first click is legally binding, and I don't know if it would apply worldwide (I think it would in the US with the recent laws relating to click through licenses.) The paper approach sounds like it would be more certain worldwide though.

However, printing, signing, and mailing a document raises the barrier to participation so high that people might not be willing to try participating at all. The "click here if you agree to join the list and accept the charter" approach provides two easy choice points to control how a participant contributes. One click signs up the potential contributor (who is not really contributing anything yet, so there is no immediate cost or risk, and yet that click provides an immediate benefit of now getting an email stream of interest). A second click by the contributor in an email program later on brings the previously agreed on charter into play by making a "gift" of a license to the community of some aspects of the person's copyright rights in the emailed item. People could always send mail privately or to another list to avoid making contributions covered under the list's charter. I'm assuming here anyone can read the list archives or use them under the license, so there is no other incentive to sign than to contribute code or otherwise participate in the ongoing dialogue. To avoid worry, one might want to specify a short grace period in the charter (perhaps one to three days) during which submissions to the list made in error or otherwise immediately regretted could be canceled or nullified as far as licensing. The issue isn't to force people to contribute -- it is to make it easy to do so in a manner that automatically provides a reasonable amount of "due diligence".

=== GNU Smalltalk ===

GNU Smalltalk has a lot to recommend it. Frankly, working with the GNU Smalltalk platform is something I've seriously considered -- although if I was not going to work with Squeak, Python (or some form of Lisp or Scheme) would probably come in second because of the size of the user communities and the crossover to immediate business value. GNU Smalltalk (based on reading about it) sounds very impressive -- especially considering the small number of maintainers compared to Squeak. It seemingly effortlessly deals with things -- exceptions, events, and modules -- that have long been fought over on the Squeak list as far as even convincing people they are worthwhile. And it does seem to have a clearer title in terms of handling contributions and attempts to avoid infringement (for example it has a more flexible event system added to avoid seeming to infringe an existing Smalltalk). Without having tried it, I think (probably showing my ignorance :-) that GnuSt shows better software engineering than Squeak but perhaps shows to date less broad a vision and less user enthusiasm (in part probably simply for being a smaller community, but also for lack of Alan Kay & co.). Still, what some may call less vision, others might call practicality or a different vision. However, I'm looking for something somewhat beyond Smalltalk, so GNU Smalltalk as is wouldn't quite fit either. Still, perhaps some Squeak "vision" features in a Morphic direction or even ported code (Celeste?) added to GNU Smalltalk might be an interesting hybrid for people willing to live with the GNU Smalltalk license.

== why rebuild something at all ===

I also hope this rebuilding process might be easier in some ways (or possibly just more fun or educational) than refactoring what exists or using a subtractive approach (as sensible as those may be to do in a different context, with different objectives, as in StSq). And after all, I am just trying to uphold Alan Kay's vision of using Squeak to build the next great thing, and avoid "Squeak eating her young".

We never know as much about something as if we help build it from the ground up. Thus, there may be great personal value in helping with a "Squeak raising" after we "burn the disk packs", much like people learn something about barns and carpentry at an old fashioned "barn raising", perhaps after one burned down from lightning.

[By the way, thanks go to Benjamin Franklin for inventing the lighting rod and avoiding many barn burnings, even though the lightning rod was very controversial at first for what now may seem surprising reasons. http://www.santafe.edu/~shalizi/White/air/rod.html Maybe Squeak needs a "crazy, paranoid developer" rod :-) ]

-Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com

Cees de Groot wrote:

If you really want to have a sort of clean-room, infringement-free variant of Squeak, I think you should go all the way and only allow people on the mailing list after they've signed papers. Before you know, it looks an awful lot like GNU Smalltalk...

Stephen Pair wrote:

I don't see the need for a "more standard license"... the Squeak license is just fine (IMHO).

I feel most people using Squeak would agree with you, including at least one lawyer on the list who says more or less the same thing as you. That's a major reason to move such an effort onto a separate list and let it sink or swim on its own.

As for me, I especially don't like having to indemnify Apple in the context of shipping commercial software, and there are other aspects about the license I don't want to go into here (I made some previous posts on the Squeak list on the licensing topic quite a while back).

In defense of your point though, this excellent Slashdot article: "Attorney Dan Ravicher on Open Source Legal Issues" http://slashdot.org/article.pl?sid=01/06/05/122240 includes a comment by that attorney: "My second suggestion is for open source developers to keep writing good code. After all is said and done, people care about getting the best product they can at the cheapest price. The free software community has already proven to many people that it provides a competitive and sometimes superior alternative to proprietary software development. Although legal issues are important to the success of an open source project, they should always come second to the technical development of the code. It is my opinion that law does not lead the market, rather the market leads the law. Therefore, winning in the marketplace will lead to winning in the legal system, not vice versa. "

Hopefully though, whether or not a "burn the disk packs" effort makes sense at this point for legal or technical reasons, the idea of such a mailing list charter might be useful to other SqF projects (including perhaps documentation ones).

-Paul Fernhout Kurtz-Fernhout Software ========================================================= Developers of custom software and educational simulations Creators of the Garden with Insight(TM) garden simulator http://www.kurtz-fernhout.com