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?
Andreas Metzler <ametz...@debian.org> wrote: >Hello, > >Debian ist still relying heavily on GnuTLS 2.12.x, and I do not think >this is sustainable for much longer. > >State of Play: >--------- >In July 2011 with version 3.0 [1] GnuTLS switched to Nettle as only >supported crypto backend. Nettle requires GMP. > >GnuTLS and Nettle are available under LGPLv2.1+. GMP used to be >licensed LGPLv2.1+ ages ago but upgraded to LGPLv3+ in version 4.2.2 >(released September 2007). > >Therefore GnuTLS 3.x cannot be used by GPLv2 (without "or later" >clause) software which is the main reason most of Debian is still >using GnuTLS 2.x. > >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+ > >#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. > > >Personal comments: >--------- >I do not think #1 and #2 are realistic given Debian's manpower issues. >Also >#1 would stop working at all if nettle required newer GMP features. (I >have not checked whether this is already the case.) > >I have given up on #3 and do not think it will happen. GMP upstream has >been made aware of the issue in 2011 [2] and has not shown any >intention of >a license change. > >#4 is just here for completeness sake. > >#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. > >Fedora is discussing the issue in ><https://bugzilla.redhat.com/show_bug.cgi?id=986347>. There is >automatically generated depency tree with the problematic packages >highlighted crosslinked in the bugreport[3]. Debian does not have the >infrastructure to do something similar, but I guess gnutls usage is >more widespread. > >Summary: >--------- >Afaict it boils down to #6. But perhaps I have missed something >obvious. Comments welcome. > >cu Andreas > > >[1] Version 2.11.1 (released 2010-09-14) used nettle as >/prefered/ crypto backend, however gcrypt was still supported as >alternative. > >[2] http://gmplib.org/list-archives/gmp-bugs/2011-February/002178.html >http://gmplib.org/list-archives/gmp-devel/2011-May/001952.html > >[3] http://people.redhat.com/nmavrogi/fedora/out.fedora.txt >-- >`What a good friend you are to him, Dr. Maturin. His other friends are >so grateful to you.' >`I sew his ears on from time to time, sure'
