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/