Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
Leo Famulari writes: > On Fri, Oct 22, 2021 at 02:17:33PM -0700, Vagrant Cascadian wrote: >> * Disable substitutes for relevent packages. Technically correct as >> license incompatibility is only triggered on transmission of binary, >> though maybe missing something about the spirit of the GPL. > > Maybe, but did anyone with standing ever take action regarding these > licensing incompatibilities? > > Perhaps, looking at these issues too closely is also missing something > about the spirit of the GPL. It just needs one person. Also see this weeks newsletter from Cory Doctorov on the lawsuit against Vizio. It might soon only take one user. Best get licensing problems fixed sooner than later. GPLv2-only is a problem quickly getting closer. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
On Fri, Oct 22, 2021 at 02:17:33PM -0700, Vagrant Cascadian wrote: > * Disable substitutes for relevent packages. Technically correct as > license incompatibility is only triggered on transmission of binary, > though maybe missing something about the spirit of the GPL. Maybe, but did anyone with standing ever take action regarding these licensing incompatibilities? Perhaps, looking at these issues too closely is also missing something about the spirit of the GPL.
Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
Vagrant Cascadian schreef op vr 22-10-2021 om 14:15 [-0700]: > [...] > Though, it is *possible* that various u-boot-BOARD in some cases > doesn't > include any openssl code at all in the resulting binaries, but builds > some tools used during the build process, that are then used to > produce > various cryptographic signatures in the build: > > https://lists.denx.de/pipermail/u-boot/2021-October/464533.html > > If that's true, it should be ok for various boards (though the > possibility of openssl code getting linked in would be hard to > catch). Add openssl to #:disallowed-references. Then the build will fail if the store item has a reference to openssl. This most likely won't catch uses of the _static_ OpenSSL libraries though, so the "openssl:static" input would need to be removed for this approach to work. Greetings, Maxime. -- not hacking on guix for a while, only occassionally looking at IRC logs and bug reports. E-mails are unsigned until backup is located.
Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
On 2021-10-21, Vagrant Cascadian wrote: > For the last couple years guix has been applying simple workarounds in > u-boot packages to disable the features that required openssl due to > GPL/openssl license incompatibilities. > > I made an attempt at updating guix to u-boot 2021.10, which seems to > have made openssl harder to workaround... many of the u-boot-BOARD > packages now require it, and the previous workarounds to disable openssl > in u-boot-tools seem ineffective. > > I see a few ways forward: > > * Dig deeper into figuring out how to disable the workarounds... > > * Refactor the code that uses openssl to use an alternate > implementation. Upstream would welcome the fixes, at least in > theory. Most promising candidate might be wolfssl, last I looked, but > it may miss some features. > > * Convince upstream u-boot to relicense relevent GPLed portions of code > with an openssl exception. Upstream is dubious about this being > practical, largely due to the sheer number of potential contributors > who would have to agree to it. * Disable substitutes for relevent packages. Technically correct as license incompatibility is only triggered on transmission of binary, though maybe missing something about the spirit of the GPL. live well, vagrant signature.asc Description: PGP signature
Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
On 2021-10-22, Leo Famulari wrote: > On Thu, Oct 21, 2021 at 11:17:03PM -0700, Vagrant Cascadian wrote: >> While openssl 3.0 is licensed compatibly with GPLv3, u-boot has portions >> which are GPLv2-only, so that's not as attractive of a way forward as >> one might hope for... > > What are other distros doing? Surely we can't be the only group > distributing u-boot? Both fedora and (recently) debian have openssl declared as a system library, invoking the GPL's system library exception... which I personally find at best to be a grey area workaround. I wouldn't be surprised if most distros simply ignore the issue entirely. Interestingly, today I was called in on a relevent discussion on the u-boot mailing list: https://lists.denx.de/pipermail/u-boot/2021-October/464529.html Though, it is *possible* that various u-boot-BOARD in some cases doesn't include any openssl code at all in the resulting binaries, but builds some tools used during the build process, that are then used to produce various cryptographic signatures in the build: https://lists.denx.de/pipermail/u-boot/2021-October/464533.html If that's true, it should be ok for various boards (though the possibility of openssl code getting linked in would be hard to catch). u-boot-tools would still need a viable workaround, though. live well, vagrant signature.asc Description: PGP signature
Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
On Thu, Oct 21, 2021 at 11:17:03PM -0700, Vagrant Cascadian wrote: > While openssl 3.0 is licensed compatibly with GPLv3, u-boot has portions > which are GPLv2-only, so that's not as attractive of a way forward as > one might hope for... What are other distros doing? Surely we can't be the only group distributing u-boot?
Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others
On 2019-03-08, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> I'm not sure where it would be appropriate to add more comments >> regarding the GPL/Openssl incompatibilities; e.g. if someone were to >> propose adding one of the u-boot targets that requires it, they might >> just go ahead and re-add the openssl input... > > There’s always a risk. I guess we’ll have to be careful when doing > reviews. > > In addition, we can add a ‘lint’ checker for this case, WDYT? > >> From ee613387c49ca60905e0a40af8af017828c8aec8 Mon Sep 17 00:00:00 2001 >> From: Vagrant Cascadian >> Date: Thu, 7 Mar 2019 21:50:58 + >> Subject: [PATCH] gnu: u-boot: Remove openssl input. >> >> Fixes: https://bugs.gnu.org/34717 >> >> * gnu/packages/bootloaders (u-boot): Remove openssl from native-inputs. >> (u-boot-tools): Disable FIT_SIGNATURES in tests. > > Applied, thanks! For the last couple years guix has been applying simple workarounds in u-boot packages to disable the features that required openssl due to GPL/openssl license incompatibilities. I made an attempt at updating guix to u-boot 2021.10, which seems to have made openssl harder to workaround... many of the u-boot-BOARD packages now require it, and the previous workarounds to disable openssl in u-boot-tools seem ineffective. I see a few ways forward: * Dig deeper into figuring out how to disable the workarounds... * Refactor the code that uses openssl to use an alternate implementation. Upstream would welcome the fixes, at least in theory. Most promising candidate might be wolfssl, last I looked, but it may miss some features. * Convince upstream u-boot to relicense relevent GPLed portions of code with an openssl exception. Upstream is dubious about this being practical, largely due to the sheer number of potential contributors who would have to agree to it. * ??? While openssl 3.0 is licensed compatibly with GPLv3, u-boot has portions which are GPLv2-only, so that's not as attractive of a way forward as one might hope for... live well, vagrant signature.asc Description: PGP signature
