Factors determining binary archivability

[Jason Liu]

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.

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:

"ffmpeg" is not distributable because its license "gpl" conflicts with
> license "OpenSSL" of dependency "openssl"
>

"jack" is not distributable because its license "gpl" conflicts with
> license "OpenSSL" of dependency "openssl"
>

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:

"qt5-qtbase" is distributable
> Already uploaded public archive:
> qt5-qtbase-5.14.2_1+openssl.darwin_18.x86_64.tbz2
>

and yet 'qt5-qtbase +openssl', which is directly dependent on OpenSSL, is
available on packages.macports.org as a binary archive. What allows
qt5-qtbase to achieve this seemingly miraculous feat?

-- 
Jason Liu


On Tue, Sep 8, 2020 at 8:34 PM Joshua Root <jmr at macports.org> wrote:

> On 2020-9-9 05:08 , Jason Liu wrote:
> > At this point, it looks like the vast majority of builds for Blender
> > have either succeeded or failed, according to the status at
> > https://ports.macports.org/port/blender/builds. Digging through the logs
> > of the builders, I encountered this message in the "gather-archives"
> step:
> >
> >     "blender" is not distributable because its license "gpl" conflicts
> >     with license "OpenSSL" of dependency "openssl"
> >
> >
> > Does this mean that the Blender port is yet another victim of The Curse
> > of the OpenSSL License?
>
> Yes (though you could equally call it the Curse of the GPL, as both are
> responsible).
>
> > Is there any way around this?
> We do have Portfile options to manually indicate license compatibility,
> so you could look in to whether Blender really uses OpenSSL, but I
> suspect it's very likely that Blender does something involving HTTPS or
> hashes at some point, which would most likely involve OpenSSL. If a
> process containing GPL'd code can end up executing OpenSSL code, then
> the conflict is real. That includes any python scripts that use the ssl
> or hashlib modules.
>
> - Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200908/933cb881/attachment.htm>