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