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 <j...@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 >