System libraries and the GPLv2 (was: Re: GnuTLS in Debian)
* Andreas Metzler:
> GnuTLS 2.12.x is dated. It is upstream's old-old-old stable release
> (followed by 3..x). The latest bugfix release happened in
> February 2012, later security fixes have not been solved by releases but
> by patches in GIT. GnuTLS 2.12.x does not work with the recently released
> gcrypt 1.6.0. Therefore we will need keep another old library version
> around. (I doubt that GnuTLS upstream will port GnuTLS 2.12.x to newer
> How to continue from here/solve this:
> #1 Fork LGPLv2.1+ GMP (version 4.2.1) for Debian.
> #2 Fork GnuTLS 2 for Debian.
> #3 Hope that GMP is relicensed to GPL2+/LGPLv3+
(this is what eventually happened.
> #4 Hop nettle switches to a different arbitrary precision arithmetic
> #5 Declare GMP to be a system library.
> #6 Move to GnuTLS3, drop GnuTLS2. Packages which cannot use GnuTLS3
> for license reasons will need to drop TLS support or be relicensed or
> be ported to a different TLS library.
> #5 was how Fedora looked at the OpenSSL library issue. Since Debian
> has another viewpoint on OpenSSL I somehow doubt we would use it for
I would like to suggest to treat more libraries as eligible for the
system library exception within Debian.
This would apply to OpenSSL (pre- and post-relicensing), and, perhaps
more importantly, to libgcc (a widely used C run-time library which is
mandatory to link against on some architectures).
libgcc been available under the GPLv3 for some time, and yet we still
use it to compile GPLv2-only programs. (My understanding is that the
GCC run-time library exception that applies to libgcc does not make
the library licensing GPLv2-compatible, it only helps licenses without
Would it be possible to get real legal advice on this matter, with the
concrete goal to find a usable process to leverage the system library
exception in the GPLv2?