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

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

[Vagrant Cascadian]

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

The u-boot package definition includes openssl amoung it's inputs, but
is also a GPL2+ software project... but the GPL and OpenSSL licenses are
incompatible:

  https://www.gnu.org/licenses/license-list.html#OpenSSL

It doesn't explain the details of *why* they're incompatibly, which is
astoundingly unhelpful. The best explanation I've found is here:

  https://people.gnome.org/~markmc/openssl-and-the-gpl.html

Essentially, the Openssl/SSLeay license(s) place additional restrictions
requiring "advertising" clause when distributing in binary form, while
the GPL forbids placing additional restrictions on distribution.


I'm not sure if there's a simple way to search for other packages with
license:gpl and openssl as an input in order to do a quick pass at
auditing... some packages may use the openssl binary as part of the
build process or tests, and not linking any GPLed code against it; in
those cases there would be no license conflict.


Since I believe the incompatibility is only invoked when distributing
binaries, GNU Guix may be in an interesting position to at least make a
simple workaround for affected packages by using:

  (arguments `(#:substitutable? #f))

Thus disabling substitutes. Though it poses a curious philosophical
question weather that is an acceptible/appropriate workaround for GNU
Guix...


In the Debian u-boot packaging, some of the features using openssl are
disabled, and some of the u-boot targets that require openssl are not
part of the packages. I'd be happy to help with making such adjustments
if this is deemed the better approach for u-boot specifically.


Other more long-term approaches:

Patch (and submit upstream) the affected packages to support using other
GPL compatible libraries, such as gnutls.

If upstream is reasonably able to add a license exception, that could
also resolve the issue:

  https://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs


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

[Ludovic Courtès]

Hi Vagrant,

Vagrant Cascadian <vagrant@debian.org> skribis:

> The u-boot package definition includes openssl amoung it's inputs, but
> is also a GPL2+ software project... but the GPL and OpenSSL licenses are
> incompatible:
>
>   https://www.gnu.org/licenses/license-list.html#OpenSSL

Thanks for bringing it up.

> I'm not sure if there's a simple way to search for other packages with
> license:gpl and openssl as an input in order to do a quick pass at
> auditing... some packages may use the openssl binary as part of the
> build process or tests, and not linking any GPLed code against it; in
> those cases there would be no license conflict.

openssl@1.0 has 7,029 dependent packages, so it may be hard to sort it
out.  I wonder what would be the best way to approach it.

> Since I believe the incompatibility is only invoked when distributing
> binaries, GNU Guix may be in an interesting position to at least make a
> simple workaround for affected packages by using:
>
>   (arguments `(#:substitutable? #f))
>
> Thus disabling substitutes. Though it poses a curious philosophical
> question weather that is an acceptible/appropriate workaround for GNU
> Guix...

Hmm yeah, that doesn’t sound right.  :-)

> In the Debian u-boot packaging, some of the features using openssl are
> disabled, and some of the u-boot targets that require openssl are not
> part of the packages. I'd be happy to help with making such adjustments
> if this is deemed the better approach for u-boot specifically.

That’d be great.  We could definitely remove the OpenSSL dependency when
it’s not needed.

In cases where it is needed, it would be nice to see what it’s used
for.  Many projects use OpenSSL just for its cryptographic hash
functions, for example, and there’s plenty of options to choose from if
that’s all that’s needed (Gcrypt, Nettle, etc.).

I guess this should be discussed with upstream.

Thanks,
Ludo’.

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

[Danny Milosavljevic]

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

Hi,

> openssl@1.0 has 7,029 dependent packages, so it may be hard to sort it
> out.  I wonder what would be the best way to approach it.

I can't believe I seriously suggest the following but:

A license algebra and guix commands that automate part of the lawyering,
by using the "license" field of the packages, which would now have at
least "and-license" and "or-license" operators and maybe also finer-grained
ones, and a placeholder for "it's too difficult, sort it out manually"
(maybe just detect the list we have now as "it's too difficult").

If we do it, we should add a disclaimer that it doesn't replace the need
for legal counsel entirely.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Ludovic Courtès]

Danny Milosavljevic <dannym@scratchpost.org> skribis:

> I can't believe I seriously suggest the following but:
>
> A license algebra [...]

Yeah, licensing is anything but an algebra, so let’s not take that path.
:-)

Ludo’.

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

[Vagrant Cascadian]

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

