Skip to content

PyQt GPL "infecting" even when using PySide backend #11453

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kiwi0fruit opened this issue Jun 18, 2018 · 5 comments
Closed

PyQt GPL "infecting" even when using PySide backend #11453

kiwi0fruit opened this issue Jun 18, 2018 · 5 comments

Comments

@kiwi0fruit
Copy link

kiwi0fruit commented Jun 18, 2018

There happened a useful conversation on Reddit about publishing python apps that depend on PySide and MIT/BSD wrappers around PySide/PyQt like qtpy/pyqtgraph/matplotlib. Backup of the discussion.

According that conversation there are concerns that using qtpy/pyqtgraph/matplotlib in the propriate app even with PySide backend may lead to GPL violation. The problems came from two points:

  • even trying to import from PyQt may lead to the GPL "infecting",
  • even having PyQt as a dependency may lead to the GPL "infecting" (so that pip/conda installation would install pyqt automatically).

After all the discussion on Reddit the best way to solve the problem seems to do that upstream: make sure that there is a reliable switch in the qtpy/pyqtgraph/matplotlib modules that effectively and reliably turns the app that uses them (app as a whole) to something like:

if False:
    import PyQt

Maybe such switch is already there - but this needs checking. It's also would be great to unify that interface among modules.

And also remove PyQt from their dependencies so that they do not auto-download PyQt (I guess most of them already behave this way).

UPD

Quote about PyQt deps that are in some MIT/BSD modules:

If it's not a bug then it's a missing (or unused) feature.

I'm not as familiar with conda's own feature set, but given that these are pip installable packages, the upstream packages shouldn't declare PyQt (or PySide) as requires, but as extra_requires, and then downstream can decide to use install_requires to ensure that the they've got the GPL or LGPL GUI code of their choice. Really no package maintainer should ever include GPL code in requires without their own code being expressly GPL licensed, and that being their clear intent. If upstream packages are correctly using extra_requires and an automatic download is still being triggered then something has incorrectly set PyQt as an explicit or implicit requirement, and there's the bug.

Again though an automatic download onto the end user machine without use is something that very likely should be fixed upstream, but most likely could pass muster as an unintentional at best infringement with no meaningful impact. It's the use that implicates the GPL. The one exception is when the incidental and unused download is then bundled into a distributed artifact (like a wheel or frozen exe), because now you're distributing the GPL'd code with your own.

@kiwi0fruit
Copy link
Author

kiwi0fruit commented Jun 18, 2018

  • (checked) I guess qt_compat.py should be checked whether it tries to import pyqt when it has PySide QT_API env var or already imported PySide.
  • QT_API env var is the best choise for unifying the switch API.
  • As of now matplotlib depends on PyQt on conda (and maybe on pip also).

@anntzer
Copy link
Contributor

anntzer commented Jun 18, 2018

The QT_API environment variable achieves the desired effect (controlling what binding we attempt to import).
Matplotlib's PyPI package does not declare a dependency on any GUI toolkit. conda packaging issues should be raised, well, on the conda tracker.

@anntzer anntzer closed this as completed Jun 18, 2018
@kiwi0fruit
Copy link
Author

kiwi0fruit commented Jun 18, 2018 via email

@tacaswell
Copy link
Member

Further someone writing a proprietary application could bundle a patched version of matplotlib with their app that just imports from pyside.

I am disinclined to make any changes to how we do things or engage in speculative discussion without an actual lawyer involved.

@anntzer
Copy link
Contributor

anntzer commented Jun 18, 2018

(would be nice to get #9993 in, though)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants