[ANN] Closure Compiler

Jimmie Houchin jhouchin at texoma.net
Wed Mar 26 18:02:43 UTC 2003


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

A couple thoughts.

My preference is the BSD route. Pragmatically any freer/cleaner license 
acceptable to Apple is a step in the right direction.

If someone Alan, Andrew start a dialogue with Apple, Steve to improve 
the Squeak License I think it would be nice to start with our greatest 
hope and if necessary through dialogue work towards our minimal solution 
addressing issues we have with the current Squeak License and allow 
Apple to provide an acceptable solution.

In this case we would need to have the community confirm what issues we 
would like addressed by Apple. Fonts (can be removed), Export, 
pre-release untested may explode in your face paragraph (yuck, IMO (yes 
I know part of it is for protection, but...)), others?

If we start with the optimal solution which I think is BSD* and work 
towards the sub-optimal solution we are better off. If Apple agrees to 
the optimal solution, yay!, problem solved. If not, accept the best we 
can get and move forward from there.

If the sub-optimal solution is what is provided by Apple then what may 
be desirous or incumbent upon us would be to designate a "Core" of 
Squeak which is governed by the new Squeak License and then all else 
above the "Core" could be placed or encouraged to be placed in the new 
Squeak Community License.

Apple may own or hold the copyright to Squeak (Core) product, but we are 
the Squeak Community and as such could have a Squeak Community License 
for all things not "Core". "Core" in this instance would be all Apple 
derived code, not the definition from other discussions.

The Squeak Community License could technically be drawn up right now. We 
could start moving as much stuff to it as we (authors of code to which 
they have rights of licenseship) have ownership of.

As stated many times before, GPL should be a non-starter. It doesn't 
work for Squeak regardless of license changes unless Squeak went GPL. 
Personally I don't want Squeak GPL.

*BSD. I think Apple would prefer BSD over MIT. Primary reason is that 
the only difference according to OSI is the BSD non-endorsement 
statement. I think Apple would like the non-endorsement statement.

Jimmie Houchin



More information about the Squeak-dev mailing list