On 2019-03-06, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant@debian.org> skribis:
>
>> The u-boot package definition includes openssl amoung it's inputs, but
>> is also a GPL2+ software project... but the GPL and OpenSSL licenses are
>> incompatible:
>>
>>   https://www.gnu.org/licenses/license-list.html#OpenSSL
>
> Thanks for bringing it up.
>
>> I'm not sure if there's a simple way to search for other packages with
>> license:gpl and openssl as an input in order to do a quick pass at
>> auditing... some packages may use the openssl binary as part of the
>> build process or tests, and not linking any GPLed code against it; in
>> those cases there would be no license conflict.
>
> openssl@1.0 has 7,029 dependent packages, so it may be hard to sort it
> out.  I wonder what would be the best way to approach it.

How many of them are also license:gpl* though? That would hopefully
reduce the scope somewhat, or maybe even significantly...

If "guix package --search= ..." could be extended to to also search
other fields, e.g. license: and dependencies: ... it might not be so
difficult a search.


>> In the Debian u-boot packaging, some of the features using openssl are
>> disabled, and some of the u-boot targets that require openssl are not
>> part of the packages. I'd be happy to help with making such adjustments
>> if this is deemed the better approach for u-boot specifically.
>
> That’d be great.  We could definitely remove the OpenSSL dependency when
> it’s not needed.

For what it's worth, I did do local builds of all the current u-boot-*
targets in guix with openssl removed from inputs, and the only one that
failed to build without openssl was u-boot-tools.


> In cases where it is needed, it would be nice to see what it’s used
> for.  Many projects use OpenSSL just for its cryptographic hash
> functions, for example, and there’s plenty of options to choose from if
> that’s all that’s needed (Gcrypt, Nettle, etc.).

I think it is using it for generating and verifying rsa signatures, and
probably other similar basic things. So far I had only thought about
gnutls, but if gcrypt or nettle are other options, then so much the
better.

I briefly looked at gnutls's openssl compatibility layers, but it didn't
seem to implement sufficiently similar include files, which is largely
all that it is doing.


> I guess this should be discussed with upstream.

I did bring it upstream a little over a year ago, and the response was
pretty much to rewrite it with gnutls, and I pointed out the most likely
files that needed updating:

  https://lists.denx.de/pipermail/u-boot/2017-November/312483.html
  https://lists.denx.de/pipermail/u-boot/2017-December/313616.html
  https://lists.denx.de/pipermail/u-boot/2017-December/313742.html

I suspect it's pretty much a "patches accepted" sort of scenario.


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

[Vagrant Cascadian]

[-- Attachment #1.1: Type: text/plain, Size: 1590 bytes --]

On 2019-03-06, Vagrant Cascadian wrote:
> On 2019-03-06, Ludovic Courtès wrote:
>> Vagrant Cascadian <vagrant@debian.org> skribis:
>>> The u-boot package definition includes openssl amoung it's inputs, but
>>> is also a GPL2+ software project... but the GPL and OpenSSL licenses are
>>> incompatible:
>>>
>>>   https://www.gnu.org/licenses/license-list.html#OpenSSL
...
>>> In the Debian u-boot packaging, some of the features using openssl are
>>> disabled, and some of the u-boot targets that require openssl are not
>>> part of the packages. I'd be happy to help with making such adjustments
>>> if this is deemed the better approach for u-boot specifically.
>>
>> That’d be great.  We could definitely remove the OpenSSL dependency when
>> it’s not needed.
>
> For what it's worth, I did do local builds of all the current u-boot-*
> targets in guix with openssl removed from inputs, and the only one that
> failed to build without openssl was u-boot-tools.

I've tested that the attached patch builds all u-boot-* targets on
x86_64 (cross-building most of them), with openssl removed from
native-inputs.

Unfortunately, u-boot-tools fails it's tests on aarch64 and armhf, but
that appears to be the case with or without this patch, so it's no worse
off than it was...

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...


live well,
  vagrant


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-gnu-u-boot-Remove-openssl-input.patch --]
[-- Type: text/x-diff, Size: 2008 bytes --]

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.
---
 gnu/packages/bootloaders.scm | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/gnu/packages/bootloaders.scm b/gnu/packages/bootloaders.scm
