ask for APSL? for real this time?

goran.krampe at goran.krampe at
Tue Jan 13 00:05:20 UTC 2004


"Andrew C. Greenberg" <werdna at> wrote:
> On Jan 12, 2004, at 4:14 AM, goran.krampe at wrote:
> > Hi Andrew and all!
> >
> > Since you still haven't responded regarding the quote I will for now
> > conclude that it probably is for reasons unknown to me (what do I know)
> > and I have instead selected a single question to ask you in hope for a
> > reply.
> Goran, I'm not sure why you are being so beligerent.  While I never 

Well, I have already said why in plain letters. And it just keeps
repeating itself - you simply avoid responding to stuff. For example:

You insinuate that I don't treat the community seriously - and then when
I ask if that is indeed what you are saying - no response.

You imply that I have "proposed a path" and when I react strongly on
that - no response.


> considered the "quote" you so frequently refer to as contrary to my 
> present position,

That I simply can not get into my head.

> I intended the quoted portion below missive to be the 
> detailed response you were seeking, placing your expansive reading of 
> my prior remarks in a clearer context, hopefully so we can find a basis 
> for mutual understanding.  In particular, it was intended to answer 
> your specific question.
> > Regarding the quote: It simply seems to me that you have changed your
> > mind regarding what can be considered a modified work - and that is the
> > source for the change in attitude towards dual licensing of
> > contributions.
> I don't agree that I have changed my mind, but it doesn't matter. 

It matters to me, because I want to understand this.

> As 
> to the practice you now thing was based upon my advices, this is my 
> considered view:
> 	Don't do it any more.  Stop.  Fix it.  Please.

I assume you mean the practice of allowing code written in Squeak that
is not covered by the viral aspect (modifications to base) to be dual
licensed under Squeak-L and MIT.

Given your language of today you seem to expressly discourage *any* kind
of dual licensing regardless of which license the "other" would be, for
code to be considered as official base Squeak.

Given the quote (that you still haven't explained), and hey - I can
repeat it ad-nauseum:

"I believe that we could survive with a communal understanding to
release all of our code under Squeak-L, or a more liberal license, dual
licensed with Squeak-L understanding that it gets viraled into Squeak-L
when thrust into the image."

Let's have that in slow motion:

...or a more liberal license, dual licensed with Squeak-L...

Ok, how much clearer must it be? At that time you said that we could do
that - I will grant you though that you didn't say how much more liberal
such a dual license could be allowed to be. Perhaps you meant that such
a license still must be "no less protective of Apple yaddayadda" which
MIT is clearly not.

But the fact remains - we have discussed this at length on the list on
several occasions and never once before have I heard that dual licensing
with Squeak-L/MIT could be a problem.

And even so - your view today is clearly that dual licensing *at all* is
a problem.

> The fundamental difficulty (which is also the fundamental attraction to 
> "free software" ideologues) with viral open source licenses, is that it 
> is difficult in most every case to avoid licensing any related code 
> under any license other than the original license.  Squeak-L is 
> quasi-viral, but viral enough so that you always have a problem 
> whenever you make a derivative work, or a work that a potential 
> plaintiff might call a derivative work.
> In the last round of "what license next," there was a part of our 
> community that did not like BPL and related licenses, in part, because 
> they were non-viral.

Sorry for me being ignorant - what does BPL refer to?

> Yes, if you work on or in Squeak-L code, you may be barred from 
> licensing it under anything other than Squeak-L, at least if you want 
> to be safe from legal ambiguity.  That is my point -- the image code 
> MUST be free from such ambiguity.

> This point was made, with clarity, 
> even in the quotation of mine you love to recite, which notes that code 
> stuck in the image is likely Squeak-L, regardless how the author wants 
> to license it.

Eh, what? It didn't only say that! See above.

> For SqF, the question is this: how to maintain a codebase with a clear 
> and consistent, and legally defensible license?  This is an open source 
> project, and we can never be certain whether a submission by a random 
> person infringes a copyright or patent, or was copies from SCO sources 
> or otherwise.  But if it was built in Squeak, we can be fairly 
> confident that it will not violate Squeak-L to license it under 
> Squeak-L.  If it was built in Squeak, we cannot be certain without 
> substantially more and detailed analysis, both of a proposed 
> alternative license and the particular code itself, whether it may 
> otherwise be licensed.

I find this to be a sad day in the Squeak community. If what you say is
true then Squeak just turned out to be a really bad choice for people or
companies interested in building things with it under other licenses
than Squeak-L.

> There simply isn't enough money in our group to defend a serious 
> lawsuit from anybody -- we need to keep our code as copyright and 
> license clean as possible.  Period.  We should take a prophylactic view 
> of these things, in my view, to preserve the ability to go forward and 
> not have the entire project brought to a screeching halt because of a 
> self-inflicted wound that we didn't need to take.  Seriously, really, 
> absolutely, don't misundertand me.  My advice concerning the present 
> practice is this:
> 	Don't do it any more.  Stop.  Fix it.  Please.
> Certainly don't continue it in my name.

Again, I interpret this to mean that all code that is developed in
Squeak - regardless of if it contains modifications to the base or not,
it simply is enough that it is built *using* Squeak - can only be
released under Squeak-L and *ONLY* Squeak-L unless you hire a laywer to
do "substantial and detailed analysis" of the proposed other license and
the code.

Hell, it may even be enough that you have looked at the Squeak source
code to be in trouble, who knows.

If my interpretation is correct it simply sucks. And I assume this may
also mean that SmaCC must be thrown out and that no packages that we
want to distribute as the official Squeak can have any other license
than Squeak-L and ONLY Squeak-L.

This means that SqueakMap itself for example is a problem...

regards, Göran

More information about the Squeak-dev mailing list