Re: GnuTLS in Debian

[Jonathan Nieder <jrnieder@gmail.com>]

Russ Allbery wrote:

> Has anyone asked the Git maintainers whether they object to their software
> being linked with a libcurl that uses OpenSSL?

I am not the author of the most of Git.  As a minority author:

 - libcurl provides a quite similar API with OpenSSL as with GnuTLS.
   I wish it provided a compatible ABI.  Then this question could be
   sidestepped (similarly to the way lesstif used to be used)

 - I'm glad Debian git is not built against OpenSSL, since it provides
   a sanity check that git works without that dependency.  GnuTLS is
   stricter about adherance to the TLS protocol and has caught some
   server bugs that way.  It might be worth trying a build against nss
   to see how it compares.

 - I do not want git binaries built to depend on and distributed with
   non-free operating system components.  I do not want e.g. Microsoft
   to customize git to rely on some custom logic in proprietary DLLs
   and then distribute it with the OS.
   
   If the license that achieves that *also* makes git linked against
   free components like OpenSSL nondistributable in some circumstances
   (but still useful in other circumstances, like the Mac build where
   OpenSSL comes separately as part of the OS), that's an unfortunate
   but acceptable side effect, which I don't think it's worth chipping
   away at the license to get rid of.

   Using the GPL for git makes it easy to incorporate code from other
   sources (e.g., the kernel).  GPL+OpenSSL exception doesn't have
   that property.

 - Git has its own blk-sha1/ implementation which is pleasantly
   written, portably written, and very fast.  Even if there were no
   licensing issues involved, git for Debian would be built with
   BLK_SHA1=YesPlease (meaning the only relevant OpenSSL dependency
   is via libcurl).

Hope that helps,
Jonathan