index b0617f452a..15953ab75e 100644
--- a/gnu/packages/bootloaders.scm
+++ b/gnu/packages/bootloaders.scm
@@ -391,7 +391,6 @@ tree binary files.  These are board description files used by Linux and BSD.")
        ("dtc" ,dtc)
        ("flex" ,flex)
        ("lz4" ,lz4)
-       ("openssl" ,openssl)
        ("python-2" ,python-2)
        ("python2-coverage" ,python2-coverage)
        ("python2-pytest" ,python2-pytest)
@@ -440,9 +439,14 @@ also initializes the boards (RAM etc).")
               (("def test_ctrl_c")
                "@pytest.mark.skip(reason='Guix has problems with SIGINT')
 def test_ctrl_c"))
-             ;; This test requires a sound system, which is un-used in u-boot-tools.
              (for-each (lambda (file)
                               (substitute* file
+                                  ;; Disable signatures, due to GPL/Openssl
+                                  ;; license incompatibilities.  See
+                                  ;; https://bugs.gnu.org/34717 for details.
+                                  (("CONFIG_FIT_SIGNATURE=y") "CONFIG_FIT_SIGNATURE=n")
+                                  ;; This test requires a sound system, which is un-used
+                                  ;; in u-boot-tools.
                                   (("CONFIG_SOUND=y") "CONFIG_SOUND=n")))
                               (find-files "configs" "sandbox_.*defconfig$"))
              #t))
-- 
2.20.1


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

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

[Ludovic Courtès]

Hi,

Vagrant Cascadian <vagrant@debian.org> skribis:

> I've tested that the attached patch builds all u-boot-* targets on
> x86_64 (cross-building most of them), with openssl removed from
> native-inputs.
>
> Unfortunately, u-boot-tools fails it's tests on aarch64 and armhf, but
> that appears to be the case with or without this patch, so it's no worse
> off than it was...

This can be fixed separately then.

> 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!

Ludo’.

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

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 975 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.

Sure. I was thinking maybe putting a comment in the native-inputs where
"openssl" was removed, but wasn't sure what the conventions might be.


> In addition, we can add a ‘lint’ checker for this case, WDYT?

Does the lint checker have a way to identify a confidence level,
e.g. *maybe* it has this issue vs. *certainly*? Is there a way to
override the lint checker issues for known false positives? Otherwise,
it might just be annoying noise for packagers where it isn't
appropriate.


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

[Ludovic Courtès]

Vagrant Cascadian <vagrant@debian.org> skribis:

> 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.
>
> Sure. I was thinking maybe putting a comment in the native-inputs where
> "openssl" was removed, but wasn't sure what the conventions might be.

Yeah that would have worked I guess.

>> In addition, we can add a ‘lint’ checker for this case, WDYT?
>
> Does the lint checker have a way to identify a confidence level,
> e.g. *maybe* it has this issue vs. *certainly*? Is there a way to
> override the lint checker issues for known false positives? Otherwise,
> it might just be annoying noise for packagers where it isn't
> appropriate.

No it doesn’t have that notion of a confidence level.

The warning could be triggered only when a package is GPL’d and has a
direct dependency on OpenSSL (we’d forget about indirect dependencies in
this case.)  The noise would be rather limited and justified in this
case, I think.  WDYT?

Thanks,
Ludo’.

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

[Vagrant Cascadian]

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

On 2019-03-09, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant@debian.org> skribis:
>> On 2019-03-08, Ludovic Courtès wrote:
>>> Vagrant Cascadian <vagrant@debian.org> skribis:
>>> In addition, we can add a ‘lint’ checker for this case, WDYT?
>>
>> Does the lint checker have a way to identify a confidence level,
>> e.g. *maybe* it has this issue vs. *certainly*? Is there a way to
>> override the lint checker issues for known false positives? Otherwise,
>> it might just be annoying noise for packagers where it isn't
>> appropriate.
>
> No it doesn’t have that notion of a confidence level.

And I presume no overrides either, given no comment about that?


> The warning could be triggered only when a package is GPL’d and has a
> direct dependency on OpenSSL (we’d forget about indirect dependencies in
> this case.)  The noise would be rather limited and justified in this
> case, I think.  WDYT?

The openssl package currently ships the "openssl" binary, as well as the
libraries. I suspect there are at least three potential cases where a
package might depend on it:

* Calls the "openssl" binary as part of test suite or run-time. No
licensing compatibility issue, no worries!

* Using include files from the openssl headers; I guess you could search
for "include .* openssl/*.h" in the source code. Might get some false
positives. Can be run without actually even building it.

* Linking against the library which should actually be easy to detect
with ldd or other tools. Would need to build and then run the checks to
be sure.


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

[Jack Hill]

Hi,

Hopefully the OpenSSL re-licensing [0] will help with this problem in the 
long-term. At least for code that can be distributed under GPLv3, which 
may include u-boot [1].

Best,
Jack

[0] https://www.openssl.org/blog/blog/2018/03/01/last-license/
[1] https://www.denx.de/wiki/U-Boot/Licensing

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

[Ludovic Courtès]

Hi,

Vagrant Cascadian <vagrant@debian.org> skribis:

> On 2019-03-09, Ludovic Courtès wrote:
>> Vagrant Cascadian <vagrant@debian.org> skribis:
>>> On 2019-03-08, Ludovic Courtès wrote:
>>>> Vagrant Cascadian <vagrant@debian.org> skribis:
>>>> In addition, we can add a ‘lint’ checker for this case, WDYT?
>>>
>>> Does the lint checker have a way to identify a confidence level,
>>> e.g. *maybe* it has this issue vs. *certainly*? Is there a way to
>>> override the lint checker issues for known false positives? Otherwise,
>>> it might just be annoying noise for packagers where it isn't
>>> appropriate.
>>
>> No it doesn’t have that notion of a confidence level.
>
> And I presume no overrides either, given no comment about that?

We could arrange for this lint “checker” to honor some per-package
property that would silence it.  We do that with the ‘cve’ checker and
the ‘lint-hidden-cve’ property.

>> The warning could be triggered only when a package is GPL’d and has a
>> direct dependency on OpenSSL (we’d forget about indirect dependencies in
>> this case.)  The noise would be rather limited and justified in this
>> case, I think.  WDYT?
>
> The openssl package currently ships the "openssl" binary, as well as the
> libraries. I suspect there are at least three potential cases where a
> package might depend on it:
>
> * Calls the "openssl" binary as part of test suite or run-time. No
> licensing compatibility issue, no worries!
>
> * Using include files from the openssl headers; I guess you could search
> for "include .* openssl/*.h" in the source code. Might get some false
> positives. Can be run without actually even building it.
>
> * Linking against the library which should actually be easy to detect
> with ldd or other tools. Would need to build and then run the checks to
> be sure.

So for the 1st case we’d definitely need that property to tell ‘lint’
that everything is known-good.

‘guix lint’ does very inexpensive tests, so unpacking the tarball and
grepping it would be beyond its scope.  However, if we can provide the
warning and people have a way to silence it, I guess we’re fine?

Thanks,
Ludo’.

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 --]

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

