Noury Bouraqadi <bouraqadi at ensm-douai.fr> wrote:
> goran.hultgren at bluefish.se wrote:
>  >
>  >[...]
> > 
> > My advice is to simply duallicense under SqueakL and MIT. That would
> > keep everyone happy except for Richard Stallman, but GPL isn't a
> > practical option in Squeak land anyway. MIT is AFAIK mixable with
> > anything since it practially doesn't contain any restrictions at all.
> > 
> What is MIT?

http://www.opensource.org/licenses/mit-license.php


> Does it make sens to have two different licences for the same uses of 
> the same software? I mean licences can be conflicting. So how to avoid 

Yes it does and there are several good examples, like for example the
dual licenses available for Qt from TrollTech (widget kit used in KDE)
etc.

As the author of a piece of software you can grant different licenses to
different people/companies. For example, when buying a class library you
may often either buy a binary only license or a license with source
included (more expensive).

When it comes to "open" licenses you may as the customer typically pick
the one you like.

> conflicts and how to know when one is "active" or not?

If I publish a piece of software and say that this is available for you
to download and use under license A or B then you simply pick the one
you want.

When a company offer a product under (for example) either GPL or a
proprietary license including support and extra goodies etc then - if
you are a company you may want support, the extra goodies and even the
possibility to embed the stuff in your proprietary products. You can do
that if you buy the proprietary license so you are happy. And the GPLers
are also happy because they get the product under the terms of GPL (no
support, no goodies, no possibility of embedding it in a proprietary
closed product).

If you develop software in Squeak that you want to share with *as many
as possible* then you should duallicense under SqueakL and MIT. People
using other Smalltalks can then utilize your software under MIT and the
Squeak community can utilize it under SqueakL. Why SqueakL? Because we
want to have all the code in "the base Squeak artefact" (packages mean
that the term "image" is not enough) under SqueakL in order to more
easily renegotiate SqueakL with Apple in the future. And in any event it
is better to simply have ONE license for the "base Squeak artefact" than
multiple.

regards, Göran