Re: License GPL-2 conflicts with OpenSSLException

[Joshua Root]

On 2021-4-17 13:42 , Jason Liu wrote:
On Fri, Apr 16, 2021 at 9:21 PM Joshua Root > wrote:


OpenSSLException conflicts with everything except the OpenSSL license.


Wait, what? If OpenSSLException conflicts with everything except the 
OpenSSL license, doesn't that make it tautologically equivalent to the 
OpenSSL license itself? (i.e. the sentence is basically the same as 
saying "if and only if")


I thought the entire point of OpenSSLException was to specify that the 
authors have made the exception (in writing) that allows their 
GPL-licensed project to link against OpenSSL? Wouldn't that imply that 
OpenSSLException has to be compatible with something (i.e. the GPL) in 
addition to the OpenSSL license?


I meant it when I said it was an implementation detail. To specify in a 
Portfile that the license is "X with an OpenSSL exception", you write:


license {X OpenSSLException}

A sub-list in the licenses option means you have a choice of the 
licenses in that list. X by itself conflicts with the OpenSSL license, 
but you have the choice of OpenSSLException which doesn't (but also 
doesn't gain you compatibility with anything else.)


- Josh

Re: License GPL-2 conflicts with OpenSSLException

[Jason Liu]

On Fri, Apr 16, 2021 at 9:21 PM Joshua Root  wrote:

> OpenSSLException conflicts with everything except the OpenSSL license.
>

Wait, what? If OpenSSLException conflicts with everything except the
OpenSSL license, doesn't that make it tautologically equivalent to the
OpenSSL license itself? (i.e. the sentence is basically the same as saying
"if and only if")

I thought the entire point of OpenSSLException was to specify that the
authors have made the exception (in writing) that allows their GPL-licensed
project to link against OpenSSL? Wouldn't that imply that OpenSSLException
has to be compatible with something (i.e. the GPL) in addition to the
OpenSSL license?

-- 
Jason Liu


On Fri, Apr 16, 2021 at 9:21 PM Joshua Root  wrote:

> On 2021-4-17 11:16 , Ryan Schmidt wrote:
> >
> https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/55652/steps/gather-archives/logs/stdio
> >
> >> "hydrogen" is not distributable because its license "GPL-2" conflicts
> with license "OpenSSLException" of dependency "qt5-qtbase"
> >
> > Does this make sense or is there an error in the script? Why would GPL-2
> or anything conflict with OpenSSLException? It's just an exception. It
> lifts some restrictions imposed by the GPL. It shouldn't be imposing
> additional restrictions itself, should it?
>
> Implementation detail. OpenSSLException conflicts with everything except
> the OpenSSL license. If you see that, it means that all the other
> license options also conflicted (in this case, GPL-3 or LGPL-3).
>
> - Josh
>

Re: License GPL-2 conflicts with OpenSSLException

[Ryan Schmidt]

On Apr 16, 2021, at 21:30, Joshua Root wrote:

>> And is this really true that a GPL-2 program like Hydrogen is not 
>> distributable if it links with a GPL-3 / LGPL-3 library like Qt5?
> 
> Yep. That's why the FSF has always recommended licensing under version n or 
> later of the GPL rather than just version n.
> 
> 

Thanks. I think Hydrogen probably is GPL-2 or later since it says that in the 
source code headers but its README just says GPL-2. I'm asking for 
clarification from upstream.

Re: OpenSSL GPL conflict

[Ryan Schmidt]

On Apr 16, 2021, at 21:25, Fred Wright wrote:

>> I'm not aware of the Oracle / Google ruling.
> 
> They ruled in favor of Google, meaning that copying Oracle's Java header 
> files to use in conjunction with Google's Java implementation did not 
> constitute a violation of Oracle's copyright.  Essentially they said that 
> APIs aren't copyrightable.

I've now read about it.

The supreme court specifically did not rule whether or not APIs are 
copyrightable. They ruled that, if the Java API is copyrightable, then Google's 
use of it in the Android operating system was fair use.

I don't think this ruling has any bearing on the GPL / OpenSSL license issue.

Re: OpenSSL GPL conflict (was: Re: License GPL-2 conflicts with OpenSSLException)

[Joshua Root]

