[ANN] Closure Compiler

Andrew C. Greenberg werdna at mucow.com
Wed Mar 26 17:26:43 UTC 2003


On Wednesday, March 26, 2003, at 05:56 AM, Andreas Raab wrote:

> Göran,
>
>> 	Squeak-L permits sublicensing as long as the new
>> license "no less protective of Apple" etc. Could we create
>> a sublicense then in which we simply dumpl clause 6? Export
>> has nothing to do with Apple, has it?
>
> Interesting idea in fact. This might work (but only a lawyer can tell 
> you).
> What would be good about this were that the new license could be a 
> little
> less "Apple centric" in its verbage. The new license could actually 
> exclude
> the font clause given that no Apple fonts were in the release.

I have brought this up before.  This is something we should not do 
unilaterally, but it is very reasonable to believe this can be done.

The export provision DOES exist to protect Apple from claims of 
contribution to the violation of the law by others.  However, Apple has 
already waived the point to the extent the language in APSL does, and 
as a point of policy ought to agree to at least limit the language to 
the corresponding language in APSL, which is OSI compatible.  That 
language has been whittled down from earlier APSL's to the present 
language in the severability section "if applicable law prohibits or 
restricts You from fully and/or specifically complying with [the grant 
of rights and limitations] this license will immediately terminate and 
You must immediately discontinue any use of the Covered Code and 
destroy all copies of it that are in your possession or control."

The font language is no less protective to the extent that the code 
doesn't include the fonts, I agree.

As to the change of the language, the agreement expressly contemplates 
(using the bizarre self-referential twist at the end that looks like it 
was written by a Quine or Hofstadter) -- of course it can be rewritten 
"no less protective," even to the extent of eliminating Apple's name 
for the phrase (prior licensee).

The question is whether such a license would satisfy the community.  If 
so, we build it, and then after reaching consensus, get Apple to sign 
off on replacing the export language with the "compliance with law" 
language in APSL.

Ideally, we would get Apple to sign off that it is "no less 
protective," and then the result is completely clean upon approval of 
the contributors and excising the non-approved code.  This results in 
an OSI compatible license.  Would everybody be happy with that, or 
would we just have to revisit this whole shebang again to satisfy the 
dissenters?  Would it still be incompatible with GPL? (likely, as APSL 
was, when last I recall, considered incompatible with GPL).

I agree that the "minor repairs" approach is the best way to go.  Do we 
want to go that way?  Or do we want to present a BSD-style license and 
try to bludgeon it out of Apple?

Consistent with good engineering practices, let us reach a communal 
consensus as to what we want FIRST, and then use that to help us 
develop requirements for proceeding.

In the meanwhile, let's just deal with APSL and not hang ourselves 
before we can actually fix things.


More information about the Squeak-dev mailing list