Lex, thank you very much for taking the time for such a complete answer, I appreciate it.

"Lex Spoon" lex@cc.gatech.edu writes:

You raise a lot of issues, Chris. A lot of these are actually better, if you the docs would just point you better. Some are getting better, I think, but certainly still need work.

IME, this is not all unusual in Free software, especially when it 'moves' as fast as Squeak seems to. Documentation always lags, and I've notied serval times that when people ask Richard Stallman the best thing to contribute, documentation and testing are alway at or very near the top of the list.

But it is unfortunate, especially since Squeak's major intended audience is the opposite of 'geekly'. :-)

Also, since I posted the original, I've learned a *lot* more - someone on #squeak mentioned your Universes work, and I read a little about it. That looks like a *big* step in the right direction, and believe me, I am familiar with a lot of the issues and realize what a challenge coming up with a reasonable solution is.

So I feel much better already, thanks.

A few resources you should have in mind:

1. There is a Debian package of Squeak, but it is not in Debian proper

because of licensing disputes. (If you have any idea how to resolve that, it would be great to know -- writing to debian-legal has just gotten me into a never-progressing debate.) Anyway, on the swiki, go to "Downloading Squeak", then "Download for Unix", and then "Squeak for Debian Users":

http://minnow.cc.gatech.edu/squeak/3616

2. There is a "stable 3.7 universe" release which has loadable Comanche.

