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

[Ansgar <ansgar@debian.org>]

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