[Ludovic Courtès]

Hi

Vagrant Cascadian <vagrant@debian.org> skribis:

> On 2019-03-06, Ludovic Courtès wrote:

[...]

>> openssl@1.0 has 7,029 dependent packages, so it may be hard to sort it
>> out.  I wonder what would be the best way to approach it.
>
> How many of them are also license:gpl* though? That would hopefully
> reduce the scope somewhat, or maybe even significantly...
>
> If "guix package --search= ..." could be extended to to also search
> other fields, e.g. license: and dependencies: ... it might not be so
> difficult a search.

Here’s an estimate:

--8<---------------cut here---------------start------------->8---
$ guix package -s "" |recsel -e 'license ~ "GPL"' -e 'dependencies ~ "openssl"' |grep ^name| wc -l
265
--8<---------------cut here---------------end--------------->8---

You can view the list of packages like this:

--8<---------------cut here---------------start------------->8---
guix package -s "" |recsel -e 'license ~ "GPL"' -e 'dependencies ~ "openssl"' -p name,version
--8<---------------cut here---------------end--------------->8---

>>> In the Debian u-boot packaging, some of the features using openssl are
>>> disabled, and some of the u-boot targets that require openssl are not
>>> part of the packages. I'd be happy to help with making such adjustments
>>> if this is deemed the better approach for u-boot specifically.
>>
>> That’d be great.  We could definitely remove the OpenSSL dependency when
>> it’s not needed.
>
> For what it's worth, I did do local builds of all the current u-boot-*
> targets in guix with openssl removed from inputs, and the only one that
> failed to build without openssl was u-boot-tools.

Not that bad!

