On Jan 12, 2004, at 4:14 AM, goran.krampe at bluefish.se 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 
considered the "quote" you so frequently refer to as contrary to my 
present position, 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.  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.

> Anyway...
>
> "Andrew C. Greenberg" <werdna at mucow.com> wrote:
>> 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.
>
> Reading this and also further down in your posting you wrote:
>
> "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."
>
> ...leading me to wondering if you then think that the following 
> scenario
> is also "legally problematic":
>
> I (or a company) write an application in Squeak (no base modifications)
> and then license that application to someone else under a license of
> my/the company's choosing.
>
> Because as I interpret you the problem here is not the distinction 
> about
> modifications to the base but rather that ANYTHING I produce inside
> Squeak is (or at least can be considered to be) a *modified work*.
>
> And *that* means, given the language of the license:
>
> "You may distribute and sublicense such Modified Software only under 
> the
> terms of a valid, binding license that makes no representations or
> warranties on behalf of Apple, and is no less protective of Apple and
> Apple's rights than this License."
>
> ...that say using MIT is out of the question. Because it is probably 
> not
> "no less protective of Apple and Apple's rights than this License".
>
> So Andrew, is this an at least somewhat correct interpretation of the
> siuation? :)

The answer is simple: it depends.  This is the answer to almost any 
legal hypothetical, because the facts can always be twisted to yield 
different results.  Like it or not, that's the way it is in such 
matters.  Every company that deals with a Source code license faces the 
same problems.  Always.

Your analysis has some legal difficulties, confusing the contract 
language "Modified Software" with the Copyright notion of "derivative 
work," since a cause of action might arise, severally, in contract or 
copyright infringement  -- but I'll skip over the hypertechnical issues 
to say that, at the bottom line, you are close to right:

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.

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.

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.

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.
-------------- 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/20040112/90748522/smime.bin