Bug#1094969: git linked with OpenSSL

[Pirate Praveen]

brian m. carlson (one of the git upstream copyright holders) claims
in Bug #1094969 that git cannot be distributed when linked with
OpenSSL. IIRC the Debian position is to use the system library
exception.
Indeed our /usr/lib/git-core/git-remote-https links against
libssl.so.3, probably via libcurl-gnutls.so.4.
To avoid introducing distro-wide changes at a time where this seems
inappropriate, an option is to disable building git with libcurl.
Below is a simple patch to accomplish this. Barring any new insights
or feedback from the involved maintainers, this might be a way out.
I believe all relevant people are in CC:, and they can figure this
out. Details can be found in the bug.

[...]
Hello,
well, we have decided to use the system library exception because we
thought we had the right to so, not because we hoped that no copyright
holder would notice. Undoing this for specific packages where a
copyright holders tells us he disagrees undermines this position. Imho we
need to either with using the exception or somebody(TM) needs to do a
license analysis of our packages and we then need to implement coding
changes to weed out any and all GPL<->openssl linkage.
Personally I doubt we have the manpower nowadays to switch back from
linking against OpenSSL.
cu Andreas

Didn't OpenSSL switch license to Apache 2.0 and now compatible with GPL?
What am I missing here?

[Pirate Praveen]

Post by Pirate Praveen
Didn't OpenSSL switch license to Apache 2.0 and now compatible with
GPL? What am I missing here?

https://gplv3.fsf.org/wiki/index.php/Compatible_licenses#GPLv2-incompatible_licenses

Thanks, so only GPL v3/v2+ is compatible, not GPL v2 only. I missed that
nuance.

[Henrik Ahlgren]

Post by Pirate Praveen
Didn't OpenSSL switch license to Apache 2.0 and now compatible with
GPL? What am I missing here?

https://gplv3.fsf.org/wiki/index.php/Compatible_licenses#GPLv2-incompatible_licenses

[Robert Edmonds]

libcurl-gnutls -> libldap2 -> libssl
(There may be others; I didn't do a thorough check. Does anyone know if
there's a tool that will recursively analyze a binary's NEEDED sections
and build a human-readable graph of the library dependencies?)

I see the following with "libtree -vvv" (output trimmed by hand to just
the paths to libcrypto or libssl):

/usr/lib/git-core/git-remote-https
├── libcurl-gnutls.so.4 [ld.so.conf]
│ ├── libldap.so.2 [ld.so.conf]
│ │ ├── libcrypto.so.3 [ld.so.conf]
│ │ ├── libssl.so.3 [ld.so.conf]
│ │ └── libsasl2.so.2 [ld.so.conf]
│ │ ├── libcrypto.so.3 [ld.so.conf]
│ ├── libssh2.so.1 [ld.so.conf]
│ │ ├── libcrypto.so.3 [ld.so.conf]

[Sam Hartman]

Chris> brian m. carlson (one of the git upstream copyright holders)
Chris> claims in Bug #1094969 that git cannot be distributed when
Chris> linked with OpenSSL. IIRC the Debian position is to use the
Chris> system library exception.


TL;DR: I think that an individual upstream copyright holder's
interpretation should be given less rather than more weight in
interpreting a license.
I think that Debian should adopt a project-wide interpretation of the
system library exception and apply it inconsistently. Allowing the
exception to be interpreted differently on different packages harms our
users and the free software community.

here is a longer proposal on how I would recommend approaching an issue
like this:

1) Debian maintainers have a lot of flexibility. If the Git maintainers

[Sam Hartman]

Chris> brian m. carlson (one of the git upstream copyright holders)
Chris> claims in Bug #1094969 that git cannot be distributed when
Chris> linked with OpenSSL. IIRC the Debian position is to use the
Chris> system library exception.

[This was prematurely sent]

TL;DR: I think that an individual upstream copyright holder's
interpretation should be given less rather than more weight in
interpreting a license.
I think that Debian should adopt a project-wide interpretation of the
system library exception and apply it inconsistently. Allowing the
exception to be interpreted differently on different packages harms our
users and the free software community.

here is a longer proposal on how I would recommend approaching an issue
like this:

1) Debian maintainers have a lot of flexibility. If the Git maintainers
wish to change what they link with, they have that flexibility. I view
this more as "Upstream asked us to ship the software differently and we
decided to disagree." I do not think an NMU has this level of preference.


