upgrade to openssl 3.0.0

[Joshua Root]

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