<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>The automated check naturally errs on the side of caution. If you can<br>
show that there is in fact no use of openssl from this GPL'd code, it<br>
can be marked as non-conflicting.<br>
</div></blockquote><div><br></div><div>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".</div><div><br></div><div>So how would I mark Blender as being non-conflicting?</div><div><br></div><div>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.<br></div><div><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>-- </div><div>Jason Liu<br></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 9, 2020 at 2:49 AM Joshua Root <<a href="mailto:jmr@macports.org">jmr@macports.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-9-9 15:37 , Jason Liu wrote:<br>
> In this particular case, Blender's add-ons are truly "add-ons"... it's<br>
> actually fairly easy in the CMake scripts to exclude the add-ons from<br>
> being copied into Blender's final application bundle; and even if the<br>
> add-ons are excluded from the distribution, it doesn't affect Blender's<br>
> core functionality in any way. I have no idea how FSF would interpret<br>
> this scenario, but I just thought I'd throw it out there.<br>
<br>
They have another similarly unhelpful FAQ regarding when a plugin and<br>
the program that loads it are considered to be a single combined<br>
program: <<a href="https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins" rel="noreferrer" target="_blank">https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins</a>><br>
<br>
> By the way, Blender Foundation itself, as well as most Linux distros,<br>
> don't seem to have an issue distributing Blender (or other software<br>
> apps, for that matter) as a pre-compiled binary package. Why does the<br>
> MacPorts project seem to be so hung up on this licensing conflict? No<br>
> one else seems to care. (I hope I don't insult anyone by asking that.<br>
> I'm genuinely curious.)<br>
<br>
You'd have to ask those other people for their reasoning. Maybe the<br>
Blender Foundation's packages don't include or require openssl. Or maybe<br>
they and distros think the system library exception applies.<br>
<br>
We're not hung up on Blender in particular, it's an automated check. I<br>
don't think it's unreasonable to assume in general that licenses mean<br>
what they say. The GPL and the OpenSSL license are pretty well<br>
universally recognised as conflicting.<br>
<br>
The automated check naturally errs on the side of caution. If you can<br>
show that there is in fact no use of openssl from this GPL'd code, it<br>
can be marked as non-conflicting.<br>
<br>
- Josh<br>
</blockquote></div>