* Andreas Metzler: > Problems: > --------- > GnuTLS 2.12.x is dated. It is upstream's old-old-old stable release > (followed by 3.[012].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 > gcrypt.) > > 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 > library. > > #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. (snip) > #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 > GMP. 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 copyleft-like provisions.) 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?
