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