[ANN] Closure Compiler

Swan, Dean Dean_Swan at Mitel.COM
Wed Mar 26 23:50:35 UTC 2003


Hi Jimmie,

	I am admittedly assuming a worst case scenario.  You are quite
correct: I have no knowledge of what Apple's opinion is on this
matter.  My opinion is based on the idea that Apple is content with
the current situation and may not be receptive to entertaining a
dialogue.

	While we may have nothing but friendly intentions, just as a
sleeping dog may bite a child who only wants to pet it, there is the
possibility that Apple may not be interested in dealing with this
issue.  My hesitation is largely based on various hearsay accounts of
Apple's CEO's predilection towards being unpredictable and sometimes
volatile.  If there's even a slight chance that the dog might bite me,
I try not to disturb it.

	Perhaps my position is unnecessarily conservative.

	I'm just sticking my $0.02 worth by stating my opinion.  I
will gladly yield to the consensus.

	I don't think your BSD proposal is inherently wrong.  I am just
concerned that it could possibly result in Apple changing the license
to something more restrictive, which would be worse for "us".  I
realize the possibility might be remote, but I'm paranoid and cynical. ;-)

	So, if people who know better think your idea is the way to go,
I have no problem with that.  Your reply just sounded like you may have
taken offense.  None was intended.

					-Dean

P.S.  My personal definitions-

	Dialogue: discussing something that everybody already agrees on.
	Negotiation: discussing something that is not already agreed upon.
 

> -----Original Message-----
> From: Jimmie Houchin [mailto:jhouchin at texoma.net]
> Sent: Wednesday, March 26, 2003 2:46 PM
> To: The general-purpose Squeak developers list
> Subject: Re: [ANN] Closure Compiler
> 
> 
> Hello Dean,
> 
> Nothing I stated intimated having an upper hand. I spoke of 
> dialogue, a 
> discussion. I never said negotiation. However, nothing is 
> improved with 
> Apple's consent or 'signing off' without dialogue.
> 
> If you wish to call the dialogue a negotiation, fine. You may be 
> technically correct. However, I don't call many discussions which are 
> meant to determine an outcome, a negotiation.
> 
> There is nothing unfriendly about what I suggested. We have 
> no idea what 
> Apple's opinion is on this matter at all until a dialogue is 
> begun with 
> an appropriate party. Apple may be perfectly happy to sign 
> off on a BSD 
> license. I don't know, do you? Apple may want something more 
> restrictive. If so fine. We (whomever) can talk.
> 
> I spoke of issues. Some don't have any. Fine.
> I believe there are some reasonable things to discuss about 
> the license. 
> However, we will have nothing to discuss with Apple, nothing 
> for Apple 
> to sign off on if we don't have what issues we would like 
> addressed. It 
> would be naive to think that Apple would sign off on anything without 
> reading it and determining what it says and what is different. Well, 
> what is different is the 'issues'.
> 
> There absolutely does not have to be anything negative or 
> antagonistic 
> in our approach to Apple regarding relicensing. Yes, we are 
> asking for a 
> favor. It is not wrong to nicely ask for the one we want 
> (first) instead 
> the one we'll settle for. (because we're afraid)
> 
> An upper hand is not required. We are not trying to beat 
> anything out of 
> Apple. We have a place we would like to draw the line (say BSD) they 
> have a place they would like to draw the line. They may want 
> to leave it 
> alone, they may want BSD. Who knows without dialogue. Apple 
> may not have 
> given this one moments thought since late 1996. So they may 
> not have a 
> firm opinion. More reasons for dialogue, not negotiation.
> 
> I say 'tomato', you say 'tomato'... Lets just talk it over. :)
> Okay the song doesn't quite come off in email. :)
> 
> Jimmie Houchin
> 
> 
> 
> Swan, Dean wrote:
> > I disagree on this one.  I don't think Apple has any reason
> > to want to spend ANY time negotiating this.  If they do
> > agree to anything, it will be out of consideration for
> > the many contributors to Squeak.
> > 
> > The current license situation is good for Apple, so
> > they have no reason to bother with it.
> > 
> > I'm inclined to agree with Andrew on this issue.  Either
> > come up with a license that Apple will almost certainly
> > sign off on without negotiation or just live with the
> > status quo.
> > 
> > We do not have the upper hand here, so I think the more
> > aggressive strategy proposed by Jimmie is not a good idea.
> > 
> > 				-Dean
> > 
> >>-----Original Message-----
> >>From: Jimmie Houchin [mailto:jhouchin at texoma.net]
> >>Sent: Wednesday, March 26, 2003 1:03 PM
> >>To: The general-purpose Squeak developers list
> >>Subject: Re: [ANN] Closure Compiler
> >>
> >>
> >>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