upgrade to openssl 3.0.0
jmr at macports.org
Sat Oct 2 18:24:58 UTC 2021
Blender is GPL-2+, which means it can be distributed when linked with
OpenSSL 3.0, since GPL-3 is compatible with Apache-2.
On 2021-10-3 05:09 , Jason Liu wrote:
> I hope the question that I'm about to ask doesn't induce
> "Inception"-style migraines, but since it directly relates to one of the
> ports I maintain, here goes. What if one of my ports indirectly uses
> openssl through one of its dependencies, and the licensing terms in the
> current version of my port only covers openssl 1.1.1, but not 3.0?
> To use a specific example, Blender uses openssl 1.1.1 indirectly, by way
> of using networking through python. I contacted the Blender devs about
> this, and even though they acknowledged that they were unknowingly using
> OpenSSL without including the OpenSSL license, the only thing they ended
> up doing was to add the OpenSSL license to their licenses directory.
> They refuse, even now, to add the chunk of text specifying the
> GPL-OpenSSL exception to their licenses. Somehow their legal team seems
> to think that's enough to allow them to distribute pre-compiled
> binaries, but the MacPorts automatic license checking is flagging my
> Blender port as being non-distributable. Since my port is a couple of
> versions behind the latest release of Blender (there are some new
> dependent libraries that I need to submit first), how should we specify
> in our Portfiles that one of the dependencies should continue using the
> old openssl11, without adding the old_openssl PortGroup, and thus a
> direct dependency on openssl? Does this mean that the dependencies which
> are directly dependent on openssl will need new variants, e.g. +openssl
> and +openssl11?
> Jason Liu
More information about the macports-dev