Factors determining binary archivability

[Jason Liu]

>
> The automated check naturally errs on the side of caution. If you can
> show that there is in fact no use of openssl from this GPL'd code, it
> can be marked as non-conflicting.
>

I'm fairly certain that this is the case for Blender. In fact, in Blender's
CMake scripts, there are references to OpenSSL in terms of the flags that
Blender passes to various libraries when Blender compiles its dependencies,
but they are all used to turn off OpenSSL. (I patch Blender to use
MacPorts' pre-built libraries in my portfile.) For example, Blender tries
to compile ffmpeg using the flag "--disable-openssl", and it tries to
compile OpenImageIO using the flag "-DUSE_OPENSSL=OFF".

So how would I mark Blender as being non-conflicting?

P.S.: Sorry to everyone on the mailing list for being such a pest about
this one package. Blender takes a really long time to compile from source,
so if I'm able to resolve any external issues like licensing conflicts in
order to make Blender available as a binary archive, I think it's probably
worth the mail traffic.

-- 
Jason Liu


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

> On 2020-9-9 15:37 , Jason Liu wrote:
> > In this particular case, Blender's add-ons are truly "add-ons"... it's
> > actually fairly easy in the CMake scripts to exclude the add-ons from
> > being copied into Blender's final application bundle; and even if the
> > add-ons are excluded from the distribution, it doesn't affect Blender's
> > core functionality in any way. I have no idea how FSF would interpret
> > this scenario, but I just thought I'd throw it out there.
>
> They have another similarly unhelpful FAQ regarding when a plugin and
> the program that loads it are considered to be a single combined
> program: <https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins>
>
> > 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.
>
> We're not hung up on Blender in particular, it's an automated check. I
> don't think it's unreasonable to assume in general that licenses mean
> what they say. The GPL and the OpenSSL license are pretty well
> universally recognised as conflicting.
>
> The automated check naturally errs on the side of caution. If you can
> show that there is in fact no use of openssl from this GPL'd code, it
> can be marked as non-conflicting.
>
> - Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20200909/80d20d90/attachment.htm>