On Jan 12, 2004, at 7:05 PM, goran.krampe at bluefish.se 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.

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

What I am saying is that in certain cases, the practice of accepting 
in-Squeak-developed code for dual licensing and distribution is a very 
dangerous practice, and that we should stop it and fix it.

I hope that clarifies matters.


>> considered the "quote" you so frequently refer to as contrary to my
>> present position,
>
> That I simply can not get into my head.

How can I help this?

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

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

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

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

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.

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.

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

> [SNIP]
>> 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.
>
> 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.

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

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.

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

>  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 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.  Any person could take 
SqueakMap tomorrow, change a comment, and relicense it under Squeak-L.  
the danger is, if it *IS* derived, for the poor saps who opt for the 
MIT prong for use outside of Squeak.
-------------- 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/20040113/59ef30a9/smime.bin