QUIP 4 | Third-Party Components in Qt
|Title:||Third-Party Components in Qt|
|Author:||Kai Köhne, Sami Makkonen|
Qt incorporates code and data not authored by employees of The Qt Company, nor contributed under the Qt License Agreement. This might be because the functionality was already created outside the Qt Project, the component is shared between different projects, or Qt needs to use existing code to interface with other libraries and systems. Such components are commonly called Third-Party Components.
There is nothing wrong with reusing and sharing code and data per se. However, the license terms of Third-Party Components can complicate acceptance of the Qt product by those who would use it. In particular, we need to make it easy for such clients to keep track of the versions and provenance of Third-Party Components, if only to enable them to properly adhere to their license terms. Where the component continues to evolve, independent of the Qt Project, updates to it are also important to Qt development and potentially to those deploying Qt.
Source code of Third-Party Components should only be added to Qt if really necessary. In particular, testing for and linking to external (system) libraries is preferred over copying the same library into the Qt sources.
Every addition of a new Third-Party Component requires an explicit approval by the Maintainer of the respective Qt module, and the Chief Maintainer. For components that are added to build infrastructure, tests or examples only, the approval of the Maintainer suffices.
Whether a component is acceptable depends on factors like
- The usefulness of the component
- The exact license terms of the component
- Whether the component is actively used
- Whether it is typically redistributed by users
Third party code should be kept separate from other code by placing it in a '3rdparty' directory inside the Qt module's sources. If the code becomes part of the Qt libraries or plugins, it shall be added to 'src/3rdparty' in the root directory of the relevant Qt module sources.
If the third party source code is of non-trivial size, it should be added as a git submodule.
Before each release the module maintainer shall check whether any Third-Party Component needs to be updated. This is typically the case if a newer version was released upstream, or security vulnerabilities have been found.
Updates for components that become part of a Qt library, plugin, or tool need to be mentioned in the change log of the release in a "[Third-Party Code]" area.
Every third-party addition needs to be documented:
- Components that become part of a Qt library, plugin or tool need to be documented as part of the respective module or tool documentation. Also, changes need to be mentioned in the change log of the release in a [Third-Party Code] area.
- Components that become part of an example need to be documented as part of the example's documentation.
Since Qt 5.8, the documentation must happen in the form of qt_attribution.json files (see QUIP 7).
Acceptable is the BSD License, or licenses that are (for all practical and legal purposes, including but not limited to license compatibility) equivalent to the BSD license.
Other licenses are acceptable if
- they are compatible with the respective open source licenses the part of Qt is released under (GNU LGPL v3 and/or GNU LGPL v2 for Qt Libraries and Plugins, GNU GPL v3 for Tools), and
- they are compatible with the commercial licenses of Qt , and
- the code does not become part of the Qt Essentials
For Third-Party Code that already is used in Qt, the Qt Project can accept an update to that Third-Party Component, provided it is licensed under the same terms as the component it is replacing.
Moreover, on a case by case basis, the Chief Maintainer may make exceptions to this rule.