Bug 1019408 - gnutls is now effectively LPGLv3+
gnutls is now effectively LPGLv3+
Status: CLOSED DUPLICATE of bug 1110689
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnutls (Show other bugs)
7.0
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Nikos Mavrogiannopoulos
BaseOS QE Security Team
:
Depends On: 1110689
Blocks:
  Show dependency treegraph
 
Reported: 2013-10-15 12:15 EDT by Daniel Berrange
Modified: 2014-11-06 04:24 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 986347
Environment:
Last Closed: 2014-11-06 04:24:32 EST
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)

  None (edit)
Description Daniel Berrange 2013-10-15 12:15:20 EDT
+++ This bug was initially created as a clone of Bug #986347 +++

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

--- Additional comment from Tomas Mraz on 2013-07-19 14:53:41 BST ---

I certainly cannot do anything with it in gnutls. Although it was my mistake to not consider this.

--- Additional comment from Tomas Mraz on 2013-07-19 14:59:13 BST ---

Reverting to 2.12 is basically impossible.

--- Additional comment from Dan Winship on 2013-07-19 15:59:03 BST ---

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.

--- Additional comment from Tomas Mraz on 2013-07-19 16:14:20 BST ---

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.

--- Additional comment from Tomas Mraz on 2013-07-19 16:16:16 BST ---

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?

--- Additional comment from Tomas Mraz on 2013-07-19 16:34:30 BST ---

For example cups can be linked against openssl and now has even the license exception for that.

--- Additional comment from Tomas Mraz on 2013-07-19 16:38:02 BST ---

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 7 Nikos Mavrogiannopoulos 2014-01-28 10:15:58 EST
It seems GMP is being re-licensed to GPLv2+LGPLv3 so it can be compatible with GPLv2-only software. While the released version with RHEL will not have this license, I think that the issue can be resolved by updating to the new gmplib once that is available (may take few weeks).

https://gmplib.org/repo/gmp/rev/02634effbd4e
Comment 11 Tomas Mraz 2014-11-06 04:24:32 EST
I think it can be closed as duplicate of that bug.

*** This bug has been marked as a duplicate of bug 1110689 ***

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