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…

This entry was edited (5 months ago)
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.