Dual licencing and Squeak ENH policy
goran.krampe at bluefish.se
goran.krampe at bluefish.se
Tue Jan 20 08:29:33 UTC 2004
I Am Not A Lawyer - the following just reflects what I believe to be
Samir Saidani <saidani at info.unicaen.fr> wrote:
> I'm about to release new packages on squeakmap and these packages need
> to modify some squeak base classes (hence in Squeak-L) in order to
> work properly. So if they modify this classes, I guess I have to
> release all the packages under the Squeak-L, but I don't want, mainly
> because of the exportation clause.
According to Squeak-L you only need to publish your base changes
according the rules explained in the license - not the whole package.
> So I take a look on several
> packages on squeakmap, to get a feeling on what is the common usage, and
> I notice two different strategies :
> - People who release their contribution on Squeak base classes (in
> Squeak-L) in a package different from their main contribution (the
> application in MIT Licence or whatever)
Well, ok - that was what I said. :) Hadn't realized someone had used
that strategy though.
> - People who don't distinguish between their contribution to the core
> of Squeak and their application, and they sometimes choose MIT Licence
> or another one, (eg. StarBrowser, Refactoring Browser...) which seems
> to me illegal according to the term of Squeak-L
Exactly. This is something that have come more into light recently.
Releasing modifications to base classes under MIT is clearly against
Squeak-L. AFAICT. They needn't be released under *exactly* Squeak-L but
in practice it is easiest to just pick Squeak-L.
We have been using a dual license (Squeak-L/MIT) for quite a few
packages and we all need to revisit that decision. Personally I am
moving a few of my packages over to Squeak-L only for the time being. I
don't like it - but since we don't have a proper "SqueakSub-L-template"
to use yet...
Regarding if you can develop non base modifications (apps) and release
those (separately from the image) under MIT has also been discussed and
Andrew Greenberg says that his view is that you *can't even do that* -
at least not without doubt. The problem (if I understood him correctly)
lies in being sure that your app can not be considered to be a "base
I do want to say that his view might be considered a bit "on the safe
side" since he is talking about community code - it sure is a good thing
to be paranoid when it comes to that. I am not sure how paranoid you
would need to be if you were a company or a private individual.
> NB: I found quite funny and interesting that licence problems force us
> to clarify our packaging policy... Our problems help us !
Well, they only help us in some very few aspects unfortunately. The rest
is just a pain.
More information about the Squeak-dev