<div dir="ltr"><div>I dug through Blender's source code, and AFAICT, Blender doesn't directly use any part of OpenSSL. There are no references to any of OpenSSL's header files, nor any references to libcrypto, libssl, etc. Blender also doesn't directly do anything involving HTTPS or hashes. All of Blender's add-ons are python scripts, but aren't actually a part of Blender's compiled binaries. There are quite a few add-ons which use the ssl or hashlib modules, but I'm not even sure how MacPorts would be able to detect that those python scripts use the ssl or hashlib modules, since they aren't being run during the build process.<br></div><div><br></div><div>However, the log for the "gather-archives" step does also show that some of Blender's dependencies are apparently also subject to the GPL/OpenSSL licensing conflict:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>"ffmpeg" is not distributable because its license "gpl" conflicts with license "OpenSSL" of dependency "openssl"</div></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>"jack" is not distributable because its license "gpl" conflicts with license "OpenSSL" of dependency "openssl"</div></blockquote><div><br></div><div>Does this mean that any port that depends on a port which has the license conflict will also be considered to have the license conflict? Because I also noticed this in Blender's dependency tree:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>"qt5-qtbase" is distributable<br>Already uploaded public archive: qt5-qtbase-5.14.2_1+openssl.darwin_18.x86_64.tbz2</div></blockquote><div><br></div><div>and yet 'qt5-qtbase +openssl', which is directly dependent on OpenSSL, is available on <a href="http://packages.macports.org">packages.macports.org</a> as a binary archive. What allows qt5-qtbase to achieve this seemingly miraculous feat?<br></div><div><br></div><div><div><div dir="ltr" data-smartmail="gmail_signature"><div dir="ltr"><div>-- </div><div>Jason Liu<br></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 8, 2020 at 8:34 PM Joshua Root <<a href="mailto:jmr@macports.org" target="_blank">jmr@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-9-9 05:08 , Jason Liu wrote:<br>
> At this point, it looks like the vast majority of builds for Blender<br>
> have either succeeded or failed, according to the status at<br>
> <a href="https://ports.macports.org/port/blender/builds" rel="noreferrer" target="_blank">https://ports.macports.org/port/blender/builds</a>. Digging through the logs<br>
> of the builders, I encountered this message in the "gather-archives" step:<br>
> <br>
>     "blender" is not distributable because its license "gpl" conflicts<br>
>     with license "OpenSSL" of dependency "openssl"<br>
> <br>
> <br>
> Does this mean that the Blender port is yet another victim of The Curse<br>
> of the OpenSSL License?<br>
<br>
Yes (though you could equally call it the Curse of the GPL, as both are<br>
responsible).<br>
<br>
> Is there any way around this?<br>
We do have Portfile options to manually indicate license compatibility,<br>
so you could look in to whether Blender really uses OpenSSL, but I<br>
suspect it's very likely that Blender does something involving HTTPS or<br>
hashes at some point, which would most likely involve OpenSSL. If a<br>
process containing GPL'd code can end up executing OpenSSL code, then<br>
the conflict is real. That includes any python scripts that use the ssl<br>
or hashlib modules.<br>
<br>
- Josh<br>
</blockquote></div>