Grab the 3.7univ image from the Debian repository, or go to . I know that that version basically works, because an older version of Universes was using that version. (I've since dumped it in favor of a StringSocket-based protocol, augmented by a static webserver to help people behind firewalls -- which is the main reason to use HTTP outside of real web browsers.)

Thanks, if only I had known about that before! In the meantime, I got 3.7 running from the linux tarball at the 'inria' site, though Goran and C. Degroot (sp?) had to help debug Pakage Loader, which refused to load *anything*.

UUIDGenerator's makeUnixSeed was getting nulls when it tried to read /dev/urandom, and Goran suggested that I comment out rhe first two lines. After that - woot! Everything I wanted - KomHttp, Seaside, Swazoo, Postgres, MySql - all dropped right into place and fired up just fine.

For the record, it looks like the Swiki distribution comes as an image already bundled with (an older) Comanche? I haven't tried that yet, but plan to very soon, on my old, 200mhz server (with SCSI drives).

That sucks about the man page. I don't honestly have time to work on it, though.... You might want to poke around on the web and see if you can find a good description of the arguments. Honestly, though, you don't need most of those options by far.

If I wasn't such a n00b w/Squeak, I probably would have split my original post into two - one for here and the other for squeak-dev, but I had no idea whether I would even be able to post to squeak-dev.

To pick a nit, individual maintainers aren't that awesome. However,

Yup, nobody's perfect, and there are all sorts of maintainers.

Anyway, one thing we should adopt, IMHO, is the notion of generating stable *sets* of packages. Additionally, we should adopt their approach of not breaking compatibility so much. It's easy to say "let's move to the next great thing in Squeak", but all too often that battle cry seems to amount to loading half-working code that breaks compatibility with existing code. All other things aside, we simply have to be careful about breaking code that *uses* Squeak.

To me, this seems to be the heart of the matter, and man, is it a tough one. It has been a while since I did serious OO work (I've been much more focused on Lisp/Scheme for a couple of years, and database stuff for a couple of years before that), but one I thing I *do* remember is the necessity of being very, very careful how you design the message protocol (I think that is the SmallTalk term? Interface contract, more generally).

Code needs to change over time, that is a given. And keeping old methods around so that old code doesn't break, or refactoring them to use the newer ones isn't very pretty, either, or even always possible.

Another important factor here is the *type* of thing being written - monolithic apps are one thing, reusable building blocks that other people can rely on to incorporate into their programs entirely another, and at least another order of magnitude more difficult to do well.

They do indeed take 1-2 years to produce new stable releases. I don't know whether we will end up in the same boat. They, like us, seem to have trouble finding volunteers to help with those last several release critical bugs. I agree that it's worth it, though, so long as it doesn't take any longer than this. Having an occasional stable release is a very valuable thing. It lets people work in Squeak without dealing with the day to day errors that developers are adding.

Producing a stable release of hundreds (as in Squeak's case) or thousands (as in Debian's case) of software packages is simply a mind-boggling feat, in my view. Its like the saying about the dancing dog - it isn't so much the fact it dances well that amazes, but the fact that it dances at all. :-)

I noticed that in Squeak Map, some packages offer both a current release and earlier versions - Comanche for example offers 3 versions, I think. If we extend this idea a bit, a repository of all earlier published versions might be useful for the more technically capable Squeak users - does something like this exist?

One of the things that I really like about Squeak/ST is some of the ideas inspired by Lisp and the old Lisp machines - access to the entire system's code base, change-on-the-fly, browsers and built in version control. Concerning the latter, in the Lisp world one decides on a number of versions to be kept for an object (this can be 'all'), and the system takes care of it, so the recent change history is available locally, but not when published, unless one chooses to include the version history. From the very little I know of Squeak, the 'changesets' facility is similar? (At the moment, the Swiki on 'minnow' seems to be refusing connections.)

I don't know if you are familiar w/Tom Lord's version control system, GNU/Arch, but it uses *nix programs diff and patch to manage changes, and when you grab a package from an Arch site, you get the entire change history. So it makes it easy to recreate any version of the software. (In fact, they use the concept of a 'patchset'.) IINM, CVS makes this possible as well, though I think it takes a bit more work than with Arch.

More to the point, that is how Arch-maintained software is distributed - with the version history. The process of fetching the archive includes applying all the patches to the original version, so when the fetch process is complete, you have the current version, freshly reconstructed, in your directories ready for building, if necessary.

So unless it is only binaries being shipped, one has the entire history.

With both Arch and CVS, it is possible to define 'synch points' across multiple components of a project. For example, just before shipping something deemed 'stable', one flags the current state of the repository with a 'label', and anytime thereafter it is simple to get that version of the product out of the repository, even if extensive changes have been made since. One can even rollback the repository to that point.

If one were to combine the concept of Debian's pseudo-packages (I forget at the moment the correct name), with either a remote repository containing the complete version history, or local packages with version history, it seems to me this would go a long way to ameliorating the situation.

Simpler yet, a repository of all versions *released*, and psuedo-packages, though this assumes that earlier releases have no image version dependencies.

Let's use Swiki and Comanche as an example. I notice that Swiki currently ships in an image bundled with the version of Comanche it requires. Assuming there are no Squeak image version dependencies, it would be a simple matter to define a pseudo package for Swiki-Comanche that would, either from a remote repository or from the local packages, extract the correct versions and proceed with the install.

I mention all this because I am far more familiar with Arch and CVS than with Squeak changesets, but it seems with changesets already available in Squeak that it is 'do-able'.

Of course, I am a total n00b here - doubtless this has all been considered and rejected for some good reason that will become obviuos to me as I learn a bit more!

...

I have noticed that some Squeak packages do run SUnits test as the last step of install, a practice I like a lot and wish were more widespread.

I don't really like this kind of thing, personally. I wish packages would quietly load and unload and not try to get in my face with helpful offers. Automatic test-running applies to every single package, and thus it should be supported in the test loader, not as a part of each package.

Ummm, surely the tests should ship with the source code? And the only reason I noticed the Sunit tests running was because I had a Transcript open. Curious monkey that I am, I decided to see what, if anything, showed up during package loading - quite a bit, as it turns out. If I hadn't had the Transcript open, I don't think I would have seen anything related to the tests, unless perhaps they failed? And if the tests failed, I would certainly hope I was notified!

Same with documentation, configuration options, extra load options, and dependencies. Don't say "Would you like to load *mumble*"; put it as a "Recommends" dependency. Don't pop up a workspace -- install a document into the system documentation repository.

Or perhaps offer an option for a 'verbose' package load that if enabled, does all the things you dislike ;-) otherwise behaves as you'd prefer?

Where might I find such a beast, this 'system documentation repository'? I'd *love* to poke around in it for a while. I think?

-Lex

Matej Kosik kosik@fiit.stuba.sk wrote:

PS: Why didn't we register Squeak _directly_ in Debian's package repository? (main/contrib/non-free).

IIRC that was a no, no because of their dislike of the indemnification clause. But that is just my vague recollection - may be wrong. Lex probably knows.

regards, Göran

I usually agree with you Lex, but Debian is right not to make exceptions. They set a clear policy and they stick to it as best they can. Squeak is one project among thousands; it doesn't make sense for them to assume any legal risk at all.

On Thu, 24 Feb 2005 21:49:29 -0400, Lex Spoon lex@cc.gatech.edu wrote:

Everyone, I do believe we could get Apple to change the license to APSL.

Heh, funny, but is it the time of the year? I'm quite positive that this topic pops up every year around Feb/Mar ;)

Having said that, I think the 'emulate Croquet' route is the way to go. Just publish the whole shebang under a new license, SqueakL minus indemnification, and be done with it. Gee... it's just some stupid contraption invented by lawyers, this licensing thing...

(oh, and if we need a legal entity as a licensor, I volunteer my company. I can even add a d/b/a Squeak Licensing ;))

