Bug#995636: OpenSSL 3.0 - Apache 2.0 vs GPL 2 (Re: Bug#995636: transition: openssl)

Michael Biebl

unread,

Oct 5, 2021, 2:10:05 PM10/5/21

to

Hi Kurt, hi Luca, hi everyone,

regarding the impending transition to OpenSSL 3.0 in unstable (which is
now licensed under Apache 2.0), I wonder what that means for Debian,
given that apparently GPL-2 (and also LGPL-2) and Apache 2.0 are
incompatible with each other.

If I read Luca correctly[1], any library or executable using GPL-2+
effectively becomes GPL-3+ once they link against OpenSSL 3.0.
And especially for libraries, this would have a ripple effect through
the whole distribution and cause issues e.g for GPL-2 only packages.

Fwiw, I'm surprised that this also apparently affects LGPL-2.

That said, I'm not a lawyer and reading license texts hurts my brain.
So my goal is is mainly to raise awareness of this issue and seek input
from the community.

Regards,
Michael

Am 03.10.21 um 14:59 schrieb Kurt Roeckx:
> Package: release.debian.org
> Severity: normal
> User: release.d...@packages.debian.org
> Usertags: transition
>
> Hi,
>
> We would like to transition to OpenSSL 3.0.0. It's currently in
> experimental. It has an soname change, so the binary packages got
> renamed and binNMUs will be required.
>
> We did a rebuild of packages and currently have 105 packages
> that FTBFS with OpenSSL 3.0.0 that build with 1.1.1. I've started
> filing bugs for that:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=pkg-open...@lists.alioth.debian.org&tag=ftbfs-3.0
>
>
> Kurt
>

[1] https://github.com/systemd/systemd/pull/20915

OpenPGP_signature

Sebastian Andrzej Siewior

unread,

Oct 5, 2021, 3:30:03 PM10/5/21

to

On 2021-10-05 20:03:49 [+0200], Michael Biebl wrote:
> Hi Kurt, hi Luca, hi everyone,

Hi Michael,

> That said, I'm not a lawyer and reading license texts hurts my brain.
> So my goal is is mainly to raise awareness of this issue and seek input from
> the community.

GPL code which linked against OpenSSL usually has a "gpl-exception
clause for OpenSSL". This should be still accepted since it refers
specifically to OpenSSL.

Additionally OpenSSL is considered system library, see
https://bugs.debian.org/951780
https://bugs.debian.org/972181

> Regards,
> Michael

Sebastian

Luca Boccassi

unread,

Oct 6, 2021, 7:40:02 AM10/6/21

to

On Tue, 2021-10-05 at 21:04 +0200, Sebastian Andrzej Siewior wrote:
> On 2021-10-05 20:03:49 [+0200], Michael Biebl wrote:
> > Hi Kurt, hi Luca, hi everyone,
> Hi Michael,
>
> > That said, I'm not a lawyer and reading license texts hurts my brain.
> > So my goal is is mainly to raise awareness of this issue and seek input from
> > the community.
>
> GPL code which linked against OpenSSL usually has a "gpl-exception
> clause for OpenSSL". This should be still accepted since it refers
> specifically to OpenSSL.

Many projects do not have that. Also to be extremely pedantic it needs
to be checked if it just references OpenSSL as a project, or
specifically the OpenSSL license which is a specific and well defined
document: https://spdx.org/licenses/OpenSSL.html AFAIK there's no
"standard" clause, everyone uses their own wording, more or less.

More importantly, as far as I understand and I was told recently these
are not transitive - ie, it's fine for an executable, but if it
concerns a library, it does not "transfer" to external programs linking
to that library.

> Additionally OpenSSL is considered system library, see
> https://bugs.debian.org/951780
> https://bugs.debian.org/972181

Even if that interpretation holds, and it's not a universal
interpretation (eg: lawyers from Canonical strongly disagree as far as
I know), again that applies to first-party binaries only as far as I
understand. It's not as clear-cut with libraries used by third parties.

