simon at josefsson.org
Sun Dec 16 10:19:00 CET 2007
Andreas Metzler <ametzler at downhill.at.eu.org> writes:
> On 2007-11-29 Simon Josefsson <simon at josefsson.org> wrote:
>> We are considering to use the GPLv3 instead of GPLv2 for everything
>> except the core library, and I'd like to invite comments about this.
> I know this is a litle bit late.
If serious problems arise, I don't think it is totally impossible to go
back to GPLv2. However, that requires _serious_ problems.
libgnutls-extra doesn't contain any (as far as I know) widely used
features right now, so I do expect the problems to be minor. Most can
probably be resolved by not linking to libgnutls-extra. Doing the
license switch will trigger analysis like the one you did, which we
really appreciate. If we never make the switch, nobody will bother to
do a good analysis.
> I have gone over Debian/main eyeing packages depending on libgnutls13
> and checking whether they link against libgnutls-extra or
I'd expect this to be quite few libraries. For my information, how do
you generate a list of packages that link to libgnutls-extra? I'd like
to analyze those packages further myself.
> Most of the packages listing GPLv2 as license seem to be false
> positives or a least unclear (freewheeling, gkrellm, kildclient,
> sipsak). ssmtp is also in the unclear camp. lynx seems to be the only
> package that actually will lose its SSL functionality, since it is
Can't they just stop using libgnutls-extra? Lynx doesn't support
OpenPGP or SRP authentication anyway, does it? I don't see why it needs
to link with libgnutls-extra.
Generally, it would be interesting to know if there are _any_ widely
deployed tools that truly depend on the libgnutls-extra features.
> Please note that that I have not checked whether license conflicts of
> this form would exist
> program links against libgnutls-extra or libgnutls-openssl.
> program also links agains libfoo, and libfoo is not GPLv3 compatible.
I'd expect there are some of these...
More information about the Gnutls-devel