upgrade to openssl 3.0.0

[Ken Cunningham]

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.

Ken


> 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...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20211002/392d04cf/attachment.htm>