Paul asks

> I'd appreciate a more precise use of language when you imply for example
> that I am "positing threats" about a fork.

and then writes:

> B. I have tried on numerous occasions to reduce the chance of such a
> fork by saying a fork will be inevitable if certain issues are not
> addressed by SqueakC,

Q.E.D.

> C. FYI, If I was going to make a fork of my own at this point given the
> current existence of "Stable Squeak" fork, it would be more on the basis
> of establishing a clear legal title to all the contributions made to
> Squeak from the original Apple release by starting from the original and
> one by one re-adding changes (or making my own replacements), going
> through a methodical process of establishing who the contributor was,
> and getting when appropriate a signed assignment of copyright and
> statement of originality from each author including those at Disney (or
> a statement that they had permission to make the contribution of other
> copyrighted work, or if their employer owned any IP they made that they
> had the employers permission to contribute) similar to as is done by the
> FSF for GNU products or for Python when it was at CNRI. That is the
> other major thing I think Squeak needs (although for legal, not
> community or technical reasons), but that is another topic on which we
> disagree (based on our previous discussions on this list).

True (except for Paul's mistaken assumption about FSF -- I can't speak 
about Python, except that I have contributed some code, and I have never 
signed anything), and readers are invited to review the amazingly 
over-exhausted arguments on this subejct in the archives.  I will not 
rehash them here, but will make a few observations:

I'll note that as between Paul and myself: one of us is a well-regarded, 
published computer lawyer, and the other is not.  Disney, and their 
lawyers seemed unafraid.  Apple and their lawyers seemed unafraid.  
Exobox and their lawyers seemed unafraid.  Gentle readers are invited to 
decide for themselves.  Clearly, each individual should consult their 
own attorney whom they have hired to represent their interests.

But the kind of comfort Paul seeks in an open source project is 
unavailable anywhere.   There are huge legal risks inherent risks in ALL 
open source development projects -- anything less than a dedication to 
the public domain risks a unilateral revocation of each and every 
contribution.  Paul seeks a degree of comfort at odds with every open 
source ethic, and not likely to be found anywere.  Apple just released 
(indeed, bet the farm) by committing to an OS relying on the 
reasonableness of a vast amount of BSD and open source software and 
their licenses, none of which meets the standards Paul insists are 
necessary.

The legal questions ARE interesting and worthy of discussion, however, 
just as are the issues of modularity.  None of these issues require, let 
alone suggest the virtues of, a fork, however.  None of them.