2) The people involved need to be comfortable with their legal
liability. If Debian were a legal entity this would be easy: we would
ask for legal review and make a decision after receiving it. Such a
decision would typically be made at a fairly high level as to whether a
particular issue posed unacceptable legal risk. To the extent that any
party is concerned about their legal liability, please discuss in
private--probably by first reaching out to the DPL and asking how to
engage with lawyers. Do not discuss the specifics of the situation
except in private mail (not copying a bug) with the lawyers.

3) Generally, copyright holders trying to interpret a license after the
fact should be given less weight rather than more. After all the
copyright holder could have chosen a different license or published a
clarification along with their release. Clearly if it turns out that
the system library exception does apply in this situation, but Git wants
it not to for git-remote-https, then effectly they copyright holders
would be creating a fork of GPL-2 (gpl-2-restrictive-system-library)
that is GPL 2 incompatible.
Allowing copyright holders to do that after the fact--especially when
they selectivly try to enforce that interpretation against some parties
but not others--serves the community poorly.


4) We should interpret the system library exception consistently. If we
believe it allows us to link with openssl, we should stick to that
position.
I think it is cleare that software freedom and our users are served by
letting free software link with Openssl. (I understand some parties
argue that the consequences of interpreting the system library exception
in a manner that permits that linking are worse than the consequences
of avoiding GPL-2 OpenSSL combinations.)
However our position does generally seem to be that we interpret the
system library exception as allowing that linking.
If our interpretation is challenged, we should respond the same way we
would to any other legal challenge to software freedom.
We should seek out people who have aligned interests and try and find
common cause. In this instance I'd definitely suggest the DPL reach out
to Canonical and Redhat.

5) If a license is being interpreted in a manner that discriminates
against Linux distributions--it allows everyone but Linux distributions
to distribute some combination--I think that license discriminates
against a kind of use/field of endeavor. In other words, such a license
would not be DFSG free.

--Sam

[Simon Josefsson]

As I have said before: I think that computer programmers have a
tendency to treat licenses as if they are self-executing (and precise
like software).

Agreed, this is often a challenge when technical people discuss legal
matters, and it helps to keep this in mind.

From what I can tell, the legal system does not operate that way, and
actual lawyers make distinctions based on harm/damages or lack
thereof.

My experience with lawyers is that circumstances, expectations and
intentions are more relevant than damages. Damages are more relevant
when assessing compensation, not when deciding who is right.

If someone has a claim to something and reasonable can expect certain
things in a situation, and that is violated, there is a legal case even
if you can make a technical argument that the person is wrong citing
various paragraphs in return. This is often frustrating for technical
people, feeling they are "right" and that circumstances doesn't matter.

I think Debian should take the position that Apache-2.0 and
GPL-2.0-only are compatible in practice.

I don't think that is a good position to be in. I believe it would be
better to work with rights holders to work out problems rather than to
ignore requests and throw legal arguments at them.

/Simon

[Ansgar 🙀]

Hi,

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.

[brian m. carlson]

Post by Ansgar 🙀
Hi,

Hi,

Post by Ansgar 🙀
As Git doesn't seem any different, I think we should close this bug.

I agree with you that we should close the bug, which I did a few minutes
ago. I provided slightly different reasons in the close message, but I
agree this would cause a lot of problems which we'd want to avoid and
it's not in the interests of the project to pursue it further.

My apologies for the needless controversy.

[Simon Josefsson]

Post by Ansgar 🙀
No, that is not the core problem. Debian, like most other binary
distributions, heavily relies on the system library exception in many,
many places.

I believe that is a fairly new (~5 years?) approach within Debian.
Debian used to treat OpenSSL incompatible with GPLv2 and that all code
that link to OpenSSL has to have a GPL+OpenSSL exception. Does anyone
recall how and when this decision was made?

Licensing wrt to libcurl and OpenSSL has been discussed before:

https://lists.debian.org/debian-legal/2004/08/msg00221.html

/Simon

[Michael Stone]

Post by Simon Josefsson
I believe that is a fairly new (~5 years?) approach within Debian.
Debian used to treat OpenSSL incompatible with GPLv2 and that all code
that link to OpenSSL has to have a GPL+OpenSSL exception. Does anyone
recall how and when this decision was made?

I think it was at least in part a pragmatic realization that debian was
being overly strict, as most other distributions (including those with
lawyers presumably incentivized to protect assets worth suing over) were
following a different interpretation.

FWIW, I think the current interpretation is much more in line with the
spirit of the text: we're not including openssl for the specific purpose
of linking to git; libssl is a part of the distribution that happens to
be pulled in (indirectly) when building git. It also seems not in
keeping with the spirit of the license that a completly non-free OS
linking non-free software would have fewer restrictions than a free OS
linking free software.

