[Squeakfoundation]New mailing list request for Bellesqueak

[Paul Fernhout]

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