Debian and SqueakL revisited again...(was Re: Debian source package)

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Wed Oct 24 14:57:27 UTC 2001


"Andrew C. Greenberg" <werdna at mucow.com> wrote:
> On Wednesday, October 24, 2001, at 05:18  AM, goran.hultgren at bluefish.se 
> wrote:
> 
> > Andrew Greenberg also wrote:
> >> There was, for a few versions (somewhere between 2.4 and 2.7), a 
> >> message
> >> that clearly stated that contributions and changes were, unless
> >> expressly stated otherwise, made under Squeak-L.  I don't think it is 
> >> in
> >> the present version, but it ought to be placed back, as a matter of 
> >> good
> >> legal hygiene.
> >
> > Yes I second this. And perhaps we could complement the upcoming
> > repository/modules system with some license mechanisms - easy way of
> > stamping a license on a module and also easily have a list available
> > describing what licenses play together etc.
> 
> I'm not for the latter proposal.  The LAST thing we need to do is 
> facilitate alternative licenses for microscopic pieces of Squeak.  In my 

Well, that was not what I meant. The stuff that typically is in the base
today should be under ONE license - Squeak-L2 - I agree. Otherwise it
would be a real mess.

But the module system will also probably fulfill the role of something
like CPAN where people publish their apps and libraries not necessarily
meaning that they are defined as being "base Squeak" modules. And you
should be able to publish something that you have built without being
forced to use Squeak-L2, right? :-)

> view, Squeak-L needs to be fixed, yes.  And thus, Squeak must be 
> backported to Squeak-L2, yes.  In the meanwhile, apart from some 
> discomfort in some quarters and precluding publication as Debian, 
> Squeak-L is internally consistent legally, and has no meaningful 
> problems.  A proliferation of various, potentially incompatible, and 
> mixed-in-image licenses could ultimately kill Squeak or render it wholly 
> unusable for most practical purposes.
> 
> Squeak-L works great for Squeak in practice -- the offensive provisions 
> are not really all that offensive, and the community is solid.  GPL will 
> never be consistent with an image-based product unless the image-based 
> product is GPL'd.  But there are some old sores that are keeping Squeak 

Could I publish my GPLed code as a Squeak project in for example .pr
form and include source with that and then bundle that with a Squeak VM
and a small "boot" image that loads the .pr when started? (More or less
mimicking how the Java guys do it).

If we could consider loading a .pr or ImageSegment as being "linking"
then it should be ok, right?

I would just like to have an answer when a GPL-advocate says he can't
use Squeak for his app since it is not "GPL-compatible"...

> out of the "mainstream" of open source, and they can be fixed in time.  
> Apple has abandoned the policies for license terms that suggest we can 
> renegotiate, and perhaps we should.
> 
> All we really need is the will to do it.  In the meanwhile, the failure 
> to include Squeak in Debian reflects, to me, more of a weakness in 
> Debian policies than in Squeak-L, and is a shame.  But in preparation 

Could you elaborate on that? I mean, do you think they are "wrong" in
their argument or that they just are too "picky"?

And for the stuff you wrote about collecting a "Hall Of Fame" - I agree,
it would be good to be prepared.

regards, Göran




More information about the Squeak-dev mailing list