gnutls 3.x depends on nettle, which depends on gmp, which is LGPLv3+. :-/ Per the matrix-of-doom, this means gnutls can no longer be used by GPLv2-only code... repoquery turns up: climm, connman, cups, ekg2-jabber, gloox, jd, openvasscanner, suricata, xfce4-mailwatch-plugin (Inspired by https://bugzilla.gnome.org/show_bug.cgi?id=704503, which doesn't show up in the above list because nothing actually links directly to glib-networking. I don't know exactly what that means licensingwise.) Not sure what we need to do here...
I certainly cannot do anything with it in gnutls. Although it was my mistake to not consider this.
Reverting to 2.12 is basically impossible.
Yeah, I'm not sure what should be done, or by who, but clearly someone needs to do something... at the moment we are shipping some packages in f19 in violation of their licenses.
Also note that we've been shipping traditionally GPLv2 applications linked against openssl which was also licensing violation but we declared openssl being part of the OS platform. I think there still are some applications that do not have the exception to link to OpenSSL although they're GPLv2(+), I did not verify this though and I am also unsure whether this applies to the current situation with gnutls.
I can't see much else that can be done than creating bug reports against the packages mentioned above and fix them to either link to something else if possible or in the corner case just drop it from the Fedora?
For example cups can be linked against openssl and now has even the license exception for that.
Comment from gnutls-devel mailing list. This seems to be adressed on the GnuTLS download page: 1. Gmplib is under LGPLv3. Older versions of gmplib under LGPLv2 are also supported. So I guess the easiest way would be to fork the LGPLv2 version of gmplib for gnutls use and GPLv2 programs should be in the clear. Juho
This also affects the (LGPLv2-only) 'oz' package since it uses libvirt, which in turns uses gnutls.
If 'oz' is LGPLv2-only, then that's different than GPLv2-only. Remember, the LGPLv2 license states: > 3. You may opt to apply the terms of the ordinary GNU General Public > License instead of this License to a given copy of the Library. To do > this, you must alter all the notices that refer to this License, so > that they refer to the ordinary GNU General Public License, version 2, > instead of to this License. (If a newer version than version 2 of the > ordinary GNU General Public License has appeared, then you can specify > that version instead if you wish.) [...] So an LGPLv2-only library can be linked into a GPLv3 app because LGPL guaranteed the or-later clause during the up-conversion. An app can also link both LGPLv2-only and LGPLv3 libraries at the same time, as long as the app exercises the up-conversion clause of both libraries, with the resulting app necessarily being GPLv3. The only combination of doom is GPLv2-only with LGPLv3, because there is no way to upgrade LGPLv3 into GPLv2.
FWIW, there is a plan afoot upstream in CUPS to move the gnutls-using code from cupsd (GPLv2) to libcups (LGPLv2), unrelated to the licensing issue. Would that avoid the issue for CUPS?
(In reply to Tim Waugh from comment #10) > FWIW, there is a plan afoot upstream in CUPS to move the gnutls-using code > from cupsd (GPLv2) to libcups (LGPLv2), unrelated to the licensing issue. > Would that avoid the issue for CUPS? Hello, I do not think it would help a lot, since cupsd links against libcups. Therefore one still ends up with cupsd (GPLv2) linking against a LGPLv3+ library (gmp), just with another library in between. cu Andreas
For my own reference, the matrix of doom is here: http://gplv3.fsf.org/dd3-faq One possible interpretation of that matrix (but I'd much rather hear it from an actual lawyer): Linking against an unmodified LGPLv3[+] library does NOT prevent the use of that library in other LGPLv2+ libraries. Thus, if gnutls did not MODIFY nettle or gmp, then even though gmp is LGPLv3+, gnutls can still be released as LGPLv2+, without tainting it. Similarly, a GPLv2-only program that links directly to an LGPLv2+ library is permissible, it is only DIRECT linking against an LGPLv3 library that violates the terms of the GPL. So as long as the license discrepancy is only via indirect transitive linking, is this actually a license violation?
(In reply to Eric Blake from comment #12) [...] > Linking against an unmodified LGPLv3[+] library does NOT prevent the use of > that library in other LGPLv2+ libraries. Thus, if gnutls did not MODIFY > nettle or gmp, then even though gmp is LGPLv3+, gnutls can still be released > as LGPLv2+, without tainting it. Similarly, a GPLv2-only program that links > directly to an LGPLv2+ library is permissible, it is only DIRECT linking > against an LGPLv3 library that violates the terms of the GPL. [...] I am not sure either, but if you start on the other end of chain, a imho convincing argument for a problem can be made: 1 cups GPLv2 2 [cups GPlv2 linking against gnutls LGPLv2.1+] --> GPLv2 3 [[cups linking against gnutls ] GPLv2 links against nettle LGPLv2.1+] --> GPLv2 4 [[cups linking against gnutls links against nettle ] GPLv2 links against GMP LGPLv3+ ---> BANG!
I don't know if the indirect linking to LGPLv3 (via LGPLv2 libraries) is permitted, but another (maybe also simpler) solution is for GPLv2-only programs to add an exception to allow linking with LGPLv3 libraries.
Presumably all GPLv2-only programs are non-GNU-maintained, and non-GNU-maintained programs usually don't have copyright assignment, so relicensing is likely to be somewhere between difficult and legally impossible.
I tried to track all gnutls dependencies using repoquery whatrequires, including the indirect ones. This provides a rough indication of the dependencies (I've put it in [0]). In that I marked out the GPLv2 (only) programs with the "^^^" symbol. While some of them may be simply GPLv2+ programs that were mistakenly marked as GPLv2, there are indeed programs that are affected. Given that the GMP upstream is not willing to keep compatibility with GPLv2 applications, the reasonable possibilities I see are: 1. Take gmp 4.1.2 (LGPLv2) and maintain it separately to be used by gnutls and nettle in Fedora. 2. Declare GMP a system library and work around the issue. That is similarly to the path taken in https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F The option (1) may not be so reasonable. [0]. http://people.redhat.com/nmavrogi/fedora/out.fedora.txt
(In reply to Nikos Mavrogiannopoulos from comment #16) > 2. Declare GMP a system library and work around the issue. That is similarly > to the path taken in > https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What. > 27s_the_deal_with_the_OpenSSL_license.3F This an approach that would have to be sent to Fedora legal for approval, not something we can decide on here as package maintainers.
I've contacted Fedora Legal.
It seems GMP is being re-licensed to GPLv2+LGPLv3 so it can be compatible with GPLv2-only software. As such I think the bug should be closed when there is a release of the newly licensed GMP in Fedora. https://gmplib.org/repo/gmp/rev/02634effbd4e
GMP 6 is in Rawhide. README of this version says dual GPLv2+ LGPLv3+. I am not a lawyer and therefore I will not express my personal opinion about the change.
Neither do I; thank you.