1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
|
QUIP: 4
Title: Third-Party Components in Qt
Author: Kai Köhne,
Sami Makkonen
Status: Active
Type: Process
Requires: QUIP 7
Created: 2016-12-08
Post-History: http://lists.qt-project.org/pipermail/development/2016-December/028114.html,
http://lists.qt-project.org/pipermail/development/2018-June/032862.html
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
==========
.. [1] https://www.qt.io/terms-conditions/
.. [2] https://wiki.qt.io/Qt_Project_Security_Policy
|
