Re: LGPL library using only LGPL-parts of partially GPL shared library (gnutls, nettle)
Simon Josefsson <email@example.com> writes:
> Andreas Metzler <firstname.lastname@example.org> writes:
>> On 2011-02-20 Simon Josefsson <email@example.com> wrote:
>>> Andreas Metzler <firstname.lastname@example.org> writes:
>>> > I have the feeling that the discussion I started is an academic one
>>> > anyway. Nettle's public key library (libhogweed) uses and links against
>>> > libgmp, which is LGPLv3+. Therefore switching gnutls from gcrypt to
>>> > nettle would break GPLv2-compatibility (GPLv2 without the "or any
>>> > later version " clause). Oh dear.
>>> It has been discussed to dual-license some libraries under
>>> GPLv2+/LGPLv3+ to avoid this problem. I wonder if this could be a way
>>> out here. GnuTLS 2.12 is not released (and there is not even any
>>> release candidates), so we still have time to resolve this in a good
>> Afaik there is nothing GnuTLS can do. It is using the most permissive
>> license of the involved packages. The culprit is the combination of
>> third party (L)GPL-v2only software (e.g. cups) with libgmp, which
>> switched from LGPLv2+ to LGPLv3+ in 4.2.2.
> The FSF has clarified that to resolve that problem, it is recommended to
> dual-license projects under GPLv2+/LGPLv3+ see:
> So if GMP follows this suggestion, the problem would be resolved for
> GPLv2-only projects. Did you really notice any LGPLv2-only projects
> using GnuTLS when you looked?
I now realize that LGPLv2-only projects is not a problem since
LGPLv2-only can be upgraded to GPLv2 which would then be
So let me rephrase the question: is there any project that happen to
combine LGPLv2-only and GPLv2+-incompatible licensed code? Only such a
project would be problematic even if GMP would become dual licensed
under GPLv2+/LGPLv3+. If we can get any kind of metrics on the scale of
this problem, we can think about whether it is a problem worth solving.