[PATCH v4 1/4] tools: Separate image types which depend on OpenSSL

[Peter Robinson]

> > >> I also have been doing some packaging of u-boot for GNU Guix, where I
> > >> suspect the stance wouldn't be as willing to accept such a compromise...
> > >>
> > >> So... I would *love* an option to be able to build a board-only config
> > >> without any of the tools;
> > >
> > > Why is this a problem (see above)? Who is building board builds? It's
> > > either the maintainer when creating the binary package, or a curious user,
> > > right? And they can surely *use* OpenSSL during build time - if it's
> > > needed by the board.
> >
> > Sure, if there is no actual openssl code embedded in the resulting
> > binary with GPLv2 code, it shouldn't be a problem...
> >
> >
> > It's a mess of an issue to tease out exactly what codepaths trigger and
> > do not trigger the compatibility issues between openssl and GPL...
> >
> >
> > Depending on openssl in a project with GPLv2-only code does seem at risk
> > to introduce license compatibility issues without sufficient and
> > constant review and dilligence, even if it is technically ok how it is
> > done right now...
>
> There's still the long standing request to migrate the tooling to use a
> different library, but it's apparently not been a large enough concern
> of company with concerns to fund a developer of theirs to do the
> migration.  I feel like that might be one of the better, at least in
> terms of license, fixes for this issue.
>
> And then maybe we do just need a way to say if you're building for
> platform X then you must also have the crypto requirement resolved to
> build mkimage.  And conversely if you aren't building those platforms,
> it's OK to not.

Does the re-license [1] to Apache License 2.0 for openssl 3+ change
this situation at all?

For reference all the pieces of U-Boot that Fedora builds seem to
build fine with openssl 3.

[1] https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/