upgrade to openssl 3.0.0
ken.cunningham.webuse at gmail.com
Sat Oct 2 18:42:51 UTC 2021
All the pythons build against openssl 3.0.0, so that python issue with all it's trail-down conflicts will disappear with the upgrade and python revbump.
A very very large % of ports do as well (and those that don't now soon will, as everyone moves to openssl 3.0.0 as the default, which homebrew did pretty much the second openssl 3 came out).
So I am hoping that this upgrade is the beginning of the end of this particular PITA for all of us.
> On Oct 2, 2021, at 11:37 AM, Jason Liu <jasonliu at umich.edu> wrote:
> 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 <mailto: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...
More information about the macports-dev