Squeak's license (uh-oh...)

agree at carltonfields.com agree at carltonfields.com
Fri Jul 16 14:32:17 UTC 1999


> 	I think future Squeak development would proceed more > quickly and with better results if newcomer developers could > quickly identify Squeak with the Open Source Definition.

I seriously doubt this to be the case.  Indeed, the contrary may be true.  Indeed, commercial developers are (properly) terrified from using "open source" code without substantial legal analysese preceding the work.  Individuals rarely, if at all, look at the licenses.  Nobody really cares about OSS certification, and --as witnessed by many debates on slashdot recently, particularly concerning the Apple license-- few people credit the certification process anyway.

> > I raised this issue a few months back and was convinced by > the responses that the > present license is pretty darned great.
> > 	If the license if great, then I think OSI approval of > it is also great (as I mentioned before). But I think the > license is poor, for the following reasons:
> > -	Disney is not mentioned, and perhaps should be. 

Isn't that for Disney and its lawyers to determine?  As understood, Squeak was owned by Apple, and licensed to Disney, which has been developing subject to that license, just as we all have done.  I'll leave it to Disney to decide whether their lack of mention makes the license a "poor" one.

>Apple > is mentioned, and possibly should not. 

Again, this is a legal question.  What we definitely SHOULD NOT DO is change the license without legal authority to do so.

> Squeak (and, for that > matter, Smalltalk) seems to have been operating largely > "under the radar" of both companies, which certainly has > benefits. However, I think lawyers from both companies may > need to get involved here and give approval. 

Approval of what?

> "We" have been > putting this off for years, and I think it could cause > serious grief later. I think we have to face up to it as soon > as possible.

What grief?

> 	Indeed, I'd prefer a license that makes no mention of > any company whatsoever! 

The license is given by the owner of the rights in and to the work licened, or it isn't a license.  Ordinarily, a contract names the parties involved.

> What are the legal ramifications of, > for example, Apple going out of business? 

The successor in interest will assume ownership of the underlying works subject to the license.

>Furthermore, the > current license has anachronistic debris in it (e.g., "In no > event shall Apple's total liability to you for all damages > exceed the mount of fifty dollars ($50.00)." 

I doubt Apple's attorneys would see it that way.  I know that I would not.

>I think sections > one, three, four, five, six, and seven are effectively dead > weight. It would be nice to cut out the cruft; the license > would be shorter and easier to read, and more people might > actually read it. It might be even better to use an existing > license we like and with which newcomers are already familiar.

It is a million miles shorter than GPL.

> -	Section two says that derivate works must be made > available at no charge. I don't like that restriction, for > the same reasons that the OSI doesn't > (http://opensource.org/faq.html, etc.). No > other "open > source" license has that restriction, not even the GNU ones.

Whether or not you like it, it is up to the owner of the underlying rights to determine those restrictions.  It is not for US to change the deal -- it is for the owners.  Those of use who have made derivative works are doing so only subject to the license.

It is simply not true that no other open source license has the restriction.  Many licenses, mostly BPL derivatives, do not permit commercial exploitation without a separate license.  There was a recent article in slashdot on this subject as well.

> -	Section two mentions the "exisiting relationships [of > existing class objects]", which I think is vague. And what > happens if Squeak gets rid of Classes altogether?

Than there will no longer be "existing relationships [of existing class objects]" and the correlative provisions would not apply.

> I think a > license that relies on implementation details of the software > it describes is too brittle.
 > -	Section two says that derivative works must be made > publicly available, but it doesn't say WHEN.

True.  I'm not sure this is a meaningful problem.  (Hey, I thought you wanted the license to be shorter!)

> 	My concerns with these points were not ameliorated by > the discussion you had on the Squeak list. And until I feel > good about Squeak's license, I don't consider Squeak a truly > worthwhile investment of my time (long story there, for some > other time...).

Surely the Squeak community would dearly miss Craig.  Nevertheless, there is not a one of us (including Disney) other than Apple that has the authority to change the license.  In practice, I do not believe that the license is troublesome at all, and has many features that I believe unreasonably encumber GPL code.

My suggestion was that we contact Apple and ask them to put Squeak under APSL, which is certainly a more sophisticated license arrangement.  Several demurred, noting that APSL, while it lacks all of the difficulties mentioned by Craig (except the name of a company, and that it is longer than Squeak's license, but shorter than GPL) is, in fact, more cumbersome and limiting in practice.

Apple might well be inclined to use a single license for its open source works, but I doubt that the Squeak community would prefer APSL to the status quo.  I cannot imagine that anything else would be acceptable to the parties that make this decision.

Finally, I believe the Squeak license is not only adequate for my purposes, but far superior to many I have seen.  Yes, it has anachronisms, but so what?  If things go properly, it will never be enforced and therefore, never ever matter.





More information about the Squeak-dev mailing list