Factors determining binary archivability

[Joshua Root]

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