ask for APSL? for real this time?

Andrew C. Greenberg werdna at mucow.com
Sat Jan 10 00:22:26 UTC 2004


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.

> 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.  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.

> 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.

>> 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.

>> 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 
advices.  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.

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 
sponsors?  If not, I would strongly recommend just dealing with 
Squeak-L, and alas, shunning any non-conforming code from general 
distribution.

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.  Nor 
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.

Once the code is BPL'd or APSL'd, we can move forward with much greater 
ease.

So, once again, is there a consensus among actual and legitimate 
stakeholders, whose code is presently distributed in the core image and 
necessary modules, as to what license they might accept in lieu of 
Squeak-L? 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2361 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20040109/dad5dd4c/smime.bin


More information about the Squeak-dev mailing list