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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131225213613.ga15...@google.com