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