>We are talking about two sets of issues here. One is the clarity and
>implications of the Squeak license. The other is the specific licensing
>terms of various specific contributions, and further, whether those
>contributions were legally made.

Right, as to the first, I suppose we are in agreement there is no 
issue.  As to the second, I'm alive to this.  This is a difficulty of 
all open source software to some extent.  Oddly enough, it hasn't 
stopped the GNU/Linux movement, or the wide and pervasive deployment 
of its software, even in major corporations.

As to your questions about the licensing status of components, I 
respectfully reiterate my prior disagreement.  A careful reading of 
the license and its viral nature does not limit it, notwithstanding 
the express naming of Apple.

>Another license issue is when using Squeak specifically for embedded
>work. In this case it is not completely clear where the VM boundaries
>begins and ends -- so if you link code into the VM to call MP3 audio
>compression/decompression routines, does this mean you need to also
>release a huge body of work that does MP3 functions? I don't know for
>sure. The safe answer is "yes".

If you say so.  This has to be answered on a case by case basis.  The 
addition of stand-alone pluggable primitive modules resolves almost 
all potential issues in this regard.

>The least risky course of action seems to me to be to go back to the
>original Apple Squeak, modularize it, and then have each and every
>contribution accompanied by a statement of orginality similar in spirit
>to that Python uses.

With all due respect to the interesting issues raised by Paul, I 
think they raise no barrier to use that I can see for most 
circumstances, but his mileage may vary.

IMHO, going back to the "original Apple Squeak" for "recertification" 
would be an extraordinary waste of time.  I, for one, am not fond of 
the notion of a centralized Pythonesque repository, which is most 
clearly the exception rather than the rule.

If you wish to resolve these issues, gather up the sources of all the 
changesets.  Despite thousands of them, there are probably under a 
hundred contributers, and see if you can get e-mail ratification of 
whatever legal documents you may require.

While I don't think it is necessary at all, I don't think it would be 
a bad idea to have an express statement along the lines of 
"distributed under Squeak-L" expressly or impliedly as a matter of 
course, or for Disney to insist that all contributions it includes 
embrace an express

>I don't think Squeak can grow beyond a research toy without grappling
>and resolving these issues as a community at some point.

It already has for others.  Perhaps not for Paul.

The problems raised by Paul do not impede broad deployment and 
commercial exploitation of Berkeley or GPL, and related software in 
proprietary form, though the same issues (except for his license 
interpretation points and concern about the definition of "over the 
line" and "under the line" of the VM) occur everywhere else.

Despite contributions from folks all over the world in a zillion 
different places, few would try to argue that the present versions of 
gcc, BIND, sendmail or dhclient (or the products built around or 
incorporating them) are "research toys."

As I noted, specific requirements may differ from company to company 
and application to application -- if you have questions, rely on a 
lawyer you have retained to apply the particular facts to the 
applicable law.  In the meanwhile, while I'm not seriously troubled 
by the issues Paul raises, and don't share his conclusions at all, I 
think there are some hygiene issues far short of the proposed 
Pythonesque cetification process that will do quite well.
-- 
Andrew C. Greenberg		acg at netwolves.com
V.P. Eng., R&D, 		813.885.2779 (office)
NetWolves Corporation		813.885.2380 (facsimile)
www.netwolves.com

Please use werdna at mucow.com instead of werdna at gate.net