"Lex Spoon" lex@cc.gatech.edu writes:

goran.krampe@bluefish.se wrote:

...

Matej Kosik kosik@fiit.stuba.sk wrote:

...

PS: Why didn't we register Squeak _directly_ in Debian's package repository? (main/contrib/non-free).

IIRC that was a no, no because of their dislike of the indemnification clause. But that is just my vague recollection - may be wrong. Lex probably knows.

That's the killer reason it is not even in non-free. There are also various reasons it is not in main -- e.g., because they don't like the export clause, and they don't like the font clause -- but who cares about main versus non-free?

I've read a lot of different open/free licensesm and at first glance, I was little concerned about Apple's, but on closer inspection it looked basically OK to me, except for the fonts. And definitely non-free.

Fonts, export, indemnification - all no-no's in the Free world. :-)

I feel almost as strongly about Free Software as does RMS. There is software I'd like to use but won't because of the license. The Apple license was right on the cusp, but after playing w/Squeak a bit, I reconsidered and decided to use it, but I am also seeing if GNU/Smalltalk can be used to do what I want, just in case.

I spent a while arguing with the Debian guys about this on the debian-legal mailing list (which, as far as I can tell, is the only place to talk about such things). The only reason to reject it from non-free, is that there is a legal risk in doing it. However, is it a realistic risk that someone is going to sue Apple over Debian's involvment with Squeak... when they could have just sued Debian directly? And if Apple does get sued -- over an open source program, that Apple has released for free, and has made no claims express or implied etc., and that Apple no longer has anything to do with -- if Apple does get sued, are they really going to pester Debian about it, even though they have made a self-image of championing open source software? And even if they were that nasty, would they be so stupid as to offer to turn over their defense completely to Debian? The clause requires this, and thus I can't imagine Apple ever trying to cash in on it. And even if Apple does get sued over a product they have nothing to do with and that has no warranty express or implied, etc., and even if Apple is really that nasty *and* that stupid, what is wrong with Debian saying "yes, we'll defend the case ourselves, thank you". Since Debian could have been sued directly, doesn't this effectively put them back where they started?

Apple is an American corporation, and the license looks very much like a short commercial license with a few words changed.

But consider this scenario: somebody uses Squeak to hack into Experian, makes off with a few hundred thousand credit reports, sells them to the Russian mafia, and gets caught. This has actually happened, but he was using a Windoze box, not Squeak.

