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
It doesn't explain the details of *why* they're incompatibly, which is
astoundingly unhelpful. The best explanation I've found is here:
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
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: