upgrade to openssl 3.0.0

Jason Liu jasonliu at umich.edu
Sat Oct 2 18:37:27 UTC 2021

That was also the Blender devs' claim, which I assume is why they decided
it wasn't necessary to include the GPL-OpenSSL exception text, since any
licensing conflicts would self-resolve once Blender starts using OpenSSL
3.0. But currently, their pre-built release binary downloads and compiles
OpenSSL 1.1.1g, which is still under the OpenSSL license, not Apache 2.0.

Jason Liu

On Sat, Oct 2, 2021 at 2:25 PM Joshua Root <jmr at macports.org> wrote:

> Blender is GPL-2+, which means it can be distributed when linked with
> OpenSSL 3.0, since GPL-3 is compatible with Apache-2.
> - Josh
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20211002/0e0c7a3f/attachment.htm>

More information about the macports-dev mailing list