<html><head></head><body><p dir="ltr">My gut reaction was that #5 or #6 are the best option (leaning to #6). However I guess I don't understand what making something a system library effects the license?</p>
<br><br><div class="gmail_quote">Andreas Metzler <ametzler@debian.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">Hello,<br /><br />Debian ist still relying heavily on GnuTLS 2.12.x, and I do not think<br />this is sustainable for much longer.<br /><br />State of Play:<br />---------<br />In July 2011 with version 3.0 [1] GnuTLS switched to Nettle as only<br />supported crypto backend. Nettle requires GMP.<br /><br />GnuTLS and Nettle are available under LGPLv2.1+. GMP used to be<br />licensed LGPLv2.1+ ages ago but upgraded to LGPLv3+ in version 4.2.2<br />(released September 2007).<br /><br />Therefore GnuTLS 3.x cannot be used by GPLv2 (without "or later"<br />clause) software which is the main reason most of Debian is still<br />using GnuTLS 2.x.<br /><br />Problems:<br />---------<br />GnuTLS 2.12.x is dated. It is upstream's old-old-old stable release<br />(followed by 3.[012].x). The latest bugfix release happened in<br />February 2012, later security fixes have not been solved by releases but<br />by patches in GIT. GnuTLS 2.12.x does not work with the recently
released<br />gcrypt 1.6.0. Therefore we will need keep another old library version<br />around. (I doubt that GnuTLS upstream will port GnuTLS 2.12.x to newer<br />gcrypt.)<br /><br />How to continue from here/solve this:<br />---------<br />#1 Fork LGPLv2.1+ GMP (version 4.2.1) for Debian.<br /><br />#2 Fork GnuTLS 2 for Debian.<br /><br />#3 Hope that GMP is relicensed to GPL2+/LGPLv3+<br /><br />#4 Hop nettle switches to a different arbitrary precision arithmetic <br />library.<br /><br />#5 Declare GMP to be a system library.<br /><br />#6 Move to GnuTLS3, drop GnuTLS2. Packages which cannot use GnuTLS3<br />for license reasons will need to drop TLS support or be relicensed or<br />be ported to a different TLS library.<br /><br /><br />Personal comments:<br />---------<br />I do not think #1 and #2 are realistic given Debian's manpower issues. Also<br />#1 would stop working at all if nettle required newer GMP features. (I<br />have not checked whether this is already the
case.)<br /><br />I have given up on #3 and do not think it will happen. GMP upstream has<br />been made aware of the issue in 2011 [2] and has not shown any intention of<br />a license change.<br /><br />#4 is just here for completeness sake.<br /><br />#5 was how Fedora looked at the OpenSSL library issue. Since Debian<br />has another viewpoint on OpenSSL I somehow doubt we would use it for<br />GMP.<br /><br />Fedora is discussing the issue in<br /><<a href="https://bugzilla.redhat.com/show_bug.cgi?id=986347">https://bugzilla.redhat.com/show_bug.cgi?id=986347</a>>. There is<br />automatically generated depency tree with the problematic packages<br />highlighted crosslinked in the bugreport[3]. Debian does not have the<br />infrastructure to do something similar, but I guess gnutls usage is<br />more widespread.<br /><br />Summary:<br />---------<br />Afaict it boils down to #6. But perhaps I have missed something<br />obvious. Comments welcome.<br /><br />cu Andreas<br
/><br /><br />[1] Version 2.11.1 (released 2010-09-14) used nettle as<br />/prefered/ crypto backend, however gcrypt was still supported as<br />alternative.<br /><br />[2] <a href="http://gmplib.org/list-archives/gmp-bugs/2011-February/002178.html">http://gmplib.org/list-archives/gmp-bugs/2011-February/002178.html</a> <br /><a href="http://gmplib.org/list-archives/gmp-devel/2011-May/001952.html">http://gmplib.org/list-archives/gmp-devel/2011-May/001952.html</a><br /><br />[3] <a href="http://people.redhat.com/nmavrogi/fedora/out.fedora.txt">http://people.redhat.com/nmavrogi/fedora/out.fedora.txt</a></pre></blockquote></div></body></html>