[Simon Josefsson]

Post by Michael Stone

Post by Simon Josefsson
I believe that is a fairly new (~5 years?) approach within Debian.
Debian used to treat OpenSSL incompatible with GPLv2 and that all code
that link to OpenSSL has to have a GPL+OpenSSL exception. Does anyone
recall how and when this decision was made?

I think it was at least in part a pragmatic realization that debian
was being overly strict, as most other distributions (including those
with lawyers presumably incentivized to protect assets worth suing
over) were
following a different interpretation.

Yes that seems likely. I think that the decision in other distributions
may have had more to do with aligning interests with organization who
fund them, though. It is a calculated risk to be in a better position
to get access to X money by breaching one interpretation of a license
that is unlikely to hurt financially. Debian doesn't have to follow the
same kind of reasoning, but I realize it is easy to do so.

Was invoking the system library exception discussed or decided on
project-wide in Debian? I tried to find some earlier discussion around
this, and while many discussions is possible to find, I don't see any
conclusions.

Post by Michael Stone
FWIW, I think the current interpretation is much more in line with the
spirit of the text: we're not including openssl for the specific
purpose of linking to git; libssl is a part of the distribution that
happens to be pulled in (indirectly) when building git. It also seems
not in keeping with the spirit of the license that a completly
non-free OS linking non-free software would have fewer restrictions
than a free OS linking free software.

I disagree.

I think the idea behind the "proprietary system library" GPL exception
is to make it possible to distribute GPL binaries linked to non-free
system libraries on systems where that is pretty much unavoidable, e.g.
system libraries on AIX, IRIX etc. The exception is that you are not
required to distribute source code for the non-free system libraries:

https://www.gnu.org/licenses/gpl-faq.en.html#SystemLibraryException

The exception in the GPLv2 says:

However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on)
of the operating system on which the executable runs, unless that
component itself accompanies the executable.

I believe that those components (compiler, kernel, OpenSSL, etc)
accompany the executable for Debian. So the exception does not appear
applicable to me.

The system library exception was not intended for distributions to be
able to link GPLv2 code to GPLv2-incompatible code: there is no "just
happens to" occuring in this situation, it is an intentional decision
made by packagers (which can be reversed to respect copyright holders).

/Simon

[Andreas Metzler]

On 2025-04-16 Simon Josefsson <***@josefsson.org> wrote:
[...]

Post by Simon Josefsson
Was invoking the system library exception discussed or decided on
project-wide in Debian? I tried to find some earlier discussion around
this, and while many discussions is possible to find, I don't see any
conclusions.

Good morning,

iirc it came up multiple times on diverse mailing lists as a suggestion.

We did not have a GR or something like it. We have a dedicated team to
decide what is acceptable to distribute (ftp-masters) and they made the
call. Given that they are the ones who need to be convinced of the
correctness of such decisions and stand by them I still think that was
the right way.

cu Andreas

[Ansgar 🙀]

Hi,

Yes that seems likely.  I think that the decision in other distributions
may have had more to do with aligning interests with organization who
fund them, though.

This is moving into conspiracy theory territory... We can as well
suspect reptiloids behind this.

Maybe other distributions also noticed that the system library
exception is required to distribute most GPL-2-only or GPL-3-only
software in practice. That is something the FSF forced, whatever their
motivations behind this are.

I believe that those components (compiler, kernel, OpenSSL, etc)
accompany the executable for Debian.  So the exception does not appear
applicable to me.
The system library exception was not intended for distributions to be
able to link GPLv2 code to GPLv2-incompatible code: there is no "just
happens to" occuring in this situation, it is an intentional decision
made by packagers (which can be reversed to respect copyright holders).

Debian has always allowed GPL-2-only code linked against GPL-3+-only
libraries such as the libstdc++ or GCC runtime libraries. (You ignore
that libraries aside of OpenSSL exist.)

Debian also has always allowed GPL-2-only code linked against OpenSSL
if one specific means of doing so was not used, for example we had (and
continue to have) GPL-2-only code using `import ssl` (directly or
indirectly) in Debian which happens to... link OpenSSL at runtime.

Debian treated one specific technical implementation of linking
(instructions for ld.so) for one specific system library (OpenSSL)
differently and stopped doing so.

