@icing my reading of that ticket is that they do use libcurl-gnutls however OpenLDAP now links against OpenSSL (with the gnutls backend slated for removal) and so libcurl-gnutls ends up linked against OpenSSL
@icing if I understood that correctly, their problem seems to be coming from OpenLDAP, which links against OpenSSL. So libcurl-gnutls doesn't help as long as it links OpenLDAP.
Quote from the thread: > either OpenLDAP needs to use GnuTLS again or libcurl4-gnutls needs to not link against OpenLDAP.
IANAL either, but wouldn't that be a problem only if OpenSSL was statically linked to git?
The Apache license says that:
> For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work [...]
So if libcurl is dynamically linked to OpenSSL, the Apache License conditions doesn't apply, and thus don't propagate to git.
However, on the GPL v2 side it can depend on how you'd interpret section 3:
> [...] However, as a special exception, the source code distributed need not include anything that is normally distributed [...] with the major components [...] of the operating system on which the executable runs. [...]
I suppose that it then depends on whether libcurl and OpenSSL are considered "a major component of the operating system". If not, nobody (not even git themselves) can redistribute git in binary form. That would also apply to a myriad of other projects aswell (e.g: the Gnome DE uses the Apache 2.0-licensed libcups).
Edit: heck, even the Linux Kernel uses OpenSSL. That would suppose that nobody could redistribute it in binary form? git.kernel.org/pub/scm/linux/k…
just replied to it with my findings, I couldn't find a single distro that's not linking git with OpenSSL, either directly or indirectly (through libcurl-openssl).
Even GuixOS which doesn't build libcurl with LDAP support ends up linking to libssl on git-imap-send.
now there's a proposal to remove libcurl from the git build as a remedy, which of course would be quite a significant blow to everyone who clones https repositories...
> In Debian's case, the component (OpenSSL) accompanies the executable (Git) on the mirrors and on install media, so it doesn't apply.
I think it's a real stretch to say OpenSSL 'accompanies' the executable here and I can't help but wonder if Brian is stirring the pot deliberately. When I install things via apt, at the very least, I'm fetching individual distributions of program binaries. Stop shipping `git` in any default install images (are there any?) and this shouldn't even be a consideration.
Stefan Eissing
in reply to daniel:// stenberg:// • • •daniel:// stenberg://
in reply to Stefan Eissing • • •Michael
in reply to daniel:// stenberg:// • • •@icing my reading of that ticket is that they do use libcurl-gnutls however OpenLDAP now links against OpenSSL (with the gnutls backend slated for removal) and so libcurl-gnutls ends up linked against OpenSSL
So it’s really more of an OpenLDAP problem
Nils
in reply to daniel:// stenberg:// • • •@icing if I understood that correctly, their problem seems to be coming from OpenLDAP, which links against OpenSSL.
So libcurl-gnutls doesn't help as long as it links OpenLDAP.
Quote from the thread:
> either OpenLDAP needs to use GnuTLS again or libcurl4-gnutls needs to not link against OpenLDAP.
But no idea if that is actually the case.
vsz
in reply to daniel:// stenberg:// • • •Samantaz Fox
in reply to daniel:// stenberg:// • • •IANAL either, but wouldn't that be a problem only if OpenSSL was statically linked to git?
The Apache license says that:
> For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work [...]
So if libcurl is dynamically linked to OpenSSL, the Apache License conditions doesn't apply, and thus don't propagate to git.
However, on the GPL v2 side it can depend on how you'd interpret section 3:
> [...] However, as a special exception, the source code distributed need not include anything that is normally distributed [...] with the major components [...] of the operating system on which the executable runs. [...]
I suppose that it then depends on whether libcurl and OpenSSL are considered "a major component of the operating system". If not, nobody (not even git themselves) can redistribute git in binary form. That would also apply to a myriad of other projects aswell (e.g: the Gnome DE uses the Apache 2.0-licensed libcups).
Edit: heck, even the Linux Kernel uses OpenSSL. That would suppose that nobody could redistribute it in binary form?
git.kernel.org/pub/scm/linux/k…
extract-cert.c « certs - kernel/git/torvalds/linux.git - Linux kernel source tree
git.kernel.orgSamuel Henrique
in reply to daniel:// stenberg:// • • •just replied to it with my findings, I couldn't find a single distro that's not linking git with OpenSSL, either directly or indirectly (through libcurl-openssl).
Even GuixOS which doesn't build libcurl with LDAP support ends up linking to libssl on git-imap-send.
daniel:// stenberg://
in reply to daniel:// stenberg:// • • •DrasLorus
in reply to daniel:// stenberg:// • • •Samuel Henrique
in reply to daniel:// stenberg:// • • •Sean M. Collins
in reply to daniel:// stenberg:// • • •Neko
in reply to daniel:// stenberg:// • • •> In Debian's case, the component (OpenSSL) accompanies the executable
(Git) on the mirrors and on install media, so it doesn't apply.
I think it's a real stretch to say OpenSSL 'accompanies' the executable here and I can't help but wonder if Brian is stirring the pot deliberately. When I install things via apt, at the very least, I'm fetching individual distributions of program binaries. Stop shipping `git` in any default install images (are there any?) and this shouldn't even be a consideration.