ask for APSL? for real this time?
goran.krampe at bluefish.se
goran.krampe at bluefish.se
Thu Jan 8 11:16:20 UTC 2004
Lothar Schenk <lothar.schenk at gmx.de> wrote:
> Hi, Goran!
> > > I think dual-licensing of original new contributions will create still
> > > more of a mess than we have now, because more code will be released under
> > > legally dubious terms.
> > I definitely do NOT agree.
> > > I think the only clean way of releasing original new code (not
> > > modifications of existing code) to be open source would be to release
> > > them under a non-Squeak-L license, which might be MIT, if authors don't
> > > care about independent commercial use by others.
> > I can *definitely not* see why that would be "cleaner". Please enlighten
> > me on why you think so.
> Simple. Don't introduce unnecessary complications if you don't have to. The
> same reason why superfluous code tends to make software buggier without
> adding functionality.
The analogy doesn't hold. In dual licensing I offer you the *choice* of
two licenses - not the union or the sum.
Use the one you like. If it is available under MIT, then you don't even
*know* if I am releaseing my code under a different license to someone
For instance - I might even have sold a special license of my HttpView2
code to a company. Not that I have, but I could have. And I am free to
do it in the future. :)
> The only purpose of Apple's Squeak-L is to protect certain Apple rights in
> relation to the original code contributions owned by Apple and any
> modifications thereof. It makes no sense to apply it to non-Apple code.
It does make sense if the code is to be used together with other code
that is available under SqueakL.
Because this means you have *all* that code under a *single* license -
SqueakL. Otherwise you will have parts under MIT, and other parts under
SqueakL - and *then* it gets complicated. MIT being a very mild source
of complication - but that is beside the point - multiple licenses mixed
together gets complicated per definition. :)
So I reiterate - if it is *my code* and I release it to you and/or the
rest of the world under MIT - then that is all you need to know. I could
be quadruple-licencing it to other people, but that doesn't affect you.
> you own original new code and want it to be free, release it under MIT or
> something similar that suits you. Why would you need to involve Apple in it?
Again, this has to do with the fact that we wanted the base Squeak code
to be under a *single* license. And since we can't get rid of SqueakL it
was decided that we should stick to it for all additions into it. But
since code written for Squeak can also be used in other contexts dual
licensing with MIT opened up a maximum of freedom.
In recent days we have though agreed to also let MIT code into the base
(IIRC) so today you can use "only MIT" too. Te principle still holds
More information about the Squeak-dev