Cees-
I would like to request a new mailing list and Wiki for a Squeak-inspired project called "Bellesqueak". This is a ground up project inspired by Squeak, intended to learn from Squeak's strengths and weaknesses including licensing issues. It is not an effort to modify Squeak itself (although Squeak may be used as scaffolding and a tool to develop Bellesqueak).
For reference, see this earlier related thread: "Operating procedures for a "burn the diskpacks" list?" http://lists.squeakfoundation.org/pipermail/squeakfoundation/2001-June/00023... By the way, the earlier mailing list charter proposed there was reviewed by Richard Stallman and Eben Moglen (the FSF's lawyer) and the feeling was (like Cees said in that earlier thread) the best thing was to get people to sign papers initially or eventually, so I have added that provision in the charter below.
The Bellesqueak mailing list charter is to be as follows:
===
The intent of the Bellesqueak list is to support a community process which creates, discusses, uses, and maintains a cross-platform computing environment and knowledge management system inspired by Squeak Smalltalk called Bellesqueak. The focus of Bellesqueak will be on transparency, robustness, and complexity management -- to support the doing of good deeds such as education, sustainable development, and ensuring humanity survives Vernor Vinge's Singularity in some form.
The entire system will be built from the ground up in a public way, with all code for the core submitted through this Bellesqueak mailing list and subject to the Bellesqueak license. The license of all discussions and code contributions and other content made to this list will be under the modified BSD license without the advertising clause (so don't contribute postings or code here if you don't want your effort to be under this license or if they legally can't be put under this license).
URL links posted to the list pointing to work under other licenses shall not be construed to mean those other works are under the Bellesqueak license, and it is acceptable on the list to discuss other works compatible with or derived from Bellesqueak, even if the other works themselves are not under the same license (remembering that all contributions to the list itself including such discussions are under the Bellesqueak license).
At some point, significant contributors to this list may be asked to a sign a document along the lines stating their contributions are original (or otherwise made with permission) and are allowed by any employers and are submitted under this license, and at some point all future mailing list participants may be asked to sign such a document in order to contribute or continue contributing to the mailing list.
To be clear, no code may be taken directly from Squeak and submitted to the Bellesqueak list without permission from the original authors to put it under the Bellesqueak license. Note that clearly defined modules developed by others under licenses easily compatible with the Bellesqueak license (like the MIT X license or in the public domain) may from time to time be accepted into the Bellesqueak project at the discretion of the community. Likewise, for scaffolding, Bellesqueak may at times rely on a variety of tools or libraries which may or may not be under the Bellesqueak license, and in those cases the licensing distinctions of such components must be clearly noted.
For purposes of managing the future of Bellesqueak, I (Paul Fernhout) hereby declare myself "benevolent Beau for as long as I wish" :-) [For a definition of Beau see: http://www.ceder.net/def/beaubelle.php3 ] of the Bellesqueak community mailing list and claim ownership of the Bellesqueak trademark (like Linus Torvalds claims ownership of Linux) with my intent being to ensure the quality of whatever is called "Bellesqueak". Naturally, anyone may at any time take the contents of the Bellesqueak system or mailing list and, respecting the license, fork it under a new name if they have significantly divergent opinions of how it should proceed.
The Bellesqueak code and posting reuse license text is as follows:
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
====
FYI Bellesqueak's impetus relates to the "Belling the cat of complexity" thread: http://squeak.cs.uiuc.edu/mail/squeak/msg04562.html Please also note that for those wishing to deride this effort, feel free to call it "Paultalk". ;-)
Also, I would appreciate it if discussion in this request thread confines itself to whether Cees or possibly by extension the Squeak Foundation should allow such a list to be made or supported based on the stated aims and the charter and license, as opposed to a discussion in and of themselves of the merit of the project, or the choice of license, or whether it is needed, or whether it will produce anything of value, etc.
-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 (and other list members)-
Just to show how wishy-washy I can be, since the Bellesqueak list hasn't been set up yet, after another night of reflection, I've decide to change the licensing of the Bellesqueak charter to be GNU GPL for the code and GNU Free Documentation License for the mailing list, WIKI contents, and other non-code content contributed to the project.
I am doing this in part so I can easily incorporate parts of GNU Lightning, http://www.gnu.org/software/lightning/ and while I am at it, raid parts of GNU Smalltalk and GNU Forth and maybe MzScheme to give Bellesqueak a jumpstart.
One might ask why not just add to GNU Smalltalk? http://www.gnu.org/software/smalltalk/ Well there are many Squeakish themes I would like to explore in code and in community discussions, and I think I would prefer to use Squeak to develop the infrastructure (making Bellesqueak for the time being sort of a Squeak application). Presumably some of the Bellesqueak work could go into GNU Smalltalk, so one might think of this as a Squeak-GNUSmalltalk hybrid, with various other things thrown in. Ultimately, I'm interested in a ground up rewrite that may not be quite compatible with conventional Smalltalk, so I feel a new project is in order for now as opposed to an enhancing GNU Smalltalk.
Hopefully, some people who have contributed things to Squeak under the more-restrictive-than-BSD Squeak License might be willing if asked to also allow them also to be put under the much more restrictive GPL. Obviously since the Squeak License is not GPL-compatible, this means the Bellesqueak code can't go into the Squeak base as is. However, on an individual basis, Bellesqueak contributors can decide to dual license their contributions under the Squeak license upon request or announce such dual licensing on the list (for such modules which they are the sole author).
Also, I am making the change as on further thinking I realize that what I have in mind will get done faster being able to raid both the GPL and BSD code bases. And ultimately, for the Bellesqueak effort, commercialization of the result in a classical way isn't a major goal (for me).
Somehow I think this project will just be more fun for me with results put under the GPL -- accepting that many people will also be turned off by the GPL licensing (including the implication applications built on Bellesqueak will likely also be under the GPL). However, I think other people will like the GPL licensing aspect. And practically speaking, people who might be interested in major commercialization of Squeak projects for the most part are using other systems right now (or use Squeak in such a way as a server or tool that Bellesqueak being GPL won't affect them much). It seems most people who have stuck with Squeak so far have done so for reasons more of science and research than commercialization, so I see the GPL as being compatible with that intent (especially since ideas in GPL code could always be re-expresed in other ways under other licenses).
Practically speaking, I realized if I want to use a reasonably robust cross-platform BSD licensed system right now for commercial applications, I could use Python. Obviously Python lacks some of the great themes and insights Squeak has (keyword syntax, morphs, transparency, being written in itself, a certain GUI portability mindset) which to an extent need to be engineered in from the ground up.
Also, while I do sell a couple of shareware products, and might like to use something like Bellesqueak for a base for them down the road, I'm comfortable enough with the idea of begging :-) that I could imagine those products released under the GPL and still trying to raise funding with nag screens (especially as we ourselves are thinking of morphing entirely into a non-profit organization for continuing such efforts).
So to summarize, I realized that if my intent is mostly to have fun with Bellesqueak and do some nice aesthetic programming, GPL is good enough and provides some codebase advantages. For example, I already have an email out to the author of GNU Lightning asking if I can use some of the documentation for the instruction set under the BSD license -- this decision eliminates the need to get his permission to use such ideas or documents as part of Bellesqueak. I can just go forward.
So here is a rewrite of the Bellesqueak mailing list charter with that in mind (and clarifying a couple other points I got questions on):
===========
The intent of the Bellesqueak list is to support a community process which creates, discusses, uses, and maintains a cross-platform computing environment and knowledge management system inspired by Squeak Smalltalk called Bellesqueak. The focus of Bellesqueak will be on transparency, robustness, complexity management, and clear licensing -- to support the doing of good deeds such as education, sustainable development, and ensuring humanity survives Vernor Vinge's Singularity in some form. [For more on the singularity, see: http://hanson.gmu.edu/vi.html or my posting at: http://www.bootstrap.org/dkr/discussion/0126.html ]
The entire system will be built from the ground up in a public way, with all code for the core submitted through this Bellesqueak mailing list and subject to the Bellesqueak license. The license of all discussions and code contributions made to this list or related WIKI will be under the GNU Free Documentation license Version 1.1 or GNU General Public License Version 2 respectively (so don't contribute postings or code here if you don't want your effort to be under this license or if they legally can't be put under this license).
URL links posted to the list pointing to work under other licenses shall not be construed to mean those other works are under the Bellesqueak license, and it is acceptable on the list to discuss other works compatible with or derived from Bellesqueak, even if the other works themselves are not under the same license (remembering that all contributions to the list itself including such discussions are under the Bellesqueak license).
At some point, significant contributors to this list may be asked to a sign a document along the lines stating their contributions are original (or otherwise made with permission) and are allowed by any employers and are submitted under the Bellesqueak (GPL or GFDL) licenses, and at some point all future mailing list participants may be asked to sign such a document in order to contribute or continue contributing to the mailing list.
To be clear, no code may be taken directly from Squeak and submitted to the Bellesqueak list without permission from the original authors to put it under the Bellesqueak license. Note that clearly defined modules developed by others under licenses easily compatible with the Bellesqueak license (like the MIT X license or in the public domain or under the LGPL or GPL) may from time to time be accepted into the Bellesqueak project at the discretion of the community. Likewise, for scaffolding, Bellesqueak may at times rely on a variety of tools or libraries which may or may not be under the Bellesqueak license, and in those cases the licensing distinctions of such components must be clearly noted.
For purposes of managing the future of Bellesqueak, I (Paul Fernhout) hereby declare myself "benevolent Senior Beau for as long as I wish" :-) of the Bellesqueak community mailing list and claim ownership of the Bellesqueak trademark (like Linus Torvalds claims ownership of Linux) with my intent being to ensure the quality of whatever is called "Bellesqueak". [For reference, a Beau in square dancing is the left hand partner of the Belle, and I picked Beau over "dictator" because of previous complaints on use of that term (rightly so). One may think of my role as final arbitrator of the quality of "Bellesqueak". See also: http://www.ceder.net/def/beaubelle.php3 ]
Naturally, anyone may at any time take the contents of the Bellesqueak system or mailing list and, respecting the license, fork it under a new name if they have significantly divergent opinions of how it should proceed.
The Bellesqueak code will be under the GNU General Public License Version 2, viewable here: http://www.gnu.org/copyleft/gpl.html
All other documentation, mailing list discussions, and other content related to the main project will be under the GNU Free Documentation license Version 1.1, viewable here: http://www.gnu.org/copyleft/fdl.html
===========
Of course, now that Bellesqueak is going down what some might call the path to the dark side [Paraphrasing Yoda: Is the GPL better? No, but quicker, easier, more fun...] I will respect any strong suggestions here saying the project should just be hosted at the FSF instead of through Cees's good graces and by extension the Squeak Foundation.
-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
I don't know about anybody else (aside from the people that have already tipped their hand previously) but I personally couldn't care less about licensing stuff.
As far as I'm concerned, any code I release for Squeak (or indeed anything else) in a public place is _public_. Do anything you want with it except blame me if it causes you problems. If you use it as a substantial part of something that makes a lot of money, do the decent thing and credit me and perhaps my bank account a little. Or make a donation in my name to some freedom related charity.
tim
on 26/01/02 7:11 PM, Tim Rowledge at tim@sumeru.stanford.edu wrote:
I don't know about anybody else (aside from the people that have already tipped their hand previously) but I personally couldn't care less about licensing stuff.
As far as I'm concerned, any code I release for Squeak (or indeed anything else) in a public place is _public_. Do anything you want with it except blame me if it causes you problems. If you use it as a substantial part of something that makes a lot of money, do the decent thing and credit me and perhaps my bank account a little. Or make a donation in my name to some freedom related charity.
tim
I agree, even if contributions are small ;).
I think that this is important if people are concerned by the licensing that they do it right. But I'm sincerly lost there. So any new list or whatever so make clear (in normal terms = laws for the dummies) what is the goal and the consequences of the proposed licensing. I do not want nor have the background to read non really "understandable" declarations.
Stef
Given the fact that you're asking the SqF for resources, whazzisgottado with Squeak, except from being inspired by it and stuff? I'm all in favor of handing out mailing lists etcetera to anyone who does things that are interesting (you might, for example, ask Cees de Groot instead of SqF), but I'm not sure that your project is aligned with the stated goal of the SqF, and therefore whether it is justifiable to burden future SqF administrators with this project.
What does the rest of the list think?
Paul Fernhout pdfernhout@kurtz-fernhout.com said:
I would like to request a new mailing list and Wiki for a Squeak-inspired project called "Bellesqueak". This is a ground up project inspired by Squeak, intended to learn from Squeak's strengths and weaknesses including licensing issues. It is not an effort to modify Squeak itself (although Squeak may be used as scaffolding and a tool to develop Bellesqueak).
Hello,
At 20:39 27-1-02 +0100, you wrote:
Given the fact that you're asking the SqF for resources, whazzisgottado with Squeak, except from being inspired by it and stuff? I'm all in favor of handing out mailing lists etcetera to anyone who does things that are interesting (you might, for example, ask Cees de Groot instead of SqF), but I'm not sure that your project is aligned with the stated goal of the SqF,
and
therefore whether it is justifiable to burden future SqF administrators with this project.
What does the rest of the list think?
[snip: rest below]
Since I am asked (as a small particle of "the rest of the list") here is my brief and hasty reply:
(1) I've still not seen Dan Ingalls' clarification (promised by last Tuesday), so Squeak Foundation seems on the moment mostly academic, and so also (2) the future burden of future administrators is even more academic. (3) However, it seems wise to try to compose some sort of association of benevolent and idealistic people and organizations, (4) and in general "the more the better", the license permitting, since also (5) by and large it is easier to prune than to grow.
Perhaps (having read Paul Fernhout's two previous mails) there is some clever and fair lawyer around who could let his or her legal light shine on the question, since it seems mostly an implicit legal issue under US law?
Regards,
Maarten.
Paul Fernhout pdfernhout@kurtz-fernhout.com said:
I would like to request a new mailing list and Wiki for a Squeak-inspired project called "Bellesqueak". This is a ground up project inspired by Squeak, intended to learn from Squeak's strengths and weaknesses including licensing issues. It is not an effort to modify Squeak itself (although Squeak may be used as scaffolding and a tool to develop Bellesqueak).
-- Cees de Groot http://www.cdegroot.com cg@cdegroot.com GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
------------------------------------------ Maarten Maartensz. Homepage: http://www.xs4all.nl/~maartens/ ------------------------------------------
Maarten Maartensz maartens@xs4all.nl said:
(1) I've still not seen Dan Ingalls' clarification (promised by last Tuesday), so Squeak Foundation seems on the moment mostly academic, and so also
You're right about that. Dan?
(4) and in general "the more the better", the license permitting, since also (5) by and large it is easier to prune than to grow.
I'm not sure about (5), that's why I am asking the list. Pruning this project in, say, three years when it is succesful and has attracted quite a bit of people to it would be hard; furthermore, it'd certainly mean moving the site elsewhere so you would either need to maintain pages with links or break a lot of links (and I don't like either). So I rather have a bit of friction about 'accepting' projects that are (or seem - maybe I'm just daft) only vaguely Squeak related than having to weed the project garden later on. And as Paul was referring to a mail from around half a year ago, I am quite sure he has the time for a couple of days of discussion.
Plus, it will help clarify what's SqF and what's not. Plus, I already offered to host it outside the SqF, so the little discussion doesn't exactly endanger the project - if we decide that SqF is not the place, Paul and I will find a solution.
Perhaps (having read Paul Fernhout's two previous mails) there is some clever and fair lawyer around who could let his or her legal light shine on the question, since it seems mostly an implicit legal issue under US law?
AFAIC, it's not. First, you decide whether you want a project under the SqueakFoundation umbrella; only then, you can talk with the project leads about the license and ask a lawyer about licensing compatibility issues, if this is deemed necessary.
Cees de Groot wrote:
I am quite sure he has the time for a couple of days of discussion.
No hurry.
Plus, it will help clarify what's SqF and what's not.
I think that is perhaps the most value in discussing some aspects of this project here.
I don't mind talking at length on issues relating to Squeak and licensing and the Foundation, but I don't want to cause any major flaming or divisions. In the 5/26/2001 message of: "SqF purpose: supporting the Squeak community?" I talked about supporting the artifact first vs. supporting the community first. I guess this dredges that issue up -- and then the majority of sentiment when a similar post was made to SQ-Dev seems to be on supporting incremental evolution of the artifact first as that then defines the community as those interested in the artifact. However I remain a minority dissenter on that issue, since I think a community can form around an ideal (even if it may take an example of that ideal in an artifact or action to serve as the initial nucleus of the community).
I think the intent of the Bellesqueak project gets at the core of what Squeaking could be about. Alan Kay has already talked publicly (at a presentation I went to last year) about how he and SqC sees Squeak less religiously than many users -- that is he sees Squeak as a step to then next best thing, with likely eventually Squeak just used as a tool to make what comes next. He always talks about the Pink vs. Blue sky planes... http://minnow.cc.gatech.edu/squeak/158 Bellesqueak is a project that will attempt Blue plane work (time permitting) based on the premise that a big part of what I would like to see improved in Squeak is the process of license management for contributed code (which also reflects back onto modularity issues).
As I wrote in a response to Göran in this thread, the more I think about this, the more I come around to seeing that what I should develop first is more a tool to manage these licensing issues -- sort of a code repository and configuration management tool that is license aware (think of it warning about loading code with a license incompatible to code already loaded...). Because if people (like Tim in a previous post) want to say their code or email posts are public domain or whatever, they should have a chance to, even if the rest of the application was for example contaminated by GPL code, and the system should record that. Then I can use that system to build up a new version of Squeak called "Bellesqueak" with an arbitrary license by picking subsets of the entire codebase and knowledgebase. [Note: this also gets at the issue of building a Squeak image from scratch.]
However, in this sense, the Bellesqueak charter is then inadequate for the day-to-day use of Bellesqueak, because it puts a specification on the licensing of the code and content which may be too strict -- as opposed to saying mailing list participants will cooperate with the licensing rights managed by Bellesqueak by explicitly specifying the licensing of all their posted contributions. I don't want to force people to GPL things for example -- I just want to be able to harmonize the parts of the system so a functional subset of it is under compatible licenses and can be distributed and used.
==== The deeper issues regarding the evolution of Squeak and why a SqF just supporting incremental evolution in the Pink plane may not be enough
The problem I see is is in part that Squeak is in conflict (creative tension?) about some things, and these conflicts will and do spill over into the community and the Squeak Foundation definition.
The first conflict is does Squeak want to be about imaginative science/education or proper legally-done engineering (or both)? The Squeak-L (License) is in the middle of this conflict. Squeak-L intends to make Squeak somewhat viral so scientists at places like Disney seemingly have to release their work, yet make it somewhat open so engineers can seemingly use it somehow for products. How to do this is a complex issue of how to make a good "intellectual capital appreciation" license that balances different conflicting desires. http://www.eoe.org/foundation/info.htm
I think the Squeak license in practice has created some difficulties to an extent in supporting either community since I still can't clarify the licensing of Morphic (is it really a base class change?) plus I still can't link the VM into a proprietary embedded system (is static linking of a library in an embedded application a change to the VM?). However, Squeak-L was a nice try and a good learning experience and got things going (and people will disagree with me on its viability for use in products).
If Squeak is about science/education, then it seems to me taht the GPL is fine and probably more desirable than Squeak-L since then I would know for sure what license all work released from, say, Disney was under. However, to an extent licensing doesn't matter much if one is just messing around for fun and research and education and never releases a major product.
If Squeak is about engineering, a Python like license (BSD) might be more appropriate so it could be easily embedded in an application or proprietary computing box (which is one reason Python is a strong player in that niche, even at Disney). Becausethe BSD license is not at all viral people may also be more clear about the licensing of their contributions (since they would never assume their new contribution is covered by the BSD license).
Squeak attracted both researching and application-building crowds, but the crowd who really sticks around is the science and research and education one (and of course application builders with a research or education interest), in part since licensing doesn't matter much to them in practice. The crowd wanting to ship Smalltalk applications has Dolphin Smalltalk and VisualWorks etc. (and those vendors do a good job and have a stable platform right now) and so Squeak seemingly always has a long road ahead of it to approach that niche (and it's not always clear why it should try to approach that one given the work involved). Squeak as-is may still appeal to some business types in certain situations -- because business is about risk management, and the risk of not using Squeak right now in terms of project failure or delays or vendor uncertainties or lack of customization etc. may still be higher than legal risks of using Squeak down the road -- but that's a business decision.
Naturally SqF may be able to raise funds or volunteers to make Squeak rival VisualWorks, but that is down the road, and it's not clear if that is where SqF wants to go (and if it does, I still think licensing is going to be a big issue..) Yet, it is problematical for SqF to essentially support only incremental evolution of an R&D-ish experiment of Squeak as it is now -- since successful research often needs apparent initial discontinuity in approach. So is SqF about making a slow VisualWorks or is it about doing R&D (in educational computing or what?) or is it about incremental evolution of the Squeak codebase under the Squeak-L (or all three)? I don't think there is an easy answer to this -- perhaps there will be multiple groups under different organizational umbrellas. But I would guess the people willing to donate cash to SqF are mainly interested in a slow VisualWorks.
The second conflict is about whether computing these days is "personal" or "interpersonal" (i.e. collaborative)? To elaborate, can a "personal" computing environment at the core ignore the fact that any computing environment today is part of a network of computing environments? Is then "personal computing environment" an entirely obsolete concept (with all due respect to Alan and his team for their accomplishments), given that the underlying technology of "personal" computing on a network must reflect social issues (of which licensing is one)? Why call computing "personal" if much of what is consists of is looking around the network for things to download and sending communications to others (like this one). If computing is now "interpersonal", then should not the base paradigm, GUI, license management strategy, and so forth of the system reflect that? Ultimately, if all software development these days is effectively an interpersonal process (even if parts are done in isolation), then great attention needs to be paid to the interpersonal aspects of Squeak, including license management. Thus one might even consider a revised SqF statement of purpose of "To assist in the evolution of Squeak into its ultimate expression as an exquisite interpersonal computing environment" http://swiki.squeakfoundation.org/squeakfoundation/6
The third conflict is somewhat technical but I include it as an example of one reason why I am interested in some ground-up rewriting (which in turn makes license changes easier to swallow at the same time). Does Squeak as a computing environment want to live in its own world or does it want to reach out to touch other computing systems (and support other languages)? Squeak gains many stability benefits by being its own virtual world with a unified message sending model, but it gains much utility (and speed) by being able to influence other computing environments on the fly like when making a C library function call. This issue manifests itself throughout the Squeak architecture (e.g. it has a message sending VM but it relies on a C compiler). It's not as important an issue as the first two, but it is one I wish to explore. For example, it could be explored by having Squeak able to generate native code such as through GNU Lightning (a somewhat platform independent approach to machine code generation under the GPL). Further, it could be explored by having Squeak able to generate new versions of itself without relying on a C compiler, and further by having Squeak able to generate, understand, and make use of problem specific binary code (essentially supporting conventional machine language debugging tools). This tension between VM vs. native code has historically been involved in defining many of Smalltalk's strengths and weaknesses in practice relative to the C/Unix-tools paradigm. This relation of Squeak to conventional processors is one that might be fun to explore (bearing in mind "if you can't crash it, you aren't doing the driving"). If the result is a major rewrite of Squeak, it is a convenient time to put a new core under a more common license (Public Domain, X/MIT, BSD, LGPL, GPL, MPL, whatever).
Plus, I already offered to host it outside the SqF, so the little discussion doesn't exactly endanger the project - if we decide that SqF is not the place, Paul and I will find a solution.
Thanks for the generous offer. I'm starting to think it might be best if I just went through SourceForge or the FSF rather than cause any more trouble here (to avoid anyone having to make a decision that might reduce valuable creative ambiguity in SqF's definition). [That's meant seriously, not sarcastically -- I believe in the value of creative ambiguity.] I have another project at SourceForge (Pointrel) so using that system for another might be easiest for me and put the least stress on the community.
As I have said before, I think the greatest value of Squeak has been to bring together a community of creative and inspired people doign neat things. Safeguarding and supporting that community should be of highest priority, and if this request damages it in any way, I will withdraw it.
-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
Paul,
Nice (and pretty long ;-) memo. However, I am somewhat surprised to see you so focused on licensing issues. After all, if you're really off the blue plane you can choose any license _you_ want. If people agree with it they'll follow. If not you gotta figure out how to fix it.
But seriously, wouldn't it be time to start thinking about what BelleSqueak wants to do besides discussing licensing issues?! ;-) In response to Cees message ("what do other people think") I would like to post my reaction depending on the content and not the license. In other words, if I think that your proposal is a step into a direction that might benefit the community in any way (be that for research, commercial or just fun purposes) I'd certainly lobby for it. And I could rarely care less about the license you choose as long as it is somewhat reasonable. However, if the agenda of BelleSqueak is basically to "have a different licensing model" I don't see a lot of benefit for the community here. After all, as long as you're doing it for your own personal purposes you _can_ use GPLed code. Nobody is arguing that parts of the code within Squeak need a clarification on the license but that doesn't quite justify a "ground up rewrite", does it?!
Cheers, - Andreas
-----Ursprüngliche Nachricht----- Von: squeakfoundation-admin@lists.squeakfoundation.org [mailto:squeakfoundation-admin@lists.squeakfoundation.org] Im Auftrag von Paul Fernhout Gesendet: Montag, 28. Januar 2002 17:18 An: squeakfoundation@lists.squeakfoundation.org Betreff: Re: [Squeakfoundation]New mailing list request for Bellesqueak
Cees de Groot wrote:
I am quite sure he has the time for a couple of days of discussion.
No hurry.
Plus, it will help clarify what's SqF and what's not.
I think that is perhaps the most value in discussing some aspects of this project here.
I don't mind talking at length on issues relating to Squeak and licensing and the Foundation, but I don't want to cause any major flaming or divisions. In the 5/26/2001 message of: "SqF purpose: supporting the Squeak community?" I talked about supporting the artifact first vs. supporting the community first. I guess this dredges that issue up -- and then the majority of sentiment when a similar post was made to SQ-Dev seems to be on supporting incremental evolution of the artifact first as that then defines the community as those interested in the artifact. However I remain a minority dissenter on that issue, since I think a community can form around an ideal (even if it may take an example of that ideal in an artifact or action to serve as the initial nucleus of the community).
I think the intent of the Bellesqueak project gets at the core of what Squeaking could be about. Alan Kay has already talked publicly (at a presentation I went to last year) about how he and SqC sees Squeak less religiously than many users -- that is he sees Squeak as a step to then next best thing, with likely eventually Squeak just used as a tool to make what comes next. He always talks about the Pink vs. Blue sky planes... http://minnow.cc.gatech.edu/squeak/158 Bellesqueak is a project that will attempt Blue plane work (time permitting) based on the premise that a big part of what I would like to see improved in Squeak is the process of license management for contributed code (which also reflects back onto modularity issues).
As I wrote in a response to Göran in this thread, the more I think about this, the more I come around to seeing that what I should develop first is more a tool to manage these licensing issues -- sort of a code repository and configuration management tool that is license aware (think of it warning about loading code with a license incompatible to code already loaded...). Because if people (like Tim in a previous post) want to say their code or email posts are public domain or whatever, they should have a chance to, even if the rest of the application was for example contaminated by GPL code, and the system should record that. Then I can use that system to build up a new version of Squeak called "Bellesqueak" with an arbitrary license by picking subsets of the entire codebase and knowledgebase. [Note: this also gets at the issue of building a Squeak image from scratch.]
However, in this sense, the Bellesqueak charter is then inadequate for the day-to-day use of Bellesqueak, because it puts a specification on the licensing of the code and content which may be too strict -- as opposed to saying mailing list participants will cooperate with the licensing rights managed by Bellesqueak by explicitly specifying the licensing of all their posted contributions. I don't want to force people to GPL things for example -- I just want to be able to harmonize the parts of the system so a functional subset of it is under compatible licenses and can be distributed and used.
==== The deeper issues regarding the evolution of Squeak and why a SqF just supporting incremental evolution in the Pink plane may not be enough
The problem I see is is in part that Squeak is in conflict (creative tension?) about some things, and these conflicts will and do spill over into the community and the Squeak Foundation definition.
The first conflict is does Squeak want to be about imaginative science/education or proper legally-done engineering (or both)? The Squeak-L (License) is in the middle of this conflict. Squeak-L intends to make Squeak somewhat viral so scientists at places like Disney seemingly have to release their work, yet make it somewhat open so engineers can seemingly use it somehow for products. How to do this is a complex issue of how to make a good "intellectual capital appreciation" license that balances different conflicting desires. http://www.eoe.org/foundation/info.htm
I think the Squeak license in practice has created some difficulties to an extent in supporting either community since I still can't clarify the licensing of Morphic (is it really a base class change?) plus I still can't link the VM into a proprietary embedded system (is static linking of a library in an embedded application a change to the VM?). However, Squeak-L was a nice try and a good learning experience and got things going (and people will disagree with me on its viability for use in products).
If Squeak is about science/education, then it seems to me taht the GPL is fine and probably more desirable than Squeak-L since then I would know for sure what license all work released from, say, Disney was under. However, to an extent licensing doesn't matter much if one is just messing around for fun and research and education and never releases a major product.
If Squeak is about engineering, a Python like license (BSD) might be more appropriate so it could be easily embedded in an application or proprietary computing box (which is one reason Python is a strong player in that niche, even at Disney). Becausethe BSD license is not at all viral people may also be more clear about the licensing of their contributions (since they would never assume their new contribution is covered by the BSD license).
Squeak attracted both researching and application-building crowds, but the crowd who really sticks around is the science and research and education one (and of course application builders with a research or education interest), in part since licensing doesn't matter much to them in practice. The crowd wanting to ship Smalltalk applications has Dolphin Smalltalk and VisualWorks etc. (and those vendors do a good job and have a stable platform right now) and so Squeak seemingly always has a long road ahead of it to approach that niche (and it's not always clear why it should try to approach that one given the work involved). Squeak as-is may still appeal to some business types in certain situations -- because business is about risk management, and the risk of not using Squeak right now in terms of project failure or delays or vendor uncertainties or lack of customization etc. may still be higher than legal risks of using Squeak down the road -- but that's a business decision.
Naturally SqF may be able to raise funds or volunteers to make Squeak rival VisualWorks, but that is down the road, and it's not clear if that is where SqF wants to go (and if it does, I still think licensing is going to be a big issue..) Yet, it is problematical for SqF to essentially support only incremental evolution of an R&D-ish experiment of Squeak as it is now -- since successful research often needs apparent initial discontinuity in approach. So is SqF about making a slow VisualWorks or is it about doing R&D (in educational computing or what?) or is it about incremental evolution of the Squeak codebase under the Squeak-L (or all three)? I don't think there is an easy answer to this -- perhaps there will be multiple groups under different organizational umbrellas. But I would guess the people willing to donate cash to SqF are mainly interested in a slow VisualWorks.
The second conflict is about whether computing these days is "personal" or "interpersonal" (i.e. collaborative)? To elaborate, can a "personal" computing environment at the core ignore the fact that any computing environment today is part of a network of computing environments? Is then "personal computing environment" an entirely obsolete concept (with all due respect to Alan and his team for their accomplishments), given that the underlying technology of "personal" computing on a network must reflect social issues (of which licensing is one)? Why call computing "personal" if much of what is consists of is looking around the network for things to download and sending communications to others (like this one). If computing is now "interpersonal", then should not the base paradigm, GUI, license management strategy, and so forth of the system reflect that? Ultimately, if all software development these days is effectively an interpersonal process (even if parts are done in isolation), then great attention needs to be paid to the interpersonal aspects of Squeak, including license management. Thus one might even consider a revised SqF statement of purpose of "To assist in the evolution of Squeak into its ultimate expression as an exquisite interpersonal computing environment" http://swiki.squeakfoundation.org/squeakfoundation/6
The third conflict is somewhat technical but I include it as an example of one reason why I am interested in some ground-up rewriting (which in turn makes license changes easier to swallow at the same time). Does Squeak as a computing environment want to live in its own world or does it want to reach out to touch other computing systems (and support other languages)? Squeak gains many stability benefits by being its own virtual world with a unified message sending model, but it gains much utility (and speed) by being able to influence other computing environments on the fly like when making a C library function call. This issue manifests itself throughout the Squeak architecture (e.g. it has a message sending VM but it relies on a C compiler). It's not as important an issue as the first two, but it is one I wish to explore. For example, it could be explored by having Squeak able to generate native code such as through GNU Lightning (a somewhat platform independent approach to machine code generation under the GPL). Further, it could be explored by having Squeak able to generate new versions of itself without relying on a C compiler, and further by having Squeak able to generate, understand, and make use of problem specific binary code (essentially supporting conventional machine language debugging tools). This tension between VM vs. native code has historically been involved in defining many of Smalltalk's strengths and weaknesses in practice relative to the C/Unix-tools paradigm. This relation of Squeak to conventional processors is one that might be fun to explore (bearing in mind "if you can't crash it, you aren't doing the driving"). If the result is a major rewrite of Squeak, it is a convenient time to put a new core under a more common license (Public Domain, X/MIT, BSD, LGPL, GPL, MPL, whatever).
Plus, I already offered to host it outside the SqF, so the little discussion
doesn't exactly endanger
the project - if we decide that SqF is not the place, Paul
and I will find a
solution.
Thanks for the generous offer. I'm starting to think it might be best if I just went through SourceForge or the FSF rather than cause any more trouble here (to avoid anyone having to make a decision that might reduce valuable creative ambiguity in SqF's definition). [That's meant seriously, not sarcastically -- I believe in the value of creative ambiguity.] I have another project at SourceForge (Pointrel) so using that system for another might be easiest for me and put the least stress on the community.
As I have said before, I think the greatest value of Squeak has been to bring together a community of creative and inspired people doign neat things. Safeguarding and supporting that community should be of highest priority, and if this request damages it in any way, I will withdraw it.
-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 _______________________________________________ Squeakfoundation mailing list Squeakfoundation@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/squeakfoundation
Andreas Raab wrote:
Nice (and pretty long ;-) memo. However, I am somewhat surprised to see you so focused on licensing issues. After all, if you're really off the blue plane you can choose any license _you_ want. If people agree with it they'll follow. If not you gotta figure out how to fix it.
Thanks. Good point on picking a new license for a totally new system.
I guess I see license management as a bigger and bigger part of the open source / free software puzzle as time goes by and code and content accumulates which does not interoperate... And obviously there are other issues like modularity which I care about. My feeling about the status of Squeak licensing both in theory and practice (which others disagree with me on) has always been a major impediment to my making a major investment in using or improving Squeak (beyond casual use for some experiments such as LinksWorld, Embedded Squeak, Pointrel in Squeak, or for prototyping, doing simple text and data processing, playing Morphic games, reading email, debugging HTTP headers, exploring 3DS, wowing friends, etc.).
But seriously, wouldn't it be time to start thinking about what BelleSqueak wants to do besides discussing licensing issues?! ;-) In response to Cees message ("what do other people think") I would like to post my reaction depending on the content and not the license. [snip] After all, as long as you're doing it for your own personal purposes you _can_ use GPLed code. Nobody is arguing that parts of the code within Squeak need a clarification on the license but that doesn't quite justify a "ground up rewrite", does it?!
I was trying to avoid a discussion of the project on its (vaporware) merits in this thread -- hoping instead to have such discussions (and related redesigns they will undoubtedly suggest) on a Bellesqueak list itself. But you have a good point.
So, in a nutshell my technical vision for Bellesqueak is: * A VM based on GNU Lightning (or something similar) and including hooks to the real hardware (If you can't crash it, you're not doing the driving) * A way to translate code targeting the VM to native code (GNU Lightning, or Ian Piumarta's work on which it is based) * Easy creation of isolated VM subsets for remote debugging * Various tools to operate over that virtual instruction set * Multilanguage support including psuedo- Python, Forth, Smalltalk, Scheme, Basic (forgive me), Object Pascal, and C sharing some common libraries * A common set of tools to operate over those various languages * Integrated (distributed) source code and discussion archiving with license management * A version of a prototypish Smalltalk with a method hierarchy as opposed to a class hierarchy * A focus on modularity from the start * A focus on transparency from the start * Accepting tradeoffs towards moderate efficiency * A lighter-weight GUI than Morphic but with more "security" features for selective locking of GUI elements and otherwise holding to many of the Morphic ideals * Building security and event handling in from the start (as above) * Retaining desirable Squeak ideas like generating its own code and having a simple base portability layer for bitmaps and event handling (defined with a low level API other languages like C or Forth can easily use natively) * Some content related to sustainable development (simulations, texts) * Some information management tools for handling email and in general the flood of information we see daily these days
Obviously I haven't explained why my gut says these are good goals to pursue, but for one small example, a VM based on virtual CPU instructions will seem less efficient then a Smalltalk specific one, but I think the potential speed up in easy translation to native code will then make up for this loss in emulation many times over for Jitter type code, and then this might allow other languages on this platform to have the same big win. If all the tools target this VM set, then there is a lot of leverage and much motivation to use it well or enhance it in good ways.
These goals haven't changed that much from those I (and of course others) have been thinking about over the years, although the rest of the world is catching up with .Net DotGNU etc. See for example: http://www.create.ucsb.edu/squeak/9612.html#Letter94 Obviously, IBM was using a VM with multi-language support back in the 1960s (System 360)... http://pucc.princeton.edu/~melinda/
But these goals are in large part obviously hype, handwaving, and vaporware at this point (which is why I call them goals). But hopefully one can see that starting from scratch in this context given several of these goals makes sense if one pursues these ends -- while at the same time realizing that many existing pieces of code or documentation could be useful to integrate as the system progresses (thus even as one starts from scratch, one stands on the shoulders of others). I guess when I say start from scratch I mean something more like -- exercise tight editorial control over what goes into the system after performing some experiments. Clearly, one needs scaffolding for building from scratch and systems like Squeak (or Python) may help building the next generation systems more quickly.
Almost everyone of the goals listed above could be found in one system or another -- the difficulty is bringing them together (in an open source / free software way). The closest term one has now is an Operating System, but I think that concept lacks some flavor of what I am getting at as I try to implement "interpersonal" computing building on the ideals of Alan Kay, Doug Engelbart, Vannevar Bush, etc. Could all these be done somehow incrementally one at a time in Squeak? Probably yes (including even swapping in a more generic VM), but I think it less work and more fun to take the lessons from Squeak and "burn the disk packs". And obviously, it will be the easiest work if the project is of interest to enough people that they want to participate in it -- and obviously the people on the Squeak list are some of the best people to implement such a system if they found it of interest at some point as a next generation Squeak. But obviously, since it is vaporware at this point, it should not distract too much from incremental evolution of Squeak.
-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
message sending VM but it relies on a C compiler). It's not as important an issue as the first two, but it is one I wish to explore. For example, it could be explored by having Squeak able to generate native code such as through GNU Lightning (a somewhat platform independent approach to machine code generation under the GPL).
GNU Lighning is very similar to the low-level stuff used in the Squeak Jitter.
Marcus
Marcus Denker wrote:
GNU Lighning is very similar to the low-level stuff used in the Squeak Jitter.
Paolo Bonzini (of GNU Lighning) cites Ian Piumarta's work as its underpinnings, http://compilers.iecc.com/comparch/article/01-06-018 but I don't know how close the instruction sets are. Any comments on that (privately or not) would be appreciated.
Tangentially, I have a fun book from about twenty years ago called "Universal Assembly Language" written by people at a company making a system to write similar (though not quite identical) assembly code for hundreds of processors.
-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
Paul Fernhout pdfernhout@kurtz-fernhout.com said:
As I have said before, I think the greatest value of Squeak has been to bring together a community of creative and inspired people doign neat things. Safeguarding and supporting that community should be of highest priority, and if this request damages it in any way, I will withdraw it.
If the SqF is damageable through a discussion about whether to put the SqF flag on a project or not, we've got a serious problem.
Anyway, even though I feel compelled to write a long answer to your long post, it's rather late this side of the pond. I'll try to fathom the general sentiment on the list in a day or two. Personally, I'm all in favour of 'borderline experimentation', but experience has shown that I'm bad at judging what everyone wants here ;-)
squeakfoundation@lists.squeakfoundation.org
-
Andreas Raab -
cg＠home.cdegroot.com -
ducasse -
Maarten Maartensz -
Marcus Denker -
Paul Fernhout -
Tim Rowledge