So let me ask you directly: do you think we should remove all GPL-3
software directly or indirectly including anything from
/usr/include/linux/*.h?

Do you think we should remove all GPL-2 software linking libstdc++ or
other GCC runtime libraries?

Do you think we should remove all GPL-2 software linking (L)GPL-3+
libraries such as GnuTLS?

Do you think we should remove all GPL-2 software linking OpenSSL in any
way (including via `import ssl` or similar)?

Do you think we should remove all GPL-2 software linking any other
library licensed under, say, Apache-2 in any way (including via Python
imports or similar)?

Do you have any idea how much software would be affected?

Which of those must in your opinion be done before the release of
trixie?

Ansgar

[Bill Allombert]

Post by Ansgar 🙀
Hi,

Yes that seems likely.  I think that the decision in other distributions
may have had more to do with aligning interests with organization who
fund them, though.

This is moving into conspiracy theory territory... We can as well
suspect reptiloids behind this.

This is uncalled for. Saying that Fedora is influenced by RedHat for
example is not a conspiracy theory.

Debian has traditionally adopted a stricter approach to licenses than
other distributions.

Post by Ansgar 🙀
Debian has always allowed GPL-2-only code linked against GPL-3+-only
libraries such as the libstdc++ or GCC runtime libraries. (You ignore
that libraries aside of OpenSSL exist.)

Note that libstdc++ and GCC runtime libraries are covered by the
GCC Runtime Library Exception which is different from the system
library exception.

Cheers,
Bill.

[Ansgar 🙀]

Hi,

Post by Bill Allombert

Post by Ansgar 🙀
Debian has always allowed GPL-2-only code linked against GPL-3+-only
libraries such as the libstdc++ or GCC runtime libraries. (You ignore
that libraries aside of OpenSSL exist.)

Note that libstdc++ and GCC runtime libraries are covered by the
GCC Runtime Library Exception which is different from the system
library exception.

How is that relevant? Note that

(a) the runtime exception doesn't allow you to distribute the source
for libstdc++ under GPL-2-compatible terms which would be required by
the GPL-2-licensed software if one claims the system library exception
does not apply.

Otherwise: assume the runtime exception does so for all licenses, then
it would trivially allow to distribute the libstdc++ source under
proprietary licenses and one could just use a permissive license from
the start instead of GPL-3+-with-limited-extra-permissions.

(b) The OpenSSL license has a runtime library exception "built in" as
it doesn't require libraries linking it to be distributed under similar
terms as OpenSSL to begin with. So if it was relevant, the OpenSSL
problem would be solved too. (And proprietary operating system vendors
could just grant themselves an exception too if they wanted to
distributed GPL-2 programs as part of the operating system.)

Ansgar

[Henrik Ahlgren]

Post by Simon Josefsson
I think the idea behind the "proprietary system library" GPL exception
is to make it possible to distribute GPL binaries linked to non-free
system libraries on systems where that is pretty much unavoidable, e.g.
system libraries on AIX, IRIX etc. The exception is that you are not

I feel it is important to remember that the GPL v2 was released in June
1991. This was the era of proprietary UNIX, and the concept of a
(GNU/)Linux distribution, or the Linux kernel as a serious project, had
yet to emerge. Ian Murdoch founded Debian in 1993.

BTW, FSF considers Apache 2.0 as a good license and that "it's
unfortunate that the Apache License 2.0 isn't compatible with some free
software licenses like GPLv2". Compatibility with it was one important
goal for GPLv3. So, this incompatibility was not never designed, it was
just a mistake of an early free software license from a different era.

https://www.fsf.org/blogs/licensing/new-license-recommendations-guide

I believe that the term "system library" lacks significant meaning in an
operating system like Debian. One could argue that all libraries in
Debian qualify as "system libraries".

[Henrik Ahlgren]

But the crucial point here is that the git upstream is choosing not to
correct that mistake by moving to GPLv3 (probably they don't like some
other changes introduced) or giving another specific exception to
linking with Apache 2.0.

Well, Torvalds founded Git, and it is well known that he likes GPLv2 and
dislikes v3. Apparently he is still a major copyright holder, even after
handing over the project maintenance to Junio Hamano very early.

And how many copyright holders are involved in the project? It might be
permanently stuck to v2, much like the Linux kernel, which is now
practically impossible to change licenses.

Interestingly, the COPYING file in the Git tree states the following
(https://github.com/git/git/blob/master/COPYING):

Note that the only valid version of the GPL as far as this project
is concerned is _this_ particular version of the license (ie v2, not
v2.2 or v3.x or whatever), unless explicitly otherwise stated.

HOWEVER, in order to allow a migration to GPLv3 if that seems like
a good idea, I also ask that people involved with the project make
their preferences known. In particular, if you trust me to make that
decision, you might note so in your copyright message, ie something
like

This file is licensed under the GPL v2, or a later version
at the discretion of Linus.

might avoid issues. But we can also just decide to synchronize and
contact all copyright holders on record if/when the occasion arises.

Linus Torvalds

[Matthias Urlichs]

Post by Henrik Ahlgren
But we can also just decide to synchronize and
contact all copyright holders on record if/when the occasion arises.

Linus Torvalds should have known better than to be *that* optimistic.

The number of such notices might serve as a rough indicator for how many
people read such license files in the first place. (Spoiler: almost nobody.)

--
-- regards
--
-- Matthias Urlichs

[Simon Josefsson]

Post by Henrik Ahlgren

Post by Simon Josefsson
I think the idea behind the "proprietary system library" GPL exception
is to make it possible to distribute GPL binaries linked to non-free
system libraries on systems where that is pretty much unavoidable, e.g.
system libraries on AIX, IRIX etc. The exception is that you are not

I feel it is important to remember that the GPL v2 was released in June
1991. This was the era of proprietary UNIX, and the concept of a
(GNU/)Linux distribution, or the Linux kernel as a serious project, had
yet to emerge. Ian Murdoch founded Debian in 1993.

Sure. But the concept of non-free system libraries is still common and
the exception is applicable to these situations. Compare how Homebrew
can distribute GPLv2 binaries linked to system libraries on macOS
without having to distribute source code for those system libraries.

Post by Henrik Ahlgren
BTW, FSF considers Apache 2.0 as a good license and that "it's
unfortunate that the Apache License 2.0 isn't compatible with some free
software licenses like GPLv2". Compatibility with it was one important
goal for GPLv3. So, this incompatibility was not never designed, it was
just a mistake of an early free software license from a different era.

That would be a good argument for git to use GPLv3 from 2007 instead of
older GPLv2. I don't think that will happen, so we are stuck with GPLv2
for git, and the consequences of that decision.

Post by Henrik Ahlgren
I believe that the term "system library" lacks significant meaning in an
operating system like Debian.

I think that I agree with this. System libraries were intended for
things outside of the collection of work that you are distributing, such
as non-free system libraries on proprietary Unix. The comparable
element for Debian would be the UEFI boot loader or BIOS software.

But if this is the case, it seems you cannot invoke the GPL exception?
It is only valid for linking to something that qualify as a system
library. If OpenSSL in Debian isn't a system library, there is no
exception that allows linking.

Post by Henrik Ahlgren
One could argue that all libraries in Debian qualify as "system
libraries".

Yes, I think that could also be reasonable. However I think this
interpretation fails the "unless that component itself accompanies the
executable" part of the GPLv2 system library exception:

However, as a special exception, the source code distributed need not
include anything that is normally distributed (in either source or
binary form) with the major components (compiler, kernel, and so on)
of the operating system on which the executable runs, unless that
component itself accompanies the executable.

All this said, I think primarily the assumption that other distributions
made is that Linus won't sue to defend his GPLv2 copyright in Linux and
isn't likely to do so for Git either. That assumption works less well
for other copyright holders that may be more interested in defending
their rights.

/Simon

[Matthias Urlichs]

Post by Simon Josefsson
I think the idea behind the "proprietary system library" GPL exception
is to make it possible to distribute GPL binaries linked to non-free
system libraries on systems where that is pretty much unavoidable,

which, if you remove the "proprietary" and "non-free" wording which was
unavoidable when the GPL was written but isn't nowadays, is exactly what
we have here: it's pretty much unavoidable for nontrivial programs to
somehow link to libraries with "incompatible" licenses.

I thus move that we declare every library that supplies basic features
(nowadays SSL certainly counts as such) to a widely disparate cabal of
applications (ditto)  to be a System Library.

*Nobody* is going to go after Debian with a demand to stop doing such
linking, much less demand compensation of any damages. If anybody ever
does, well, we can discuss how to fix the problem then, **along with
pretty much every other distro out there**. This is not a Debian
specific problem.

Going out of our way to pro-actively kowtow[1] to barely-understood
legalese (we all are not lawyers, up to and including the FTP team) is
not The Way. Neither is crippling some features of git, or whichever
else program du jour has this problem.

NB no it's not possible to re-license git to GPLv3. That'd be only
slightly less difficult as re-licensing the Linux kernel.

[1] "to show obsequious deference"*
*

--
-- mit freundlichen GrÌßen
--
-- Matthias Urlichs