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

["Ludovic Courtès" <ludo@gnu.org>]

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