Now suppose that at some point our perp tells the Fibbies (FBI), who have some good very tech-geeks and would be vaey curious as to why Squeak?: "I used Squeak because it has features nothing else does'.

True statement, though the chances are very, very slim that Squeak's features were key - he almost certainly could have done the same thing from Python. You, me, we all know that.

Lawyers and judges, however, generally are not Alpha techno-geeks, to say the least. But naturally they are going to try and find out a bit more about it, and boy oh boy do they understand licenses - people abusing licenses can make them *tons* of money.

Naturally, Micr$oft will get wind of this - they are so wired into the government they almost literally laughed at their 'punishment' for monopoly abuse, and have been merrily ignoring many of the 'remedies' imposed on them.

Money and politics, money and politics. Consider SCO, and who was backing them.

You think ole BillG is going to pass up a chance to stick it to his 'buddy' Steve at Apple? Ha ha, sure. Over an open source program? BillG and "Monkey Boy" Ballmer would be *shouting* to the *world* "We told you open source was dangerous! We told you so! Nyah nyah nyah nyah!"

Now, suppose it was a web site ending in '.gov' our perp cracked, or our perp was of Middle Eastern descent. Never mind about gross negligence on the part of the web master, sysadmin, etc., for the .gov site - that would all be 'classified' anyway, so our perp's lawyer can't use it in court.

In today's current event climate, it seems pretty clear that it is far from unimaginable that more than a few lawyers would go orgasmic just thinking about a case like that.

Sad state of affairs, and I have I no idea if Debian-legal thinks along the same demented lines I sometimes do, but then our legal system seems to be ever more demented about computers and software, especially when they are Free.

In my optimistic moments, I expect the pendelum to swing back eventually. For goodness' sake, Debian now rejects the Mozilla Public License and also the GNU Free Document License (GFDL). How far will

It really got my attention when I saw an interview in which RMS commented on Debian not liking the GFDL - he seemed a bit irked at them, but said it was their decision to make.

I got curious and looked into the issue on the Debian mailing lists, and to my surprise, I thought they had a couple of good points, but forget what exactly.

But GFDL is good enough for me.

In the meantime, I have far better things to do with my time than go around in circles with those guys. That battle is winable, I believe, because Debian exists to do things like distribute Squeak. However, the energy and time required to convince them of what's in their own good, is extraordinary and could be better spent elsewhere.

I don't suppose that there is any chance of Apple allowing re-licensing? If it is only the idemnification clause keeping Squeak out of Debian, there may be some way to ensure that they still get (deserved) credit, and of course the fonts stuff would have to be in the new license as well.

-Lex

Lex Spoon wrote:

goran.krampe@bluefish.se wrote:

...

Matej Kosik kosik@fiit.stuba.sk wrote:

...

PS: Why didn't we register Squeak _directly_ in Debian's package repository? (main/contrib/non-free).

IIRC that was a no, no because of their dislike of the indemnification clause. But that is just my vague recollection - may be wrong. Lex probably knows.

That's the killer reason it is not even in non-free. There are also various reasons it is not in main -- e.g., because they don't like the export clause, and they don't like the font clause -- but who cares about main versus non-free?

I spent a while arguing with the Debian guys about this on the debian-legal mailing list (which, as far as I can tell, is the only place to talk about such things). The only reason to reject it from non-free, is that there is a legal risk in doing it. However, is it a realistic risk that someone is going to sue Apple over Debian's involvment with Squeak... when they could have just sued Debian directly? And if Apple does get sued -- over an open source program, that Apple has released for free, and has made no claims express or implied etc., and that Apple no longer has anything to do with -- if Apple does get sued, are they really going to pester Debian about it, even though they have made a self-image of championing open source software? And even if they were that nasty, would they be so stupid as to offer to turn over their defense completely to Debian? The clause requires this, and thus I can't imagine Apple ever trying to cash in on it. And even if Apple does get sued over a product they have nothing to do with and that has no warranty express or implied, etc., and even if Apple is really that nasty *and* that stupid, what is wrong with Debian saying "yes, we'll defend the case ourselves, thank you". Since Debian could have been sued directly, doesn't this effectively put them back where they started?

