Opened 4 years ago
Closed 3 years ago
#60559 closed enhancement (fixed)
py-pyqt5 binaries are not distributable
Reported by: | jwhowarth | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | reneeotten (Renee Otten), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), cooljeanius (Eric Gallager) | |
Port: | py-pyqt5 |
Description
When installing pymol, the py-pyqt5 binary packages always seem to be missing from the prebuilt binary packages. As it takes a significant amount of time to build any of the py-pyqt5 variants, if this could be solved, it would be nice.
Change History (16)
comment:1 Changed 4 years ago by mf2k (Frank Schima)
Keywords: | py-pyqt5 buildbot removed |
---|---|
Type: | request → enhancement |
comment:2 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
"py38-pyqt5" is not distributable because its license "gpl" conflicts with license "OpenSSL" of dependency "openssl"
comment:3 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Summary: | py-pyqt5 binaries never seem to be built on buildbots → py-pyqt5 binaries are not distributable |
---|
comment:4 follow-up: 7 Changed 4 years ago by reneeotten (Renee Otten)
Ryan: which tcl script again figures out if something is distributable? I see that for example the qt5
ports have an additional OpenSSLException
listed as their license, if that's the case the port would be distributable - correct?
I guess it's worthwhile to figure out if the same applies to PyQt5 as well - suggestions on how I would check that?
[edit]: the only mention of openssl
in the build log I can find is: DEBUG: qt5-qtbase is installed with the following variants: +openssl
, is that the cause of the issue here? If so, since qt5-qtbase
has the OpenSSLException
, would it be appropriate to add this here as well?
comment:5 Changed 4 years ago by reneeotten (Renee Otten)
Cc: | reneeotten added |
---|
comment:6 follow-up: 8 Changed 4 years ago by jwhowarth
Looking through the .so files generated for py37-pyqt5-5.14.2_0.darwin_19.x86_64.tbz2, I don't see any direct linkages on libssl.
comment:7 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to reneeotten:
Ryan: which tcl script again figures out if something is distributable?
https://github.com/macports/macports-infrastructure/blob/master/jobs/port_binary_distributable.tcl
I see that for example the
qt5
ports have an additionalOpenSSLException
listed as their license, if that's the case the port would be distributable - correct?
The qt5 ports are distributable because they specify the license OpenSSLException
. The py-pyqt5 subports aren't distributable because they don't specify the licenseOpenSSLException
.
I guess it's worthwhile to figure out if the same applies to PyQt5 as well - suggestions on how I would check that?
I don't know how to determine whether PyQt5 is using OpenSSL. I guess you'd have to look through its source code or ask its developer.
[edit]: the only mention of
openssl
in the build log I can find is:DEBUG: qt5-qtbase is installed with the following variants: +openssl
, is that the cause of the issue here?
The cause of the issue is that one of py-pyqt5's subports' dependencies declares that it is under the OpenSSL
license, and py-pyqt5's subports declare that they are under the GPL-3 which is incompatible (in terms of distributability) with the OpenSSL
license, and py-pyqt5's subports don't declare that they qualify for the OpenSSLException
.
If so, since
qt5-qtbase
has theOpenSSLException
, would it be appropriate to add this here as well?
I don't know whether it would be appropriate to add that to py-pyqt5. You might have to check its licensing terms or ask its developer.
comment:8 follow-up: 9 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to jwhowarth:
Looking through the .so files generated for py37-pyqt5-5.14.2_0.darwin_19.x86_64.tbz2, I don't see any direct linkages on libssl.
MacPorts does not check for linkages to libssl. All MacPorts checks for, to determine distributability, is the values of the license
fields of the port and all of its dependencies.
I don't know whether library linkage is the only condition that would impose nondistributability. IANAL.
comment:9 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to ryandesign:
All MacPorts checks for, to determine distributability, is the values of the
license
fields of the port and all of its dependencies.
The values of the installs_libs
fields also play a role.
comment:10 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
I'm frustrated by this license stuff too and don't understand it completely. Some of what I said may be inaccurate. I often have to ask Joshua for his advice. He understands it better since he wrote the script.
comment:11 Changed 4 years ago by reneeotten (Renee Otten)
Cc: | MarcusCalhoun-Lopez added |
---|
it's probably related to the files in PyQt5-5.14.2/sip/QtNetwork
where it uses the the headers (qssl.h
from the qt5-qtbase
port.
But since qt5-qtbase
says that it uses the OpenSSLException
because of "# for OpenSSLException, see source and header files in src/network/ssl of qtbase", I see no obvious reason why using these headers in PyQt5
would then not qualify for the OpenSSLException
. But I'm not a lawyer and don't claim to understand these things.... perhaps Marcus has some insights here as he has looked at this more closely for the qt5
ports?
Finally, the port isn't updated all that often so building from source every now and then isn't too bad, but I agree that it would be nice to resolve.
comment:12 Changed 4 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
I am afraid I am neither a lawyer nor an expert on licenses.
The license for the Qt 5 port has OpenSSLException
because of the following in the source file:
/**************************************************************************** ** ** In addition, as a special exception, the copyright holders listed above give ** permission to link the code of its release of Qt with the OpenSSL project's ** "OpenSSL" library (or modified versions of the "OpenSSL" library that use the ** same license as the original version), and distribute the linked executables. ** ** You must comply with the GNU General Public License version 2 in all ** respects for all of the code used other than the "OpenSSL" code. If you ** modify this file, you may extend this exception to your version of the file, ** but you are not obligated to do so. If you do not wish to do so, delete ** this exception statement from your version of this file. ** ****************************************************************************/
I can not find anything similar in the py-pyqt5 port.
Octave has license_noconflict openssl
since
- OpenSSL's libraries are never linked into Octave,
- OpenSSL's header files are never included, and
- the OpenSSL's part of Qt is never used.
According to this post, a binary is a derivative work if it "uses anything that even indirectly uses something
else that uses openssl."
The bundle QtNetwork.so
links against QtNetwork
.
QtNetwork
in turn links against libssl.1.1.dylib
.
From my limited understanding of licenses, this means that py-pyqt5 should not be distributable.
As has been suggested by others, contacting the authors might be the best bet.
Perhaps they would be willing to add an OpenSSL exception just as Qt has.
comment:13 Changed 3 years ago by reneeotten (Renee Otten)
this should be resolved once the openssl
is update to the 3.* branch
comment:14 Changed 3 years ago by cooljeanius (Eric Gallager)
Cc: | cooljeanius added |
---|
comment:15 Changed 3 years ago by reneeotten (Renee Otten)
forgot to close the ticket automatically, I've added an OpenSSLException
in this commit based on the response of Phil Thompson on the PyQt mailinglist.
comment:16 Changed 3 years ago by reneeotten (Renee Otten)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Note that a "request" ticket type is only for requesting a new port.