On 2021-4-17 12:25 , Fred Wright wrote:


Yes, I'm aware of that alleged explanation.  But the key point is that 
it relates to the *redistribution* of OpenSSL, and I contend that merely 
dynamically linking against a non-bundled OpenSSL library does not 
constitute "redistribution" of said library, and hence the alleged 
conflict is inapplicable.


It's the GPL that prevents distribution of the GPL-licensed software in 
this situation. There's no problem redistributing OpenSSL itself.


- Josh

Re: License GPL-2 conflicts with OpenSSLException

[Joshua Root]

On 2021-4-17 12:09 , Ryan Schmidt wrote:

Ok, right. So I would need to get info on qt5-qtbase in this case and see that 
it is licensed LGPL-3 or GPL-3 or OpenSSLException and realize that GPL-3 
conflicts with GPL-2. Is there a way that the message could be improved to 
mention the conflict with GPL-3 instead? Does the license checking script check 
the licenses in the order in which they are specified in the portfile, or if 
not, could it do so?


Yes, it checks the licenses in the order listed. Yes, the reporting 
could probably be improved.



And is this really true that a GPL-2 program like Hydrogen is not distributable 
if it links with a GPL-3 / LGPL-3 library like Qt5?


Yep. That's why the FSF has always recommended licensing under version n 
or later of the GPL rather than just version n.




- Josh

Re: OpenSSL GPL conflict (was: Re: License GPL-2 conflicts with OpenSSLException)

[Fred Wright]

On Fri, 16 Apr 2021, Ryan Schmidt wrote:

On Apr 16, 2021, at 20:33, Fred Wright wrote:


[...]
For that matter, IMO this whole business of the OpenSSL license 
conflicting with the GPL is a bunch of nonsense (at least in the 
typical MacPorts scenario).  Since when does *dynamically* linking 
against an *unbundled* shared library constitute "redistribution" of 
said library? And if anyone tries to claim that merely including the 
bits necessary to link against the library is "redistribution", the 
recent SCOTUS ruling in Oracle v. Google should put that to rest.


Since you're now asking a different question than what I was asking, 
let's retitle the thread.


I'm not aware of the Oracle / Google ruling.


They ruled in favor of Google, meaning that copying Oracle's Java header 
files to use in conjunction with Google's Java implementation did not 
constitute a violation of Oracle's copyright.  Essentially they said that 
APIs aren't copyrightable.


The reason why the OpenSSL license and GPL conflict, unless an exception 
is granted, when the OpenSSL is not part of the operating system, is 
explained here:


https://people.gnome.org/~markmc/openssl-and-the-gpl


Yes, I'm aware of that alleged explanation.  But the key point is that it 
relates to the *redistribution* of OpenSSL, and I contend that merely 
dynamically linking against a non-bundled OpenSSL library does not 
constitute "redistribution" of said library, and hence the alleged 
conflict is inapplicable.


Fred Wright

Re: License GPL-2 conflicts with OpenSSLException

[Ryan Schmidt]

On Apr 16, 2021, at 20:21, Joshua Root wrote:

> On 2021-4-17 11:16 , Ryan Schmidt wrote:
>> https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/55652/steps/gather-archives/logs/stdio
>>> "hydrogen" is not distributable because its license "GPL-2" conflicts with 
>>> license "OpenSSLException" of dependency "qt5-qtbase"
>> Does this make sense or is there an error in the script? Why would GPL-2 or 
>> anything conflict with OpenSSLException? It's just an exception. It lifts 
>> some restrictions imposed by the GPL. It shouldn't be imposing additional 
>> restrictions itself, should it?
> 
> Implementation detail. OpenSSLException conflicts with everything except the 
> OpenSSL license. If you see that, it means that all the other license options 
> also conflicted (in this case, GPL-3 or LGPL-3).

Ok, right. So I would need to get info on qt5-qtbase in this case and see that 
it is licensed LGPL-3 or GPL-3 or OpenSSLException and realize that GPL-3 
conflicts with GPL-2. Is there a way that the message could be improved to 
mention the conflict with GPL-3 instead? Does the license checking script check 
the licenses in the order in which they are specified in the portfile, or if 
not, could it do so?