>> In cases where it is needed, it would be nice to see what it’s used
>> for.  Many projects use OpenSSL just for its cryptographic hash
>> functions, for example, and there’s plenty of options to choose from if
>> that’s all that’s needed (Gcrypt, Nettle, etc.).
>
> I think it is using it for generating and verifying rsa signatures, and
> probably other similar basic things. So far I had only thought about
> gnutls, but if gcrypt or nettle are other options, then so much the
> better.
>
> I briefly looked at gnutls's openssl compatibility layers, but it didn't
> seem to implement sufficiently similar include files, which is largely
> all that it is doing.

Yeah, GnuTLS’ OpenSSL compat layer has been bitrotting since forever.

But really rather than GnuTLS they should target one of these crypto
libraries, which seem to be a better fit.

>> I guess this should be discussed with upstream.
>
> I did bring it upstream a little over a year ago, and the response was
> pretty much to rewrite it with gnutls, and I pointed out the most likely
> files that needed updating:
>
>   https://lists.denx.de/pipermail/u-boot/2017-November/312483.html
>   https://lists.denx.de/pipermail/u-boot/2017-December/313616.html
>   https://lists.denx.de/pipermail/u-boot/2017-December/313742.html
>
> I suspect it's pretty much a "patches accepted" sort of scenario.

I guess “we” should consider doing it at some point.  Changing the RSA
signature code to use another API can’t be that hard™.  ;-)

I see from the message above that PEM encoding/decoding may also be
needed, which Gcrypt doesn’t provide.

Thanks,
Ludo’.

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

[Ludovic Courtès]

Ludovic Courtès <ludo@gnu.org> skribis:

> Here’s an estimate:

Oops, I was doing an “or” instead of an “and”; here’s the fix:

--8<---------------cut here---------------start------------->8---
$ guix package -s "" |recsel -e 'license ~ "GPL" && dependencies ~ "openssl"' |grep ^name | wc -l
154
--8<---------------cut here---------------end--------------->8---

Still a lot, and that doesn’t take into account indirect GPL dependents.

Ludo’.

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

[Adonay Felipe Nogueira]

[-- Attachment #1.1: Type: text/plain, Size: 4762 bytes --]

Hi there! :D

Em 07/03/2019 01:17, Vagrant Cascadian escreveu:
> How many of them are also license:gpl* though? That would hopefully

My Guix pull is from commit d22d246a256814784dfb03437949bdc2efd746a5.

I made a little recsel trick to get all packages licensed under [A]GPL
(any version) and which are dependent on any package licensed under
OpenSSL. However, this doesn't check if the [A]GPL'd packages use the
OpenSSL'd dependencies' library or the object code/executable. That
said, there might be plenty of false entries here.

------------------------------------------------------------------------
$ guix package -s '' | recsel -CR "name,version" -e 'license ~
"([[:space:]]|^)[A]?GPL" && dependencies ~ "([[:space:]]|^)('$(guix
package -s '' | recsel -CR 'name,version' -e 'license ~ "OpenSSL"' | tr
'\n' '|' | sed 's/[[:space:]]/@/g; s/\(\.\)/\\\1/g;
s/|\($\)/\1/g')')([[:space:]]|$)"' | sed 's/ /@/g' | tr '\n' ' '
------------------------------------------------------------------------

This gives the following list:

