Factors determining binary archivability

[Jason Liu]

Yes, I'm aware. I specifically use the "-DWITH_PYTHON_INSTALL=OFF" flag in
my portfile, because with that option set to ON, Blender will copy the
entire system python distribution into its application bundle, including
the ssl and hashlib python modules, which as you said would be problematic,
since doing so automatically causes Blender's CMake files to set python to
use "--with-openssl=${LIBDIR}/ssl". In addition, this scenario will also
cause Blender to build the ssl and hashlib python modules by actually
downloading OpenSSL and compiling it from source as an internal dependency.
This would likely run afoul of the licensing conflict, since that
essentially integrates OpenSSL directly into the application bundle.

-- 
Jason Liu


On Wed, Sep 9, 2020 at 11:35 AM Joshua Root <jmr at macports.org> wrote:

> On 2020-9-9 16:49 , Joshua Root wrote:
> > On 2020-9-9 15:37 , Jason Liu wrote:
> >> By the way, Blender Foundation itself, as well as most Linux distros,
> >> don't seem to have an issue distributing Blender (or other software
> >> apps, for that matter) as a pre-compiled binary package. Why does the
> >> MacPorts project seem to be so hung up on this licensing conflict? No
> >> one else seems to care. (I hope I don't insult anyone by asking that.
> >> I'm genuinely curious.)
> >
> > You'd have to ask those other people for their reasoning. Maybe the
> > Blender Foundation's packages don't include or require openssl. Or maybe
> > they and distros think the system library exception applies.
>
> I had a look at the blender.org binary and it appears to be shipping a
> full python installation with the _hashlib and _ssl modules statically
> linked with openssl. Using those from the included GPL'd python scripts
> seems at least potentially problematic to me. But then I'm not an
> expert, so it would probably be best to get an opinion from
> <licensing at fsf.org> as well as the Blender Foundation's take.
>
> The main executable only links with system frameworks plus libomp,
> libiconv, libz and libbz2, so if the port is the same, that part of it
> is fine.
>
> - Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200909/3d4269dc/attachment-0001.htm>