[fragmede]

https://opensource.stackexchange.com/a/8806

In order to abide by QT's license, you have to follow the appropriate set of rules, depending on how you use it. You can use it LGPL, at which point you need to release the QT source you used and dynamically link it in your program. You can use it GPL but you have to release the source to your app. Finally, you can give QT money, and use it closed source. Okay, that wasn't that complex, but those are the rules if you want to use and distribute QT legally.

https://doc.qt.io/qt-6/licensing.html

[rubymamis]

> You can use it LGPL, at which point you need to release the QT source you used and dynamically link it in your program.

This is wrong. There's a misconception that you can't statically link your app when using the open-source LGPL version of Qt. From my reading of the LGPL license this doesn't appear to be the case[1]. The LGPL allows you to statically link your app as long as you provide the object files and allow users to relink your app with a different version of Qt.

I've observed many people spreading this misinformation about only being able to dynamically link with the LGPL version of Qt. Please stop this.

[1] https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...

[fragmede]

Here is the exact guidance from QT:

> In case of dynamic linking, it is possible, but not mandatory, to keep application source code proprietary as long as it is “work that uses the library” – typically achieved via dynamic linking of the library. In case of static linking of the library, the application itself may no longer be “work that uses the library” and thus become subject to LGPL. It is recommended to either link dynamically, or provide the application source code to the user under LGPL.

https://www.qt.io/licensing/open-source-lgpl-obligations#lgp...

That last sentence is key. It is a recommendation to dynamically link OR provide application source code. We don't want to be forced to provide application source code, so according to QT.io, dynamically linking is the way to go.

On top of that, there are GPL-only licensed QT modules that aren't suitable for use by closed source applications. Programs using QT on locked down OSes aka iOS and Android are subject to LGPL version 3's anti Tivo-ization clause. I'll revert to my original claim: Using QT is complex for commerical products.

Specific questions about dynamic linking and derivative works re: LGPLv3 have never been tested in a court of law, in any jurisdiction, so all we have to go on are tea leaves and armchair Internet lawyer-ing. The FSF and GNU are certainly entitled to their own opinion about their own license, but they also have a vested interest in casting as wide a net as possible. There are plenty of dissenting opinions out there, by actual lawyers. The important point is that GNU/FSF wouldn't be one deciding what's what in a court of law, a judge is. That judge gets to decide if the specific technical differences between static linking vs dynamic linking are even relevant in the first place. They might decide there isn't one!

Since it hasn't been tested in a court of law, different people are going to have different opinions on what's actually right. QT.io gives a specific recommendation on how to use their library, so I'll defer to what they have to say, but everyone's free to make their own decisions.