------------------------------------------------------------------------
neon@0.30.2 fetchmail@6.3.26 git-crypt@0.5.0 socat@1.7.3.2 scribus@1.5.4
389-ds-base@1.4.0.13 bigloo@4.3e1 kdelibs4support@5.55.0 munge@0.5.13
gnunet@0.10.1 mupdf@1.14.0 slurm@17.11.3 sssd@1.16.2 wesnoth@1.14.6
yapet@1.1 keepalived@2.0.5 perl-net-ssleay@1.85 r-ggally@1.4.0
john-the-ripper-jumbo@1.8.0-1 psyclpc@20160821-2.61cf9aa hexchat@2.14.2
glusterfs@3.10.12 openvpn@2.4.7 libesmtp@1.0.6 httping@2.5
clamav@0.101.1 python2-mysqlclient@1.3.13 python-mysqlclient@1.3.13
openrct2@0.2.1 calibre@3.35.0 encfs@1.9.5 mosh@1.3.2 qbittorrent@4.1.5
mongodb@3.4.10 wimlib@1.13.0 libsignal-protocol-c@2.3.2 kicad@5.0.0
stunnel@5.48 ceph@13.2.2 looking-glass-client@a12-182c475
warzone2100@3.2.3 linuxdcpp@1.1.0 openvswitch@2.10.1 transmission@2.94
gvpe@3.1 ppp@2.4.7 libgit2@0.27.7 u-boot-novena@2019.01 uwsgi@2.0.18
icecast@2.4.4 rdesktop@1.8.4 gandi.cli@1.3 thc-ipv6@3.4-0.4bb7257
linux-libre-arm-omap2plus@4.20.13 linux-libre-arm-omap2plus@4.19.26
linux-libre-arm-omap2plus@4.14.104 linux-libre-arm-generic@4.20.13
linux-libre-arm-generic@4.19.26 linux-libre-arm-generic@4.14.104
cadaver@0.23.3 rtorrent@0.9.6 libmesode@0.9.2 restbed@4.6-1.6eb385f
virtuoso-ose@7.2.5 libtorrent@0.13.6 libstrophe@0.9.2
jupyter-guile-kernel@0.0.0-1.a7db924 clementine@1.3.1-2.4619a4c
linux-libre@4.9.161 linux-libre@4.4.176 linux-libre@4.20.13
linux-libre@4.19.26 linux-libre@4.14.104 synergy@1.10.1 moc@2.5.2
netsurf@3.8 git-minimal@2.21.0 kodi@18.1 mysql@5.7.23 strongswan@5.6.3
perl-crypt-openssl-rsa@0.31 perl-crypt-openssl-random@0.13 libcmis@0.5.2
git@2.21.0 hydra@20151030.1ff48da perl-crypt-openssl-bignum@0.09
links@2.18 neomutt@20180716 u-boot-tools@2019.01 burp@2.3.0
u-boot-nintendo-nes-classic-edition@2019.01 cgit@1.2.1 dillo@3.0.5
isync@1.3.0 testdisk@7.0 r-git2r@0.24.0 khtml@5.55.0 tinc@1.0.35
4store@1.1.6 u-boot-a20-olinuxino-micro@2019.01
u-boot-a20-olinuxino-lime2@2019.01 efitools@1.9.2
u-boot-a20-olinuxino-lime@2019.01 u-boot-bananapi-m2-ultra@2019.01
u-boot-am335x-boneblack@2019.01 u-boot-vexpress-ca9x4@2019.01
profanity@0.5.1 virt-viewer@7.0 irssi@1.1.2 wesnoth-server@1.14.6
u-boot-puma-rk3399@2019.01 u-boot-pine64-plus@2019.01 mariadb@10.1.37
u-boot-cubietruck@2019.01 u-boot-cubieboard@2019.01
u-boot-wandboard@2019.01 u-boot-mx6cuboxi@2019.01
u-boot-pinebook@2019.01 u-boot-malta@2019.01 xen@4.11.1 faust@2.5.23
mutt@1.11.3 sbsigntools@0.9.2
------------------------------------------------------------------------


-- 
- Página com formas de contato:
  https://libreplanet.org/wiki/User:Adfeno#vCard
- Ativista do software livre (não confundir com o gratuito). Avaliador
  da liberdade de software e de sites.
- Página com lista de contribuições:
  https://libreplanet.org/wiki/User:Adfeno#Contribs
- Para uso em escritórios e trabalhos, favor enviar arquivos do padrão
  internacional OpenDocument/ODF 1.2 (ISO/IEC 26300-1:2015 e
  correlatos). São os .odt/.ods/.odp/odg. O LibreOffice é a suíte de
  escritório recomendada para editar tais arquivos.
- Para outros formatos de arquivos, veja:
  https://libreplanet.org/wiki/User:Adfeno#Arquivos
- Gosta do meu trabalho? Contrate-me ou doe algo para mim!
  https://libreplanet.org/wiki/User:Adfeno#Suporte
- Use comunicações sociais federadas padronizadas, onde o "social"
  permanece independente do fornecedor. #DeleteWhatsApp. Use #XMPP
  (https://libreplanet.org/wiki/XMPP.pt), #DeleteFacebook
  #DeleteInstagram #DeleteTwitter #DeleteYouTube. Use #ActivityPub via
  #Mastodon (https://joinmastodon.org/).
- #DeleteNetflix #CancelNetflix. Evite #DRM:
  https://www.defectivebydesign.org/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 213 bytes --]