[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Do Debian now simply ignore OpenSSL incomatibilities with GPL?



On Tue, Oct 20, 2020 at 1:16 PM Jonas Smedegaard wrote:

> This was just now brought to my attention:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937#105

The decision linked therein appears to be based on the GPL system
library exception and on the fact that Fedora is relying on this
exception.

I personally don't believe that this exception is intended to be used
in the way that Debian and Fedora are now using it. It was mainly
intended for the use by third-party GPLed software distributed for
(but not with!) OSes with proprietary core libraries (libc etc), so
you can distribute coreutils binaries for IBM AIX linked against their
libc but IBM cannot include coreutils with AIX and then distribute the
result without also releasing the AIX libc source code under a GPL
compatible license.

I also note that Richard Fontana (a RedHat lawyer) called Fedora's use
of the system library exception "obviously bogus", see 27:15 in:

http://video.fosdem.org/2014/H2213/Sunday/Taking_license_compatibility_semiseriously.webm

I also note that the decision mentions CUPS as a concern, but when
Apple relicensed CUPS to the Apache 2.0 license, they added an
exception for GPLv2 codebases, so that part of the decision isn't
needed. I note that some files in the CUPS source package copyrighted
by Canonical are Apache 2.0 license but do not have the exception, but
these are apparmor files and are not linked into the binaries, so I
would guess they aren't a concern, I assume an exception from
Canonical would be a good clarification though.

> Do I understand correctly that Debian now ignore OpenSSL
> incomatibilities with GPL?

I feel like we have been doing so in certain cases for a long time
before the ftp-master decision anyway, so I don't think this is really
new.

> I.e. do we no longer need to either a) seek special exception for each
> and every piece of GPL-licensed code linking with current or older
> OpenSSL code, or b) patch such code to instead link with some
> alternative crypto library, or

In many cases, the GPL licensed code already has such exceptions or
patches applied, so the main issue has been transitive linking like
the bug reported above.

> c) wait for relicensd OpenSSL 3.0.0?

This is already available in experimental, but please note that it
uses the Apache 2.0 license, which is considered by some to be
incompatible with GPLv2 but not GPLv3 (and thus not GPLv2+).

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


Reply to: