I'd like to see one of the parties that had noted the licensing problem chime in and explain it again.
The short of it is the openssl license has an advertising clause, and the GPL requires no additional terms may be added when distributing binaries. This is *fine* when distributing source code only, but once a project such as Debian or some commercial entitry distributes binaries of u-boot, the license incompatibility is triggered...
With OpenSSL 3, which is due shortly, the project will be moving to the Apache 2 license.
A more detailed explanation of the issue:
https://people.gnome.org/~markmc/openssl-and-the-gpl.html
That said, Debian has recently and somewhat quietly decided to declare openssl as a "system library" which in some opinions works around the issue. I believe Fedora has used this workaround for quite a while too. I personally think this is a very weak workaround and have only reluctantly added openssl support in parts of Debian's u-boot packages, and sometimes wonder if I shouldn't revert those changes...
Fedora has always had OpenSSL as a system library but there's been certain things that can't link against it because of incompatible licenses.
If someone has the ability, time, resources, etc. to (optionally?) switch u-boot to using a library that doesn't have any potential license compatibility issues, that would be ideal, so ideal! But of course, it requires *someone* to do the *work*. I don't believe *I* have the requisite skills.
It might be too soon to requiring something as new as openssl 3 but it may also end up being the quickest way as openssl3 is parallel installable with older versions.
Another route would be to audit all the current codepaths using openssl and get permission from all involved copyright holders to add a license exception expressly permitting linking against openssl. In the past, this was seen as something between impossible or implausible, due to the sheer number of potential copyright holders which would need to give permission to effectively relicense their GPL contributions with this exception. Maybe the actual affected code paths would limit the number of people involved enough to make it worth it... maybe not. Again, a fair amount of work that *someone* would need to do just to even audit the feasibility of this approach.
It is somewhat interesting to explore not adding *new* code to u-boot that uses openssl by using a different library, and then the old code might be able to be gradually migrated over to a different library? Last I did a cursory look, nettle, gnutls and gcrypt seemed the most promising candidates. I believe libressl has the same licensing issues as openssl.
live well, vagrant