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