Licensing issue with openssl <3.0 #961

New Issue

OVERLORD · 2025-10-09T16:58:26+03:00

OVERLORD commented

2025-10-09 16:58:26 +03:00

Originally created by @dionysius on GitHub.

While building my debian packaging I got informed by the tooling that vaultwarden, licensed as GPL-3, links to openssl, licensed as either Apache 2.0 (v3.0+) or the dual OpenSSL and SSLeay license (<v3.0), which can be incompatible. Apache 2.0 seems fine from my mind, but I'm not fit in that licensing jungle. The OpenSSL license for <3.0 seem to be the issue.

Linking a stackoverflow question which summerizes the situation and solution pretty well.

Current Ubuntu LTS jammy uses openssl 3.0.0, but current Debian stable bullseye uses openssl 1.1.1. It's good that we soon don't have to worry anymore once openssl 3.0.0 is rolled out everywhere (implicates that my above assumption is correct regarding Apache 2.0).

Is it possible to include an exception for openssl as they've discussed in the above stackoverflow question? So far I couldn't find such an exception in the current license text yet.

Originally created by @dionysius on GitHub. While building my debian packaging I got informed by the tooling that vaultwarden, [licensed as GPL-3](https://github.com/dani-garcia/vaultwarden/blob/main/LICENSE.txt), links to openssl, [licensed as either Apache 2.0 (v3.0+) or the dual OpenSSL and SSLeay license (<v3.0)](https://www.openssl.org/source/license.html), which can be incompatible. _Apache 2.0 seems fine from my mind, **but I'm not fit in that licensing jungle**_. The OpenSSL license for <3.0 seem to be the issue. [Linking a stackoverflow question which summerizes the situation and solution pretty well.](https://opensource.stackexchange.com/questions/2233/gpl-v3-with-openssl-exception) Current Ubuntu LTS jammy uses openssl 3.0.0, but current Debian stable bullseye uses openssl 1.1.1. It's good that we soon don't have to worry anymore once openssl 3.0.0 is rolled out everywhere (implicates that my above assumption is correct regarding Apache 2.0). Is it possible to include an exception for openssl as they've discussed in the above stackoverflow question? So far I couldn't find such an exception in the current license text yet.

OVERLORD closed this issue

2025-10-09 16:58:27 +03:00

OVERLORD commented

2025-10-09 16:58:29 +03:00

@dionysius commented on GitHub:

I worked a bit more on my packaging and ended up not shipping a build for debian anyway since github actions has no debian images. BTW its the debian tooling that informed me, so I'd have to dig deeper why I still get the warning if debian would have such exception globally.

For me it would be fine closing this. I'm right now not affected by this anymore and the issue will anyway silently go away in time. I just also wanted to let you know.

@dionysius commented on GitHub: I worked a bit more on my packaging and ended up not shipping a build for debian anyway since github actions has no debian images. BTW its the debian tooling that informed me, so I'd have to dig deeper why I still get the warning if debian would have such exception globally. For me it would be fine closing this. I'm right now not affected by this anymore and the issue will anyway silently go away in time. I just also wanted to let you know.

OVERLORD commented

2025-10-09 16:58:31 +03:00

@BlackDex commented on GitHub:

I think Debian/Ubuntu isn't an issue atm. But the Alpine based images which are using 1.1.1 as a static library might be. Switching to 3.x is maybe something we should think about. Also with the debian images. But i rather wait until bookworm is stable.

@BlackDex commented on GitHub: I think Debian/Ubuntu isn't an issue atm. But the Alpine based images which are using 1.1.1 as a static library might be. Switching to 3.x is maybe something we should think about. Also with the debian images. But i rather wait until bookworm is stable.

OVERLORD commented

2025-10-09 16:58:31 +03:00

@stefan0xC commented on GitHub:

Does the system library exception not apply? As far as I've looked into this, Debian apparently decided to treat OpenSSL as a system library like Fedora but I'm not a lawyer and not sure if an exception is still necessary or not, and to what extend the usage of openssl crate (which could theoretically be also linked against LibreSSL) makes a difference in this case or not.

Since the Apache 2.0 license is compatible you could ship a vendored openssl-3.0 instead of linking to the system library as a workaround (if Debian packaging policies allow this).

@stefan0xC commented on GitHub: Does the system library exception not apply? As far as I've looked into this, Debian apparently [decided to treat OpenSSL as a system library](https://bugs.debian.org/972181) like Fedora but I'm not a lawyer and not sure if an exception is still necessary or not, and to what extend the usage of `openssl` crate (which could theoretically be also linked against LibreSSL) makes a difference in this case or not. Since the Apache 2.0 license [is compatible](https://www.apache.org/licenses/GPL-compatibility.html) you could ship a vendored `openssl-3.0` instead of linking to the system library as a workaround (if Debian packaging policies allow this).

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#961