[Squeakfoundation]Re: Sublicensing seems possible

[Paul D. Fernhout]

Daniel Vainsencher wrote:
> The subprojects mentioned are new. Schools are starting to think about
> all the teacher hours they could pay with their software licensing
> budgets. Various user groups are starting to tailor free alternatives
> for them to consider. People often check out and maybe even use whatever
> tools they have preinstalled on their computers. Do you see where this is 
> going?
> 
> [what's stopping open source/free software people from contributing to
> Squeak]
> If they happen to know about Smalltalk, or like reading licenses for
> fun, probably nothing. If they compare Python and Squeak, notice that
> Squeak isn't DFSG, and isn't OSI (but Python is...), they might just
> think "why bother?". And there goes another one...

To pour more gasoline on the licensing fire... :-)

In general, as a developer, I prefer Smalltalk's keyword & variable 
declaring syntax over Python's equivalents of function names and 
variable declaration on first assignment. I also prefer Squeak's 
architectural notions of openness and self-containedness and 
self-generation and self-inspection to Python's layer of C-ish opacity 
and opaque add-ons (e.g. wxPython/wxWindows, which otherwise I like). 
Still, despite my preferenece for the Squeak vision, I am using Python & 
extensions in my current and future plans specifically because I prefer 
Python's licensing status and related licensing clarity (and that of its 
most popular Python add-ons like wxPython/wxWindows).

I brought up some of these licensing issues years ago on the Squeak list 
and on thsi list and on more than one occasions. It is nice to see them 
getting a lot of interest right now. Usually a resident Squeak list 
laywer would shoot down anything I wrote with some variant of "The 
Squeak License is good enough as is for most any prudent person who 
wants to write open source software" -- which helped torpedo my efforts 
to resolve this issue.

I can appreciate that legal position, but, I haven't pointed this out 
much before, and now feel more free to do so because you wrote the 
above, but some of my comments (not being a lawyer myself) came from 
practical experience trying to get others (including lawyers) to 
consider Squeak in business settings and encountering exactly these 
sorts of concerns, similar to what you point to above. And by contrast, 
I found Python's license a much easier "sell" than Squeak's.

Open source of free licenses need to be "sold" sometimes even though the 
cost of use is otherwise free, and "selling" a free license to the power 
hierarchy in a business often takes a lot of time (and so indirectly 
money) especially when it needs to pass internal legal review and 
doesn't fit into past experience (GPL, LGPL, BSD, X/MIT, Apache, etc.).

And, believe it or not, these days it may even be harder to "sell" a 
"free" license to a school than to a business, because Microsoft and 
other companies have so terrorized and bullied schools through SPA 
audits and related threats, to the point where I know of teachers who 
are forced to sign agreements that they can be fired if the install any 
software not approved specifically by their supervisors (even if they 
buy it themselves!). To that end, it would be much better if one could 
ask a teacher to just once get their school district to approve 
materials under certain specific free licenses, or to approve a specific 
free software platform like DebianEdu (or some version of Squeak?) where 
all the add-ons were certified free. Such a project (a certified free 
platform with certified free plugins) is one interest of mine in 
pursuing a Squeak-ish architectural approach to educational software.

However, be careful if you want complete Squeak licensing clarity. My 
own greatest difficulty with Squeak licensing, in the end, was not all 
the issues raised here (e.g. fonts, indemnification, Apple specificity, 
export clauses, etc.) -- as important as they are.

So, what do I see as the deepest Squeak licensing problem? The second 
question a good lawyer might ask about Squeak after asking about the 
license is: "and so what about the licenses of all the add-ons or other 
contributions from other than the primary author(s)"? To my knowledge 
there was never a statement by _Disney_ as to the licensing status of 
contributions made while SqueakC was there. So getting clarification 
from _Apple_ in my opinion is not enough. One needs to approach _Disney_ 
to do it right. And that really is putting your head into the lion's jaws.

For a cautionary example, which I raised on the Squeak list previously, 
after Python was released by CNRI for years, when Guido van Rossum 
(Python's creator) was leaving, CNRI suddenly claimed that the license 
being distributed with Python, which only mentioned Guido's previous 
employer in the Netherlands, did not cover any of the new work Guido or 
others ahd done at CNRI. So, the license was renegotiated by CNRI amidst 
great opposition, including for a while leaving Python developers who 
used the GPL in legal limbo as the new license was applied retroactively 
to previous versions and was GPL-incompatible. I would think it quite 
possible Disney could pull the same stunt. In Guido's case, he said he 
had it written into his contract at CNRI at the start that Python would 
remain free and so he had some legal leverage. I do not know if SqC 
would have similar legal leverage in their contracts with Disney 
(somehow I doubt it, knowing how Disney operates historically in regards 
to copyrights and patents -- i.e. they helped push through the Sonny 
Bono Copyright Extension act).

I raised this issue of a clear license statement from Disney with Alan 
Kay when SqC announced they were leaving Disney soon, and the response 
was essentially that licensing clarity was not a priority in SqC work -- 
or perhaps even at all even possible in today's seemingly non-sensical 
and inconsistent legal world where copyright and patent decisions were 
usually made arbitrarily by judges or juries with little experience with 
copyrights or patents or software. I was told SqC's focus was (and 
presumably still is) scientific exploration and related open 
collaboration with like-minded individuals. Alan also mentioned an 
alterate reading of the Squeak license making it seem more like the GPL 
or LGPL, implying all their work at Disney (including Morphic, which I 
otherwise considered more of an addition than an extension) thus fell 
under the Squeak license clauses requiring distribution and sublicensing 
under the Squeak license. I can respect Alan Kay's position, but I 
differ in my own choice of comfort on some of these issues and readings 
of the license. That is why, as much as I admire Squeak's current 
implementation and it's goals, I have also moved away from it and not 
fixed some of the more obvious issues with it myself. I also question 
whether long term collaboration can be sustained in the abscence of at 
least a modicum of license clarity and a serious effort towards tracking 
the evolving concensus on what constitutes "free" or "open source" 
software (as in the Debian guidelines). My "Burn the Disk packs" 
approach such as proposing "BelleSqueak" also came from spending far too 
much time in the past spent untying other's knotty code -- I find it 
easier usually when confronted with literally person-decades of code not 
designed from the start for modularity to start over informed by the 
past example. (Good refactoring tools obviously also help with this in 
some cases.) I am in awe of the amount of effort and creativity people 
have been sustaining in trying to untangle the Squeak code to modularize 
it and I wish that effort well. I haven't contributed to that mainly 
because I am not sure of the legal status of what I would have at the 
end given these comments on Disney etc. I hope for their sake I am 
completely wrong on these issues.

Still, I feel, given the Disney ambiguity issue, and my expectation that 
Disney will be unapproachable as for licensing clarification now that 
SqC has left there, that the only way to move forward with Squeak may in 
the end be to reinvent it -- subject to the caveats already raised here 
about "contamination" in any Smalltalker creating a new Smalltalk. So, I 
lean more towards a "burn the disk packs" approach with something new 
which addresses the core goals of Squeak. I have my own take on how that 
might be done (prototypish, firewallish, remote-debuggable, 
image-buildable, multi-lingual, network-centric, and a few other 
issues). Since few here had much desire for the "burn the disk packs" 
approach when I floated it in the past, I have ended up building on a 
somewhat better licensed foundation like Python for practical reasons of 
makign immediate progress on applications since that task seems to 
daunting to do by myself.

I hope these license issues can be resolved -- but please think 
carefully about the Disney issue when deciding how to proceed.

--Paul Fernhout
http://www.pointrel.org