Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 2157 bytes --]

On 2019-03-08, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant@debian.org> 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 <vagrant@debian.org>
>> Date: Thu, 7 Mar 2019 21:50:58 +0000
>> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

[Leo Famulari]

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

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1337 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

[Maxime Devos]

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

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: bug#34717: GPL and Openssl incompatibilities in u-boot and possibly others

[Leo Famulari]

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

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]


Leo Famulari <leo@famulari.name> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]