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