ask for APSL? for real this time?

goran.krampe at goran.krampe at
Thu Jan 15 14:38:10 UTC 2004

Hi Andrew and all!

Ok, just before I begin - I truly, truly am discussing this because I
want to understand it. I am not "fighting" anything or anyone. I am
simply confused and while being confused by weird code using
continuations is quite alright - it is NOT alright to be confused about
licenses. Definitely when you are using them. ;-)

Here we go.

"Andrew C. Greenberg" <werdna at> wrote:
> On Jan 12, 2004, at 7:05 PM, goran.krampe at wrote:
> > 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.
> I am not insinuating that you don't treat the community seriously.

Good. But it sure sounded like it.

> > You imply that I have "proposed a path" and when I react strongly on
> > that - no response.
> I don't know what you are talking about.

I am talking about this, you wrote:

> As I have noted, please at least understand it comes from a 
> mutual love of Squeak -- I want to SOLVE our licensing problem, and am 
> very fearful that your proposed path will exacerbate the issue.

And I responded:
> *My* "proposed path"? I am speechless.

...and then nothing. But whatever, forget it. I will.

> >> 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.
> Aside from writing, as I have, in detail to distinguish practices that 
> are problematic from those that are less so, how else may I help you?

That is perfectly fine - I was just saying that it does matter to me in
order to understand it.

> >> 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.
> No.  Code that is not covered by the viral aspect of Squeak-L may be 
> licensed in any way.  But you are presuming that this is so, and for 
> code developed in Squeak, there is simply no practice way to do that.

Ok. The gist is then I assume - code developed *in* Squeak is
potentially smitten, at least for all legal practical purposes, that is
how we should view it.

> > 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.
> No.  I made clear that dual licensing is not as dangerous in certain 
> circumstances.

Ok - but not for code developed *in* Squeak - which was what I meant but
didn't explicitly write.

> > 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."
> OK
> > 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.
> Code not developed in Squeak can be do distributed.

Eh, code not developed in Squeak can *obviously* be so distributed -
because why would Squeak-L have anything to do with it then? But I am
with you - fine.

> Code written in Squeak cannot be safely so distributed absent 
> affirmative proof that the code was independently developed.  You are 
> not capable of maintaining a clean room for all Squeak code, nor do we 
> have any team of individuals capable of executing code development 
> under a clean room.

Ok, so my misunderstanding here is based on the fact that I *assumed*
that "all of our code" that you mention in the quote was *developed in
Squeak*. I think that was an honest mistake to make - given that such
code is what we are talking about 99% of the time in this community.

> Don't do it any more.  Stop.  Fix it.  Please.
> > 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.
> You have heard it MANY times now.  You don't like that I have so 
> stated, but that is what I am saying.  Don't do it any more.  Stop.  
> Fix it.  Please.

Sure, I have heard it MANY times this last week. But we have been
talking about the dual licensing (and practicing it) for quite some time

And also - it isn't about liking what you say - it is about liking what
this *means*.

> > And even so - your view today is clearly that dual licensing *at all* 
> > is
> > a problem.
> No.  that is an overstatement of my view -- a straw man.

But again - I am talking about code developed in Squeak. I am a
Squeaker. This is squeak-dev. I code in Squeak.

And given code developed *in Squeak* - that is what you are saying. So
code developed by us *in Squeak* and meant for *base Squeak* (private
packages are up to the authors of course) can ONLY be released under
Squeak-L. Period.

A little question regarding SM: Are you also opposing SM to list
packages that are NOT in official Squeak and that are under other
licenses? I have always viewed SM as a catalog - so what I am wondering
- is there in some way that SM can be viewed as the distributor of those

Hmmm, I assume SM2 can obviously be considered to be the distributor
(since it allows uploads and also has a cache). Damn, this is really
making an ugly turn. Ok, what is your advice on that?

> > Sorry for me being ignorant - what does BPL refer to?
> Berkeley Public License.  The code under which  most of FreeBSD is 
> distributed.  Ultra-liberal, like MIT.

Oh, I always refer to that one as BSD. Ok.

> >> 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.
> I wouldn't use Squeak to build non-Squeak-L code.
> I disagree that it is particularly problematic for Squeak or at all "a 
> sad day."  I suggest that those who would like to license code more 
> liberally get with the program, suggested elsewhere by Doug, and 
> contemplate how we might relicense the code base entirely, rather than 
> engaging in the generally useless artifact of a dual license (which is 
> ENTIRELY a legal sleight of hand).

I was more considering companies and individuals that are interested in
making proprietary products written in Squeak. AFAICT that goes out the
window. Or? That was after all one of the key points of Squeak-L that
has been touted all along. Now it looks like it was a mirage.

> Note that ANY dual-licensed code, because disjunctive, can be taken by 
> ANY individual and relicensed under just one of the two.  Where code is 
> practically used only in Squeak, it makes no difference at all.

Perhaps everyone else understood this paragraph - but my thick skull
isn't parsing it. :)

> > 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.
> Overstated, and a bit of a straw man, but not entirely wrong.  The 
> COMMUNITY cannot afford to redistribute code other than in Squeak-L for 
> the reasons previously stated, but individuals may opt to take such 
> risks as they determine to be appropriate.

Hmmm, why would individuals want to take that risk? Doesn't sound like I
can recommend Squeak to other people for making apps anymore.

> >  And I assume this may
> > also mean that SmaCC must be thrown out
> SmaCC was not developed in Squeak, isn't that right?  to the extent 
> there are deltas, we can parse those out from the central code-base, 
> and separately license the changesets, the "pure" code in dual, and the 
> impure code in Squeak-L.  However, it is uncelar that much is gained, 
> since a Squeak-made fork of SmaCC can be taken by any individual and 
> made purely Squeak-L just by that person opting for the Squeak-L prong.

And that individual is then covered by say the indemnification clause -
I mean - to fork SmaCC under Squeak-L someone needs to make the
sublicense I assume.
At this point a SqF would be nice to have I guess.
> > 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.
> I made clear that certainly some packages could be so distributed.  As 
> a practical matter, however, this class of packages does not include 
> code developed inside of Squeak.
> > This means that SqueakMap itself for example is a problem...
> Goran -- I'm not sure for what you are fighting.

Hehe, I am fighting *to understand*. And since I seem to be currently
breaking the Squeak-L (SM) then I want to understand this. And what you
say is making All Difference In The World. But *only* if it doesn't
sound like gobbledeegook. ;-)

> Any person could take 
> SqueakMap tomorrow, change a comment, and relicense it under Squeak-L.

Yes... (rubbing temples)

> the danger is, if it *IS* derived, for the poor saps who opt for the 
> MIT prong for use outside of Squeak.

...because that "prong" (I guess it means branch or something) isn't a
"correct" license? Right?

Andrew - I think I understand all now - both the misunderstandings etc.
You may of course prove me wrong. But...

...could you please elaborate just a teeny bit more about how *I* can
release something under Squeak-L which doesn't even mention my name and
mentions Apple quite a lot? I mean - wouldn't it be better if we *at
least* produced a sublicense for us to use in which we can replace the
name "Apple" etc appropriately?

It seems so "strange" to "release something under Squeak-L". I know this
was also what bugged John Brant with SmaCC etc.

regards, Göran

More information about the Squeak-dev mailing list