On 03/13/2014 09:44 PM, Clint Adams wrote: > On Fri, Mar 14, 2014 at 01:11:16AM +0100, Alessandro Ghedini wrote: >> Well, nope. libgnutls28 still links against libgmp10 which is still LGPL3+. >> Unless I'm missing something that would make git (GPL2only) >> unredistributable. >> So no, that's not actually possible (again, unless I'm missing something). > > As far as I'm concerned, git should change its license irrespective of any > gmp compromise.
i'd love to see git sort out more sensible licensing too, but libgmp *is* actually in the process of a transition to dual-licensed LGPL3+ and GPL2+: https://gmplib.org/repo/gmp/rev/02634effbd4e This should suffice for git, afaict. GMPLib hasn't rolled a release that includes this change yet, but they do apparently plan a release in "early 2014". I'd love to see gnutls26 just go away in debian when this transition happens, but it seems silly to block on it. If libcurl-gnutls really has licensing concerns about moving to libgnutls28, and that causing problems for GPLv2 code that links against this version of libcurl, one possibility is to introduce libcurl4-gnutls28 -- there are already 3 TLS-library flavors of libcur, what is one more? :P >> Also, I don't see how this is a critical bug in curl. If your concern is >> libapache2-mod-gnutls why not just switch it back to libgnutls26? > > That's a question for the libapache2-mod-gnutls maintainer. GnuTLS 2.12.x (SONAME 26) is not supported by upstream any longer (has not been for years) and GnuTLS 3.x (SONAME 28) has significant improvements in terms of protocol version and algorithm availability (e.g. AES-GCM, the only known cipher mode that resists all known attacks is not available in 2.12.x) and useful configuration options (e.g. priority string improvements). There is no good reason i can see for libapache2-mod-gnutls to prefer the older version with less robust algorithm availability and weaker configuration options. Regards, --dkg
signature.asc
Description: OpenPGP digital signature
