AW: [Squeakfoundation]New mailing list request for Bellesqueak

[Andreas Raab]

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=FCngliche Nachricht-----
> Von: squeakfoundation-admin@lists.squeakfoundation.org=20
> [mailto:squeakfoundation-admin@lists.squeakfoundation.org] Im=20
> Auftrag von Paul Fernhout
> Gesendet: Montag, 28. Januar 2002 17:18
> An: squeakfoundation@lists.squeakfoundation.org
> Betreff: Re: [Squeakfoundation]New mailing list request for=20
> Bellesqueak
>=20
>=20
> Cees de Groot wrote:
> > I am quite sure he has
> > the time for a couple of days of discussion.
>=20
> No hurry.
> =20
> > Plus, it will help clarify what's SqF and what's not.
>=20
> I think that is perhaps the most value in discussing some aspects of
> this project here.
>=20
> 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=20
> 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=20
> interested in
> the artifact. However I remain a minority dissenter on that=20
> 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).
>=20
> 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=20
> Squeak less
> religiously than many users -- that is he sees Squeak as a=20
> 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=20
> would like to
> see improved in Squeak is the process of license management for
> contributed code (which also reflects back onto modularity issues).
>=20
> As I wrote in a response to G=F6ran in this thread, the more I=20
> think about
> this, the more I come around to seeing that what I should=20
> 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=20
> 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=20
> 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=20
> the entire
> codebase and knowledgebase. [Note: this also gets at the issue of
> building a Squeak image from scratch.]
>=20
> 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=20
> harmonize
> the parts of the system so a functional subset of it is under=20
> compatible
> licenses and can be distributed and used.
>=20
> =3D=3D=3D=3D The deeper issues regarding the evolution of Squeak and =
why a SqF
> just supporting incremental evolution in the Pink plane may not be
> enough
>=20
> The problem I see is is in part that Squeak is in conflict (creative
> tension?) about some things, and these conflicts will and do=20
> spill over
> into the community and the Squeak Foundation definition.=20
>=20
> 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=20
> do this is a
> complex issue of how to make a good "intellectual capital=20
> appreciation"
> license that balances different conflicting desires.
>     http://www.eoe.org/foundation/info.htm
>=20
> I think the Squeak license in practice has created some=20
> difficulties to
> an extent in supporting either community since I still can't=20
> 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=20
> 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).=20
>=20
> 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.=20
>=20
> 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=20
> 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).
> =20
> 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=20
> much to them
> in practice. The crowd wanting to ship Smalltalk applications has
> Dolphin Smalltalk and VisualWorks etc. (and those vendors do=20
> a good job
> and have a stable platform right now) and so Squeak seemingly=20
> 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=20
> 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=20
> a business
> decision.=20
>=20
> 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=20
> 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=20
> experiment
> of Squeak as it is now -- since successful research often=20
> needs apparent
> initial discontinuity in approach. So is SqF about making a slow
> VisualWorks or is it about doing R&D (in educational=20
> 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=20
> organizational
> umbrellas. But I would guess the people willing to donate cash to SqF
> are mainly interested in a slow VisualWorks.
>=20
> The second conflict is about whether computing these days is=20
> "personal"
> or "interpersonal" (i.e. collaborative)? To elaborate, can a=20
> "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=20
> concept (with
> all due respect to Alan and his team for their accomplishments), given
> that the underlying technology of "personal" computing on a=20
> network must
> reflect social issues (of which licensing is one)? Why call computing
> "personal" if much of what is consists of is looking around=20
> 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
>=20
> The third conflict is somewhat technical but I include it as=20
> an example
> of one reason why I am interested in some ground-up rewriting=20
> (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=20
> world or does
> it want to reach out to touch other computing systems (and=20
> 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=20
> call. This
> issue manifests itself throughout the Squeak architecture=20
> (e.g. it has a
> message sending VM but it relies on a C compiler). It's not=20
> as important
> an issue as the first two, but it is one I wish to explore.=20
> For example,
> it could be explored by having Squeak able to generate native=20
> code such
> as through GNU Lightning (a somewhat platform independent approach to
> machine code generation under the GPL). Further, it could be=20
> explored by
> having Squeak able to generate new versions of itself without=20
> relying on
> a C compiler, and further by having Squeak able to generate,=20
> understand,
> and make use of problem specific binary code (essentially supporting
> conventional machine language debugging tools). This tension=20
> 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=20
> mind "if you
> can't crash it, you aren't doing the driving"). If the result=20
> 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).
>=20
> > Plus, I already offered
> > to host it outside the SqF, so the little discussion=20
> doesn't exactly endanger
> > the project - if we decide that SqF is not the place, Paul=20
> and I will find a
> > solution.
>=20
> Thanks for the generous offer. I'm starting to think it might=20
> 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=20
> least stress
> on the community.
>=20
> As I have said before, I think the greatest value of Squeak=20
> has been to
> bring together a community of creative and inspired people doign neat
> things. Safeguarding and supporting that community should be=20
> of highest
> priority, and if this request damages it in any way, I will=20
> withdraw it.
>=20
> -Paul Fernhout
> Kurtz-Fernhout Software=20
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D
> 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
>=20