Rename quip .txt files to .rst

This allows tooling to do nice highlighting. Python tried to rename its
PEPs recently but found it hard because of the PEPs being such an
established thing.
QUIPs are fresh, let's learn from the others.

Change-Id: Id31d0c800758f19d208fed88ae62e985d0355d4a
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>

1 files changed, 123 insertions, 0 deletions

diff --git a/quip-0007.rst b/quip-0007.rst
new file mode 100644
index 0000000..37aea02
--- /dev/null
+++ b/quip-0007.rst
@@ -0,0 +1,123 @@
+QUIP: 7
+Title: qt_attribution.json File Format
+Author: Kai Köhne
+Status: Active
+Type: Implementation
+Created: 2017-02-15
+Post-History: http://lists.qt-project.org/pipermail/development/2017-March/029198.html
+
+Overview
+========
+
+From Qt 5.8, Qt modules document their 3rd party code in qt_attribution.json
+files. The format is JSON-based and can be processed with the
+qtattributionscanner tool.
+
+This QUIP is about the file format of the qt_attribution.json files.
+See QUIP 4 for the process on how to add and update 3rd party code to Qt.
+
+File Format
+===========
+
+A qt_attribution.json file needs to contain one JSON object or an array of such
+objects. Each object's properties have the following meanings:
+
+Id
+  Unique name for component, without spaces. All lower case. Mandatory.
+Name
+  Descriptive name of the component, without version number. Camel case.
+  Mandatory.
+QDocModule
+  The qch file the documentation of the component should be part of. Mandatory.
+QtParts
+  Array with possible entries "examples", "tests", "tools", or "libs".
+  Components that will be included in Qt libraries or plugins should set
+  "libs", components that will be included in executables like Qt Designer or
+  are part of the build infrastructure "tools".
+  Optional, default is [ "libs" ].
+QtUsage
+  Free text on where the Third-Party Component in Qt is used, when it is
+  included  (e.g. if it's limited to a specific platform), how to avoid it
+  (e.g. by using configure options), and what functionality is missing in
+  this case.
+  Mandatory.
+Path
+  (Relative) path to the sources. Default is same directory as the file.
+  Optional.
+Description
+  A short description of what the component is and is used for. Optional.
+Homepage
+  Homepage of the upstream project. Optional.
+Version
+  Version used from the upstream project. This can also be a revision number
+  or commit hash from a version control system.
+  Optional.
+DownloadLocation
+  Link to exact upstream version. Optional.
+License
+  The license under which the component is distributed, preferably with the
+  names from SPDX [1]_ 'Full Name'. Mandatory.
+LicenseId
+  SPDX License Identifier [1]_, or an SPDX Expression [2]_. Optional.
+LicenseFile
+  Relative path to file containing the license text. Optional for code in the
+  Public Domain, otherwise needed.
+Copyright
+  Aggregated list of copyright lines. Mandatory.
+
+  The list can be edited for brevity by, for example, combining different
+  copyright years for the same author. Terms like "All rights reserved" can be
+  removed, too.
+
+  If there are too many copyright lines in the sources, aggregating them into::
+
+    Copyright YYYY The x project contributors
+
+  or::
+
+    Copyright YYYY <main author> and contributors
+
+  is also acceptable.
+
+Related Work
+============
+
+The issue of attributing Third-Party Components correctly is known in a lot of
+projects and companies. Some companies require elaborate documents about
+Third-Party Components from their suppliers. Multiple projects have invented
+their own formats for documenting Third-Party Components and licenses.
+
+SPDX
+----
+
+SPDX [3]_ (Software Package Data Exchange) is a standard format for
+communicating the components, licenses and copyrights associated with a
+software package. It supports several file formats (XML, RDF, Key/Value), and
+is aimed to be generated by code-scanning tools.
+
+We have adapted the SPDX license list [1]_, but considered the standard itself
+to be too heavy for our use. However, it should be possible to generate
+(parts of) SPDX files out of the qt_attribution.json files.
+
+debian/copyright files
+----------------------
+
+Debian has established a convention for making their debian/copyright files
+machine-readable [4]_. This is meant to be used on the packaging level.
+
+README.chromium files
+---------------------
+
+README.chromium files [5]_ are used by Google Chrome to generate the
+'about://credits' page. Qt WebEngine uses them also to document the Third-Party
+Components inside Chromium. Compared to qt_attribution.json files, the format
+is not strictly enforced.
+
+References
+==========
+
+.. [1] https://spdx.org/licenses/
+.. [2] https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60
+.. [3] https://spdx.org/specifications
+.. [4] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+.. [5] https://src.chromium.org/viewvc/chrome/trunk/src/third_party/README.chromium.template