On Thu, Mar 13, 2014 at 10:42:23PM -0400, Daniel Kahn Gillmor wrote: > 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+:
As I said in my email, I'm already aware of this, but as long as that hasn't
reached Debian we still have to deal with the problem. You may ask the gmp
maintainer to merge those changes in Debian though. That would help.
> 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.
"Avoid making git unredistributable" doesn't sound that silly to me (having
these kind of problems in the first place kind of is though).
There's also the chance that switching to libgnutls28 would break packages that
directly or indirectly depend on libgnutls26 (that is, the inverse of the
libapache2-mod-gnutls problem).
> 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
That's not going to happen. If anything libgnutls-dev and libgnutls28-dev can't
be installed at the same time, and just because curl's packaging is already a
mess doesn't mean it's ok to make it even more messier.
On the bright side, I was looking into reducing the libcurl flavors to just the
libnss one, but that's not yet possible, as long as #726116 doesn't get fixed.
> >> 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.
Well, "making it work, i.e. fix #741557, and avoid having it removed from
testing" sounds like a pretty good reason to me. Granted, it's really not that
much of a good solution, but it would hopefully be only temporary.
Cheers
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'
signature.asc
Description: Digital signature
