Should we include license notice for all 3rd party libraries used by Qt? [closed]

Question

Closed. This question is off-topic. It is not currently accepting answers.

---

Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 8 years ago.

Improve this question

I use Qt as dynamically linked library and I plan to use it with LGPL license in a propriety software. Qt toolkit uses other libraries such as OpenGL, ANGLE, Libjpeg, Webkit, to name a few. Even the function QDate::weekNumber() has license notice by the University of California, Berkeley (see here). Many of the 3rd party libraries are part of the core Qt modules.

Normally we need to include the license notice of the 3rd party programs/libraries we use in our software. However, I’m not sure whether in my notice about licenses used, I need to include the license notice about using Qt toolkit library only, or I have to include a separate notice about each and every 3rd party library or piece of code used by Qt?

Another confusion is that some contributions to Qt like those by KDE are licensed with GPL only (not LGPL). How do people use Qt library with LGPL license in this kind of context?

Thank you!

Answer 1

We usually list the licenses from the third party components. You can find the list here: http://qt-project.org/doc/qt-5.0/qtdoc/licenses.html

Therefor we follow Digia's recommendation:

"Digia gratefully acknowledges these and other contributions to Qt. We recommend that programs that use Qt also acknowledge these contributions, and quote these license statements in an appendix to the documentation."

All the KDE contributions in the Qt core libraries fall under LGPL, even if they might have a different license elsewhere. This only applies to core Qt contributions, not external libraries from the KDE project of course.

Answer 2

The general rule of thumb it's that if you have a GPL licensed piece of code you are forced to release your entire software/code-base under the GPL license, because GPL it's viral and non-permissive.

It's a quite common problem, for example when dealing with the linux kernel, GPU makers always try to find alternative paths to directly link their code to the kernel, because the linux kernel it's GPL and they want to keep their drivers closed-source and keep owning all the rights and sources.

A BSD-style license it's much more permissive than a LGPL, I don't think that you can experience problems with a BSD/MIT license, but putting a note when using other people's work it's always nice.

The real problem it's that some censored markets like the ones from Apple and Microsoft, usually do not accepts LGPL licensed software, so your application it's likely to be censored and it's not going to be published in this kind of markets.

Speaking of limitations with the LGPL version of QT, the main limitation it's that you are not allowed to link statically and you can only link dynamically, you need to buy QT in order to respect the license and link QT statically.