PEP 639: Changes for clarity and consistency (#1780)
This commit is contained in:
Kevin P. Fleming
GitHub
parent
476f8b8703
commit
faf6247812
288
pep-0639.rst
288
pep-0639.rst
|
|
@ -25,8 +25,8 @@ PEP 566.
|
|||
|
||||
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
|
||||
ambiguous:
|
||||
SPDX license identifiers [#spdxlist]_ such that license documentation is simpler
|
||||
and less ambiguous:
|
||||
|
||||
- for package authors to create,
|
||||
- for package users to read and understand, and,
|
||||
|
|
@ -49,48 +49,48 @@ distribution:
|
|||
- 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
|
||||
in use in some tools (e.g. by adding the ``Licence-File`` field already used in
|
||||
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 in use
|
||||
in some tools (e.g. by adding the ``License-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).
|
||||
|
||||
In addition to an update to the metadata specification, this PEP contains:
|
||||
|
||||
- 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.
|
||||
- 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.
|
||||
|
||||
- informational appendixes that contain surveys of how we document licenses
|
||||
- informational appendices that contain surveys of how we document licenses
|
||||
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.
|
||||
implement the recommendations for validation and warnings specified in this PEP.
|
||||
|
||||
|
||||
Non-Goals
|
||||
=========
|
||||
|
||||
This PEP is neutral regarding the choice of various licenses.
|
||||
This PEP is neutral regarding the choice of license by any package author.
|
||||
|
||||
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.
|
||||
simpler and more expressive conventions to document accurately any kind of
|
||||
license that applies to a Python package, whether it is an open source license,
|
||||
a free or libre software license, a proprietary license, or a combination of
|
||||
such licenses.
|
||||
|
||||
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
|
||||
restrictions when uploading to PyPI.
|
||||
This PEP makes no recommendation for specific licenses and does not require the
|
||||
use of specific license documentation conventions. This PEP also does not impose
|
||||
any restrictions when uploading to PyPI.
|
||||
|
||||
Instead, this PEP is intended to document common practices already in use,
|
||||
and recommends that publishing tools should encourage users via informational
|
||||
Instead, this PEP is intended to document common practices already in use, and
|
||||
recommends that publishing tools should encourage users via informational
|
||||
warnings when they do not follow this PEP's recommendations.
|
||||
|
||||
This PEP is not about documenting license in code files, even though this is a
|
||||
surveyed topic in the appendix.
|
||||
This PEP is not about license documentation in files inside packages, even
|
||||
though this is a surveyed topic in the appendix.
|
||||
|
||||
|
||||
Possible future PEPs
|
||||
|
|
@ -109,16 +109,16 @@ related but separate PEPs in the future such as:
|
|||
Motivation
|
||||
==========
|
||||
|
||||
Software is licensed and providing accurate licensing information to Python
|
||||
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.
|
||||
licenses are 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:
|
||||
Several package authors have expressed difficulty and/or frustrations due to the
|
||||
limited capabilities to express licensing in package metadata. This also applies
|
||||
to Linux and BSD* distribution packagers. This has triggered several
|
||||
license-related discussions and issues, in particular:
|
||||
|
||||
- https://github.com/pypa/trove-classifiers/issues/17
|
||||
- https://github.com/pypa/interoperability-peps/issues/46
|
||||
|
|
@ -126,7 +126,7 @@ discussions and issues and in particular:
|
|||
- 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
|
||||
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.
|
||||
|
|
@ -137,7 +137,7 @@ source projects that is incubating at the OSI (Open Source Initiative) [#osi]_.
|
|||
Rationale
|
||||
=========
|
||||
|
||||
A mini survey of existing license metadata definitions in use in the Python
|
||||
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.
|
||||
|
||||
|
|
@ -146,18 +146,18 @@ There are a few takeaways from the survey:
|
|||
- Most package formats use a single ``License`` field.
|
||||
|
||||
- Many modern package formats use some form of license expression syntax to
|
||||
optionally combine more than one license identifiers together. SPDX and
|
||||
optionally combine more than one license identifier together. SPDX and
|
||||
SPDX-like syntaxes are the most popular in use.
|
||||
|
||||
- SPDX license identifiers are becoming a de-facto way to reference common licenses
|
||||
everywhere, whether or not a license expression syntax is used.
|
||||
- SPDX license identifiers are becoming a de facto way to reference common
|
||||
licenses 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.
|
||||
- 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 package authors to include their full
|
||||
text in a distribution.
|
||||
|
||||
These considerations have guided the design and recommendations of this PEP.
|
||||
These considerations have guided the design and recommendations of this PEP.
|
||||
|
||||
The reuse of the ``License`` field with license expressions will provide an
|
||||
intuitive and more structured way to express the license of a distribution using
|
||||
|
|
@ -165,7 +165,7 @@ a well-defined syntax and well-known license identifiers.
|
|||
|
||||
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.
|
||||
package authors, consumers and redistributors.
|
||||
|
||||
|
||||
Core Metadata Specification updates
|
||||
|
|
@ -175,7 +175,7 @@ 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
|
||||
document as part of this PEP are described here and will be added to the
|
||||
canonical source once this PEP is approved.
|
||||
|
||||
|
||||
|
|
@ -185,8 +185,8 @@ Added in Version 2.2
|
|||
License-File (multiple use)
|
||||
:::::::::::::::::::::::::::
|
||||
|
||||
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.
|
||||
The License-File is a string that is a path, relative to``.dist-info``, to a
|
||||
license file. The license file content MUST be UTF-8 encoded text.
|
||||
|
||||
Build tools SHOULD honor this field and include the corresponding license
|
||||
file(s) in the built package.
|
||||
|
|
@ -218,31 +218,34 @@ When used in the ``License`` field and as a specialization of the SPDX license
|
|||
expression definition, a license expression can use the following license
|
||||
identifiers:
|
||||
|
||||
- any SPDX-listed license short-form identifiers that are published in the
|
||||
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
|
||||
license identifiers: instead they may only mark an identifier as "obsolete".
|
||||
- any SPDX-listed license short-form identifiers that are published in the SPDX
|
||||
License List [#spdxlist]_ using either Version 3.10 or any later compatible
|
||||
version. Note that the SPDX working group never removes any license
|
||||
identifiers: instead they may choose to mark an identifier as "deprecated".
|
||||
|
||||
- the ``LicenseRef-Public-Domain`` and ``LicenseRef-Proprietary`` strings to support
|
||||
generic identifiers that are not available in the SPDX license list.
|
||||
- the ``LicenseRef-Public-Domain`` and ``LicenseRef-Proprietary`` strings to
|
||||
identify licenses that are not included in the SPDX license list.
|
||||
|
||||
When processing the ``License`` field to determine if it contains a valid license
|
||||
expression, tools:
|
||||
When processing the ``License`` field to determine if it contains a valid
|
||||
license expression, tools:
|
||||
|
||||
- MUST ignore the case of the ``License`` field
|
||||
|
||||
- SHOULD report an informational warning if one or more of the following applies:
|
||||
- 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]_
|
||||
|
||||
- SHOULD store a case-normalized version of the ``License`` field using the
|
||||
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.
|
||||
and WITH keywords.
|
||||
|
||||
- SHOULD report an informational warning if normalization process results in
|
||||
changes to the ``License`` field contents.
|
||||
|
||||
License expression examples::
|
||||
|
||||
|
|
@ -272,12 +275,12 @@ Examples::
|
|||
Classifier: Development Status :: 4 - Beta
|
||||
Classifier: Environment :: Console (Text Based)
|
||||
|
||||
Tools SHOULD issue an informational warning if this field contains a licensing
|
||||
Tools SHOULD issue an informational warning if this field contains a licensing-
|
||||
related classifier string starting with the ``License ::`` prefix and SHOULD
|
||||
suggest the use of a license expression in the ``License`` field instead.
|
||||
|
||||
If the ``License`` field is present and contains a valid license expression,
|
||||
publishing tools MUST NOT also provide any licensing related classifier entries
|
||||
publishing tools MUST NOT also provide any licensing-related classifier entries
|
||||
[#classif]_.
|
||||
|
||||
However, for compatibility with existing publishing and installation processes,
|
||||
|
|
@ -287,17 +290,17 @@ licensing-related classifier entries SHOULD continue to be accepted if the
|
|||
Publishing tools MAY infer a license expression from the provided classifier
|
||||
entries if they are able to do so unambiguously.
|
||||
|
||||
However, no new licensing related classifiers will be added, with anyone
|
||||
requesting them being directed to use a license expression in the ``License``
|
||||
field instead. Note that the licensing related classifiers may be deprecated in
|
||||
However, no new licensing related classifiers will be added; anyone
|
||||
requesting them will be directed to use a license expression in the ``License``
|
||||
field instead. Note that the licensing-related classifiers may be deprecated in
|
||||
a future PEP.
|
||||
|
||||
|
||||
Mapping Legacy Classifiers to New License Expressions
|
||||
'''''''''''''''''''''''''''''''''''''''''''''''''''''
|
||||
|
||||
Publishing tools MAY infer or suggest an equivalent license expression from
|
||||
the provided ``License`` or ``Classifier`` information if they are able to do so
|
||||
Publishing tools MAY infer or suggest an equivalent license expression from the
|
||||
provided ``License`` or ``Classifier`` information if they are able to do so
|
||||
unambiguously. For instance, if a package only has this license classifier::
|
||||
|
||||
Classifier: License :: OSI Approved :: MIT License
|
||||
|
|
@ -308,20 +311,20 @@ expression to suggest would be::
|
|||
License: MIT
|
||||
|
||||
|
||||
Here are mappings guidelines for the legacy classifiers:
|
||||
Here are mapping guidelines for the legacy classifiers:
|
||||
|
||||
- Classifier ``License :: Other/Proprietary License`` becomes License:
|
||||
``LicenseRef-Proprietary`` expression.
|
||||
|
||||
- Classifier ``License :: Public Domain`` becomes License: ``LicenseRef-Public-Domain``
|
||||
expression, though tools should encourage the use of more explicit and legally
|
||||
portable licenses identifiers such as ``CC0-1.0`` [#cc0]_, the ``Unlicense``
|
||||
[#unlic]_: the meaning associated with the term "public domain" is thoroughly
|
||||
portable license identifiers such as ``CC0-1.0`` [#cc0]_, the ``Unlicense``
|
||||
[#unlic]_ since 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.
|
||||
|
||||
- The generic and ambiguous classifiers ``License :: OSI Approved``
|
||||
and ``License :: DFSG approved`` do not have an equivalent license expression.
|
||||
- The generic and ambiguous classifiers ``License :: OSI Approved`` and
|
||||
``License :: DFSG approved`` do not have an equivalent license expression.
|
||||
|
||||
- The generic and sometimes ambiguous classifiers
|
||||
``License :: Free For Educational Use``, ``License :: Free For Home Use``,
|
||||
|
|
@ -333,13 +336,13 @@ Here are mappings guidelines for the legacy classifiers:
|
|||
for now and no package uses them in PyPI as of the writing of this PEP.
|
||||
|
||||
The remainder of the classifiers using a ``License ::`` prefix map to a simple
|
||||
single license expression using the corresponding SPDX license identifiers.
|
||||
single-identifier license expression using the corresponding SPDX license identifiers.
|
||||
|
||||
When multiple license-related classifiers are used, their relation is
|
||||
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
|
||||
legacy classifier usage.
|
||||
When multiple license-related classifiers are used, their relation is 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 reliably infer a license expression and should suggest that the package
|
||||
author construct a license expression which expresses their intent.
|
||||
|
||||
|
||||
Summary of Differences From PEP 566
|
||||
|
|
@ -353,52 +356,52 @@ Summary of Differences From PEP 566
|
|||
Backwards Compatibility
|
||||
=======================
|
||||
|
||||
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
|
||||
support for that field.
|
||||
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 support for that field.
|
||||
|
||||
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.
|
||||
license-related classifiers means that we can gently prepare users for possible
|
||||
strict and incompatible validation of these fields in the future.
|
||||
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
How to Teach Users to Use License Expressions
|
||||
=============================================
|
||||
|
||||
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 simple cases are simple: a single license identifier 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
|
||||
the ``Classifier`` field.
|
||||
The plan to teach users of packaging tools how to express their package's
|
||||
license with a valid license expression is to have tools issue informative
|
||||
messages when they detect invalid license expressions or when a license-related
|
||||
classifier is used in the ``Classifier`` field.
|
||||
|
||||
With a warning message that does not terminate processing, publishing tools will
|
||||
gently teach users on how to provide correct license expressions over time.
|
||||
gently teach users how to provide correct license expressions over time.
|
||||
|
||||
Tools may also help with the conversion and suggest a license expression in some
|
||||
cases:
|
||||
|
||||
1. The section `Mapping Legacy Classifiers to New License expressions` provides
|
||||
tools authors with guidelines on how to suggest a license expression from
|
||||
legacy classifiers.
|
||||
tool authors with guidelines on how to suggest a license expression produced
|
||||
from legacy classifiers.
|
||||
|
||||
2. Tools may also be able to infer and suggest how to update an existing
|
||||
incorrect ``License`` value and convert that to a correct license expression.
|
||||
For instance a tool may suggest to correct a ``License`` field from ``Apache2``
|
||||
(which is not a valid license expression as defined in this PEP) to
|
||||
``Apache-2.0`` (which is a valid license expression using an SPDX license id as
|
||||
defined in this PEP).
|
||||
For instance a tool may suggest to correct a ``License`` field from
|
||||
``Apache2`` (which is not a valid license expression as defined in this PEP)
|
||||
to ``Apache-2.0`` (which is a valid license expression using an SPDX license
|
||||
identifier as defined in this PEP).
|
||||
|
||||
|
||||
Reference Implementation
|
||||
|
|
@ -408,48 +411,47 @@ Tools will need to support parsing and validating license expressions in the
|
|||
``License`` field.
|
||||
|
||||
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]_.
|
||||
implementation of 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]_.
|
||||
|
||||
|
||||
Rejected ideas
|
||||
==============
|
||||
|
||||
1. use a new ``License-Expression`` field and deprecate the ``License`` field.
|
||||
1. Use a new ``License-Expression`` field and deprecate the ``License`` field.
|
||||
|
||||
Adding a new field would introduce backward incompatible changes when the
|
||||
``License`` field would be retired later and require to have a more complex
|
||||
``License`` field would be retired later and require having more complex
|
||||
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
|
||||
is not seen anywhere else in any other package metadata (e.g. a new 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
|
||||
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
|
||||
A mapping would be needed as you cannot guarantee that all expressions (e.g.
|
||||
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.
|
||||
an Apache license ``LICENSE`` and its ``NOTICE`` file for instance are two
|
||||
distinct file). Yet in most cases, there is a simpler `one license`, `one or
|
||||
distinct files). 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
|
||||
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
|
||||
identifier, but you are not forcing the more complex data model (e.g. a mapping)
|
||||
on everyone that may not need it.
|
||||
|
||||
We could of course have data field with multiple possible value types (it’s a
|
||||
We could of course have a 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
|
||||
|
|
@ -457,11 +459,11 @@ 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
|
||||
3. Mapping licenses to specific source files and/or directories of source files
|
||||
(or vice versa).
|
||||
|
||||
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
|
||||
existing ``SPDX-License-Identifier`` [#spdxids]_ convention can be used and
|
||||
may not need further specification as a PEP.
|
||||
|
||||
|
||||
|
|
@ -483,22 +485,22 @@ The simplest migration to this PEP would consist of using this instead::
|
|||
LICENSE
|
||||
|
||||
Another possibility would be to include the licenses of the third-party packages
|
||||
bundled in that are vendored in the ``setuptools/_vendor/`` and
|
||||
``pkg_resources/_vendor`` directories::
|
||||
that are vendored in the ``setuptools/_vendor/`` and ``pkg_resources/_vendor``
|
||||
directories::
|
||||
|
||||
appdirs==1.4.3
|
||||
packaging==20.4
|
||||
pyparsing==2.2.1
|
||||
ordered-set==3.1.1
|
||||
|
||||
These are using these license expressions::
|
||||
These license expressions for these packages are::
|
||||
|
||||
appdirs: MIT
|
||||
packaging: Apache-2.0 OR BSD-2-Clause
|
||||
pyparsing: MIT
|
||||
ordered-set: MIT
|
||||
|
||||
Therefore, a comprehensive license documentation covering both ``setuptools`` proper
|
||||
Therefore, a comprehensive license expression covering both ``setuptools`` proper
|
||||
and its vendored packages could contain these metadata, combining all the
|
||||
license expressions in one expression::
|
||||
|
||||
|
|
@ -572,7 +574,7 @@ possible source of confusion:
|
|||
- In wheels [#wheels]_ license files are automatically added to the ``.dist-info``
|
||||
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
|
||||
license file paths to include in the built wheel using in the
|
||||
``license_files`` field in the ``[metadata]`` section of the project's
|
||||
``setup.cfg``. Previously this was a (singular) ``license_file`` file attribute
|
||||
that is now deprecated but is still in common use. See [#pipsetup]_ for
|
||||
|
|
@ -599,8 +601,8 @@ In Python code files
|
|||
(Note: Documenting licenses in source code is not in the scope of this PEP)
|
||||
|
||||
Beside using comments and/or ``SPDX-License-Identifier`` conventions, the license
|
||||
is sometimes documented in Python code file using `dunder` variables typically
|
||||
named after one of the lower cased Core metadata field such as ``__license__``
|
||||
is sometimes documented in Python code files using `dunder` variables typically
|
||||
named after one of the lower cased Core Metadata fields such as ``__license__``
|
||||
[#pycode]_.
|
||||
|
||||
This convention (dunder global variables) is recognized by the built-in ``help()``
|
||||
|
|
@ -637,25 +639,25 @@ 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
|
||||
for common licenses also closely related to SPDX identifiers.
|
||||
for common licenses (also closely related to SPDX identifiers).
|
||||
|
||||
- Fedora RPM packages [#fedora]_ specifies how to include ``License Texts``
|
||||
- Fedora packages [#fedora]_ specify how to include ``License Texts``
|
||||
[#fedoratext]_ and how use a ``License`` field [#fedoralic]_ that must be filled
|
||||
with an appropriate license Short License identifier(s) from an extensive list
|
||||
of "Good Licenses" identifiers [#fedoralist]_. Fedora also defines its own
|
||||
license expression syntax very similar to the SDPX syntax.
|
||||
|
||||
- OpenSuse RPMs packages [#opensuse]_ use SPDX license expressions with a
|
||||
either SPDX license identifiers and a list of extra license identifiers
|
||||
- openSUSE packages [#opensuse]_ use SPDX license expressions with
|
||||
SPDX license identifiers and a list of extra license identifiers
|
||||
[#opensuselist]_.
|
||||
|
||||
- Gentoo ebuild use a ``LICENSE`` variable [#gentoo]_. This field is specified
|
||||
- Gentoo ebuild uses a ``LICENSE`` variable [#gentoo]_. This field is specified
|
||||
in GLEP-0023 [#glep23]_ and in the Gentoo development manual [#gentoodev]_.
|
||||
Gentoo also defines a license expressions syntax and a list of allowed
|
||||
Gentoo also defines a license expression syntax and a list of allowed
|
||||
licenses. The expression syntax is rather different from SPDX.
|
||||
|
||||
- FreeBSD package Makefile [#freebsd]_ provide a ``LICENSE`` and a
|
||||
``LICENSE_FILE`` field with a list of custom license symbols. For
|
||||
- FreeBSD package Makefile [#freebsd]_ provides ``LICENSE`` and
|
||||
``LICENSE_FILE`` fields 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``
|
||||
|
|
@ -672,21 +674,21 @@ globally once in a shared documentation directory (e.g. /usr/share/doc).
|
|||
``PKG_LICENSE_FILES`` variables and recommend the use of SPDX License
|
||||
identifiers.
|
||||
|
||||
- NixOS uses SPDX identifiers [#nixos]_ and some extras license identifiers in
|
||||
- NixOS uses SPDX identifiers [#nixos]_ and some extra 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
|
||||
- Alpine Linux packages [#alpine]_ recommend using SPDX identifiers in the
|
||||
license field.
|
||||
|
||||
|
||||
License in Language and Application packages
|
||||
--------------------------------------------
|
||||
|
||||
- In Java, Maven POM [#maven]_ defines a licenses XML tag with a list of license
|
||||
- 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.
|
||||
|
||||
|
|
@ -695,13 +697,13 @@ License in Language and Application packages
|
|||
A license file can be referenced as an alternative using "SEE LICENSE IN
|
||||
<filename>" in the single ``license`` field.
|
||||
|
||||
- Rubygems gemspec [#gem]_ specifies either a singular license string for a list
|
||||
of licenses strings. The relationship between multiple licenses in a list is
|
||||
- Rubygems gemspec [#gem]_ specifies either a singular license string or a list
|
||||
of license strings. The relationship between multiple licenses in a list is
|
||||
not specified. They recommend using SPDX license identifiers.
|
||||
|
||||
- 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
|
||||
is not specified. There is a list of custom license identifiers plus
|
||||
these generic identifiers: ``open_source``, ``restricted``, ``unrestricted``,
|
||||
``unknown``.
|
||||
|
||||
|
|
@ -712,9 +714,9 @@ License in Language and Application packages
|
|||
``license`` or ``license_file`` fields are set when you upload a package.
|
||||
|
||||
- PHP Composer composer.json [#composer]_ uses a ``license`` field with an SPDX
|
||||
License id or "proprietary". The ``license`` field is either a single string
|
||||
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
|
||||
license id or "proprietary". The ``license`` field is either a single string
|
||||
that can use something which resembles the SPDX license expression syntax with
|
||||
"and" and "or" keywords; or 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
|
||||
|
|
@ -732,7 +734,7 @@ License in Language and Application packages
|
|||
hyphens.
|
||||
|
||||
- JavaScript Bower [#bower]_ ``license`` field is either a single string or a list
|
||||
of strings using either SPDX license identifiers, a path or a URL to a
|
||||
of strings using either SPDX license identifiers, or a path or a URL to a
|
||||
license file.
|
||||
|
||||
- Cocoapods podspec [#cocoapod]_ ``license`` field is either a single string or a
|
||||
|
|
@ -746,11 +748,11 @@ License in Language and Application packages
|
|||
field that lists license files that will be installed with the package.
|
||||
|
||||
- Erlang/Elixir mix/hex package [#mix]_ specifies a ``licenses`` field as a
|
||||
required list of license strings and recommends to use SPDX License
|
||||
required list of license strings and recommends to use SPDX license
|
||||
identifiers.
|
||||
|
||||
- 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.
|
||||
its own license expression syntax and both are similar to the SPDX conventions.
|
||||
|
||||
- R Package DESCRIPTION [#cran]_ defines its own sophisticated license
|
||||
expression syntax and list of licenses identifiers. R has a unique way to
|
||||
|
|
@ -762,9 +764,9 @@ Conventions used by other ecosystems
|
|||
------------------------------------
|
||||
|
||||
- ``SPDX-License-Identifier`` [#spdxids]_ is a simple convention to document the
|
||||
license inside a code file.
|
||||
license inside a file.
|
||||
|
||||
- The Free Software Foundation (FSF) promotes using SPDX license identifiers
|
||||
- The Free Software Foundation (FSF) promotes the use of SPDX license identifiers
|
||||
for clarity in the GPL and other versioned free software licenses [#gnu]_
|
||||
[#fsf]_.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue