2020-09-28 03:58:34 -04:00
|
|
|
|
PEP: 639
|
|
|
|
|
Title: Metadata for Python Software Packages 2.2
|
|
|
|
|
Version: $Revision$
|
|
|
|
|
Last-Modified: $Date$
|
|
|
|
|
Author: Philippe Ombredanne <pombredanne at nexb.com>
|
|
|
|
|
Sponsor: Paul Moore <p.f.moore at gmail.com>
|
|
|
|
|
BDFL-Delegate: Paul Moore <p.f.moore at gmail.com>
|
|
|
|
|
Discussions-To: https://discuss.python.org/t/2154
|
|
|
|
|
Status: Draft
|
|
|
|
|
Type: Standards Track
|
|
|
|
|
Content-Type: text/x-rst
|
2020-10-16 15:39:49 -04:00
|
|
|
|
Created: 15-Aug-2019
|
2020-09-28 03:58:34 -04:00
|
|
|
|
Python-Version: 3.x
|
|
|
|
|
Post-History:
|
|
|
|
|
Replaces: 566
|
|
|
|
|
Resolution:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Abstract
|
|
|
|
|
========
|
|
|
|
|
|
|
|
|
|
This PEP describes the changes between versions 2.1 and 2.2 of the `Core
|
|
|
|
|
Metadata Specification` [#cms]_ for Python packages. Version 2.1 is specified in
|
|
|
|
|
PEP 566.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
The primary change introduced in this PEP updates how licenses are documented in
|
|
|
|
|
core metadata via the ``License`` field with license expression strings using
|
|
|
|
|
SPDX license identifiers [#spdxlist]_ such that license documentation is simpler and less
|
2020-09-28 03:58:34 -04:00
|
|
|
|
ambiguous:
|
|
|
|
|
|
|
|
|
|
- for package authors to create,
|
|
|
|
|
- for package users to read and understand, and,
|
|
|
|
|
- for tools to process package license information mechanically.
|
|
|
|
|
|
|
|
|
|
The other changes include:
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- specifying a ``License-File`` field which is already used by ``wheel`` and
|
|
|
|
|
``setuptools`` to include license files in built distributions.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
- defining how tools can validate license expressions and report warnings to
|
2020-09-30 10:13:58 -04:00
|
|
|
|
users for invalid expressions (but still accept any string as ``License``).
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Goals
|
|
|
|
|
=====
|
|
|
|
|
|
|
|
|
|
This PEP's scope is limited strictly to how we document the license of a
|
2020-09-30 10:13:58 -04:00
|
|
|
|
distribution:
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
- with an improved and structured way to document a license expression, and,
|
|
|
|
|
- by including license texts in a built package.
|
|
|
|
|
|
|
|
|
|
The core metadata specification updates that are part of this PEP, have been
|
|
|
|
|
designed to have minimal impact and to be backward compatible with v2.1.
|
|
|
|
|
These changes utilize emerging new ways to document licenses that are already
|
2020-09-30 10:13:58 -04:00
|
|
|
|
in use in some tools (e.g. by adding the ``Licence-File`` field already used in
|
|
|
|
|
``wheel`` and ``setuptools``) or by some package authors (e.g. storing an SPDX
|
|
|
|
|
license expression in the existing ``License`` field).
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
In addition to an update to the metadata specification, this PEP contains:
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- recommendations for publishing tools on how to validate the ``License``
|
|
|
|
|
and ``Classifier`` fields and report informational warnings when a package uses
|
|
|
|
|
an older, non-structured style of license documentation conventions.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- informational appendixes that contain surveys of how we document licenses
|
2020-09-28 03:58:34 -04:00
|
|
|
|
today in Python packages and elsewhere, and a reference Python library to
|
|
|
|
|
parse, validate and build correct license expressions.
|
|
|
|
|
|
|
|
|
|
It is the intent of the PEP authors to work closely with tool authors to
|
|
|
|
|
implement to recommendations for validation and warnings specified in this
|
|
|
|
|
PEP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Non-Goals
|
|
|
|
|
=========
|
|
|
|
|
|
|
|
|
|
This PEP is neutral regarding the choice of various licenses.
|
|
|
|
|
|
|
|
|
|
In particular, the SPDX license expression syntax proposed in this PEP provides
|
|
|
|
|
simpler and more expressive conventions to document more accurately any kind of
|
|
|
|
|
license that applies to a Python package, whether under an open source, free or
|
|
|
|
|
libre software license or a proprietary license.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
This PEP makes no recommendation for certain licenses and does not require the use of
|
|
|
|
|
specific license documentation conventions. This PEP also does not impose any
|
2020-09-28 03:58:34 -04:00
|
|
|
|
restrictions when uploading to PyPI.
|
|
|
|
|
|
|
|
|
|
Instead, this PEP is intended to document common practices already in use,
|
2020-09-30 10:13:58 -04:00
|
|
|
|
and recommends that publishing tools should encourage users via informational
|
|
|
|
|
warnings when they do not follow this PEP's recommendations.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
This PEP is not about documenting license in code files, even though this is a
|
2020-09-30 10:13:58 -04:00
|
|
|
|
surveyed topic in the appendix.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Possible future PEPs
|
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
|
|
It is the intention of the authors of this PEP to consider the submission of
|
|
|
|
|
related but separate PEPs in the future such as:
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- make ``License`` and new ``License-File`` fields mandatory including
|
2020-09-28 03:58:34 -04:00
|
|
|
|
stricter enforcement in tools and PyPI publishing.
|
|
|
|
|
|
|
|
|
|
- require uploads to PyPI to use only FOSS (Free and Open Source software)
|
|
|
|
|
licenses.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Motivation
|
|
|
|
|
==========
|
|
|
|
|
|
|
|
|
|
Software is licensed and providing accurate licensing information to Python
|
|
|
|
|
packages users is an important matter. Today, there are multiple places where
|
|
|
|
|
license is documented in package metadata and there are limitations to what can
|
|
|
|
|
be documented. This is often leading to confusion or a lack of clarity both for
|
|
|
|
|
package authors and package users.
|
|
|
|
|
|
|
|
|
|
Several package authors have expressed difficulty and/or frustrations with the
|
|
|
|
|
possibilities to express licensing in package metadata. This also applies to
|
|
|
|
|
Linux and BSD* distribution packagers. This has triggered several license-related
|
|
|
|
|
discussions and issues and in particular:
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- https://github.com/pypa/trove-classifiers/issues/17
|
2020-09-28 03:58:34 -04:00
|
|
|
|
- https://github.com/pypa/interoperability-peps/issues/46
|
|
|
|
|
- https://github.com/pypa/packaging-problems/issues/41
|
|
|
|
|
- https://github.com/pypa/wheel/issues/138
|
|
|
|
|
- https://github.com/pombredanne/spdx-pypi-pep/issues/1
|
|
|
|
|
|
|
|
|
|
On average, Python packages tend to have more ambiguous or missing license
|
|
|
|
|
information than other common application package formats (such as npm, Maven or
|
|
|
|
|
Gem) as can be seen in the statistics [#cdstats]_ page of the ClearlyDefined
|
|
|
|
|
[#cd]_ project that cover all packages from PyPI, Maven, npm and Rubygems.
|
|
|
|
|
ClearlyDefined is an open source project to help improve clarity of other open
|
|
|
|
|
source projects that is incubating at the OSI (Open Source Initiative) [#osi]_.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rationale
|
|
|
|
|
=========
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
A mini survey of existing license metadata definitions in use in the Python
|
|
|
|
|
ecosystem today and documented in several other system/distro and application
|
|
|
|
|
package formats is provided in Appendix 2 of this PEP.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
There are a few takeaways from the survey:
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- Most package formats use a single ``License`` field.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
- Many modern package formats use some form of license expression syntax to
|
|
|
|
|
optionally combine more than one license identifiers together. SPDX and
|
|
|
|
|
SPDX-like syntaxes are the most popular in use.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- SPDX license identifiers are becoming a de-facto way to reference common licenses
|
2020-09-28 03:58:34 -04:00
|
|
|
|
everywhere, whether or not a license expression syntax is used.
|
|
|
|
|
|
|
|
|
|
- Several package formats support documenting both a license expression and
|
|
|
|
|
the paths of the corresponding files that contain the license text. Most free
|
|
|
|
|
and open source software licenses require to include their full text in a
|
|
|
|
|
distribution.
|
|
|
|
|
|
|
|
|
|
These considerations have guided the design and recommendations of this PEP.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
The reuse of the ``License`` field with license expressions will provide an
|
2020-09-28 03:58:34 -04:00
|
|
|
|
intuitive and more structured way to express the license of a distribution using
|
2020-09-30 10:13:58 -04:00
|
|
|
|
a well-defined syntax and well-known license identifiers.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
Over time, recommending the usage of these expressions will help Python package
|
|
|
|
|
publishers improve the clarity of their license documentation to the benefit of
|
|
|
|
|
packages authors, consumers and redistributors.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Core Metadata Specification updates
|
|
|
|
|
===================================
|
|
|
|
|
|
|
|
|
|
The canonical source for the names and semantics of each of the supported
|
|
|
|
|
metadata fields is the Core Metadata Specification [#cms]_ document.
|
|
|
|
|
|
|
|
|
|
The details of the updates considered to the Core Metadata Specification [#cms]_
|
|
|
|
|
document as part of this PEP are detailed here and will be added to the
|
|
|
|
|
canonical source once this PEP is approved.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Added in Version 2.2
|
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
|
|
License-File (multiple use)
|
|
|
|
|
:::::::::::::::::::::::::::
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
The License-File is a string that is a ``.dist-info`` relative path to a license
|
|
|
|
|
file. The license file content MUST be UTF-8 encoded text.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
Build tools SHOULD honor this field and include the corresponding license
|
|
|
|
|
file(s) in the built package.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Changed in Version 2.2
|
|
|
|
|
----------------------
|
|
|
|
|
|
|
|
|
|
License (optional)
|
|
|
|
|
::::::::::::::::::
|
|
|
|
|
|
|
|
|
|
Text indicating the license covering the distribution. This text can be either a
|
2020-09-30 10:13:58 -04:00
|
|
|
|
valid license expression as defined here or any free text.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
Publishing tools SHOULD issue an informational warning if this field is empty,
|
|
|
|
|
missing, or is not a valid license expression as defined here. Build tools MAY
|
|
|
|
|
issue a similar warning.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
License Expression syntax
|
|
|
|
|
'''''''''''''''''''''''''
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
A license expression is a string using the SPDX license expression syntax as
|
2020-09-28 03:58:34 -04:00
|
|
|
|
documented in the SPDX specification [#spdx]_ using either Version 2.2
|
|
|
|
|
[#spdx22]_ or a later compatible version. SPDX is a working group at the Linux
|
|
|
|
|
Foundation that defines a standard way to exchange package information.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
When used in the ``License`` field and as a specialization of the SPDX license
|
|
|
|
|
expression definition, a license expression can use the following license
|
2020-09-28 03:58:34 -04:00
|
|
|
|
identifiers:
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- any SPDX-listed license short-form identifiers that are published in the
|
2020-09-28 03:58:34 -04:00
|
|
|
|
SPDX License List [#spdxlist]_ using either Version 3.10 of this list or any
|
|
|
|
|
later compatible version. Note that the SPDX working group never removes any
|
2020-09-30 10:13:58 -04:00
|
|
|
|
license identifiers: instead they may only mark an identifier as "obsolete".
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- the ``LicenseRef-Public-Domain`` and ``LicenseRef-Proprietary`` strings to support
|
|
|
|
|
generic identifiers that are not available in the SPDX license list.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
When processing the ``License`` field to determine if it contains a valid license
|
2020-09-28 03:58:34 -04:00
|
|
|
|
expression, tools:
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- MUST ignore the case of the ``License`` field
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
- SHOULD report an informational warning if one or more of the following applies:
|
|
|
|
|
|
|
|
|
|
- the field does not contain a license expression,
|
|
|
|
|
- the license expression syntax is invalid,
|
|
|
|
|
- the license expression syntax is valid but some license identifiers are
|
|
|
|
|
unknown as defined here or the license identifiers have been marked as
|
|
|
|
|
deprecated in the SPDX License List [#spdxlist]_
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- SHOULD store a case-normalized version of the ``License`` field using the
|
2020-09-28 03:58:34 -04:00
|
|
|
|
reference case for each SPDX license identifier and uppercase for the AND, OR
|
|
|
|
|
and WITH keywords. And SHOULD report an informational warning if the reference
|
|
|
|
|
case is not used.
|
|
|
|
|
|
|
|
|
|
License expression examples::
|
|
|
|
|
|
|
|
|
|
License: MIT
|
|
|
|
|
|
|
|
|
|
License: BSD-3-Clause
|
|
|
|
|
|
|
|
|
|
License: MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause)
|
|
|
|
|
|
|
|
|
|
License: GPL-3.0-only WITH Classpath-Exception-2.0 OR BSD-3-Clause
|
|
|
|
|
|
|
|
|
|
License: This software may only be obtained by sending the
|
|
|
|
|
author a postcard, and then the user promises not
|
|
|
|
|
to redistribute it.
|
|
|
|
|
|
|
|
|
|
License: LicenseRef-Proprietary AND LicenseRef-Public-Domain
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Classifier (multiple use)
|
|
|
|
|
:::::::::::::::::::::::::
|
|
|
|
|
|
|
|
|
|
Each entry is a string giving a single classification value for the
|
|
|
|
|
distribution. Classifiers are described in PEP 301.
|
|
|
|
|
|
|
|
|
|
Examples::
|
|
|
|
|
|
|
|
|
|
Classifier: Development Status :: 4 - Beta
|
|
|
|
|
Classifier: Environment :: Console (Text Based)
|
|
|
|
|
|
|
|
|
|
Tools SHOULD issue an informational warning if this field contains a licensing
|
2020-09-30 10:13:58 -04:00
|
|
|
|
related classifier string starting with the ``License ::`` prefix and SHOULD
|
|
|
|
|
suggest the use of a license expression in the ``License`` field instead.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
If the ``License`` field is present and contains a valid license expression,
|
|
|
|
|
publishing tools MUST NOT also provide any licensing related classifier entries
|
2020-09-28 03:58:34 -04:00
|
|
|
|
[#classif]_.
|
|
|
|
|
|
|
|
|
|
However, for compatibility with existing publishing and installation processes,
|
2020-09-30 10:13:58 -04:00
|
|
|
|
licensing-related classifier entries SHOULD continue to be accepted if the
|
|
|
|
|
``License`` field is absent or does not contain a valid license expression.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
Publishing tools MAY infer a license expression from the provided classifier
|
2020-09-28 03:58:34 -04:00
|
|
|
|
entries if they are able to do so unambiguously.
|
|
|
|
|
|
|
|
|
|
However, no new licensing related classifiers will be added, with anyone
|
2020-09-30 10:13:58 -04:00
|
|
|
|
requesting them being directed to use a license expression in the ``License``
|
|
|
|
|
field instead. Note that the licensing related classifiers may be deprecated in
|
|
|
|
|
a future PEP.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
Mapping Legacy Classifiers to New License Expressions
|
2020-09-28 03:58:34 -04:00
|
|
|
|
'''''''''''''''''''''''''''''''''''''''''''''''''''''
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
Publishing tools MAY infer or suggest an equivalent license expression from
|
|
|
|
|
the provided ``License`` or ``Classifier`` information if they are able to do so
|
2020-09-28 03:58:34 -04:00
|
|
|
|
unambiguously. For instance, if a package only has this license classifier::
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
Classifier: License :: OSI Approved :: MIT License
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
Then the corresponding value for a ``License`` field using a valid license
|
|
|
|
|
expression to suggest would be::
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
License: MIT
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Here are mappings guidelines for the legacy classifiers:
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- Classifier ``License :: Other/Proprietary License`` becomes License:
|
|
|
|
|
``LicenseRef-Proprietary`` expression.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- Classifier ``License :: Public Domain`` becomes License: ``LicenseRef-Public-Domain``
|
2020-09-28 03:58:34 -04:00
|
|
|
|
expression, though tools should encourage the use of more explicit and legally
|
2020-09-30 10:13:58 -04:00
|
|
|
|
portable licenses identifiers such as ``CC0-1.0`` [#cc0]_, the ``Unlicense``
|
2020-09-28 03:58:34 -04:00
|
|
|
|
[#unlic]_: the meaning associated with the term "public domain" is thoroughly
|
|
|
|
|
dependent on the specific legal jurisdiction involved and some jurisdictions
|
|
|
|
|
have no concept of Public Domain as it exists in the USA.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- The generic and ambiguous classifiers ``License :: OSI Approved``
|
|
|
|
|
and ``License :: DFSG approved`` do not have an equivalent license expression.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- The generic and sometimes ambiguous classifiers
|
|
|
|
|
``License :: Free For Educational Use``, ``License :: Free For Home Use``,
|
|
|
|
|
``License :: Free for non-commercial use``, ``License :: Freely Distributable``,
|
|
|
|
|
``License :: Free To Use But Restricted``, and ``License :: Freeware`` are mapped
|
|
|
|
|
to the generic License: ``LicenseRef-Proprietary`` expression.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- Classifiers ``License :: GUST*`` have no mapping to SPDX license identifierss
|
|
|
|
|
for now and no package uses them in PyPI as of the writing of this PEP.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
The remainder of the classifiers using a ``License ::`` prefix map to a simple
|
2020-09-28 03:58:34 -04:00
|
|
|
|
single license expression using the corresponding SPDX license identifiers.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
When multiple license-related classifiers are used, their relation is
|
2020-09-28 03:58:34 -04:00
|
|
|
|
ambiguous and it is typically not possible to determine if all the licenses
|
|
|
|
|
apply or if there is a choice that is possible among the licenses. In this case,
|
|
|
|
|
tools cannot infer reliably a license expression to suggest using only the
|
2020-09-30 10:13:58 -04:00
|
|
|
|
legacy classifier usage.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Summary of Differences From PEP 566
|
|
|
|
|
===================================
|
|
|
|
|
|
|
|
|
|
* Metadata-Version is now 2.2.
|
|
|
|
|
* Added one new field: ``License-File``
|
2020-09-30 10:13:58 -04:00
|
|
|
|
* Updated the documentation of two fields: ``License`` and ``Classifier``
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Backwards Compatibility
|
|
|
|
|
=======================
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
The reuse of the ``License`` field means that we keep backward compatibility. The
|
|
|
|
|
specification of the ``License-File`` field is only writing down the practices
|
|
|
|
|
of the ``wheel`` and ``setuptools`` tools and is backward compatible with their
|
2020-09-28 03:58:34 -04:00
|
|
|
|
support for that field.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
The "soft" validation of the ``License`` field when it does not contain a valid
|
|
|
|
|
license expression and when the ``Classifier`` field is used with legacy
|
|
|
|
|
license-related classifiers means that we can gently prepare users for a
|
|
|
|
|
possible strict and incompatible validation of these fields in the future.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Security Implications
|
|
|
|
|
=====================
|
|
|
|
|
|
|
|
|
|
This PEP has no foreseen security implications: the License field is
|
|
|
|
|
a plain string and the License-File(s) are file paths. None of them introduces
|
|
|
|
|
any new security concern.
|
|
|
|
|
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
How to Teach Users to Use License Expressions
|
2020-09-28 03:58:34 -04:00
|
|
|
|
=============================================
|
|
|
|
|
|
|
|
|
|
The simple cases are simple: a single license id is a valid license expression
|
|
|
|
|
and a large majority of packages use a single license.
|
|
|
|
|
|
|
|
|
|
The plan to teach users of packaging tools how to use the license with a valid
|
|
|
|
|
license expressions is to have tool issue warning messages when they detect an
|
|
|
|
|
incorrect license expressions or when a license-related classifier is used in
|
2020-09-30 10:13:58 -04:00
|
|
|
|
the ``Classifier`` field.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
With a warning message that does not terminate processing, publishing tools will
|
|
|
|
|
gently teach users on how to provide correct license expressions over time.
|
|
|
|
|
|
|
|
|
|
Tools may also help with the conversion and suggest a license expression in some
|
|
|
|
|
cases:
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
1. The section `Mapping Legacy Classifiers to New License expressions` provides
|
2020-09-28 03:58:34 -04:00
|
|
|
|
tools authors with guidelines on how to suggest a license expression from
|
2020-09-30 10:13:58 -04:00
|
|
|
|
legacy classifiers.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
2. Tools may also be able to infer and suggest how to update an existing
|
2020-09-30 10:13:58 -04:00
|
|
|
|
incorrect ``License`` value and convert that to a correct license expression.
|
|
|
|
|
For instance a tool may suggest to correct a ``License`` field from ``Apache2``
|
2020-09-28 03:58:34 -04:00
|
|
|
|
(which is not a valid license expression as defined in this PEP) to
|
2020-09-30 10:13:58 -04:00
|
|
|
|
``Apache-2.0`` (which is a valid license expression using an SPDX license id as
|
2020-09-28 03:58:34 -04:00
|
|
|
|
defined in this PEP).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reference Implementation
|
|
|
|
|
========================
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
Tools will need to support parsing and validating license expressions in the
|
|
|
|
|
``License`` field.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
The ``license-expression`` library [#licexp]_ is a reference Python
|
|
|
|
|
implementation for a library that handles license expressions including
|
|
|
|
|
parsing, validating and formatting license expressions using flexible lists of
|
|
|
|
|
license symbols (including SPDX license identifiers and any extra identifiers
|
|
|
|
|
referenced here). It is licensed under the Apache-2.0 license and is used in a
|
|
|
|
|
few projects such as the SPDX Python tools [#spdxpy]_, the ScanCode toolkit
|
|
|
|
|
[#scancodetk]_ and the Free Software Foundation Europe (FSFE) Reuse project
|
|
|
|
|
[#reuse]_.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rejected ideas
|
|
|
|
|
==============
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
1. use a new ``License-Expression`` field and deprecate the ``License`` field.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
Adding a new field would introduce backward incompatible changes when the
|
2020-09-30 10:13:58 -04:00
|
|
|
|
``License`` field would be retired later and require to have a more complex
|
2020-09-28 03:58:34 -04:00
|
|
|
|
validation. The use of such a field would further introduce a new concept that
|
|
|
|
|
is not seen anywhere else in any other package metadata (e.g. a new a field only
|
|
|
|
|
for license expression) and possibly be a source of confusion. Also, users are
|
|
|
|
|
less likely to start using a new field than make small adjustments to their use
|
|
|
|
|
of existing fields.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2. mapping licenses used in the license expression to specific files in the
|
|
|
|
|
license files (or vice versa).
|
|
|
|
|
|
|
|
|
|
This would require using a mapping (two parallel lists would be too prone to
|
|
|
|
|
alignment errors) and a mapping would bring extra complication to how license
|
|
|
|
|
are documented by adding an additional nesting level.
|
|
|
|
|
|
|
|
|
|
A mapping would be needed as you cannot guarantee that all expressions (e.g. a
|
|
|
|
|
GPL with an exception may be in a single file) or all the license keys have a
|
|
|
|
|
single license file and that any expression does not have more than one. (e.g.
|
2020-10-16 15:39:49 -04:00
|
|
|
|
an Apache license ``LICENSE`` and its ``NOTICE`` file for instance are two
|
2020-09-30 10:13:58 -04:00
|
|
|
|
distinct file). Yet in most cases, there is a simpler `one license`, `one or
|
|
|
|
|
more license files`. In the rarer and more complex cases where there are many
|
2020-09-28 03:58:34 -04:00
|
|
|
|
licenses involved you can still use the proposed conventions at the cost of a
|
|
|
|
|
slight loss of clarity by not specifying which text file is for which license
|
2020-10-16 15:39:49 -04:00
|
|
|
|
identifier, but you are not forcing the more complex data model (e.g. a mapping)
|
|
|
|
|
on everyone that may not need it.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
We could of course have data field with multiple possible value types (it’s a
|
|
|
|
|
string, it’s a list, it’s a mapping!) but this could be a source of confusion.
|
|
|
|
|
This is what has been done for instance in npm (historically) and in Rubygems
|
|
|
|
|
(still today) and as result you need to test the type of the metadata field
|
|
|
|
|
before using it in code and users are confused about when to use a list or a
|
|
|
|
|
string.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
3. mapping licenses to specific source files and/or directories of source files
|
|
|
|
|
(or vice versa).
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
File-level notices are not considered as part of the scope of this PEP and the
|
|
|
|
|
existing the ``SPDX-License-Identifier`` [#spdxids]_ convention can be used and
|
2020-09-28 03:58:34 -04:00
|
|
|
|
may not need further specification as a PEP.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Appendix 1. License Expression example
|
|
|
|
|
======================================
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
The current version of ``setuptools`` metadata [#setuptools5030]_ does not use
|
|
|
|
|
the ``License`` field. It uses instead this license-related information in
|
|
|
|
|
``setup.cfg``::
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
license_file = LICENSE
|
|
|
|
|
classifiers =
|
|
|
|
|
License :: OSI Approved :: MIT License
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
The simplest migration to this PEP would consist of using this instead::
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
license = MIT
|
|
|
|
|
license_files =
|
|
|
|
|
LICENSE
|
|
|
|
|
|
|
|
|
|
Another possibility would be to include the licenses of the third-party packages
|
2020-09-30 10:13:58 -04:00
|
|
|
|
bundled in that are vendored in the ``setuptools/_vendor/`` and
|
|
|
|
|
``pkg_resources/_vendor`` directories::
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
appdirs==1.4.3
|
|
|
|
|
packaging==20.4
|
|
|
|
|
pyparsing==2.2.1
|
|
|
|
|
ordered-set==3.1.1
|
|
|
|
|
|
|
|
|
|
These are using these license expressions::
|
|
|
|
|
|
|
|
|
|
appdirs: MIT
|
|
|
|
|
packaging: Apache-2.0 OR BSD-2-Clause
|
|
|
|
|
pyparsing: MIT
|
|
|
|
|
ordered-set: MIT
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
Therefore, a comprehensive license documentation covering both ``setuptools`` proper
|
2020-09-28 03:58:34 -04:00
|
|
|
|
and its vendored packages could contain these metadata, combining all the
|
|
|
|
|
license expressions in one expression::
|
|
|
|
|
|
|
|
|
|
license = MIT AND (Apache-2.0 OR BSD-2-Clause)
|
|
|
|
|
license_files =
|
|
|
|
|
LICENSE.MIT
|
|
|
|
|
LICENSE.packaging
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
Here we would assume that the ``LICENSE.MIT`` file contains the text of the MIT
|
|
|
|
|
license and the copyrights used by ``setuptools``, ``appdirs``, ``pyparsing`` and
|
|
|
|
|
``ordered-set``, and that the ``LICENSE.packaging`` file contains the texts of the
|
2020-09-28 03:58:34 -04:00
|
|
|
|
Apache and BSD license, its copyrights and its license choice notice [#packlic]_.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Appendix 2. Surveying how we document licenses today in Python
|
|
|
|
|
==============================================================
|
|
|
|
|
|
|
|
|
|
There are multiple ways used or recommended to document Python package
|
|
|
|
|
licenses today:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In Core metadata
|
|
|
|
|
----------------
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
There are two overlapping core metadata fields to document a license: the
|
|
|
|
|
license-related ``Classifier`` strings [#classif]_ prefixed with ``License ::`` and
|
|
|
|
|
the ``License`` field as free text [#licfield]_.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
The core metadata documentation ``License`` field documentation is currently::
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
License (optional)
|
|
|
|
|
::::::::::::::::::
|
|
|
|
|
|
|
|
|
|
Text indicating the license covering the distribution where the license
|
|
|
|
|
is not a selection from the "License" Trove classifiers. See
|
|
|
|
|
"Classifier" below. This field may also be used to specify a
|
|
|
|
|
particular version of a license which is named via the ``Classifier``
|
|
|
|
|
field, or to indicate a variation or exception to such a license.
|
|
|
|
|
|
|
|
|
|
Examples::
|
|
|
|
|
|
|
|
|
|
License: This software may only be obtained by sending the
|
|
|
|
|
author a postcard, and then the user promises not
|
|
|
|
|
to redistribute it.
|
|
|
|
|
|
|
|
|
|
License: GPL version 3, excluding DRM provisions
|
|
|
|
|
|
|
|
|
|
Even though there are two fields, it is at times difficult to convey anything
|
2020-09-30 10:13:58 -04:00
|
|
|
|
but simpler licensing. For instance some classifiers lack accuracy (GPL
|
2020-09-28 03:58:34 -04:00
|
|
|
|
without a version) and when you have multiple License-related classifiers it is
|
|
|
|
|
not clear if this is a choice or all these apply and which ones. Furthermore,
|
2020-09-30 10:13:58 -04:00
|
|
|
|
the list of available license-related classifiers is often out-of-date.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
In the PyPA ``sampleproject``
|
|
|
|
|
-----------------------------
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
The latest PyPA ``sampleproject`` recommends only to use classifiers in
|
|
|
|
|
``setup.py`` and does not list the ``license`` field in its example
|
|
|
|
|
``setup.py`` [#samplesetup]_.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
The License Files in wheels and setuptools
|
2020-09-28 03:58:34 -04:00
|
|
|
|
------------------------------------------
|
|
|
|
|
|
|
|
|
|
Beyond a license code or qualifier, license text files are documented and
|
|
|
|
|
included in a built package either implicitly or explicitly and this is another
|
|
|
|
|
possible source of confusion:
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- In wheels [#wheels]_ license files are automatically added to the ``.dist-info``
|
2020-09-28 03:58:34 -04:00
|
|
|
|
directory if they match one of a few common license file name patterns (such
|
|
|
|
|
as LICENSE*, COPYING*). Alternatively a package author can specify a list of
|
|
|
|
|
license files paths to include in the built wheel using in the
|
2020-09-30 10:13:58 -04:00
|
|
|
|
``license_files`` field in the ``[metadata]`` section of the project's
|
|
|
|
|
``setup.cfg``. Previously this was a (singular) ``license_file`` file attribute
|
2020-09-28 03:58:34 -04:00
|
|
|
|
that is now deprecated but is still in common use. See [#pipsetup]_ for
|
|
|
|
|
instance.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- In ``setuptools`` [#setuptoolssdist]_, a ``license_file`` attribute is used to add
|
2020-09-28 03:58:34 -04:00
|
|
|
|
a single license file to a source distribution. This singular version is
|
2020-09-30 10:13:58 -04:00
|
|
|
|
still honored by ``wheels`` for backward compatibility.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
- Using a LICENSE.txt file is encouraged in the packaging guide [#packaging]_
|
2020-09-30 10:13:58 -04:00
|
|
|
|
paired with a ``MANIFEST.in`` entry to ensure that the license file is included
|
2020-09-28 03:58:34 -04:00
|
|
|
|
in a built source distribution (sdist).
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
Note: the License-File field proposed in this PEP already exists in ``wheel`` and
|
|
|
|
|
``setuptools`` with the same behaviour as explained above. This PEP is only
|
|
|
|
|
recognizing and documenting the existing practice as used in ``wheel`` (with the
|
|
|
|
|
``license_file`` and ``license_files`` ``setup.cfg`` ``[metadata]`` entries) and in
|
|
|
|
|
``setuptools`` ``license_file`` ``setup()`` argument.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In Python code files
|
|
|
|
|
--------------------
|
|
|
|
|
|
|
|
|
|
(Note: Documenting licenses in source code is not in the scope of this PEP)
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
Beside using comments and/or ``SPDX-License-Identifier`` conventions, the license
|
2020-09-28 03:58:34 -04:00
|
|
|
|
is sometimes documented in Python code file using `dunder` variables typically
|
2020-09-30 10:13:58 -04:00
|
|
|
|
named after one of the lower cased Core metadata field such as ``__license__``
|
2020-09-28 03:58:34 -04:00
|
|
|
|
[#pycode]_.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
This convention (dunder global variables) is recognized by the built-in ``help()``
|
|
|
|
|
function and the standard ``pydoc`` module. The dunder variable(s) will show up in
|
|
|
|
|
the ``help()`` DATA section for a module.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In some other Python packaging tools
|
|
|
|
|
------------------------------------
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- `Conda package manifest` [#conda]_ has support for ``license`` and ``license_file``
|
|
|
|
|
fields as well as a ``license_family`` license grouping field.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- ``flit`` [#flit]_ recommends to use classifiers instead of License (as per the
|
2020-09-28 03:58:34 -04:00
|
|
|
|
current metadata spec).
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- ``pbr`` [#pbr]_ uses similar data as setuptools but always stored setup.cfg.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- ``poetry`` [#poetry]_ specifies the use of the ``license`` field in
|
|
|
|
|
``pyproject.toml`` with SPDX license identifiers.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Appendix 3. Surveying how other package formats document licenses
|
|
|
|
|
=================================================================
|
|
|
|
|
|
|
|
|
|
Here is a survey of how things are done elsewhere.
|
|
|
|
|
|
|
|
|
|
License in Linux distribution packages
|
|
|
|
|
---------------------------------------
|
|
|
|
|
|
|
|
|
|
Note: in most cases the license texts of the most common licenses are included
|
|
|
|
|
globally once in a shared documentation directory (e.g. /usr/share/doc).
|
|
|
|
|
|
|
|
|
|
- Debian document package licenses with machine readable copyright files
|
|
|
|
|
[#dep5]_. This specification defines its own license expression syntax that is
|
|
|
|
|
very similar to the SDPX syntax and use its own list of license identifiers
|
2020-09-30 10:13:58 -04:00
|
|
|
|
for common licenses also closely related to SPDX identifiers.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- Fedora RPM packages [#fedora]_ specifies how to include ``License Texts``
|
|
|
|
|
[#fedoratext]_ and how use a ``License`` field [#fedoralic]_ that must be filled
|
2020-09-28 03:58:34 -04:00
|
|
|
|
with an appropriate license Short License identifier(s) from an extensive list
|
2020-10-16 15:39:49 -04:00
|
|
|
|
of "Good Licenses" identifiers [#fedoralist]_. Fedora also defines its own
|
2020-09-28 03:58:34 -04:00
|
|
|
|
license expression syntax very similar to the SDPX syntax.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- OpenSuse RPMs packages [#opensuse]_ use SPDX license expressions with a
|
|
|
|
|
either SPDX license identifiers and a list of extra license identifiers
|
|
|
|
|
[#opensuselist]_.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- Gentoo ebuild use a ``LICENSE`` variable [#gentoo]_. This field is specified
|
|
|
|
|
in GLEP-0023 [#glep23]_ and in the Gentoo development manual [#gentoodev]_.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
Gentoo also defines a license expressions syntax and a list of allowed
|
|
|
|
|
licenses. The expression syntax is rather different from SPDX.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- FreeBSD package Makefile [#freebsd]_ provide a ``LICENSE`` and a
|
|
|
|
|
``LICENSE_FILE`` field with a list of custom license symbols. For
|
|
|
|
|
non-standard licenses, FreeBSD recommend to use ``LICENSE=UNKNOWN`` and add
|
|
|
|
|
``LICENSE_NAME`` and ``LICENSE_TEXT`` fields, as well as sophisticated
|
|
|
|
|
``LICENSE_PERMS`` to qualify the license permissions and ``LICENSE_GROUPS``
|
|
|
|
|
to document a license grouping. The ``LICENSE_COMB`` allows to document more
|
|
|
|
|
than one license and how they apply together, forming a custom license
|
|
|
|
|
expression syntax. FreeBSD also recommends the use of
|
|
|
|
|
``SPDX-License-Identifier`` in source code files.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
- Archlinux PKGBUILD [#archinux]_ define its own license identifiers
|
2020-09-30 10:13:58 -04:00
|
|
|
|
[#archlinuxlist]_. The value ``'unknown'`` can be used if the license is not
|
|
|
|
|
defined.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- OpenWRT ipk packages [#openwrt]_ use the ``PKG_LICENSE`` and
|
|
|
|
|
``PKG_LICENSE_FILES`` variables and recommend the use of SPDX License
|
|
|
|
|
identifiers.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
- NixOS uses SPDX identifiers [#nixos]_ and some extras license identifiers in
|
|
|
|
|
its license field.
|
|
|
|
|
|
|
|
|
|
- GNU Guix (based on NixOS) has a single License field, uses its own license
|
|
|
|
|
symbols list [#guix]_ and specifies to use one license or a list of licenses
|
|
|
|
|
[#guixlic]_.
|
|
|
|
|
|
|
|
|
|
- Alpine Linux apk packages [#alpine]_ recommend using SPDX identifiers in its
|
|
|
|
|
license field.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
License in Language and Application packages
|
|
|
|
|
--------------------------------------------
|
|
|
|
|
|
|
|
|
|
- In Java, Maven POM [#maven]_ defines a licenses XML tag with a list of license
|
|
|
|
|
items each with a name, URL, comments and "distribution" type. This is not
|
|
|
|
|
mandatory and the content of each field is not specified.
|
|
|
|
|
|
|
|
|
|
- JavaScript npm package.json [#npm]_ use a single license field with SPDX
|
2020-09-30 10:13:58 -04:00
|
|
|
|
license expression or the ``UNLICENSED`` id if no license is specified.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
A license file can be referenced as an alternative using "SEE LICENSE IN
|
2020-09-30 10:13:58 -04:00
|
|
|
|
<filename>" in the single ``license`` field.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
- Rubygems gemspec [#gem]_ specifies either a singular license string for a list
|
|
|
|
|
of licenses strings. The relationship between multiple licenses in a list is
|
2020-09-30 10:13:58 -04:00
|
|
|
|
not specified. They recommend using SPDX license identifiers.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
- CPAN Perl modules [#perl]_ use a single license field which is either a single
|
|
|
|
|
string or a list of strings. The relationship between the licenses in a list
|
|
|
|
|
is not specified. There is a list of support own license identifiers plus
|
2020-09-30 10:13:58 -04:00
|
|
|
|
these generic identifiers: ``open_source``, ``restricted``, ``unrestricted``,
|
|
|
|
|
``unknown``.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
- Rust Cargo [#cargo]_ specifies the use of an SPDX license expression (v2.1) in
|
2020-09-30 10:13:58 -04:00
|
|
|
|
the ``license`` field. It also supports an alternative expression syntax using
|
|
|
|
|
slash-separated SPDX license identifiers. There is also a ``license_file``
|
|
|
|
|
field. The crates.io package registry [#cratesio]_ requires that either
|
|
|
|
|
``license`` or ``license_file`` fields are set when you upload a package.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- PHP Composer composer.json [#composer]_ uses a ``license`` field with an SPDX
|
|
|
|
|
License id or "proprietary". The ``license`` field is either a single string
|
2020-09-28 03:58:34 -04:00
|
|
|
|
that can use something which resemble the SPDX license expression syntax with
|
|
|
|
|
"and" and "or" keywords; or this is a list of strings if there is a choice of
|
|
|
|
|
licenses (aka. a "disjunctive" choice of license).
|
|
|
|
|
|
|
|
|
|
- NuGet packages [#nuget]_ were using only a simple license URL and are now
|
|
|
|
|
specifying to use an SPDX License expression and/or the path to a license
|
|
|
|
|
file within the package. The NuGet.org repository states that they only
|
|
|
|
|
accepts license expressions that are `approved by the Open Source Initiative
|
|
|
|
|
or the Free Software Foundation.`
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- Go language modules ``go.mod`` have no provision for any metadata beyond
|
2020-09-28 03:58:34 -04:00
|
|
|
|
dependencies. Licensing information is left for code authors and other
|
|
|
|
|
community package managers to document.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- Dart/Flutter spec [#flutter]_ recommends to use a single ``LICENSE`` file
|
|
|
|
|
that should contain all the license texts each separated by a line with 80
|
2020-09-28 03:58:34 -04:00
|
|
|
|
hyphens.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- JavaScript Bower [#bower]_ ``license`` field is either a single string or a list
|
2020-09-28 03:58:34 -04:00
|
|
|
|
of strings using either SPDX license identifiers, a path or a URL to a
|
|
|
|
|
license file.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- Cocoapods podspec [#cocoapod]_ ``license`` field is either a single string or a
|
2020-09-28 03:58:34 -04:00
|
|
|
|
mapping with attributes of type, file and text keys. This is mandatory unless
|
|
|
|
|
there is a LICENSE or LICENCE file provided.
|
|
|
|
|
|
|
|
|
|
- Haskell Cabal [#cabal]_ accepts an SPDX license expression since version 2.2.
|
2020-09-30 10:13:58 -04:00
|
|
|
|
The version of the SPDX license list used is a function of the ``cabal`` version.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
The specification also provides a mapping between pre-SPDX Legacy license
|
2020-09-30 10:13:58 -04:00
|
|
|
|
Identifiers and SPDX identifiers. Cabal also specifies a ``license-file(s)``
|
|
|
|
|
field that lists license files that will be installed with the package.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- Erlang/Elixir mix/hex package [#mix]_ specifies a ``licenses`` field as a
|
|
|
|
|
required list of license strings and recommends to use SPDX License
|
|
|
|
|
identifiers.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
- D lang dub package [#dub]_ defines its own list of license identifiers and
|
|
|
|
|
its own license expression syntax and both are similar to SPDX the conventions.
|
|
|
|
|
|
|
|
|
|
- R Package DESCRIPTION [#cran]_ defines its own sophisticated license
|
2020-09-30 10:13:58 -04:00
|
|
|
|
expression syntax and list of licenses identifiers. R has a unique way to
|
|
|
|
|
support specifiers for license versions such as ``LGPL (>= 2.0, < 3)`` in its
|
|
|
|
|
license expression syntax.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Conventions used by other ecosystems
|
|
|
|
|
------------------------------------
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- ``SPDX-License-Identifier`` [#spdxids]_ is a simple convention to document the
|
2020-09-28 03:58:34 -04:00
|
|
|
|
license inside a code file.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- The Free Software Foundation (FSF) promotes using SPDX license identifiers
|
|
|
|
|
for clarity in the GPL and other versioned free software licenses [#gnu]_
|
|
|
|
|
[#fsf]_.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
- The Free Software Foundation Europe (FSFE) REUSE project [#reuse]_ promotes
|
2020-09-30 10:13:58 -04:00
|
|
|
|
using ``SPDX-License-Identifier``.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- The Linux kernel uses ``SPDX-License-Identifier`` and parts of the FSFE REUSE
|
2020-09-28 03:58:34 -04:00
|
|
|
|
conventions to document its licenses [#linux]_.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- U-Boot spearheaded using ``SPDX-License-Identifier`` in code and now follows the
|
2020-09-28 03:58:34 -04:00
|
|
|
|
Linux ways [#uboot]_.
|
|
|
|
|
|
|
|
|
|
- The Apache Software Foundation projects use RDF DOAP [#apache]_ with a single
|
2020-09-30 10:13:58 -04:00
|
|
|
|
license field pointing to SPDX license identifiers.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- The Eclipse Foundation promotes using ``SPDX-license-Identifiers`` [#eclipse]_
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- The ClearlyDefined project [#cd]_ promotes using SPDX license identifiers and
|
2020-09-28 03:58:34 -04:00
|
|
|
|
expressions to improve license clarity.
|
|
|
|
|
|
2020-09-30 10:13:58 -04:00
|
|
|
|
- The Android Open Source Project [#android]_ use ``MODULE_LICENSE_XXX`` empty
|
|
|
|
|
tag files where ``XXX`` is a license code such as BSD, APACHE, GPL, etc. And
|
|
|
|
|
side-by-side with this ``MODULE_LICENSE`` file there is a ``NOTICE`` file
|
|
|
|
|
that contains license and notices texts.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
References
|
|
|
|
|
==========
|
|
|
|
|
|
|
|
|
|
This document specifies version 2.2 of the metadata format.
|
|
|
|
|
|
|
|
|
|
- Version 1.0 is specified in PEP 241.
|
|
|
|
|
- Version 1.1 is specified in PEP 314.
|
|
|
|
|
- Version 1.2 is specified in PEP 345.
|
|
|
|
|
- Version 2.0, while not formally accepted, was specified in PEP 426.
|
|
|
|
|
- Version 2.1 is specified in PEP 566.
|
|
|
|
|
|
|
|
|
|
.. [#cms] https://packaging.python.org/specifications/core-metadata
|
|
|
|
|
.. [#cdstats] https://clearlydefined.io/stats
|
|
|
|
|
.. [#cd] https://clearlydefined.io
|
|
|
|
|
.. [#osi] http://opensource.org
|
|
|
|
|
.. [#classif] https://pypi.org/classifiers
|
|
|
|
|
.. [#spdxlist] https://spdx.org/licenses
|
|
|
|
|
.. [#spdx] https://spdx.org
|
|
|
|
|
.. [#spdx22] https://spdx.github.io/spdx-spec/appendix-IV-SPDX-license-expressions/
|
|
|
|
|
.. [#wheels] https://github.com/pypa/wheel/blob/b8b21a5720df98703716d3cd981d8886393228fa/docs/user_guide.rst#including-license-files-in-the-generated-wheel-file
|
|
|
|
|
.. [#reuse] https://reuse.software/
|
|
|
|
|
.. [#licexp] https://github.com/nexB/license-expression/
|
|
|
|
|
.. [#spdxpy] https://github.com/spdx/tools-python/
|
|
|
|
|
.. [#scancodetk] https://github.com/nexB/scancode-toolkit
|
|
|
|
|
.. [#licfield] https://packaging.python.org/guides/distributing-packages-using-setuptools/?highlight=MANIFEST.in#license
|
|
|
|
|
.. [#samplesetup] https://github.com/pypa/sampleproject/blob/52966defd6a61e97295b0bb82cd3474ac3e11c7a/setup.py#L98
|
|
|
|
|
.. [#pipsetup] https://github.com/pypa/pip/blob/476606425a08c66b9c9d326994ff5cf3f770926a/setup.cfg#L40
|
|
|
|
|
.. [#setuptoolssdist] https://github.com/pypa/setuptools/blob/97e8ad4f5ff7793729e9c8be38e0901e3ad8d09e/setuptools/command/sdist.py#L202
|
|
|
|
|
.. [#packaging] https://packaging.python.org/guides/distributing-packages-using-setuptools/?highlight=MANIFEST.in#license-txt
|
|
|
|
|
.. [#pycode] https://github.com/search?l=Python&q=%22__license__%22&type=Code
|
|
|
|
|
.. [#setuptools5030] https://github.com/pypa/setuptools/blob/v50.3.0/setup.cfg#L17
|
|
|
|
|
.. [#packlic] https://github.com/pypa/packaging/blob/19.1/LICENSE
|
|
|
|
|
.. [#conda] https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#about-section
|
|
|
|
|
.. [#flit] https://github.com/takluyver/flit
|
|
|
|
|
.. [#poetry] https://poetry.eustace.io/docs/pyproject/#license
|
|
|
|
|
.. [#pbr] https://docs.openstack.org/pbr/latest/user/features.html
|
|
|
|
|
.. [#dep5] https://dep-team.pages.debian.net/deps/dep5/
|
|
|
|
|
.. [#fedora] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/
|
|
|
|
|
.. [#fedoratext] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text
|
|
|
|
|
.. [#fedoralic] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_valid_license_short_names
|
|
|
|
|
.. [#fedoralist] https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses
|
|
|
|
|
.. [#opensuse] https://en.opensuse.org/openSUSE:Packaging_guidelines#Licensing
|
|
|
|
|
.. [#opensuselist] https://docs.google.com/spreadsheets/d/14AdaJ6cmU0kvQ4ulq9pWpjdZL5tkR03exRSYJmPGdfs/pub
|
|
|
|
|
.. [#gentoo] https://devmanual.gentoo.org/ebuild-writing/variables/index.html#license
|
|
|
|
|
.. [#glep23] https://www.gentoo.org/glep/glep-0023.html
|
|
|
|
|
.. [#gentoodev] https://devmanual.gentoo.org/general-concepts/licenses/index.html
|
|
|
|
|
.. [#freebsd] https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/licenses.html
|
|
|
|
|
.. [#archinux] https://wiki.archlinux.org/index.php/PKGBUILD#license
|
|
|
|
|
.. [#archlinuxlist] https://wiki.archlinux.org/index.php/PKGBUILD#license
|
|
|
|
|
.. [#openwrt] https://openwrt.org/docs/guide-developer/packages#buildpackage_variables
|
|
|
|
|
.. [#nixos] https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix
|
|
|
|
|
.. [#guix] http://git.savannah.gnu.org/cgit/guix.git/tree/guix/licenses.scm
|
|
|
|
|
.. [#guixlic] https://guix.gnu.org/manual/en/html_node/package-Reference.html#index-license_002c-of-packages
|
|
|
|
|
.. [#alpine] https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#license
|
|
|
|
|
.. [#maven] https://maven.apache.org/pom.html#Licenses
|
|
|
|
|
.. [#npm] https://docs.npmjs.com/files/package.json#license
|
|
|
|
|
.. [#gem] https://guides.rubygems.org/specification-reference/#license=
|
|
|
|
|
.. [#perl] https://metacpan.org/pod/CPAN::Meta::Spec#license
|
|
|
|
|
.. [#cargo] https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata
|
|
|
|
|
.. [#cratesio] https://doc.rust-lang.org/cargo/reference/registries.html#publish
|
|
|
|
|
.. [#composer] https://getcomposer.org/doc/04-schema.md#license
|
|
|
|
|
.. [#nuget] https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl
|
|
|
|
|
.. [#flutter] https://flutter.dev/docs/development/packages-and-plugins/developing-packages#adding-licenses-to-the-license-file
|
|
|
|
|
.. [#bower] https://github.com/bower/spec/blob/master/json.md#license
|
|
|
|
|
.. [#cocoapod] https://guides.cocoapods.org/syntax/podspec.html#license
|
|
|
|
|
.. [#cabal] https://cabal.readthedocs.io/en/latest/developing-packages.html#pkg-field-license
|
|
|
|
|
.. [#mix] https://hex.pm/docs/publish
|
|
|
|
|
.. [#dub] https://dub.pm/package-format-json.html#licenses
|
|
|
|
|
.. [#cran] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Licensing
|
|
|
|
|
.. [#spdxids] https://spdx.org/using-spdx-license-identifier
|
|
|
|
|
.. [#gnu] https://www.gnu.org/licenses/identify-licenses-clearly.html
|
|
|
|
|
.. [#fsf] https://www.fsf.org/blogs/rms/rms-article-for-claritys-sake-please-dont-say-licensed-under-gnu-gpl-2
|
|
|
|
|
.. [#linux] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst
|
|
|
|
|
.. [#uboot] https://www.denx.de/wiki/U-Boot/Licensing
|
|
|
|
|
.. [#apache] https://svn.apache.org/repos/asf/allura/doap_Allura.rdf
|
|
|
|
|
.. [#eclipse] https://www.eclipse.org/legal/epl-2.0/faq.php
|
|
|
|
|
.. [#android] https://github.com/aosp-mirror/platform_external_tcpdump/blob/master/MODULE_LICENSE_BSD
|
|
|
|
|
.. [#cc0] https://creativecommons.org/publicdomain/zero/1.0/
|
|
|
|
|
.. [#unlic] https://unlicense.org/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Copyright
|
|
|
|
|
=========
|
|
|
|
|
|
|
|
|
|
This document is placed in the public domain or under the CC0-1.0-Universal
|
2020-09-30 10:13:58 -04:00
|
|
|
|
license [#cc0]_, whichever is more permissive.
|
2020-09-28 03:58:34 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Acknowledgements
|
|
|
|
|
================
|
|
|
|
|
|
|
|
|
|
- Nick Coghlan
|
|
|
|
|
- Kevin P. Fleming
|
|
|
|
|
- Pradyun Gedam
|
|
|
|
|
- Oleg Grenrus
|
|
|
|
|
- Dustin Ingram
|
|
|
|
|
- Chris Jerdonek
|
|
|
|
|
- Cyril Roelandt
|
|
|
|
|
- Luis Villa
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
..
|
|
|
|
|
Local Variables:
|
|
|
|
|
mode: indented-text
|
|
|
|
|
indent-tabs-mode: nil
|
|
|
|
|
sentence-end-double-space: t
|
|
|
|
|
fill-column: 80
|
|
|
|
|
End:
|