On Wed, Aug 29, 2001 at 05:47:46PM +0200, Henning Makholm wrote:
> It's your program so you're the boss - but I wouldn't recommend that.
>
> I understand there's a GPL-compatible first version of the library
> out there. An expring exeption seems to put you behind two chairs
> - either you want to help people who have the newer version, or you
> don't.
I want to help people who have the newer version, but at the same time,
I would like to encourage them to change their license (*first* with a
polite request in email to them, and then, if that fails, with this
dual-license). Since the non-GPL-compatible license is modelled after
the old Python license, and the Python folks have since fixed their
license to make it GPL compatible, doesn't it make sense for these guys
to follow suit? I hope this argument is compelling.
In the meantime, I do not wish to support, in perpetuity, the linkage
with non-GPL-compatible software, because it encourages other
distributions either to include only the new non-GPL-compatible version,
thereby putting any pure-GPL'd programs in that distro which call
mxDateTime in jeopardy, or to have to bend over backwards to support
both a GPL-compatible and non-GPL-compatible version of the same
library. It's a bad situation, the "right" solution to which would be
to have the mxDateTime license fixed, in my opinion. Without the
pressure of the dual expiring license, my exception clause simply gives
permission to the licensors to keep it in its current broken state. It
also makes it impossible for someone to use my software as a component
in a pure-GPL'd work, as they will have to make the exception too.
> > I have been pointed at the apt license as an example.
>
> Hmm, strange. I'm pretty sure the debian-legal consensus
> was that software which it is only legal to modify and distribute
> for a limited amount of time is *not free*. But there was a great
> deal of flamewars and politics about the Qt Question at that time,
> so this might have been a political compromise worked out in higher
> places than the -legal list.
But I am not in that position, as an old, GPL-compatibly-licensed
version of mxDateTime exists, and my software will retain compatibility
with that version. My dual license means that you can chose the free
terms, or use the newer mxDateTime under its terms. Ahhh ... I see the
problem now. So if the Debian maintainer of python-mxdatetime decided
for some reason to replace it with 2.0.2 today, the terms of my expiring
license are applicable immediately, forcing my package to move from main
into non-free? That would indeed be bad.
But what other recourse do I have? I wish to express with some force
that I make this exception for now because the other choices are
unpalatable (i.e. dispensing with mxDateTime altogether, or disallowing
linkage with the new mxDateTime) yet it is not ideal, I wish to see it
change, and I will seek an alternative to mxDateTime in future if it is
not fixed in a reasonable timeframe. If, at this point, people are
still using my old version, and use the new mxDateTime, they are in
violation of my license unless they upgrade to my pure-GPL'd version,
which is what I wanted to provide in the first place.
Regards,
Ben
--
nSLUG http://www.nslug.ns.ca [EMAIL PROTECTED]
Debian http://www.debian.org [EMAIL PROTECTED]
[ pgp key fingerprint = 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]
[ gpg key fingerprint = 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
