[IAEP] squeak/etoys accepted into Debian main

[Jecel Assumpcao Jr]

Jonas Smedegaard wrote:
> You are perfectly right. Subject changed.

Thanks!

> [a couple of good and clearly summarized observations snipped]

I'll try to keep this short too...

> [it is good to have such debates]

Indeed, but not everybody likes it. The Squeak community itself pulls in
opposite directions - so much so that we even have special terms for
that ("pink plane" and "blue plane" but I can never remember which is
which).

> [the whole point of distributions]

We agree once again (in the Squeak world we had to create the SqueakMap
and Package Universes to deal with the issues you mentioned).

> If teachers and children don't care, then the reason is simply that they 
> got someone else to do that boring (and perhaps complex) task for them. 
> It still needs doing. I suspect the same applies to you (Edubuntu is a 
> distribution too!).

What I meant is that this crowd normally doesn't get stuff from their
distribution which isn't pre-installed. So not only would you have to
put it into main but it would also have to appear in the "applications /
development" menu by default (supposing Edubuntu uses Gnome - I am not
familiar with it. Perhaps I should mention here that I design Smalltalk
computers for children and only deal with Linux as a normal user rather
than a developer).

> >[practical result of relicensing efforts?]
> [value of compatible licenses in a distribution]
>
> So no, I disagree that the tiresome task of getting rid of 3 "silly" 
> clauses was irrelevant. The alternative to getting rid of them would be 
> to relax the restrictions in same 3 "silly" areas for the remaining 
> thousands of pieces that your distribution consist of.

I agree about that - solving the problem in one place via license
standards.

Just to give you a little background on this - Squeak was the very first
open source software for Apple. The lawyers did the best they could by
modifying their standard licenses. You can hardly blame them for not
being compatible with a standard that would be defined a few years in
the future! Squeak moved immediately to Disney and evolved quickly and
you might say that Apple had released it back when it wasn't part of
their corporate culture to do so because they were no longer interested
in it. So when the Open Source definition was created and it excluded
Squeak, it would take a collaboration between Apple and the developers
at Disney to adapt to it and this was not possible.

It took the tremendous mindshare created by OLPC to allow Alan Kay to
ask Steve Jobs to personally deal with this. Apple changed the license
of their part to APSL and then some people didn't accept that so we had
to go back and bother them again to release it a third time under the
Apache license. Then we had to track every single bit of code since 1996
and get each developer to release their part under the MIT license in
signed letters, including bothering relatives of people who have passed
away. Perhaps some of what Sun has gone through for Java and Solaris
might have been of the same magnitude but I can assure you that Mozilla
and Blender were a walk in the park in comparison.

My point was: is forbidding the export clause as part of the Open Source
definition a practical concern or is it just a philosophical checkbox? I
agree that it would not make sense to have one rule for Squeak and
another for the 20K packages you mentioned. And it was the indenization
clause that the Debian people objected to in any case, not the export
one. So changing this aspect of the Open Source definition wouldn't have
helped there.

I just want efforts like these (I contributed very little - just figured
out who a couple of the developers were) to be rewarded by something
actually changing as a result.

-- Jecel