Factors determining binary archivability

Joshua Root jmr at macports.org
Wed Sep 9 02:59:43 UTC 2020


On 2020-9-9 12:29 , Jason Liu wrote:
> 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.

MacPorts can't detect this, which is why it assumes the worst case by
default when checking for license compatibility. But the fact that
blender doesn't use openssl directly doesn't mean it doesn't use it; you
have to check all the dependencies, recursively. Blender could call a
curl function which calls an openssl function, or blender could call an
llvm function which calls a libxar function which calls an openssl
function. There are a lot of paths it could take with this many
dependencies, so it's not trivial to check.

> 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?

Usually, yes.

> 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 <http://packages.macports.org> as
> a binary archive. What allows qt5-qtbase to achieve this seemingly
> miraculous feat?

It's not under the plain GPL; there is an additional exception that
allows linking with OpenSSL.
<https://doc.qt.io/qt-5.12/qtnetwork-index.html#licenses-and-attributions>

- Josh


More information about the macports-dev mailing list