GPLv3

[Simon Josefsson]

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
> libgnutls-openssl.

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
> GPLv2.

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...

/Simon