Overview

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.

Adding Third-Party Components

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.

Updating Third-Party Components

The Module Maintainer is ultimately responsible for tracking upstream development of Third Party Modules in their module. The maintainer should watch out for new security vulnerabilities that are reported, or new releases becoming available. The maintainer can delegate this responsibility though.

A newly known security vulnerability in versions of a Third Party Module that is part of any still supported Qt library, plugin or tool needs to be reported to the Qt Project security mailing list [2]. The core security team can then decide whether any immediate action is necessary.

Before each release of Qt, the Module Maintainer shall check whether any Third-Party Component needs to be updated. We aim to always ship with the latest release of an upstream feature series, for all supported branches of Qt.

If an upstream project or feature series we use in an active branch becomes unsupported, it is the responsibility of the Module Maintainer to watch out for security issues or patches for it. This might mean for instance coordinating with Linux distributions.

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.

Documenting Third-Party Components

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 Licenses

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 [1], 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.

References