Andrew-

Thanks for the great reply.

"Andrew C. Greenberg" wrote:
> 
> >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.

There are several reasons for this.

The legal exposure of a company using something like Perl of Linux or
send-mail in-house is not nearly as great as if they redistribute it.
When I consider personally hosting or using a Squeak for business,
redistribution needs would seem to require a higher legal standard. 

If I am just shipping out Perl scripts and tell people to download Perl,
I am at worst "inducing" people to infringe, and then I am only one
among tens of thousands.

A license like the GPL for much of the core of Linux makes the intent
for distribution of modified versions of that core much clearer. That
is, the company an employee works for will have a tougher time later
saying in court, "well we meant our changes to the GPL code to be always
proprietary" while at the same time saying "we also intended also to
distribute the code not under the GPL". Note it is quite OK to make
proprietary changes to GPL code as long as you don't intend on
distributing the code or binaries, as an ISP might do (and is now an
issue in discussions of revising GPL loopholes). 

With Squeak, it is quite conceivable a company might say that they did
not ever intend for a package built on Squeak to be given away without a
proprietary license, thus increasing the need for clarity in licensing
statements when employees "donate" code.

Also, the GNU project for example is trying to uphold the highest level
of legality regarding contributions to their own code base, especially
regarding GCC.

Look for example at:

http://www.gnu.org/prep/standards_4.html#SEC4
: Accepting Contributions
: 
: If the program you are working on is copyrighted by the Free Software
: Foundation, then when someone else sends you a piece of code to add 
: to the program, we need legal papers to use it -- just as we asked
: you to sign papers initially. Each person who makes a nontrivial 
: contribution to a program must sign some sort of legal papers 
: in order for us to have clear title to the program; 
: the main author alone is not enough. 

Or:

http://www.gnu.org/prep/standards_3.html#SEC3
: Referring to Proprietary Programs
: 
: Don't in any circumstances refer to Unix source code for 
: or during your work on GNU! (Or to any other
: proprietary programs.) 
: 
: If you have a vague recollection of the internals of a Unix program, 
: this does not absolutely mean you
: can't write an imitation of it, but do try to organize the imitation 
: internally along different lines, because
: this is likely to make the details of the Unix version 
: irrelevant and dissimilar to your results. 

You also wrote:
> 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.

If that is the case, the issue specifically is the creation of
additional classes which the license explicitly says it does not cover.
In these classes, a clear statement of IP ownership and license would be
required (even if just saying it is under a Squeak-like license). 

Note however, that the Apple license says:
http://www.squeak.org/license.html
: 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.

So, you still need a license. Further if you do say it is under a
"Squeak License" does this really effectively disclaim your own
warranties?
I guess it would hinge on whether the author of a Squeak enhancement was
considered one of "Apple's licensor(s)" which I don't know of as the
case. Somehow, I don't think so. Maybe someone could clarify "Licensor"
as opposed to "Licensee". I read Licensor as other people who owned IP
who Apple has the right to use -- like Xerox. Maybe I am wrong. 

In the GPL,  the warranty is broader to simply say all the software
comes with no warranty, not that a specific company does not warranty
anything.
http://www.gnu.org/copyleft/gpl.html
: BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, 
: THERE IS NO WARRANTY FOR THE PROGRAM,
 
> >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.

Good point. Pluggable primitives do improve things a great deal.
However, in an embedded system where everything might be put in the same
ROM, or loaded from the same compiled binary file, pluggability is not
quite as clean a distinction as it might otherwise be on a desktop
application.

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

I certainly am not eager to do it. Squeak 2.7 is quite stable and nice.

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

Good suggestion as a way to proceed.

> 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'm almost surprised Disney lawyers haven't already requested it. It was
the CNRI lawyers who got Guido doing it for Python.

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

Actually I've used Squeak in a capacity for which I was paid a few
times. Mostly it was as a utility to accomplish a specific task. In one
case it was for a prototype that was never "distributed".
 
> 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."

Again, see the above. There may be a lot of behinds the scenes work
making these projects legally coherent that may not obvious to the end
user.
 
> 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.

Good compromise.

> 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

Thanks again for the reply. I appreciate your "pro bono" comments as
coming from one of the best legal authorities on the Squeak license.
It's all new ground and we're all learning as we go -- I guess I learn
by trying to write up what I think I know.

Disclaimer: I am not a lawyer, so see a lawyer who understands your
circumstances and how the law applies to them. 

Someday, I hope software developers will be like lawyers, and paid as
well. That is, all the code will be "free" in code libraries, and people
will pay you to apply it to their specific situation. :-)

Although then, maybe programmers will have to go to the equivalent of
"law school" and pay as much to enter the profession. :-(

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com