> > >> 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/