[License]: need expert [CSOTD newbie technique tip included!]

Lex Spoon lex at cc.gatech.edu
Fri Feb 8 23:50:22 UTC 2002


> My impression about SqueakL/Debian though (my memory may serve me wrong
> here) was that the export clause (!) was no problem for Debian, it was
> the indemnification stuff as Stephen Stafford explained:
> 
> http://macos.tuwien.ac.at:9009/438570542.asHtml
> 
> ...which probably would be a problem for OSI too then I guess.

That was my impression as well.  But this has nothing to do with whether
the software is "open source" or not, so OSI may well be fine with it. 
Apparently, such indemnification clauses are common, and, since people
seem to live with them, I'm guessing that they aren't as broadly
applicable as they sound like.

Here it is, for the record:

=====
5. Indemnification.  You agree to indemnify and hold Apple harmless
from any and all damages, liabilities, costs and expenses (including
but not limited to attorneys' fees and costs of suit) incurred by
Apple as a result of any claim, proceeding, and/or judgment to the
extent it arises out of or is connected in any manner with the
operation, use, distribution or modification of Modified Software, or
the combination of Apple Software or Modified Software with other
programs; provided that Apple notifies Licensee of any such claim or
proceeding in writing, tenders to Licensee the opportunity to defend
or settle such claim or proceeding at Licensee's expense, and
cooperates with Licensee in defending or settling such claim or
proceeding.
======


The language really irritates me -- how do you decide whether a claim is "connect in any manner" with the distribution of the software?  Can't you say "well, it's called Squeak, and some guys have distributed it, so it's connected to the distribution" ?!?!

[OT]  What is law worth if you don't know what the laws are?


-Lex


> 
> > Just read it:
> > 
> > http://www.debian.org/social_contract#guidelines
> > http://opensource.org/docs/definition_plain.html
> > 
> > > I think it just did not happen.
> > >
> > It did not happen because everyone who thought about it *knew* what the
> > outcome of such a question would be: "SqueakL is not Open Source according
> > to the Open Source definition"
> > 
> > Maybe this is just what's needed to get people to *really* start thinking
> > about changing SqueakL?
> 
> Yep. But it won't happen until someone coughs up money to have it done I
> guess. :-)
> But throwing SqueakL at OSI and see what they say could probably be
> done. I think I even did that a few months ago but got no answer. Or
> perhaps it was FSF - I don't remember - it was one of them at least.
> 
> regards, Göran
> 
> PS. <CSOTD>
> Well, well... Can't come up with code right now. But I could explain a
> nice little technique called
> "double dispatch" perhaps not known to some newbies.
> 
> Personally I use when I want to be able to have multiple views on domain
> objects
> and still be able to rely on polymorphism on the domain object to create
> the proper view.
> 
> Let's say you have a bunch of different fruit objects of classes Banana,
> Lemon etc. Perhaps you also
> create some form of UI classes called for example Views. A BananaView
> for Bananas, LemonView for Lemons and so on.
> 
> Instead of doing this like a real OO newbie:
> 
> obj class == Banana ifTrue:[ BananaView on: obj ] 
> 
> ...you would of course implement a method called say "getView" in the
> Banana class like this:
> 
> Banana>>getView
> 	^BananaView on: self
> 
> ...thus you implement getView for all fruit classes and you will get the
> proper view. Ok, but what if you
> suddenly have different views altogether, for example a bunch of
> viewclasses for the web and another for
> Morphic? Darn. Well, the obvious mistake would be too fall back into
> non-OO practices like this:
> 
> Banana>>getWebView
> Banana>>getMorphicView
> 
> ...and let the caller decide which one to use. But that's ugly. Another
> way would be to stuff a conditional into getView like this:
> 
> Banana>>getView
> 	(some test finding out which view to make - not so easy)
> 		ifTrue:[ ^WebBananaView on: self]
> 		ifFalse:[ ^MorphicBananaView on: self]
> 
> ...not so pretty either and the test can be hard. Yuk. Conditionals are
> a sure sign that perhaps we could use polymorphism instead - "let the
> objects decide" so to speak. Ok. What if the domain object, when it gets
> the message #getView could just bounce back and ask, "Well, I don't know
> which particular view, but since I am a banana, it better be a
> SomethingBananaView...". This can be implemented like:
> 
> getViewFor: theCaller
> 	"Bounce right back and call the proper method in the caller.
> 	Since I am a Banana, I will call the getBananaViewFor: method."
> 
> 	^theCaller getBananaViewFor: self
> 
> 
> ...ok, now it is up to the called to implement #getBananaViewFor: so
> that the correct type of View is created.
> The first dispatch is on the domain object, the second is a
> bounce-right-back-thingy on the caller, which typically is another
> already existing View object. Thus - "double dispatch".
> 
> We could also view it as a way to find the correct method not only based
> on the class of the receiver but also on the class of the caller.
> 
> Over-and-out.
> 
> </CSOTD> DS



More information about the Squeak-dev mailing list