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
