ask for APSL? for real this time?

Andrew C. Greenberg werdna at mucow.com
Sat Jan 10 17:38:02 UTC 2004


1.  On Squeak-Map acceptance of dual-licensed code drawn from Squeak.  
It seems to have been suggested that I have left the community with 
ambiguous and/or waffled views concerning  a licensing question.  I 
hope with this posting to, at least, clarify what is my position.  As 
to:

Whether the community should continue the practice of reproducing or 
distributing Squeak-developed code (whether in-image or extracted from 
an image) under a disjunctive dual license including Squeak-L?

	It is legally problematic.  It is possibly very dangerous.  It can 
come back to hurt us.

if that is too lawyerly, please consider this lay statement.

	Don't do it any more.  Fix it.  Stop.  Please.

That is my position.  It is not my view as to whether or not the 
liberalizing of Squeak-L would be a good thing.  To be clear, I LIKE 
BPL -- heck, if there were no liability issues that can be avoided with 
disclaimers of warranty, I would like public domain dedication for free 
software.  When I say "don't do it," I am not stating whether I think 
it would or would not be a good thing -- I am commenting about whether 
it might legally compromise the product or the community.

Note please, it is not my opinion that every circumstance where this is 
done will immediately yield a paralyzing lawsuit bankrupting every 
reader of this e-mail.  I am stating that the general practice could 
never be approved by a lawyer -- and a policy requiring case-by-case 
analysis would be impractical and error-prone.  Licensing is 
necessarily a conservative business -- the idea of EVERY contract is to 
minimize to the extent practicable the possibility of mistake or 
confusion.  We lawyers write in gobbledegook because we write not so we 
can be easily understood, but rather so that we cannot be 
misunderstood.

Under the present practice, I believe that a lawyer being asked by an 
individual, "can I make this out of squeak and do ____" would probably 
review this and other practices and respond -- "it depends on many 
things, any conclusive opinion would require a tremendously expensive 
analysis -- try Ruby or Python instead -- I can answer your question 
for those products."  In my view, that would be a bad thing.

There is a way to liberalize licensing of the product -- this is not 
it.  It can't be done this way.

Once again, I strongly recommend the following:

	Stop.  Fix it.  Don't do it any more.  Please.

2. On other situations I have discussed in the past.

I have in the past been asked whether a GPL'd or LGPL'd product could 
be distributed with Squeak.  Each case required a careful analysis, and 
in some cases the answer was alternatively, "No," "Yes, if we can talk 
the owner into a dual license," or "Maybe, but it is risky."  These 
were done case-by-case, and the decisions made by SqC and others would 
be made under a totality of circumstances in view of all of the 
relevant factors.  Very useful code was not incorporated in the past, 
and very useful code was.

An example of this would be code entire written by others outside of 
Squeak and hence can not at all be infected by Squeak-L.  The code runs 
without modification in Squeak.  We have no doubt as to the pedigree or 
origin of the code.  The code is broadly licensed under a very liberal 
license that permits others to relicense the code under a more 
restrictive license without consultation.

In such a case, it is possible that such code could be distributed in 
the image under Squeak-L (possibly a more limited conjunctive license), 
or outside the image under a dual license with the understanding that 
once incorporated into the image, the code becomes Squeak-L (the more 
liberal disjunctive arm of the license is only for uses where the code 
is NOT used with squeak).  In many such cases, we may be able to 
distribute the code without problem.

This is a narrow hypothetical, and the devil is in the details.  For 
example, assume that to make it run in Squeak, you must first load the 
changeset, make "minor" modifications, and then extract the modified 
code for use with Squeak.  Could this code be extracted and dual 
licensed?  The devil is in the details.  The safest way would be to 
have the original unmodified code distributed by itself, together with 
a Squeak-L only changeset embodying the modifications.

Even this hypothetical is dramatically narrower than the more general 
circumstance under which SqF seems presently to be operating.

3. On my general inability to spend more time than I have with Squeak 
this month.

I am simply not able to offer more time than I have.  Notwithstanding 
the suggestion that I do not carefully enough read these threads, or 
that I somehow should spend more time more carefully detailing the 
bases for these conclusions, I still don't have more time than I have.  
Sorry, but that's the way it is when you have a 70 witness, 10 week 
trial (involving, by the way, FAR SIMPLER IP issues)  looming in your 
near future.

CONCLUSION

	Stop it.  Fix it.  Don't do it any more.  Please.
-------------- 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/20040110/2fca92ef/smime.bin


More information about the Squeak-dev mailing list