ask for APSL? for real this time?
goran.krampe at bluefish.se
goran.krampe at bluefish.se
Sat Jan 10 15:21:34 UTC 2004
"Andrew C. Greenberg" <werdna at mucow.com> wrote:
> On Jan 9, 2004, at 11:30 AM, goran.krampe at bluefish.se wrote:
> >> In the real world, you don't want technicians to make legal decisions
> >> regarding the licensing of their code.
> > This is the "open source" world where both companies AND individuals
> > are
> > authors.
> Of course. I presume that the open source world likewise lives in the
> real world. I am counsel, pro bono and for pay, for many open source
> projects, and my comments are directed to all players.
What I meant is that in the open source world these decisions are for
practical reasons still left to the authors to take. I can't hire a
lawyer to help me so I, and a lot of other authors in the "open source"
world, need to get enough understanding to make the decisions ourselves.
You know this for sure.
> > When an individual is the author, typically making something in his
> > spare time, he will simply have to do as best he or she can. This isn't
> > the corporate world Andrew, we are simply forced to make these
> > decisions
> > ourselves.
> Nonsense -- nobody needs to make any decisions at all.
You are perfectly aware of that I meant in the general case, and that is
not nonsense. It is plain facts.
> We can do much
> better. We can avoid ENTIRELY any chance that an individual is
> infecting the community's project with invalidly licensed code by
> insisting upon licensing standards. Squeak-L has done quite well for
> years in precisely this manner.
Let me repeat the obvious stuff that you surely MUST be aware of:
- We have long had a standing rule that anything going into the base
image should be under Squeak-L. AFAIK we have allowed, **exactly
according to the quote from you**, to have such code be optionally
*dual* licensed under say MIT too. This is because the contributors of
non-derived work might want a less restricted license for their code -
for example to facilitate its inclusion in other Smalltalks or whatever.
The choice between "Squeak-L only", "Squeak-L / MIT" or "Squeak-L /
some-other-license" has always been up to the author, and of course is
also subject to the rules of Squeak-L (possible derivation yaddayadda).
- Lately we agreed to also let MIT code into the base image, mostly in
order to be able to include SmaCC because John couldn't see what it
meant for him to put his code under Squeak-L - and I surely can't blame
him. At the time *I* was the one screaming the loudest regarding the
license issue, so anyone on this list can tell you that I am *very*
aware of the licensing dangers here. IIRC you didn't post on that
subject. But we agreed that letting MIT code in (and keeping track of
it) was ok since it is such a simple license and since it allows
sublicensing which means some other party (correct me if I am wrong)
could sublicense it under Squeak-L if needed.
So... this is not news at all.
> > I am the author of *my* code and I bloody well *will* decide how I
> > license it.
> Of course, and that's fair enough. it would be my recommendation to
> the community, however, that code you offer to the community under a
> different license not be incorporated into a general release.
And what do you think we have been *doing* for the last couple of years?
BUT... we have allowed **dual** licensing, again *exactly according to
> >> Whether code is derived or not
> >> is not a trivial issue, and certainly not a trivial issue if
> >> litigation
> > I would seriously hope that if I write an app in Squeak without
> > touching
> > the existing classes - just using them, then that app is clearly
> > *according to Squeak-L* not a derived work of Squeak itself. If that is
> > not so then PLEASE tell us, because I assume many of us would like to
> > know that.
> It is not necessarily so. You have been told.
Well *this* is interesting and I think this list includes many people
interested in the ramifications of this but I assume you will not have
the time to tell us more.
> >> of any kind is implicated in a business decision. Having dual
> >> licensing will yield little or no advantage, and may give rise to
> >> later-insurmountable problems that could be resolved now if we
> >> responded promptly.
> > I think this is the last time I will ever bother to respond to you
> > Andrew because I am so fed up with trying to discuss something with you
> > when you only respond to pieces that you pick at your leisure, or
> > simply
> > not bother to respond at all.
> As i wrote seperately, I am sorry you feel so troubled about my
Not your advice - your style of discussion. Please be accurate.
> I have written legions about these issues in the past, and I
> do tend to condense my comments to a shorthand these days, particularly
> now when i have so very little time. It is absolutely true that I
> don't have a great deal of time to respond in depth to each new
> request. 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.
*My* "proposed path"? I am speechless.
> Can we, at least, first see if we can come to consensus as to what
> license, if any, to which we might shift if at all? That is to say, is
> there any license for which EVERY person who's initials appear in the
> code can either:
> 1) firmly adopt; or at least
> 2) agree to consent to shift the code over
> which also might have at least a reasonable shot of getting consent
> once we bring it to the appropriate level at the several corporate
And we are again ignoring the fact that there is another large player
involved here - Disney.
I still haven't gotten a clear answer regarding if they own large parts
of Squeak or not. Alan vaguely says they don't, but recalling the thread
on this from a while back (which you participated in IIRC) it seems
obvious they *should* do since the authors where employed there at the
time. And hey, what do you know - it even *says so* in Squeak itself:
"Portions of Squeak are:
Copyright (c) 1996 Apple Computer, Inc.
Copyright (c) 1997-2001 Walt Disney Company, and/or
Copyrighted works of other contributors.
All rights reserved."
IMHO deciding if it is worth to do the work involved in the above (your
plan) depends heavily on at least getting the Disney question somewhat
> If not, I would strongly recommend just dealing with
> Squeak-L, and alas, shunning any non-conforming code from general
And again - this is AFAIK exactly what we have been doing all along -
except for the allowance of dual licensing (most oftenly MIT). Now you
are saying, contrary to what you have been saying before, that dual
licensing is bad too. Is that a correct understanding from me?
> For my part, I can be talked into almost anything that is not
> monolithic image incompatible. While I like the safe and quasi-viral
> aspects of Squeak-L, I would not oppose a BPL-like license. I am not a
> partisan of APSL, but I do consider that Apple would be far more likely
> to consent to APSL than to BPL. I understand that Cees believes he has
> fathomed this issue, but I sincerely believe that a concerted approach
> after proper preparation, supported by the illuminati (Alan and cabal)
> and directed to executives well above the "manager" position, further
> supported by competent counsel to negotiate issues properly, would fare
> much better.
> I don't believe that Apple would seriously consider any inquiry that
> would be impractical, or lead to any litigation downside for them.
All the above seems reasonable.
> would they treat us seriously if we don't treat our own community
> seriously enough. No kidding, but language along the lines of goran's
> intemperate language earlier is not likely to help the matter at all.
Are you now implying that I don't treat our community seriously enough?
More information about the Squeak-dev