Re: [PATCH 0/4] sunxi: TOC0 image type support

[Peter Robinson <pbrobinson@gmail.com>]

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