Using PySide for a proprietary product? (LGPL backward-engineering clause)

Coding
,
#1

Given that Qt and PySide UIs are so ubiquitous for tools, I’m hoping someone can shed some light on the legal consequences of making PySide UI for a proprietary product. The hours I spent googling weren’t very fruitful so far.

The issue is:
Same as their respective Qt version, PySide is licensed as LGPLv2.1, and PySide2 as LGPLv3. Other legal stuff aside, when using an LGPL library in your code, you have to provide a mechanism that would allow the user to replace said library with a different one (in the case of LGPLv3 the result also has to be runable, aka. anti-tivoization clause). Likely to this end, the license also states that you explicitly allow backward-engineering of your code, even though you can keep most parts of your code closed-source.

Now: if I develop a C++ plugin, and a companion python script that exposes the functionality of said plugin to GUI by using PySide/PySide2; would that allow backward-engineering of the C++ plugin itself (since it’s part of the same “project”)? Or would it only allow backward-engineering of the GUI-implementing script?

Of course, for conclusive advice I’d have to pay a lawyer, but I’m wondering if anyone has encountered this or similar LGPL issues before, and how did it play out for you? Any input is very much appreciated.

#2

Big caveat of not being a lawyer, not even playing one on TV or the internet.

This is one of those situations where I think libraries like Qt.py are really useful.
Basically by working through a shim library that is also open source, you provide a proper mechanism for a user to easily replace / upgrade / whatever the underlying library.

Which after re-reading your example, is very similar to what you’re proposing, you’d keep the plugin closed source, but provide the python interface script so that it could be adapted to some other version of the underlying library.

2 Likes
#3

I think your best bet is to split the GUI from the functionality and release them as two different products with different licenses.

1 Like
#4

Using LGPL software you can sell you CLOSE code apps with no issues, you owe nothing to no one, specially if you are just using the python libs, if you use Qt frame on your C++ app you can still sell it as close source you just need to Dynamically link it.

The ONLY time you would need to share your code is, if you make changes to the PySide libraries or Qt Framework and the only thing you have to share is those changes, not your app code.

1 Like
#5

You need to make it possible for the user to recompile and link their own version of the LGPL library.
Which is where using some kind of shim library or script is rather helpful.

1 Like
#6

Hey, thanks for the reply!

You are completely right. I realize that I can keep the source closed when dealing with LGPL, however, that is not an issue. The requirement to provide a re-linking mechanism for the library isn’t a huge deal either.

To clarify:
My main issue is a clause of LGPL that explicitly allows backward-engineering of “the product”, even when dynamically linked. The backward-engineering permission does not seem to be limited to only what is required to relink the library. Although harder to do, compiled binary can still be backward-engineered. This means I would have no legal recourse if someone backward-engineers my plugin and publishes the backward-engineered product.

In my research I frequently found discussions of LGPL as it pertains to DRMs; in such a situation, the conclusion seems to be: if someone backward-engineers the DRM and publishes the “cracked” variant, there is no legal recourse to make them take it down.

In the case of “Qt -> (dynamically linked in) C++ compiled binary”, it is much clearer what “the product” is: it’s dll + your own binary. What I’m concerned about is whether the whole chain of “PySide <- (using) Python script (exposing) -> DCC environment commands (implemented in) -> compiled binary” is also considered “one product” and whether, as a result, the backward-engineering of the binary is legally permitted.

#7

Great idea! Thanks!

Although a little awkward for the end users, this may be a viable solution to this puzzle.

#8

Hm, I hadn’t paid closer attention to Qt.py, but it looks really good. It’s under a very permissive MIT license.
Thanks a lot for pointing this out!

However, this begs the question: I did hear LGPL allows publishing your project under a more permissive license, PySide / PySide2 are LGPL, however PyQt is GPL, which doesn’t permit this. How is Qt.py allowed to retain its MIT license then? I imagine maybe using only PySide through Qt.py should be relatively safe.

#9

Because Qt.py doesn’t actually distribute PyQt5 or PySide2.

Basically there is nothing in the GPL or LGPL that blocks you from licensing your own code under any license you want, but if you want to distribute your code with GPL or LGPL libraries included, then you must abide by the license.

1 Like
#10

you need to allow reverse engineering only when using static linking
that means you’re using specific versions of libraries that would be imposible to replace if someone wanted to use other versions, dynamic linking is not a problem in that case and would not require reverse engineering.

1 Like
#11

The user is allowed to change and re-link the library used in the application or device – including reverse engineering. With LGPLv3 it is explicitly stated that the user also needs to be able to run the re-linked binary, and that sufficient installation information must be provided. In practice, this forbids the creation of closed devices, also known as tivoization .

From the Qt documentation: https://www1.qt.io/qt-licensing-terms/

Right above that block they distinguish between static / dynamic linking when it comes to licensing your application. But in the block about tivoization, they don’t differentiate between the two, which would imply that you need to provide for this in both cases.

Again, not a lawyer, don’t play one on tv or the internet.

1 Like
#12

Sorry for the delay,

It’d be great if it was completely clear that it’s the way you state, and backward-engineering only applied to what is required to replace the library. However, based on the info I find, it appears that the permission could be more encompassing, permitting backward-engineering not only of “derivative work” (source modifications, static linking), but also of the “program using the library” (dynamic linking, importing in interpreted language, etc.).

The part of the license I’m most concerned about is section 3 (the part in bold is what apparently permits backward-engineering of any part of the program).

  1. Protecting Users’ Legal Rights From Anti-Circumvention Law.

No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.

When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work’s users, your or third parties’ legal rights to forbid circumvention of technological measures.

Official LGPL FAQ also has a point on this (and so does Qt licensing terms that Bob linked to, in the reply right above), claiming that DRM is ineffective: https://www.gnu.org/licenses/gpl-faq.html#DRMProhibited

#13

By using an LGPL license, you aren’t required to release your own code or binaries under the LGPL, but you must adhere to the LGPL for the portions of the code that are licensed under the LGPL.

In this context, that would mean the PySide2 binaries and any other code that statically links against those binaries would be subject to the LGPL.
If this wasn’t the case, Autodesk wouldn’t ship PySide2 with Maya, as it would give all of us free reign to pirate the crap out of their software.

And for reference, Autodesk releases a version of the Qt code under the LGPL that corresponds to a given version of Maya so that end users can compile their own version of PySide(2) as needed. (Or at least they did the last time I needed to do this which way Maya 2015)

1 Like
#14

Ah, that is interesting, I was under the impression that Autodesk paid for the Qt commercial license, so their use of Qt doesn’t have to abide by LGPL. But the fact that they do the whole ritual of distributing Qt sources and providing a relinking mechanism, seems to suggest they’re going for cheap.

Thanks a lot for your help, it cleared things up quite a bit!

#15

My guess is that they do in fact pay for a commercial license for Qt, but PySide wasn’t part of the commercial license for the longest time. Granted I could be wrong and they could be using the LGPL version for both.

1 Like