Dependency PyQt5 uses GPL3 license

[xoxota99]

PyQt5 uses a more restrictive license (GPLv3) that requires developers share any source code for derivative works, under the same license.

gui_tool uses the MIT license, which does not impose the open-source restriction.

These licenses seem incompatible, since they both require that derivative works use the same license (MIT and GPL3 simultaneously), and my concern is that development projects that rely on gui_tool may be unaware that they are required by transitive license to open-source their code.

Off the top of my head, gui_tool should either remove the dependency on PyQt5, or else move to a GPL3 license, but both of these seem either burdensome technically, or problematic legally.

Is this a real problem? Is there a real solution?

[pavel-kirienko]

Is this a real problem?

Unfortunately, it seems to be so. So far I see the following solutions:

• Relicense the tool under GPLv3.
• Ask Dronecode to purchase a commercial PyQt5 license for €450. @LorenzMeier is it even a viable option?
• Migrate away from PyQt5 to https://wiki.qt.io/Qt_for_Python (any volunteers out there?)

[xoxota99]

Would it be a possibility to migrate to some other UI framework (wxPython or something)?

[pavel-kirienko]

I don't think so. We must stay with Qt lest we end up redoing the entire application from scratch. Too many things are dependent on Qt, the plotting engine is one of the most critical ones.

[xoxota99]

Sorry, I didn't see your third bullet point above for some reason. Ignore me :-$

[thirtytwobits]

It looks like PySide also uses GPL v3.

[pavel-kirienko]

PySide 2 is LGPL according to their website.

[pavel-kirienko]

Let me reply to OpenCyphal/pycyphal#38 (comment) here:

Any chance we can switch to wxwidgets or some other more liberally licensed GUI toolkit?

Will there be much objection to a web-based GUI? Does anybody have experience with Kivy?

[scottdarch]

Kivy looks slick but what graphing widgets does it provide?

[pavel-kirienko]

So there are ugly widgets like Graph, Matplot lib integrations (which are definitely not good enough), and then there's Vispy which is OpenGL based and completely independent of Kivy.

[kjetilkjeka]

Disclaimers: IANAL

I think an acceptable solution would be to get permission from all 6 pyuavcan contributors to dual license their contributions under both MIT and Apache2. (This is required as an MIT dep cannot go into a GPLv3 project). This is actually the preferred licensing option in the Rust community, meaning there should be no unexpected problems doing so.

Then get permission from all 6 uavcan_gui_tool contributor to license their contribution under GPLv3. Using the pyuavcan apache 2 license this can be included as a dependency without any problems.

What I have seen been done in similar situation is that an issue is created under the relevant repos. In this issue, all relevant persons are listed and they are encouraged to comment with a pre-written statement consenting to license their contributions under this and that license.

As long as uavcan_gui_tool is mostly about gui code, and all reusable (non-gui) components live inside pyuavcan (or another seperate repo) this should not be a problem. If we want to create a new uavcan_gui_tool without the GPLv3 lisence we will have to write most of the gui code from scratch anyway.

Since the uavcan_gui_tool isn't used as a dependency but instead as a free standing tool i don't think it will be any problems at all having it under the GPLv3 lisence.

[pavel-kirienko]

This is required as an MIT dep cannot go into a GPLv3 project

Are you sure about that? The hivemind seems to disagree: https://opensource.stackexchange.com/questions/5477/release-code-with-mit-dependencies-under-gpl

Also if the following statement from the linked above page is true, we can add new licensing options without asking anybody:

the MIT license explicitly allows you to sublicense the code (i.e. republish with a completely different license), and only requires you to keep the copyright and license notice intact.

We can easily relicense the tool under GPL v3, but that'll make it impossible for some developers to contribute. Although, as is stands, they can't do it currently either, so we're not losing anything.

[kjetilkjeka]

Are you sure about that?
I'm absolutely not in any way sure about any of the licensing related stuff.

I do not understand how MIT can work with GPL as the MIT license give "the right without limitations to modify the software". Although if the hivemind thinks I'm wrong, I probably am.

Also if the following statement from the linked above page is true, we can add new licensing options without asking anybody:

I'm pretty sure this is impossible. Dual licensing means that you can obtain a copy either following the MIT license or Apache2 license. Sub-license means that you can append the new license requirements on top of the original one. Even if it was possible to do so, it would be much nicer just to ask :), and in my experience people mainly want their code to be usable and would say yes without hesitation.

We can easily relicense the tool under GPL v3, but that'll make it impossible for some developers to contribute. Although, as is stands, they can't do it currently either, so we're not losing anything.

How I see it, they would only be unable to contribute to the parts that are already closely tied together with the GPL licensed library. To break free of the GPL license we will have to rewrite these parts anyway (since they're somewhat closely tied to the library). If we license this tool under GPLv3 now it's probably not going to cause us much extra work rewriting with a new gui library later compared to doing it without licensing. It is going to allow us to use the tool as is. In my opinion we gain significantly more than we lose.

[Linjieqiang]

When are we going to start writing new GUI programs and I'm interested in that and I want to get involved in code development. @pavel-kirienko