<div dir="ltr">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.<div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- </div><div>Jason Liu</div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 2, 2021 at 2:25 PM Joshua Root <<a href="mailto:jmr@macports.org">jmr@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Blender is GPL-2+, which means it can be distributed when linked with <br>
OpenSSL 3.0, since GPL-3 is compatible with Apache-2.<br>
<br>
- Josh<br>
<br>
On 2021-10-3 05:09 , Jason Liu wrote:<br>
> I hope the question that I'm about to ask doesn't induce <br>
> "Inception"-style migraines, but since it directly relates to one of the <br>
> ports I maintain, here goes. What if one of my ports indirectly uses <br>
> openssl through one of its dependencies, and the licensing terms in the <br>
> current version of my port only covers openssl 1.1.1, but not 3.0?<br>
> <br>
> To use a specific example, Blender uses openssl 1.1.1 indirectly, by way <br>
> of using networking through python. I contacted the Blender devs about <br>
> this, and even though they acknowledged that they were unknowingly using <br>
> OpenSSL without including the OpenSSL license, the only thing they ended <br>
> up doing was to add the OpenSSL license to their licenses directory. <br>
> They refuse, even now, to add the chunk of text specifying the <br>
> GPL-OpenSSL exception to their licenses. Somehow their legal team seems <br>
> to think that's enough to allow them to distribute pre-compiled <br>
> binaries, but the MacPorts automatic license checking is flagging my <br>
> Blender port as being non-distributable. Since my port is a couple of <br>
> versions behind the latest release of Blender (there are some new <br>
> dependent libraries that I need to submit first), how should we specify <br>
> in our Portfiles that one of the dependencies should continue using the <br>
> old openssl11, without adding the old_openssl PortGroup, and thus a <br>
> direct dependency on openssl? Does this mean that the dependencies which <br>
> are directly dependent on openssl will need new variants, e.g. +openssl <br>
> and +openssl11?<br>
> <br>
> -- <br>
> Jason Liu<br>
</blockquote></div>