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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> 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
