Bug 986347 - gnutls is now effectively LPGLv3+
gnutls is now effectively LPGLv3+
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gnutls (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Nikos Mavrogiannopoulos
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-19 09:43 EDT by Dan Winship
Modified: 2014-04-15 10:15 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1019408 (view as bug list)
Environment:
Last Closed: 2014-04-15 10:15:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1080817 None None None Never

  None (edit)
Description Dan Winship 2013-07-19 09:43:14 EDT
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...
Comment 1 Tomas Mraz 2013-07-19 09:53:41 EDT
I certainly cannot do anything with it in gnutls. Although it was my mistake to not consider this.
Comment 2 Tomas Mraz 2013-07-19 09:59:13 EDT
Reverting to 2.12 is basically impossible.
Comment 3 Dan Winship 2013-07-19 10:59:03 EDT
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.
Comment 4 Tomas Mraz 2013-07-19 11:14:20 EDT
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.
Comment 5 Tomas Mraz 2013-07-19 11:16:16 EDT
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?
Comment 6 Tomas Mraz 2013-07-19 11:34:30 EDT
For example cups can be linked against openssl and now has even the license exception for that.
Comment 7 Tomas Mraz 2013-07-19 11:38:02 EDT
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
Comment 8 Daniel Berrange 2013-10-15 12:26:26 EDT
This also affects the (LGPLv2-only) 'oz' package since it uses libvirt, which in turns uses gnutls.
Comment 9 Eric Blake 2013-10-17 19:16:06 EDT
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.
Comment 10 Tim Waugh 2013-11-07 10:19:48 EST
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?
Comment 11 Andreas Metzler 2013-11-08 13:20:00 EST
(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
Comment 12 Eric Blake 2013-11-08 13:45:44 EST
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?
Comment 13 Andreas Metzler 2013-11-10 08:24:10 EST
(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!
Comment 14 Nikos Mavrogiannopoulos 2013-11-28 06:39:26 EST
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.
Comment 15 Dan Winship 2013-11-29 17:48:31 EST
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.
Comment 16 Nikos Mavrogiannopoulos 2013-12-11 12:41:48 EST
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
Comment 17 Daniel Berrange 2013-12-11 13:02:52 EST
(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.
Comment 18 Nikos Mavrogiannopoulos 2013-12-12 04:17:55 EST
I've contacted Fedora Legal.
Comment 19 Nikos Mavrogiannopoulos 2014-01-28 10:13:38 EST
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
Comment 20 Frantisek Kluknavsky 2014-04-15 10:07:56 EDT
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.
Comment 21 Nikos Mavrogiannopoulos 2014-04-15 10:15:05 EDT
Neither do I; thank you.

Note You need to log in before you can comment on or make changes to this bug.