Hi, On Mon, 2025-04-14 at 16:18 -0500, Richard Laager wrote: > On 2025-04-14 11:10, Russ Allbery wrote: > > I do find it fairly hard to understand the logic behind a position that > > somehow our git-remote-https binary as distributed is a derived work of > > OpenSSL and thus violates the GPLv2 license based on the nature of this > > specific dependency chain, but then I was always dubious of the legal > > merits of FSF's extremely aggressive and maximalist position on the > > definition of derived works in the context of the GPLv2 license. [...] > Now that OpenSSL is licensed under Apache-2.0, everyone agrees that > GPL-3.0 and Apache-2.0 are compatible. As a result, anything that is > GPL-3.0-only or GPL-3.0-and-later or GPL-2.0-or-later (or > GPL-1.0-or-later) is fine. That probably covers most things. > > The remaining problem space is thus GPL-2.0-only, which is at issue > here. The question is, are GPL-2.0-only and Apache-2.0 compatible? The > FSF says no. As far as I can tell, the Apache Software Foundation > doesn't necessarily agree with the FSF about this incompatibility, but > respects their position on the issue. [1]
No, that is not the core problem. Debian, like most other binary distributions, heavily relies on the system library exception in many, many places. OpenSSL is just one instance, but there is also, for example, libstdc++ which are not available under GPL-2-compatible terms. Note that GPL-2 says the following: +--- | For an executable work, complete source | code means all the source code for all modules it contains, plus any | associated interface definition files, plus the scripts used to | control compilation and installation of the executable. +--- Now parts of build scripts of packages that curl depends on are GPL-3- or-later, for example: - libnghttp2-14: m4/ax_python_devel.m4 - libnghttp3-9: config.guess, config.sub - libc6: scripts/config.guess, scripts/config.sub - curl itself: config.guess, config.sub So these libraries cannot be distributed under GPL-2 unless someone changes the build system. (Note that common exceptions only apply for proprietary licenses, but don't allow to fulfill the GPL-2 requirements.) (As an observation: GnuTLS is also not distributable under GPL-2- compatible terms as "[...], build system, [...] are licenced under the GNU General Public License version 3+". So using it instead of OpenSSL would not work either.) Header files, linker scripts, ... from GCC might also fall under this if the exception for compilers is not valid. Arguably GNU make too as it "control[s] compilation and installation of the executable". So Git would need to use a different compiler and make implementation. One can continue with the rest of the operating system like shells. All distributions thus rely on the system library exception to be able to distribute most GPL-2-only[1] or GPL-3-only[2] code at all... As Git doesn't seem any different, I think we should close this bug. If we think the system library exception is not valid, then we probably have to remove lots of software and switch core libraries (e.g., use clang, libc++ instead of gcc). Ansgar [1]: Even ignoring fun things like build scripts due to libstdc++ and similar. [2]: GPL-3 has the same problems, just in the other direction. Consider for example /usr/include/linux/*.h which gets indirectly included in many places.
