Re: Repost of the DRAFT d-l summary of the OSL v2.0
Thanks for your answer.
GPL-compatibility would be an interesting point, but the problem that we
encounter is the GPL copyleft, which is very strong, due to the
interpretation of the FSF concerning derivative works. Moreover this
will be probably be enforced in GPL v3. It is annoying as soon as we
would like to link our projects with free/open-source, but
GPL-incompatible modules, for instance some libraries in CPL, for
instance at http://www.coin-or.org. Therefore I would prefer to use a
less-restrictive license, while ensuring some copyleft in the project,
as does the LGPL. The OSL seems a good alternative (but again
GPL-incompatible), since L. Rosen interprets derivative works in a more
convenient way at my opinion. Unfortunately, we know the Debian position
I could try to write a new license, but I think also that there are
currently to many licenses, so I would prefer to use an existing one.
Jeremy Hankins wrote:
Fabian Bastin <email@example.com> writes:
Just a little question.
If you want a copyleft license for your work debian-legal recommends
the GPL v2.0.
What is the recommendation if you want a copyleft license, but no as
strong as the GPL, in particular if you consider that simply linking a
module does not produce a derivative work? The LGPL has an annonying
point since it allows anybody to distribute the product in GPL instead
I don't know of a license that does specifically what you want, though I
don't think it would be hard to come up with one. I think the reason
there isn't one is that there's little reason for such a license. If
you want to give extra permissions, just use the LGPL. Why is it
important for your works to be GPL-incompatible?