License violations

Bug #1795876 reported by Bastian Germann on 2018-10-03
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Status tracked in Trunk
Bastian Germann

Bug Description

OpenLP (GPLv2 only) is currently violating at least two licenses: PyQt5's GPLv3 only and request's Apache 2.0.
There are two options to heal these violations: relicense OpenLP or replace the dependencies. A third option would be aquiring a commercial PyQt5 license from Riverbank and replacing requests only, but as it is paid per developer this seems to be infeasible for an open source project.

Replacing requests would be feasible: urllib is already used throughout the codebase. Just use it for the currently three files which import requests as well.

I do not know if it would be feasible to replace PyQt5 with PySide2.

You would have to use the GPLv3 license to heal both of the violations (GPLv3 is compatible with Apache 2.0). You could also use GPLv2 or later, but the logical license combined with PyQt5 is always GPLv3. That leads to another issue: pysword is GPLv2 only and a license move would require you to drop this optional dependency. But I guess this would be a minor issue as it is not released yet (?).

I do not know if relicensing is feasible as you would have to ask the majority of copyright holders to agree with the license change.

In either case you should inform your users not later than with your next (fixed!) release about the license violation as they could be in trouble using OpenLP.

Related branches

Relicensing would give you the opportunity to use PyMuPDF instead of calling its executable via subprocess.

A problematic import is also the uno module. Depending on the OpenOffice/LibreOffice version this is a license violation as well. OpenOffice <= 2 should be okay. But nobody uses these old versions today.

OpenOffice 3 is LGPLv3 licensed and Apache OpenOffice is Apache v2 licensed, which are incompatible with GPLv2 only.

LibreOffice is MPL2 licensed but in the license statement it states that this file uses Apache v2 Code. MPL2 itself should be compatible with GPLv2 but Apache v2 is not. I do not know what this means exactly, but my suggestion is that the combination is also an Apache v2 violation.

Relicensing to GPLv3 would also heal this situation, so the relicensing seems to be the better option.

Raoul Snyman (raoul-snyman) wrote :

We weren't exactly aware of this, though we've briefly discussed moving to GPLv3. I'll take this up on the mailing list.

If the relicensing takes place you would also have to get rid of the LGPLv2 licensed pyxdg module. An alternative is at

I noticed another license violation.

openlp/core/ui/media/vendor/ is actually a modified version of pymediainfo. This file has OpenLP's license header since its introduction. The original is under MIT license.

This is not about just not knowing license compatibility details...

I corrected the file in lp:~bastian-germann/openlp/setup

I asked the maintainer of the pysword module to relicense so that OpenLP could keep the sword feature on relicensing:

A better replacement for pyxdg is appdirs. It is actively maintained and available as package on all supported Linux distros.

I replaced pyxdg with appdirs in lp:~bastian-germann/openlp/setup

Jonathan Corwin (j-corwin) wrote :

I permit any code of mine to be relicensed to GPLv3+

A note for completeness: There are at least two Apache 2.0 licensed transitive dependencies: python-editor, pbr. I only checked the transitive dependencies that are exposed as install_requires.

Changed in openlp:
status: New → In Progress

One more LGPLv3 violation spotted: launchpadlib in scripts/

The voting thread is found on the mailing list:

Tim Bentley (trb143) wrote :

Releases 2.0 2.2 and 2.4 our end of life and will not have any more work done on them so it will not be possible to change the license of them.

The appdirs replacement is merged and pysword relicensed under MIT now. This enables the relicensing without dropping any features. So technically the only change to relicense is adjusting the license headers and the license file.

@springermac is the only main developer that did not agree to a license change yet.

The others are @arjans, @crichter, @edwinlunando, @elderp, @m2j, @matthub, @meths, @milleja46, @rafaellerm, @samscudder, @sguerrieri, @thelinuxguy, @whydoubt, Stuart Becker, Gerald Britton, Samuel Findlay, Michael Gorven, Ian Knightly, Gabriel Loo, Dmitriy Marmyshev, Brian Meyer, Suutari Olli, Felipe Polo-Wood, Maikel Stuivenberg, Dave Warnock, Oliver Wieland, Frode Woldsund, and Martin Zibricky.

The pymediainfo license violation is gone in trunk now. How about changing the license headers now?
Is there anyone in the last comment's list who did a lot of things? I guess @springermac.

On 22/01/2019 14:21, Bastian Germann wrote:
> The pymediainfo license violation is gone in trunk now. How about changing the license headers now?
> Is there anyone in the last comment's list who did a lot of things? I guess @springermac.
Feel free to use whichever license best serves the project for any
contributions of mine that are still around.

Jon (@meths)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related blueprints