I AM NOT A LAWYER. Just to be clear. However, neither are any of the people I was arguing with. Which just makes it triply annoying: they are bantering about around an obscure legal risk, when they don't know diddly about law to begin with.

I'm sure Debian already does plenty of things much more legally dangerous than this. I mean, what if Netscape sues them over some obscure clause in the mammoth MPL ? What about all the questionable stuff floating around in the Linux kernel sources? Why aren't they freaking out about these possibilities? And who knows where, in the millions of lines of code they distribute, there might be a patent violation?

At this point in the discussions, people start pointing out that maybe Apple will get sued even though Debian did nothing wrong (duh) and Apple did nothing wrong (duh, because Apple does nothing at all with Squeak, how could they do anything wrong?). The answer to this is obvious: if you start worrying about frivolous lawsuits, you are hosed anyway. You may as well stay home and do nothing. If some awesome lawyer really tries to sue Debian into oblivion, they are not going to need an obscure indemnification clause to do it.

Unfortunately, there's no way in Debian's org to get a real ruling on the matter, and so these packages are living off site still. If someone has more time and energy than me, you may want to press ahead on it, by either quitting your job so that you can spat on debian-legal 40 hours a week, or by pushing for a general resolution, or by whatever other approach seems right. Maybe it would make sense to broach these issues in general, e.g. how should Debian deal with *realistic* risk as opposed to *every possible* risk, or e.g., how should Debian deal with abandonware, where the license *can't* be changed? Alternatively, maybe someone should try to bypass debian-legal and get a general resolution on Squeak. Or, maybe someone should really get excited and try to propose a change to Debian's organization so that they actually have some sort of real decision-making process about what goes in or out.

In my irritated moments, I wish someone had talked to the Squeak list before making the initial proclamation to debian-legal that there is a problem. The first guy who mentioned Squeak to the Debian guys said basically "I see some problems, and I give up", without mentioning it on squeak-dev that I ever saw. If he had come here first, we could have put together a better analysis and a better argument that Squeak should be in Debian. Now, because of the ordering of things, the status quo is that Squeak is out... and in a sea of people who don't care and can't agree on anything, the status quo tends to stick around.

In my optimistic moments, I expect the pendelum to swing back eventually. For goodness' sake, Debian now rejects the Mozilla Public License and also the GNU Free Document License (GFDL). How far will they go? They used to be a Linux distribution.... but if they keep this up, they will not actually *distribute* anything! There's a good chance that the general membership of Debian will object when this silliness reaches some threshold. When that happens, either the criteria will be modified to something more reasonable, or people will fork into a more tolerant distribution.

In the meantime, I have far better things to do with my time than go around in circles with those guys. That battle is winable, I believe, because Debian exists to do things like distribute Squeak. However, the energy and time required to convince them of what's in their own good, is extraordinary and could be better spent elsewhere.

-Lex

A _future_ plan might be perhaps follows:

Let us count people which use Squeak on Debian. Let us all dedicate some amount of money and invest it purposely (not the time of all of us). If we raise a similar discussion on a proper forum with a dedicated laywer(s) and technically skilled people (or both) on our side, we could perhaps persuade the ignorant saboteurs hindering integration. We should organize a petition. We should write a manifest.

Or, there are other options. Installation of Squeak on FreeBSD (I witnessed it on the computer of friend of mine) is quite reasonable

cd ports/squeak make install # or something like this---I do not remember pricisely

We could perhaps point it out and argue. I am willing to dedicate some money for the sake of this affair. I am willing to donate part of (poor by my) wages. If "foreign transfer command" works (I did not yet try it) it would not take much time of us all except those specialists. A harder lobby is needed.

That would be good. A lot of things fit into debian that way and are used every day (eg flash). I think well maintained debian packages for squeak, linked on squeak.org would be a good step in that direction.