Re: Do Debian now simply ignore OpenSSL incomatibilities with GPL?
Hello Jonas, On Wed 21 Oct 2020 at 10:52am +02, Jonas Smedegaard wrote: > tl;dr: I think Debian should _state_ current practice (not just omit > stating obsolete practice), and state it towards our users (not only > ourselves). I just looked up old meeting minutes and the team does intend to issue a statement about it. I just pinged the person assigned to this. -- Sean Whitton
Re: Do Debian now simply ignore OpenSSL incomatibilities with GPL?
Hi Sean, and others, Quoting Sean Whitton (2020-10-20 23:04:22) > Hello, > > On Tue 20 Oct 2020 at 06:43pm +02, Jonas Smedegaard wrote: > > > It would certainly be good to have an official clarification. > > I applied a patch to the REJECT-FAQ about it yesterday (thanks to > Michael for the patch). Is that adequate? > > https://salsa.debian.org/ftp-team/website/-/commit/c804b2d2d0ff28ce50bbeaecaec6db05a58949b8 tl;dr: I think Debian should _state_ current practice (not just omit stating obsolete practice), and state it towards our users (not only ourselves). It sure helps to have official website of the ftp-team reflect current practice of the the ftp-team, by removing obsolete practice. Thanks for spotting and correcting that. What I think is important is something else, however. It is still¹ unclear to me *which* og the involved general public license(s) Debian now interpret differently - GPL-1 and/or GPL-2 and/or GPL-3 and/or SSLeay and/or OpenSSL? - and how exactly. If (as one notable speculative example) Debian now generally considers OpenSSL code as integral part of the core system for the interpretation of legal texts, then I think the ideal would be to add a note to https://www.debian.org/legal/licenses/ documenting that interpretation. Why so prominently? Because it affects our users legally that we choose a different interpretation than the one equally prominently given by the author and major active user of at least one of the involved licenses: https://www.gnu.org/licenses/license-list.en.html#OpenSSL Your proposed edit corrects _conflicting_ information from same team, but does not really _clarify_ current practice, and that same page states it "is a purely informational list, there may be more reasons." On a related note, our (arguably more official) main website points to an (arguably less official) page explicitly saying about linking GPL and OpenSSL licensed code that "a note accompanying the license giving some extra permission must be present": https://people.debian.org/~bap/dfsg-faq linked from https://www.debian.org/legal/licenses/ Kind regards, - Jonas ¹ I appreciate the input from Paul Wise and Andrey Rahmatullin, but those seem more like personal interpretations than conclusive official Debian statements. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Do Debian now simply ignore OpenSSL incomatibilities with GPL?
Hello, On Tue 20 Oct 2020 at 06:43pm +02, Jonas Smedegaard wrote: > It would certainly be good to have an official clarification. I applied a patch to the REJECT-FAQ about it yesterday (thanks to Michael for the patch). Is that adequate? https://salsa.debian.org/ftp-team/website/-/commit/c804b2d2d0ff28ce50bbeaecaec6db05a58949b8 -- Sean Whitton
Re: Do Debian now simply ignore OpenSSL incomatibilities with GPL?
On Tue, Oct 20, 2020 at 06:43:16PM +0200, Jonas Smedegaard wrote: > Quoting Michael Biebl (2020-10-20 16:23:20) > > Am 20.10.20 um 15:16 schrieb Jonas Smedegaard: > > > This was just now brought to my attention: > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937#105 > > > > > > Do I understand correctly that Debian now ignore OpenSSL > > > incomatibilities with GPL? > > > > > > 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 c) wait for relicensd OpenSSL 3.0.0? > > > > > > > Yeah. I guess an official email from the ftp-master team regarding > > this issue would be a good idea. > > > > Fwiw, I think this this is a reasonable decision by the ftp-master > > team and I support it. > > It would certainly be good to have an official clarification. > > As I understand it, the conflict is that OpenSSL requires advertising > and GPL¹ requires no other requirements than those defined by GPL. > > It would therefore be quite relevant, I think, to have clarified if > Debian a) considers the OpenSSL requirement void, or b) considers the > GPL restriction about added requirements void². Debian considers OpenSSL a "system library"/"major component" as defined in GPL2 para 3 and GPL3 para 1, which lifts some requirements. -- WBR, wRAR signature.asc Description: PGP signature
Re: Do Debian now simply ignore OpenSSL incomatibilities with GPL?
Quoting Michael Biebl (2020-10-20 16:23:20) > Am 20.10.20 um 15:16 schrieb Jonas Smedegaard: > > This was just now brought to my attention: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937#105 > > > > Do I understand correctly that Debian now ignore OpenSSL > > incomatibilities with GPL? > > > > 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 c) wait for relicensd OpenSSL 3.0.0? > > > > Yeah. I guess an official email from the ftp-master team regarding > this issue would be a good idea. > > Fwiw, I think this this is a reasonable decision by the ftp-master > team and I support it. It would certainly be good to have an official clarification. As I understand it, the conflict is that OpenSSL requires advertising and GPL¹ requires no other requirements than those defined by GPL. It would therefore be quite relevant, I think, to have clarified if Debian a) considers the OpenSSL requirement void, or b) considers the GPL restriction about added requirements void². ...or c) I am talking rubbish here and it is something else entirely. - Jonas ¹ GPL-with-some-exception is a different license than GPL. ² i.e. applying different interpreting than the authors of GPL does: https://www.gnu.org/licenses/license-list.en.html#OpenSSL -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
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
Re: Do Debian now simply ignore OpenSSL incomatibilities with GPL?
Am 20.10.20 um 15:16 schrieb Jonas Smedegaard: > This was just now brought to my attention: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924937#105 > > Do I understand correctly that Debian now ignore OpenSSL > incomatibilities with GPL? > > 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 c) wait for relicensd OpenSSL 3.0.0? > Yeah. I guess an official email from the ftp-master team regarding this issue would be a good idea. Fwiw, I think this this is a reasonable decision by the ftp-master team and I support it. Michael signature.asc Description: OpenPGP digital signature
