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