And is this really true that a GPL-2 program like Hydrogen is not distributable 
if it links with a GPL-3 / LGPL-3 library like Qt5? The developers of Hydrogen 
must think that it is distributable, since they distribute binaries here:

https://sourceforge.net/projects/hydrogen/files/Hydrogen/1.0.0%20Binaries/

Re: OpenSSL GPL conflict (was: Re: License GPL-2 conflicts with OpenSSLException)

[Ryan Schmidt]

On Apr 16, 2021, at 20:33, Fred Wright wrote:

> On Fri, 16 Apr 2021, Ryan Schmidt wrote:
> 
>> https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/55652/steps/gather-archives/logs/stdio
>> 
>>> "hydrogen" is not distributable because its license "GPL-2" conflicts with 
>>> license "OpenSSLException" of dependency "qt5-qtbase"
>> 
>> Does this make sense or is there an error in the script? Why would GPL-2 or 
>> anything conflict with OpenSSLException? It's just an exception. It lifts 
>> some restrictions imposed by the GPL. It shouldn't be imposing additional 
>> restrictions itself, should it?
> 
> For that matter, IMO this whole business of the OpenSSL license conflicting 
> with the GPL is a bunch of nonsense (at least in the typical MacPorts 
> scenario).  Since when does *dynamically* linking against an *unbundled* 
> shared library constitute "redistribution" of said library? And if anyone 
> tries to claim that merely including the bits necessary to link against the 
> library is "redistribution", the recent SCOTUS ruling in Oracle v. Google 
> should put that to rest.

Since you're now asking a different question than what I was asking, let's 
retitle the thread.

I'm not aware of the Oracle / Google ruling.

The reason why the OpenSSL license and GPL conflict, unless an exception is 
granted, when the OpenSSL is not part of the operating system, is explained 
here:

https://people.gnome.org/~markmc/openssl-and-the-gpl

Re: License GPL-2 conflicts with OpenSSLException

[Fred Wright]

On Fri, 16 Apr 2021, Ryan Schmidt wrote:


https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/55652/steps/gather-archives/logs/stdio

"hydrogen" is not distributable because its license "GPL-2" conflicts 
with license "OpenSSLException" of dependency "qt5-qtbase"


Does this make sense or is there an error in the script? Why would GPL-2 
or anything conflict with OpenSSLException? It's just an exception. It 
lifts some restrictions imposed by the GPL. It shouldn't be imposing 
additional restrictions itself, should it?


For that matter, IMO this whole business of the OpenSSL license 
conflicting with the GPL is a bunch of nonsense (at least in the typical 
MacPorts scenario).  Since when does *dynamically* linking against an 
*unbundled* shared library constitute "redistribution" of said library? 
And if anyone tries to claim that merely including the bits necessary to 
link against the library is "redistribution", the recent SCOTUS ruling in 
Oracle v. Google should put that to rest.


Fred Wright

Re: License GPL-2 conflicts with OpenSSLException

[Joshua Root]

On 2021-4-17 11:16 , Ryan Schmidt wrote:

https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/55652/steps/gather-archives/logs/stdio


"hydrogen" is not distributable because its license "GPL-2" conflicts with license 
"OpenSSLException" of dependency "qt5-qtbase"


Does this make sense or is there an error in the script? Why would GPL-2 or 
anything conflict with OpenSSLException? It's just an exception. It lifts some 
restrictions imposed by the GPL. It shouldn't be imposing additional 
restrictions itself, should it?


Implementation detail. OpenSSLException conflicts with everything except 
the OpenSSL license. If you see that, it means that all the other 
license options also conflicted (in this case, GPL-3 or LGPL-3).


- Josh

License GPL-2 conflicts with OpenSSLException

[Ryan Schmidt]

https://build.macports.org/builders/ports-10.15_x86_64-builder/builds/55652/steps/gather-archives/logs/stdio

> "hydrogen" is not distributable because its license "GPL-2" conflicts with 
> license "OpenSSLException" of dependency "qt5-qtbase"

Does this make sense or is there an error in the script? Why would GPL-2 or 
anything conflict with OpenSSLException? It's just an exception. It lifts some 
restrictions imposed by the GPL. It shouldn't be imposing additional 
restrictions itself, should it?