Hi everyone!
I am working on a small Qt cross-platform app and I would like to add OS notifications. I do a quick Google and find KNotifications library. I am now confused as to under which license I can use the library. Some files are licensed LGPL 2.0 only, others are LGPL 2.0 or later, etc.
So what do I do?
So we have a few resources that we use to decide when to use which license:
https://community.kde.org/Policies/Licensing_Policy
https://community.kde.org/Guidelines_and_HOWTOs/Licensing
But those are more of an internal thing rather than guidelines for library users.
From the little I understand about that area:
At the moment, the project is closed source and for internal use only. There are however talks about it being commercially available. I want to be a good boy and participate in the OSS ecosystem in a good faith.
In the Licensing Policy article there is this line:
Source files that are part of a library with a public API which is part of the KDE Platform (kdelibs, kdepimlibs, kde-runtime and KDE Frameworks) must be licensed under:
If I am understanding this right, this means I’ve to use license that is applicable to all public API files. According to https://api.kde.org/frameworks/knotifications/html/ (posting as preformatted text as I am not allowed to post links) public classes are following:
KNotification - LGPL-2.0-or-laterKNotificationAction - LGPL-2.0-or-laterKNotificationPlugin - LGPL-2.1-only OR LGPL-3.0-only OR LicenseRef-KDE-Accepted-LGPLKNotificationReplyAction - LGPL-2.0-or-laterKNotifyConfig - LGPL-2.1-only OR LGPL-3.0-only OR LicenseRef-KDE-Accepted-LGPLThat would mean to satisfy all conditions I would have to use LGPL 2.1 or 3.0 license, right?
This is a good resource: Copyleft and the GNU General Public License: A Comprehensive Tutorial and Guide
IANAL, but in a nutshell,
Yes. That’s assuming that two things are true:
Also note that your app and KNotifications will interact with other library dependencies, notably Qt, which in its open source version is only available under LGPL v3.
More on that
I thought I’d be thorough and check at least the version of KNotifications on the current master branch for its complete set of licenses, including non-public sources. Surprising outcome:
knotification.cpp and knotification_p.h are in fact licensed under LGPL-2.0-only. Combined with the fact that some other files require at least LGPL-2.1, this means no single license can be used for the entire library as a whole? That seems, well, not great.
One could make a point that specifying LGPL-2.0-only is likely an honest mistake and people wanted to write LGPL-2.1-only, which was just a trivial bugfix release and name change for 2.0. This mistake has happened to me too in the past, because GPL v2 is indeed 2.0 but LGPL v2 should be 2.1 and it’s easy to miss.
In either case, it looks like someone will have to look at updating their license blurbs or KNotifications is an a legal gray area.
Please read up on LGPL in the link I sent or the GPL FAQ.
LGPL may be relicensed to (A)GPL. Also LGPL may be mixed (under certain conditions) with basically any other license, as long as you follow the LGPL.
(IIAL BIANYL)
IANAL, but my understanding is as follows.
Your project can use any license you want as long as long as you’re not statically linking to any LGPL code. LGPL is basically the same as the GPL, but with an additional exception to allow dynamic linking with proprietary software. Note that regardless of KDE’s licensing, Qt’s free software most permissive license for free software is LGPLv3, so you would have to comply with that regardless.
However, if it is true that some files in KNotifications are LGPLv2-only, that is actually problematic. The LGPLv2 is not actually compatible with the LGPLv3, because the LGPLv3 imposes a few additional restriction (mainly the anti-tivoization clause) and the LGPLv2 prohibits being coupled with licenses that impose restrictions not already imposed by itself (with an exception to allow coupling with the GPL). This would actually make the library incompatible with Qt’s LGPLv3. This is why LGPLv2+ is generally significantly more desirable than LGPLv2-only. Unless I’m misunderstanding something, KDE should probably seek to relicense all of its LGPLv2-only code to LGPLv2+
This is explicitly in LGPL-2.1 (§6.b)) and LGPL-3.0. For LGPL-2.0, it’s not as clear, whether dynamic linking is enough.
What is fine for all LGPL licenses (e.g. LGPL §6.a)) so far though (I’m paraphrasing and simplifying) is, that as long as you make it so that anyone can replace the originally LGPL’d library in your code with either a different version or a modified version of the library, LGPL extends only to the code that is needed in order for the library to be removed and replaced. Using a shared object / dynamic linking, is just the most convenient way of doing that.
To quote from LGPL-2.1 (the new part in 2.1 is b), which was not present in 2.0):
6. As an exception to the Sections above, you may also combine or link a “work that uses the Library” with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer’s own use and reverse engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:
a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable “work that uses the Library”, as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)
b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user’s computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with.
[… the]
It depends. Again, unless one library is so intertwined with the other, that you cannot treat the two libraries separately under LGPL-2.x §6, you just have to comply with LGPL-3.0 for LibraryA and with LGPL-2.0 for LibraryB, and can still release your own program that uses both under any license whatsoever.
Wouldn’t hurt, no 