The core issue as always is uncertainty: any time there are doubts and
conflicting interpretations, we all lose, especially our users, and
especially those that are then forced to have awkward conversations
with their corporate lawyers. Which is why it's really unfortunate that
, in order to fix compatibility issues with the GPL, among all the
permissive licenses available out there, the OpenSSL project picked the
_one_ that has serious compatibility questions with the GPL :-(

But of course this doesn't mean we shouldn't move to the new version,
quite the contrary - I'll simply be careful about the projects I am
involved in and what it means for them and their license clarity, and
what I can do to make it better, if anything.

--
Kind regards,
Luca Boccassi

signature.asc

Paul Wise

unread,

Oct 6, 2021, 11:20:02 AM10/6/21

to

On Wed, Oct 6, 2021 at 11:30 AM Luca Boccassi wrote:
> On Tue, 2021-10-05 at 21:04 +0200, Sebastian Andrzej Siewior wrote:
> > Additionally OpenSSL is considered system library, see
> > https://bugs.debian.org/951780
> > https://bugs.debian.org/972181
>
> Even if that interpretation holds, and it's not a universal
> interpretation (eg: lawyers from Canonical strongly disagree as far as
> I know), again that applies to first-party binaries only as far as I
> understand. It's not as clear-cut with libraries used by third parties.

As I understand it, it is meant only for binaries distributed by
parties other than the one distributing the system containing the
"system library". So third-party app distributors are fine to ignore
the incompatibility between a GPL app and a proprietary libc, but the
OS vendor can't include GPL apps linked to that proprietary libc
within their system.

https://lists.debian.org/debian-devel/2020/10/msg00168.html

> The core issue as always is uncertainty: any time there are doubts and
> conflicting interpretations, we all lose, especially our users, and
> especially those that are then forced to have awkward conversations
> with their corporate lawyers. Which is why it's really unfortunate that
> , in order to fix compatibility issues with the GPL, among all the
> permissive licenses available out there, the OpenSSL project picked the
> _one_ that has serious compatibility questions with the GPL :-(

I believe OpenSSL 3's choice of the Apache 2 license only improves
compatibility, it doesn't reduce it. GPLv3 is supposedly compatible
with Apache 2, so GPLv3 and GPLv2+ programs are newly compatible with
OpenSSL 3. Most existing GPLv2-only programs that use OpenSSL will
have the exception anyway.

--
bye,
pabs

https://wiki.debian.org/PaulWise

Ansgar

unread,

Oct 6, 2021, 4:30:02 PM10/6/21

to

Paul Wise writes:
> On Wed, Oct 6, 2021 at 11:30 AM Luca Boccassi wrote:
>> On Tue, 2021-10-05 at 21:04 +0200, Sebastian Andrzej Siewior wrote:
>> > Additionally OpenSSL is considered system library, see
>> > https://bugs.debian.org/951780
>> > https://bugs.debian.org/972181
>>
>> Even if that interpretation holds, and it's not a universal
>> interpretation (eg: lawyers from Canonical strongly disagree as far as
>> I know), again that applies to first-party binaries only as far as I
>> understand. It's not as clear-cut with libraries used by third parties.

I believe Canonical also ships GPL-2-only programs linked (possibly
indirectly) to OpenSSL as part of their Linux distribution these days.

> As I understand it, it is meant only for binaries distributed by
> parties other than the one distributing the system containing the
> "system library". So third-party app distributors are fine to ignore
> the incompatibility between a GPL app and a proprietary libc, but the
> OS vendor can't include GPL apps linked to that proprietary libc
> within their system.

Debian uses many GPL-2-incompatible system libraries: for example
GPL-3-or-later libraries such as libstdc++ or libgcc or gnutls[1].
Debian also ships many GPL-2-only programs using these.

So if this was considered a problem, then the problem would be quite
large.

[1]: gnutls could be made LGPL-2.1-or-later by rewriting the
GPL-3-or-later build scripts; note that GPL-2 states that "complete
source code" includes "scripts used to control compilation and
installation of the executable"

> I believe OpenSSL 3's choice of the Apache 2 license only improves
> compatibility, it doesn't reduce it. GPLv3 is supposedly compatible
> with Apache 2, so GPLv3 and GPLv2+ programs are newly compatible with
> OpenSSL 3. Most existing GPLv2-only programs that use OpenSSL will
> have the exception anyway.

This depends on what you mean by "use OpenSSL": if program use OpenSSL
directly, maybe; if programs link to OpenSSL indirectly, for example via
dependency chains such as my-program -> some-library ->
some-library-implementing-some-network-protocol -> OpenSSL this becomes
increasingly unlikely the longer the chain is. Also people seem to keep
adding TLS support to more and more libraries, so such a dependency can
just silently appear later.

Python programs using OpenSSL also usually don't have such an exception.

🐾,
Ansgar