From 594960418773f98eaa0ff3157be5a882ae9f7d0a Mon Sep 17 00:00:00 2001 From: CAM Gerlach Date: Tue, 19 Apr 2022 02:26:30 -0500 Subject: [PATCH] PEP 639: Update header, footer, link, reference and code block syntax (#2531) * PEP 639: Update header and footer in line with new PEP 1/12 guidance * PEP 639: Update implict references to use ref role * PEP 639: Remove spurious # from link targets and make anonymous * PEP 639: Format code blocks with appropriate syntax highlighting --- .github/CODEOWNERS | 2 +- pep-0639.rst | 800 +++++++++++++++++++++++++-------------------- 2 files changed, 455 insertions(+), 347 deletions(-) diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS index 78819bf92..5ac9e42e6 100644 --- a/.github/CODEOWNERS +++ b/.github/CODEOWNERS @@ -517,7 +517,7 @@ pep-0635.rst @brandtbucher @gvanrossum pep-0636.rst @brandtbucher @gvanrossum pep-0637.rst @stevendaprano pep-0638.rst @markshannon -pep-0639.rst @pfmoore @CAM-Gerlach +pep-0639.rst @CAM-Gerlach pep-0640.rst @Yhg1s pep-0641.rst @zooba @warsaw @brettcannon pep-0642.rst @ncoghlan diff --git a/pep-0639.rst b/pep-0639.rst index ea03b6dc5..7e98750c4 100644 --- a/pep-0639.rst +++ b/pep-0639.rst @@ -1,64 +1,66 @@ PEP: 639 Title: Improving License Clarity with Better Package Metadata -Version: $Revision$ -Last-Modified: $Date$ -Author: Philippe Ombredanne , - C.A.M. Gerlach -Sponsor: Paul Moore -PEP-Delegate: Brett Cannon +Author: Philippe Ombredanne , + C.A.M. Gerlach , +Sponsor: Paul Moore +PEP-Delegate: Brett Cannon Discussions-To: https://discuss.python.org/t/12622 Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 15-Aug-2019 -Post-History: 15-Aug-2019, 17-Dec-2021 -Resolution: +Post-History: `15-Aug-2019 `__, + `17-Dec-2021 `__ +.. _639-abstract: + Abstract ======== This PEP defines a specification for how licenses are documented in the -`core metadata <#coremetadataspec_>`_, -with `license expression strings `_ using -`SPDX identifiers <#spdxid_>`_ in a new ``License-Expression`` field. +`core metadata `__, with +:ref:`license expression strings <639-spec-field-license-expression>` using +`SPDX identifiers `__ in a new ``License-Expression`` field. This will make license declarations simpler and less ambiguous for package authors to create, end users to read and understand, and tools to programmatically process. The PEP also: -- `Formally specifies `_ a new ``License-File`` field, - and defines how license files should be - `included in distributions `_, +- :ref:`Formally specifies <639-spec-field-license-file>` + a new ``License-File`` field, and defines how license files should be + :ref:`included in distributions <639-spec-project-formats>`, as already used by the Wheel and Setuptools projects. -- `Deprecates `_ the legacy ``License`` field - and ``license ::`` classifiers. +- Deprecates the legacy ``License`` :ref:`field <639-spec-field-license>` + and ``license ::`` :ref:`classifiers <639-spec-field-classifier>`. -- `Adds and deprecates `_ the corresponding keys +- :ref:`Adds and deprecates <639-spec-source-metadata>` the corresponding keys in the :pep:`621` project source metadata format. -- `Provides clear guidance `_ for authors and +- :ref:`Provides clear guidance <639-spec-converting-metadata>` for authors and tools converting legacy license metadata, adding license files and validating license expressions. -- Describes a `reference implementation `_, - analyzes numerous `potential alternatives `_, - includes `detailed examples `_, - explains `user scenarios `_ and +- Describes a :ref:`reference implementation <639-reference-implementation>`, + analyzes numerous :ref:`potential alternatives <639-rejected-ideas>`, + includes :ref:`detailed examples <639-examples>`, + explains :ref:`user scenarios <639-user-scenarios>` and surveys license documentation - `in Python packaging `_ and - `other ecosystems `_. + :ref:`in Python packaging <639-license-doc-python>` and + :ref:`other ecosystems <639-license-doc-other-projects>`. The changes in this PEP will update the -`core metadata <#coremetadataspec>`_ to version 2.3, modify the -`PEP 621 project metadata specification <#pep621spec_>`_, -and make minor additions to the `source distribution (sdist) <#sdistspec_>`_, -`built distribution (wheel) <#wheelspec_>`_ and -`installed project <#installedspec_>`_ standards. +:`core metadata `__ to version 2.3, modify the +`PEP 621 project metadata specification `__, +and make minor additions to the `source distribution (sdist) `__, +`built distribution (wheel) `__ and +`installed project `__ standards. +.. _639-goals: + Goals ===== @@ -71,10 +73,10 @@ the license of a distribution package, specifically defining: The changes to the core metadata specification that this PEP requires have been designed to minimize impact and maximize backward compatibility. This specification builds off of existing ways to document licenses that are -already in use in popular tools (e.g. adding support to core metadata for -the ``License-File`` field `already used `_ in -the Wheel and Setuptools projects) and by some package authors (e.g. storing an -SPDX license expression in the existing ``License`` field). +already in use in popular tools (e.g. adding support to core metadata for the +``License-File`` field :ref:`already used <639-license-doc-setuptools-wheel>` +in the Wheel and Setuptools projects) and by some package authors +(e.g. storing an SPDX license expression in the existing ``License`` field). In addition to these proposed changes, this PEP contains guidance for tools handling and converting these metadata, a tutorial for package authors @@ -86,6 +88,8 @@ It is the intent of the PEP authors to work closely with tool maintainers to implement the recommendations for validation and warnings specified here. +.. _639-non-goals: + Non-Goals ========= @@ -106,12 +110,14 @@ to use a new formally-specified and supported mechanism, and provide guidance for packaging tools on how to hand the transition and inform users accordingly. This PEP also is not about license documentation in files inside projects, -though this is a `surveyed topic `_ in the appendix, -and nor does it intend to cover cases where the source and -binary distribution packages don't have -`the same licenses `_. +though this is a :ref:`surveyed topic <639-license-doc-source-files>` +in an appendix, and nor does it intend to cover cases where the source and +binary distribution packages don't have :ref:`the same licenses +<639-rejected-ideas-difference-license-source-binary>`. +.. _639-motivation: + Motivation ========== @@ -125,30 +131,32 @@ Many package authors have expressed difficulty and frustrations due to the limited capabilities to express licensing in project metadata, and this creates further trouble for Linux and BSD distribution re-packagers. This has triggered a number of license-related discussions and issues, -including on `outdated and ambiguous PyPI classifiers <#classifierissue_>`_, -`license interoperability with other ecosystems <#interopissue_>`_, -`too many confusing license metadata options <#packagingissue_>`_, -`limited support for license files in the Wheel project <#wheelfiles_>`_, and -`the lack of clear, precise and standardized license metadata <#pepissue_>`_. +including on `outdated and ambiguous PyPI classifiers `__, +`license interoperability with other ecosystems `__, +`too many confusing license metadata options `__, +`limited support for license files in the Wheel project `__, and +`the lack of clear, precise and standardized license metadata `__. On average, Python packages tend to have more ambiguous and missing license information than other common ecosystems (such as npm, Maven or -Gem). This is supported by the `statistics page <#cdstats_>`_ of the -`ClearlyDefined project <#clearlydefined_>`_, an -`Open Source Initiative <#osi_>`_ incubated effort to help +Gem). This is supported by the `statistics page `__ of the +`ClearlyDefined project `__, an +`Open Source Initiative `__ incubated effort to help improve licensing clarity of other FOSS projects, covering all packages from PyPI, Maven, npm and Rubygems. +.. _639-rationale: + Rationale ========= A survey of existing license metadata definitions in use in the Python ecosystem today is provided in -`an appendix `_ of this PEP, +:ref:`an appendix <639-license-doc-python>` of this PEP, and license documentation in a variety of other packaging systems, Linux distros, languages ecosystems and applications is surveyed in -`another appendix `_. +:ref:`another appendix <639-license-doc-other-projects>`. There are a few takeaways from the survey: @@ -206,6 +214,8 @@ practices, to the benefit of package authors, consumers and redistributors alike. +.. _639-terminology: + Terminology =========== @@ -219,9 +229,9 @@ distribution/built metadata, build vs. publishing tools), or are new concepts introduced here (e.g. license expression/identifier). This PEP also uses terms defined in the -`PyPA PyPUG Glossary <#pypugglossary_>`_ +`PyPA PyPUG Glossary `__ (specifically *built/binary distribution*, *distribution package*, -*project* and *source distribution*), and by the `SPDX Project <#spdx_>`_ +*project* and *source distribution*), and by the `SPDX Project `__ (*license identifier*, *license expression*). Terms are listed here in their full versions; @@ -230,7 +240,7 @@ including short forms (``Short:``), sub-terms (``Sub:``) and common synonyms for the purposes of this PEP (``Syn:``). **Core Metadata** *(Syn: Package Metadata, Sub: Distribution Metadata)* - The `PyPA specification <#coremetadataspec_>`_ and the set of metadata fields + The `PyPA specification `__ and the set of metadata fields it defines that describe key static attributes of distribution packages and installed projects. @@ -245,35 +255,35 @@ for the purposes of this PEP (``Syn:``). metadata format key. **Distribution Package** *(Sub: Package, Distribution Archive)* - (`See PyPUG <#pypugdistributionpackage_>`__) + (`See PyPUG `__) In this PEP, **package** is used to refer to the abstract concept of a distributable form of a Python project, while **distribution** more specifically references the physical **distribution archive**. **License Classifier** - A `PyPI Trove classifier <#classifiers_>`_ (as originally defined in + A `PyPI Trove classifier `__ (as originally defined in :pep:`301`) which begins with ``License ::``, currently used to indicate a project's license status by including it as a ``Classifier`` in the core metadata. **License Expression** *(Syn: SPDX Expression)* - A string with valid `SPDX license expression syntax <#spdxpression_>`_ + A string with valid `SPDX license expression syntax `__ including any SPDX license identifiers as defined here, which describes a project's license(s) and how they relate to one another. Examples: ``GPL-3.0-or-later``, ``MIT AND (Apache-2.0 OR BSD-2-clause)`` **License Identifier** *(Syn: License ID/SPDX Identifier)* - A valid `SPDX short-form license identifier <#spdxid_>`_, as described in the - `Add License-Expression field`_ section of this PEP; briefly, + A valid `SPDX short-form license identifier `__, as described in the + :ref:`639-spec-field-license-expression` section of this PEP; briefly, this includes all valid SPDX identifiers and the ``LicenseRef-Public-Domain`` and ``LicenseRef-Proprietary`` strings. Examples: ``MIT``, ``GPL-3.0-only`` **Project** *(Sub: Project Source Tree, Installed Project)* - (`See PyPUG <#pypugproject_>`__) + (`See PyPUG `__) Here, a **project source tree** refers to the on-disk format of a project used for development, while an **installed project** is the form a project takes once installed from a distribution, as - `specified by PyPA <#installedspec_>`_. + `specified by PyPA `__. **Project Source Metadata** *(Sub: PEP 621 Metadata, Key, Subkey)* Core metadata defined by the package author in the project source tree, @@ -282,7 +292,7 @@ for the purposes of this PEP (``Syn:``). build tools. The **PEP 621 metadata** refers specifically to the former, as defined by the - `PyPA Declaring Project Metadata specification <#pep621spec_>`_. + `PyPA Declaring Project Metadata specification `__. A **PEP 621 metadata key**, or an unqualified *key* refers specifically to a top-level ``[project]`` key (notably, *not* a core metadata *field*), while a **subkey** refers to a second-level key in a table-valued @@ -319,26 +329,28 @@ for the purposes of this PEP (``Syn:``). **Wheel** *(Short: wheel, Rel: wheel format, Wheel project)* Here, **wheel**, the standard built distribution format introduced in - :pep:`427` and `specified by PyPA <#wheelspec_>`_, will be referred to in - lowercase, while the `Wheel project <#wheelproject_>`_, its reference + :pep:`427` and `specified by PyPA `__, will be referred to in + lowercase, while the `Wheel project `__, its reference implementation, will be referred to as such with **Wheel** in Title Case. +.. _639-specification: + Specification ============= The changes necessary to implement the improved license handling outlined in this PEP include those in both -`distribution package metadata `_, as defined in the -`core metadata specification <#coremetadataspec_>`_, and -`author-provided project source metadata `_, as -originally defined in :pep:`621`. +:ref:`distribution package metadata <639-spec-core-metadata>`, +as defined in the `core metadata specification `__, and +:ref:`author-provided project source metadata <639-spec-source-metadata>`, +as originally defined in :pep:`621`. -Further, `minor additions `_ to the +Further, :ref:`minor additions <639-spec-project-formats>` to the source distribution (sdist), built distribution (wheel) and installed project specifications will help document and clarify the already allowed, now formally standardized behavior in these respects. -Finally, `guidance is established `_ +Finally, :ref:`guidance is established <639-spec-converting-metadata>` for tools handling and converting legacy license metadata to license expressions, to ensure the results are consistent, correct and unambiguous. @@ -347,18 +359,20 @@ they MAY operate more strictly if users explicitly configure them to do so, such as by a CLI flag or a configuration option. +.. _639-spec-core-metadata: + Core metadata ------------- -The `PyPA Core Metadata specification <#coremetadataspec_>`_ defines the names +The `PyPA Core Metadata specification `__ defines the names and semantics of each of the supported fields in the distribution metadata of Python distribution packages and installed projects. -This PEP `adds `_ the +This PEP :ref:`adds <639-spec-field-license-expression>` the ``License-Expression`` field, -`adds `_ the ``License-File`` field, -`deprecates `_ the ``License`` field, -and `deprecates `_ the license classifiers +:ref:`adds <639-spec-field-license-file>` the ``License-File`` field, +:ref:`deprecates <639-spec-field-license>` the ``License`` field, +and :ref:`deprecates <639-spec-field-classifier>` the license classifiers in the ``Classifier`` field. The error and warning guidance in this section applies to build and @@ -369,6 +383,8 @@ that does not conform to this specification. As it adds new fields, this PEP updates the core metadata to version 2.3. +.. _639-spec-field-license-expression: + Add ``License-Expression`` field '''''''''''''''''''''''''''''''' @@ -379,8 +395,10 @@ Publishing tools SHOULD issue an informational warning if this field is missing, and MAY raise an error. Build tools MAY issue a similar warning, but MUST NOT raise an error. +.. _639-license-expression-definition: + A license expression is a string using the SPDX license expression syntax as -documented in the `SPDX specification <#spdxpression_>`_, either +documented in the `SPDX specification `__, either Version 2.2 or a later compatible version. When used in the ``License-Expression`` field and as a specialization of @@ -388,7 +406,7 @@ 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_>`_, version 3.15 or any later compatible + `SPDX License List `__, version 3.15 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". @@ -402,11 +420,12 @@ a valid license expression, build and publishing tools: - The field does not contain a valid license expression - - One or more license identifiers are not valid (as defined above) + - One or more license identifiers are not valid + (as :ref:`defined above <639-license-expression-definition>`) - SHOULD report an informational warning, and publishing tools MAY raise an error, if one or more license identifiers have been marked as deprecated in - the `SPDX License List <#spdxlist_>`_. + the `SPDX License List `__. - MUST store a case-normalized version of the ``License-Expression`` field using the reference case for each SPDX license identifier and @@ -417,7 +436,7 @@ a valid license expression, build and publishing tools: ``License-Expression`` field contents. For all newly-upload distributions that include a -``License-Expression`` field, the `Python Package Index (PyPI) <#pypi_>`_ MUST +``License-Expression`` field, the `Python Package Index (PyPI) `__ MUST validate that it contains a valid, case-normalized license expression with valid identifiers (as defined here) and MUST reject uploads that do not. PyPI MAY reject an upload for using a deprecated license identifier, @@ -425,6 +444,8 @@ so long as it was deprecated as of the above-mentioned SPDX License List version. +.. _639-spec-field-license-file: + Add ``License-File`` field '''''''''''''''''''''''''' @@ -436,7 +457,7 @@ more times, each instance listing the path to one such file. Files specified under this field could include license text, author/attribution information, or other legal notices that need to be distributed with the package. -As `specified by this PEP `__, its value +As :ref:`specified by this PEP <639-spec-project-formats>`, its value is also that file's path relative to the root license directory in both installed projects and the standardized distribution package types. In other legacy, non-standard or new distribution package formats and @@ -470,6 +491,8 @@ higher, PyPI SHOULD validate that the specified files are present in all uploaded distributions, and MUST reject uploads that do not validate. +.. _639-spec-field-license: + Deprecate ``License`` field ''''''''''''''''''''''''''' @@ -483,7 +506,7 @@ informing users it is deprecated and recommending ``License-Expression`` instead. For all newly-uploaded distributions that include a -``License-Expression`` field, the `Python Package Index (PyPI) <#pypi_>`_ MUST +``License-Expression`` field, the `Python Package Index (PyPI) `__ MUST reject any that specify a ``License`` field and the text of which is not identical to that of ``License-Expression``, as defined in this section. @@ -491,10 +514,12 @@ Along with license classifiers, the ``License`` field may be removed from a new version of the specification in a future PEP. +.. _639-spec-field-classifier: + Deprecate license classifiers ''''''''''''''''''''''''''''' -Using license `classifiers <#classifiers_>`_ in the ``Classifier`` field +Using license `classifiers `__ in the ``Classifier`` field (described in :pep:`301`) is deprecated and replaced by the more precise ``License-Expression`` field. @@ -511,46 +536,50 @@ the presence of license classifiers SHOULD NOT raise an error unless ``License-Expression`` is also provided. For all newly-uploaded distributions that include a -``License-Expression`` field, the `Python Package Index (PyPI) <#pypi_>`_ MUST +``License-Expression`` field, the `Python Package Index (PyPI) `__ MUST reject any that also specify any license classifiers. -New license classifiers MUST NOT be `added to PyPI <#classifiersrepo_>`_; +New license classifiers MUST NOT be `added to PyPI `__; users needing them SHOULD use the ``License-Expression`` field instead. Along with the ``License`` field, license classifiers may be removed from a new version of the specification in a future PEP. +.. _639-spec-source-metadata: + Project source metadata ----------------------- As originally introduced in :pep:`621`, the -`PyPA Declaring Project Metadata specification <#pep621spec_>`_ +`PyPA Declaring Project Metadata specification `__ defines how to declare a project's source metadata in a ``[project]`` table in the ``pyproject.toml`` file for build tools to consume and output distribution core metadata. -This PEP `adds `_ the ``license-expression`` key, -`adds `_ the ``license-files`` key and -`deprecates `_ the ``license`` key. +This PEP :ref:`adds <639-spec-key-license-expression>` the ``license-expression`` +key, :ref:`adds <639-spec-key-license-files>` the ``license-files`` key and +:ref:`deprecates <639-spec-key-license>` the ``license`` key. +.. _639-spec-key-license-expression: + Add ``license-expression`` key '''''''''''''''''''''''''''''' A new ``license-expression`` key is added to the ``project`` table, which has a string value that is a valid SPDX license expression, as -`defined previously `_. +:ref:`defined previously <639-license-expression-definition>`. Its value maps to the ``License-Expression`` field in the core metadata. -Build tools SHOULD validate the expression as described -`above `_, outputting +Build tools SHOULD validate the expression as described in the +:ref:`639-spec-field-license-expression` section, outputting an error or warning as specified. When generating the core metadata, tools MUST perform case normalization. If and only if the ``license-expression`` key is listed as ``dynamic`` (and is not specified), tools MAY infer a value for the ``License-Expression`` field if they can do so unambiguously, but MUST follow the provisions in the -`Converting legacy metadata`_ section. +:ref:`639-spec-converting-metadata` section. If the ``license-expression`` key is present and valid (and the ``license`` key is not specified), for purposes of backward compatibility, tools MAY @@ -558,6 +587,8 @@ back-fill the ``License`` core metadata field with the case-normalized value of the ``license-expression`` key. +.. _639-spec-key-license-files: + Add ``license-files`` key ''''''''''''''''''''''''' @@ -570,13 +601,13 @@ Its value is a table, which if present MUST contain one of two optional, mutually exclusive subkeys, ``paths`` and ``globs``; if both are specified, tools MUST raise an error. Both are arrays of strings; the ``paths`` subkey contains verbatim file paths, and the ``globs`` subkey valid glob patterns, -which MUST be parsable by the ``glob`` `module <#globmodule_>`_ in the +which MUST be parsable by the ``glob`` `module `__ in the Python standard library. **Note**: To avoid ambiguity, confusion and (per :pep:`20`, the Zen of Python) "more than one (obvious) way to do it", allowing a flat array of strings as the value for the ``license-files`` key has been -`left out for now `_. +:ref:`left out for now <639-license-files-allow-flat-array>`. Path delimiters MUST be the forward slash character (``/``), and parent directory indicators (``..``) MUST NOT be used. @@ -621,8 +652,12 @@ If the ``license-files`` key is present, and the ``paths`` or ``globs`` subkey is set to a value of an empty array, then tools MUST NOT include any license files and MUST NOT raise an error. +.. _639-default-patterns: + If the ``license-files`` key is not present and not explicitly marked as -``dynamic``, tools MUST assume a default value of the following:: +``dynamic``, tools MUST assume a default value of the following: + +.. code-block:: toml license-files.globs = ["LICEN[CS]E*", "COPYING*", "NOTICE*", "AUTHORS*"] @@ -636,6 +671,8 @@ including at least the license files matching the above patterns, unless the user has explicitly specified their own. +.. _639-spec-key-license: + Deprecate ``license`` key ''''''''''''''''''''''''' @@ -659,7 +696,8 @@ specified path, tools SHOULD issue a warning, and MUST NOT fill it in a For backwards compatibility, to preserve consistent behavior with current tools and ensure that users do not unknowingly create packages that are not legally -distributable, tools MUST assume the above default value for the +distributable, tools MUST assume the +:ref:`specified default value <639-default-patterns>` for the ``license-files`` key and also include, in addition to the license file specified under this ``file`` subkey, any license files that match the specified list of patterns. @@ -668,6 +706,8 @@ The ``license`` key may be removed from a new version of the specification in a future PEP. +.. _639-spec-project-formats: + License files in project formats -------------------------------- @@ -675,25 +715,25 @@ A few minor additions will be made to the relevant existing specifications to document, standardize and clarify what is already currently supported, allowed and implemented behavior, as well as explicitly mention the root license directory the license files are located in and relative to for -each format, per the `specification above `_. +each format, per the :ref:`639-spec-field-license-file` section. **Project source trees** - As `described above `_, the - `Declaring Project Metadata specification <#pep621spec_>`_ + As described in the :ref:`639-spec-source-metadata` section, the + `Declaring Project Metadata specification `__ will be updated to reflect that license file paths MUST be relative to the project root directory; i.e. the directory containing the ``pyproject.toml`` (or equivalently, other legacy project configuration, e.g. ``setup.py``, ``setup.cfg``, etc). **Source distributions** *(sdists)* - The `sdist specification <#sdistspec_>`_ will be updated to reflect that for + The `sdist specification `__ will be updated to reflect that for ``Metadata-Version`` is ``2.3`` or greater, the sdist MUST contain any license files specified by ``License-File`` in the ``PKG-INFO`` at their respective paths relative to the top-level directory of the sdist (containing the ``pyproject.toml`` and the ``PKG-INFO`` core metadata). **Built distributions** *(wheels)* - The `wheel specification <#wheelspec_>`_ will be updated to reflect that if + The `wheel specification `__ will be updated to reflect that if the ``Metadata-Version`` is ``2.3`` or greater and one or more ``License-File`` fields is specified, the ``.dist-info`` directory MUST contain a ``license_files`` subdirectory which MUST contain the files listed @@ -701,7 +741,7 @@ each format, per the `specification above `_. paths relative to the ``license_files`` directory. **Installed projects** - The `Recording Installed Projects specification <#installedspec_>`_ will be + The `Recording Installed Projects specification `__ will be updated to reflect that if the ``Metadata-Version`` is ``2.3`` or greater and one or more ``License-File`` fields is specified, the ``.dist-info`` directory MUST contain a ``license_files`` subdirectory which MUST contain @@ -711,6 +751,8 @@ each format, per the `specification above `_. by install tools. +.. _639-spec-converting-metadata: + Converting legacy metadata -------------------------- @@ -745,17 +787,19 @@ unambiguous, affirmative user action to select and confirm the desired ``License-Expression`` value before proceeding. +.. _639-spec-mapping-classifiers-identifiers: + Mapping license classifiers to SPDX identifiers ''''''''''''''''''''''''''''''''''''''''''''''' Most single license classifiers (namely, all those not mentioned below) map to a single valid SPDX license identifier, allowing tools to insert them into the ``License-Expression`` field following the -`specification above `_. +:ref:`specification above <639-spec-converting-metadata>`. Many legacy license classifiers intend to specify a particular license, but do not specify the particular version or variant, leading to a -`critical ambiguity <#classifierissue_>`_ as to their terms, compatibility +`critical ambiguity `__ as to their terms, compatibility and acceptability. Tools MUST NOT attempt to automatically infer a ``License-Expression`` when one of these classifiers is used, and SHOULD instead prompt the user to affirmatively select and confirm their intended @@ -779,7 +823,7 @@ These classifiers are the following: - ``License :: OSI Approved :: GNU Library or Lesser General Public License (LGPL)`` A comprehensive mapping of these classifiers to their possible specific -identifiers was `assembled by Dustin Ingram <#badclassifiers_>`_, which tools +identifiers was `assembled by Dustin Ingram `__, which tools MAY use as a reference for the identifier selection options to offer users when prompting the user to explicitly select the license identifier they intended for their project. @@ -798,9 +842,9 @@ considered canonical and normative for the purposes of this specification: ``License-Expression: LicenseRef-Public-Domain``. If tools do so, they SHOULD issue an informational warning encouraging the use of more explicit and legally portable license identifiers, - such as those for the `CC0 1.0 license <#cc0_>`_ (``CC0-1.0``), - the `Unlicense <#unlicense_>`_ (``Unlicense``), - or the `MIT license <#mitlicense_>`_ (``MIT``), + such as those for the `CC0 1.0 license `__ (``CC0-1.0``), + the `Unlicense `__ (``Unlicense``), + or the `MIT license `__ (``MIT``), since the meaning associated with the term "public domain" is thoroughly dependent on the specific legal jurisdiction involved, some of which lack the concept entirely. @@ -838,6 +882,8 @@ MUST NOT automatically infer a license expression, and SHOULD suggest that the package author construct one which expresses their intent. +.. _639-backwards-compatibility: + Backwards Compatibility ======================= @@ -905,6 +951,8 @@ any future changes by ensuring all distributions uploaded to PyPI with the new fields are valid and conform to the specification. +.. _639-security-implications: + Security Implications ===================== @@ -913,6 +961,8 @@ field is a plain string and the ``License-File`` fields are file paths. Neither introduces any known new security concerns. +.. _639-how-to-teach-this: + How to Teach This ================= @@ -937,7 +987,7 @@ and ``license-files`` in their project source metadata. Tools may also help with the conversion and suggest a license expression in many, if not most common cases: -- The section `Mapping license classifiers to SPDX identifiers`_ provides +- The section :ref:`639-spec-mapping-classifiers-identifiers` provides tool authors with guidelines on how to suggest a license expression produced from legacy classifiers. @@ -949,22 +999,26 @@ many, if not most common cases: license expression using an SPDX license identifier). +.. _639-reference-implementation: + Reference Implementation ======================== Tools will need to support parsing and validating license expressions in the ``License-Expression`` field. -The `license-expression library <#licenseexplib_>`_ is a reference Python +The `license-expression library `__ is a reference Python implementation that handles license expressions including parsing, formatting and validation, using flexible lists of license symbols (including SPDX license IDs and any extra identifiers included here). It is licensed under Apache-2.0 and is already used in several projects, -including the `SPDX Python Tools <#spdxpy_>`_, -the `ScanCode toolkit <#scancodetk_>`_ -and the Free Software Foundation Europe (FSFE) `REUSE project <#reuse_>`_. +including the `SPDX Python Tools `__, +the `ScanCode toolkit `__ +and the Free Software Foundation Europe (FSFE) `REUSE project `__. +.. _639-rejected-ideas: + Rejected Ideas ============== @@ -978,7 +1032,7 @@ core metadata fields specified in this PEP. Re-use the ``License`` field '''''''''''''''''''''''''''' -Following `initial discussion <#reusediscussion_>`_, earlier versions of this +Following `initial discussion `__, earlier versions of this PEP proposed re-using the existing ``License`` field, which tools would attempt to parse as a SPDX license expression with a fallback to free text. Initially, this would merely cause a warning (or even pass silently), @@ -1030,7 +1084,7 @@ purpose-created field, ``License-Expression``. Re-Use the ``License`` field with a value prefix '''''''''''''''''''''''''''''''''''''''''''''''' -As an alternative to the above, prefixing SPDX license expressions with, +As an alternative to the previous, prefixing SPDX license expressions with, e.g. ``spdx:`` was suggested to reduce the ambiguity inherent in re-using the ``License`` field. However, this effectively amounted to creating a field within a field, and doesn't address all the downsides of @@ -1099,7 +1153,7 @@ to a free-form description, to the same SPDX identifier they would be entering in the ``license-expression`` key anyway, assuming they can easily find documentation at all about it). In fact, this can be made even easier thanks to the new field. For example, GitHub's popular -`ChooseALicense.com <#choosealicense_>`_ links to how to add SPDX license +`ChooseALicense.com `__ links to how to add SPDX license identifiers to the project source metadata of various languages that support them right in the sidebar of every license page; the SPDX support in this PEP enables adding Python to that list. @@ -1245,7 +1299,7 @@ separately mark the ``[project]`` keys corresponding to the ``License`` and ``License-Expression`` metadata fields as dynamic. This, in turn, still renders specifying metadata following that standard incompatible with conversion of legacy metadata, as specified in this PEP's -`Converting legacy metadata`_ section, as :pep:`621` strictly prohibits the +:ref:`639-spec-converting-metadata`, as :pep:`621` strictly prohibits the ``license`` key from being both present (to define the existing value of the ``License`` field, or the path to a license file, and thus able to be converted), and specified as ``dynamic`` (which would allow tools to @@ -1488,6 +1542,8 @@ reliance on heuristics to determine interpretation—the very thing this PEP seeks to avoid. +.. _639-license-files-allow-flat-array: + Also allow a flat array value ''''''''''''''''''''''''''''' @@ -1599,8 +1655,8 @@ Flatten license files in subdirectories ''''''''''''''''''''''''''''''''''''''' Previous drafts of this PEP were silent on the issue of handling license files -in subdirectories. Currently, the `Wheel <#wheelfiles_>`_ and (following its -example) `Setuptools <#setuptoolsfiles_>`_ projects flatten all license files +in subdirectories. Currently, the `Wheel `__ and (following its +example) `Setuptools `__ projects flatten all license files into the ``.dist-info`` directory without preserving the source subdirectory hierarchy. @@ -1785,7 +1841,7 @@ Map identifiers to source files ''''''''''''''''''''''''''''''' As discussed previously, file-level notices are out of scope for this PEP, -and the existing ``SPDX-License-Identifier`` `convention <#spdxid_>`_ can +and the existing ``SPDX-License-Identifier`` `convention `__ can already be used if this is needed without further specification here. @@ -1804,7 +1860,7 @@ compatibility with a specific version of these specifications here and a PEP or similar process to update it avoids this contingency, and follows the practice of other packaging ecosystems. -Therefore, it was `decided <#spdxversion_>`_ to specify a minimum version +Therefore, it was `decided `__ to specify a minimum version and requires tools to be compatible with it, while still allowing updates so long as they don't break backward compatibility. This enables tools to immediate take advantage of improvements and accept new @@ -1812,6 +1868,8 @@ licenses, but also remain backwards compatible with the version specified here, balancing flexibility and compatibility. +.. _639-rejected-ideas-difference-license-source-binary: + Different licenses for source and binary distributions '''''''''''''''''''''''''''''''''''''''''''''''''''''' @@ -1820,9 +1878,9 @@ PEP to handle cases where the license expression for a binary distribution (wheel) is different from that for a source distribution (sdist), such as in cases of non-pure-Python packages that compile and bundle binaries under different licenses than the project itself. An example cited was -`PyTorch <#pytorch_>`_, which contains CUDA from Nvidia, which is freely -distributable but not open source. `NumPy <#numpyissue_>`_ and -`SciPy <#scipyissue_>`_ also had similar issues, as reported by the +`PyTorch `__, which contains CUDA from Nvidia, which is freely +distributable but not open source. `NumPy `__ and +`SciPy `__ also had similar issues, as reported by the original author of this PEP and now resolved for those cases. However, given the inherent complexity here and a lack of an obvious @@ -1932,60 +1990,78 @@ compatibility, while the same is not so if they are allowed now and later determined to be unnecessary or too problematic in practice. +.. _639-examples: + Appendix: License Expression Examples ===================================== +.. _639-example-basic: + Basic example ------------- -The Setuptools project itself, as of `version 59.1.1 <#setuptools5911_>`_, +The Setuptools project itself, as of `version 59.1.1 `__, does not use the ``License`` field in its own project source metadata. Further, it no longer explicitly specifies ``license_file``/``license_files`` as it did previously, since Setuptools relies on its own automatic inclusion of license-related files matching common patterns, such as the ``LICENSE`` file it uses. -It includes the following license-related metadata in its ``setup.cfg``:: +It includes the following license-related metadata in its ``setup.cfg``: + +.. code-block:: ini [metadata] classifiers = License :: OSI Approved :: MIT License -The simplest migration to this PEP would consist of using this instead:: +The simplest migration to this PEP would consist of using this instead: + +.. code-block:: ini [metadata] license_expression = MIT -Or, in a :pep:`621` ``pyproject.toml``:: +Or, in a :pep:`621` ``pyproject.toml``: + +.. code-block:: toml [project] license-expression = "MIT" -The output core metadata for the distribution packages would then be:: +The output core metadata for the distribution packages would then be: + +.. code-block:: email License-Expression: MIT License-File: LICENSE -The ``LICENSE`` file would be stored at ``/setuptools-{version}/LICENSE`` -in the sdist and ``/setuptools-{version}.dist-info/license_files/LICENSE`` +The ``LICENSE`` file would be stored at ``/setuptools-${VERSION}/LICENSE`` +in the sdist and ``/setuptools-${VERSION}.dist-info/license_files/LICENSE`` in the wheel, and unpacked from there into the site directory (e.g. ``site-packages``) on installation; ``/`` is the root of the respective archive -and ``{version}`` the version of the Setuptools release in the core metadata. +and ``${VERSION}`` the version of the Setuptools release in the core metadata. +.. _639-example-advanced: + Advanced example ---------------- Suppose Setuptools were to include the licenses of the third-party projects that are vendored in the ``setuptools/_vendor/`` and ``pkg_resources/_vendor`` -directories; specifically:: +directories; specifically: + +.. code-block:: text packaging==21.2 pyparsing==2.2.1 ordered-set==3.1.1 more_itertools==8.8.0 -The license expressions for these projects are:: +The license expressions for these projects are: + +.. code-block:: text packaging: Apache-2.0 OR BSD-2-Clause pyparsing: MIT @@ -1994,7 +2070,9 @@ The license expressions for these projects are:: A comprehensive license expression covering both Setuptools proper and its vendored dependencies would contain these metadata, -combining all the license expressions into one. Such an expression might be:: +combining all the license expressions into one. Such an expression might be: + +.. code-block:: text MIT AND (Apache-2.0 OR BSD-2-Clause) @@ -2004,18 +2082,22 @@ of the MIT license and the copyrights used by Setuptools, ``pyparsing``, ``more_itertools`` and ``ordered-set``; and the ``LICENSE*`` files in the ``setuptools/_vendor/packaging/`` directory contain the Apache 2.0 and 2-clause BSD license text, and the Packaging copyright statement and -`license choice notice <#packaginglicense_>`_. +`license choice notice `__. Specifically, we assume the license files are located at the following paths in the project source tree (relative to the project root and -``pyproject.toml``):: +``pyproject.toml``): + +.. code-block:: ini LICENSE setuptools/_vendor/packaging/LICENSE setuptools/_vendor/packaging/LICENSE.APACHE setuptools/_vendor/packaging/LICENSE.BSD -Putting it all together, our ``setup.cfg`` would be:: +Putting it all together, our ``setup.cfg`` would be: + +.. code-block:: ini [metadata] license_expression = MIT AND (Apache-2.0 OR BSD-2-Clause) @@ -2026,7 +2108,9 @@ Putting it all together, our ``setup.cfg`` would be:: setuptools/_vendor/packaging/LICENSE.BSD In a :pep:`621` ``pyproject.toml``, with license files specified explicitly -via the ``paths`` subkey, this would look like:: +via the ``paths`` subkey, this would look like: + +.. code-block:: toml [project] license-expression = "MIT AND (Apache-2.0 OR BSD-2-Clause)" @@ -2037,7 +2121,9 @@ via the ``paths`` subkey, this would look like:: "setuptools/_vendor/LICENSE.BSD", ] -Or alternatively, matched via glob patterns, this could be:: +Or alternatively, matched via glob patterns, this could be: + +.. code-block:: toml [project] license-expression = "MIT AND (Apache-2.0 OR BSD-2-Clause)" @@ -2047,7 +2133,9 @@ Or alternatively, matched via glob patterns, this could be:: ] With either approach, the output core metadata in the distribution -would be:: +would be: + +.. code-block:: email License-Expression: MIT AND (Apache-2.0 OR BSD-2-Clause) License-File: LICENSE @@ -2055,46 +2143,60 @@ would be:: License-File: setuptools/_vendor/packaging/LICENSE.APACHE License-File: setuptools/_vendor/packaging/LICENSE.BSD -In the resulting sdist, with ``/`` as the root of the archive and ``{version}`` +In the resulting sdist, with ``/`` as the root of the archive and ``${VERSION}`` the version of the Setuptools release specified in the core metadata, -the license files would be located at the paths:: +the license files would be located at the paths: - /setuptools-{version}/LICENSE - /setuptools-{version}/setuptools/_vendor/packaging/LICENSE - /setuptools-{version}/setuptools/_vendor/packaging/LICENSE.APACHE - /setuptools-{version}/setuptools/_vendor/packaging/LICENSE.BSD +.. code-block:: shell + + /setuptools-${VERSION}/LICENSE + /setuptools-${VERSION}/setuptools/_vendor/packaging/LICENSE + /setuptools-${VERSION}/setuptools/_vendor/packaging/LICENSE.APACHE + /setuptools-${VERSION}/setuptools/_vendor/packaging/LICENSE.BSD In the built wheel, with ``/`` being the root of the archive and -``{version}`` as the previous, the license files would be stored at:: +``{version}`` as the previous, the license files would be stored at: - /setuptools-{version}.dist-info/license_files/LICENSE - /setuptools-{version}.dist-info/license_files/setuptools/_vendor/packaging/LICENSE - /setuptools-{version}.dist-info/license_files/setuptools/_vendor/packaging/LICENSE.APACHE - /setuptools-{version}.dist-info/license_files/setuptools/_vendor/packaging/LICENSE.BSD +.. code-block:: shell + + /setuptools-${VERSION}.dist-info/license_files/LICENSE + /setuptools-${VERSION}.dist-info/license_files/setuptools/_vendor/packaging/LICENSE + /setuptools-${VERSION}.dist-info/license_files/setuptools/_vendor/packaging/LICENSE.APACHE + /setuptools-${VERSION}.dist-info/license_files/setuptools/_vendor/packaging/LICENSE.BSD Finally, in the installed project, with ``site-packages`` being the site dir -and ``{version}`` as the previous, the license files would be installed to:: +and ``{version}`` as the previous, the license files would be installed to: - site-packages/setuptools-{version}.dist-info/license_files/LICENSE - site-packages/setuptools-{version}.dist-info/license_files/setuptools/_vendor/packaging/LICENSE - site-packages/setuptools-{version}.dist-info/license_files/setuptools/_vendor/packaging/LICENSE.APACHE - site-packages/setuptools-{version}.dist-info/license_files/setuptools/_vendor/packaging/LICENSE.BSD +.. code-block:: shell + site-packages/setuptools-${VERSION}.dist-info/license_files/LICENSE + site-packages/setuptools-${VERSION}.dist-info/license_files/setuptools/_vendor/packaging/LICENSE + site-packages/setuptools-${VERSION}.dist-info/license_files/setuptools/_vendor/packaging/LICENSE.APACHE + site-packages/setuptools-${VERSION}.dist-info/license_files/setuptools/_vendor/packaging/LICENSE.BSD + + +.. _639-example-conversion: Conversion example ------------------ Suppose we were to return to our simple Setuptools case. -Per the specification, given it only has the following license classifier:: +Per the specification, given it only has the following license classifier: + +.. code-block:: email Classifier: License :: OSI Approved :: MIT License And no value for the ``License`` field, or equivalently, if it had a -value of:: +value of: + +.. code-block:: email License: MIT -Then the suggested value for the ``License-Expression`` field would be:: +Then the suggested value for the ``License-Expression`` field would be: + +.. code-block:: email License-Expression: MIT @@ -2104,26 +2206,26 @@ inherent ambiguity, and the user would be prompted on how to handle the situation themselves. +.. _639-example-expression: + Expression examples ------------------- -Some additional examples of valid ``License-Expression`` values:: +Some additional examples of valid ``License-Expression`` values: + +.. code-block:: email License-Expression: MIT - License-Expression: BSD-3-Clause - License-Expression: MIT AND (Apache-2.0 OR BSD-2-clause) - License-Expression: MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause) - License-Expression: GPL-3.0-only WITH Classpath-Exception-2.0 OR BSD-3-Clause - License-Expression: LicenseRef-Public-Domain OR CC0-1.0 OR Unlicense - License-Expression: LicenseRef-Proprietary +.. _639-user-scenarios: + Appendix: User Scenarios ======================== @@ -2152,13 +2254,13 @@ I just want to share my own work without legal restrictions ----------------------------------------------------------- While you aren't required to include a license, if you don't, no one has -`any permission to download, use or improve your work <#dontchoosealicense_>`_, +`any permission to download, use or improve your work `__, so that's probably the *opposite* of what you actually want. -The `MIT license <#mitlicense_>`_ is a great choice instead, as it's simple, +The `MIT license `__ is a great choice instead, as it's simple, widely used and allows anyone to do whatever they want with your work (other than sue you, which you probably also don't want). -To apply it, just paste `the text <#chooseamitlicense_>`_ into a file named +To apply it, just paste `the text `__ into a file named ``LICENSE.txt`` at the root of your repo, and add the year and your name to the copyright line. Then, just add ``license-expression = "MIT"`` under ``[project]`` in your ``pyproject.toml`` if your packaging tool supports it, @@ -2177,7 +2279,7 @@ file at the root of your repo, if you don't have it in a file starting with config file (e.g. for Setuptools, ``license_expression = LICENSE-ID`` under ``[metadata]`` in ``setup.cfg``). You can find the ``LICENSE-ID`` and copyable license text on sites like -`ChooseALicense <#choosealicenselist_>`_ or `SPDX <#spdxlist_>`_. +`ChooseALicense `__ or `SPDX `__. Many popular code hosts, project templates and packaging tools can add the license file for you, and may support the expression as well in the future. @@ -2196,7 +2298,7 @@ In your project config file, enter your license expression under packaging tool, and make sure to remove any legacy ``license`` value or ``License ::`` classifiers. Your existing ``license`` value may already be valid as one (e.g. ``MIT``, ``Apache-2.0 OR BSD-2-Clause``, etc); -otherwise, check the `SPDX license list <#spdxlist_>`_ for the identifier +otherwise, check the `SPDX license list `__ for the identifier that matches the license used in your project. If your license files begin with ``LICENSE``, ``COPYING``, ``NOTICE`` or @@ -2207,8 +2309,8 @@ or ``license-files.globs`` under ``[project]`` in ``pyproject.toml`` (if your tool supports it), or else in your tool's configuration file (e.g. ``license_files`` in ``setup.cfg`` for Setuptools). -See the `basic example`_ for a simple but complete real-world demo of how -this works in practice, including some additional technical details. +See the :ref:`639-example-basic` for a simple but complete real-world demo +of how this works in practice, including some additional technical details. Packaging tools may support automatically converting legacy licensing metadata; check your tool's documentation for more information. @@ -2256,12 +2358,14 @@ as glob patterns, or ``["LICENSE.txt", "_vendor/LICENSE-APACHE.txt", "_vendor/LICENSE-BSD.txt"]`` as literal file paths. -See a fully worked out `advanced example`_ for a comprehensive end-to-end +See a fully worked out :ref:`639-example-advanced` for a comprehensive end-to-end application of this to a real-world complex project, with copious technical -details, and consult a `tutorial <#spdxtutorial_>`_ for more help and examples +details, and consult a `tutorial `__ for more help and examples using SPDX identifiers and expressions. +.. _639-license-doc-python: + Appendix: License Documentation in Python ========================================= @@ -2269,14 +2373,18 @@ There are multiple ways used or recommended to document Python project licenses today. The most common are listed below. +.. _639-license-doc-core-metadata: + Core metadata ------------- There are two overlapping core metadata fields to document a license: the -license ``Classifier`` `strings <#classifiers_>`_ prefixed with ``License ::`` -and the ``License`` `field <#licensefield_>`_ as free text. +license ``Classifier`` `strings `__ prefixed with ``License ::`` +and the ``License`` `field `__ as free text. -The core metadata ``License`` field documentation is currently:: +The core metadata ``License`` field documentation is currently: + +.. code-block:: rst License ======= @@ -2306,6 +2414,8 @@ between them. Furthermore, the list of available license classifiers is rather limited and out-of-date. +.. _639-license-doc-setuptools-wheel: + Setuptools and Wheel -------------------- @@ -2313,7 +2423,7 @@ 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: -- In the `Setuptools <#setuptoolssdist_>`_ and `Wheel <#wheels_>`_ projects, +- In the `Setuptools `__ and `Wheel `__ projects, license files are automatically added to the distribution (at their source location in a source distribution/sdist, and in the ``.dist-info`` directory of a built wheel) if they match one of a number of common license @@ -2325,45 +2435,49 @@ and this is another possible source of confusion: project's lead, Setuptools flattens the collected license files into the metadata directory, clobbering files with the same name, and dumps license files directly into the top-level ``.dist-info`` directory, but there is a - `desire to resolve both these issues <#setuptoolsfiles_>`_, + `desire to resolve both these issues `__, contingent on this PEP being accepted. - Both tools also support an older, singular ``license_file`` parameter that allows specifying only one license file to add to the distribution, which - has been deprecated for some time but still sees `some use <#pipsetup_>`_. + has been deprecated for some time but still sees `some use `__. - Following the publication of an earlier draft of this PEP, Setuptools - `added support <#setuptoolspep639_>`_ for ``License-File`` in distribution + `added support `__ for ``License-File`` in distribution metadata as described in this specification. This allows other tools consuming the resulting metadata to unambiguously locate the license file(s) for a given package. +.. _639-license-doc-pypug: + PyPA Packaging Guide and Sample Project --------------------------------------- -Both the `PyPA beginner packaging tutorial <#packagingtuttxt_>`_ and its more -comprehensive `packaging guide <#packagingguidetxt_>`_ state that it is +Both the `PyPA beginner packaging tutorial `__ and its more +comprehensive `packaging guide `__ state that it is important that every package include a license file. They point to the ``LICENSE.txt`` in the official PyPA sample project as an example, which is -`explicitly listed <#samplesetupcfg_>`_ under the ``license_files`` key in +`explicitly listed `__ under the ``license_files`` key in its ``setup.cfg``, following existing practice formally specified by this PEP. -Both the `beginner packaging tutorial <#packagingtutkey_>`_ and the -`sample project <#samplesetuppy_>`_ only use classifiers to declare a +Both the `beginner packaging tutorial `__ and the +`sample project `__ only use classifiers to declare a package's license, and do not include or mention the ``License`` field. -The `full packaging guide <#licensefield_>`_ does mention this field, but +The `full packaging guide `__ does mention this field, but states that authors should use the license classifiers instead, unless the project uses a non-standard license (which the guide discourages). +.. _639-license-doc-source-files: + Python source 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 <#pycode_>`_ documented in Python code files using +license is `sometimes `__ documented in Python code files using a "dunder" module-level constant, typically named ``__license__``. This convention, while perhaps somewhat antiquated, is recognized by the @@ -2371,23 +2485,27 @@ built-in ``help()`` function and the standard ``pydoc`` module. The dunder variable will show up in the ``help()`` DATA section for a module. +.. _639-license-doc-other-packaging-tools: + Other Python packaging tools ---------------------------- -- `Conda package manifests <#conda_>`_ have support for ``license`` and +- `Conda package manifests `__ have support for ``license`` and ``license_file`` fields, and automatically include license files following similar naming patterns as the Wheel and Setuptools projects. -- `Flit <#flit_>`_ recommends using classifiers instead of the ``License`` +- `Flit `__ recommends using classifiers instead of the ``License`` field (per the current PyPA packaging guide). -- `PBR <#pbr_>`_ uses similar data as Setuptools, but always stored in +- `PBR `__ uses similar data as Setuptools, but always stored in ``setup.cfg``. -- `Poetry <#poetry_>`_ specifies the use of the ``license`` field in +- `Poetry `__ specifies the use of the ``license`` field in ``pyproject.toml`` with SPDX license identifiers. +.. _639-license-doc-other-projects: + Appendix: License Documentation in Other Projects ================================================= @@ -2401,28 +2519,28 @@ Linux distribution packages globally in a shared documentation directory (e.g. ``/usr/share/doc``). - Debian documents package licenses with - `machine readable copyright files <#dep5_>`_. + `machine readable copyright files `__. It defines its own license expression syntax and list of identifiers for common licenses, both of which are closely related to those of SPDX. -- `Fedora packages <#fedora_>`_ specify how to include - `License Texts <#fedoratext_>`_ and use a - `License field <#fedoralicense_>`_ that must be filled +- `Fedora packages `__ specify how to include + `License Texts `__ and use a + `License field `__ that must be filled with appropriate short license identifier(s) from an extensive list - of `"Good Licenses" <#fedoralist_>`_. Fedora also defines its own + of `"Good Licenses" `__. Fedora also defines its own license expression syntax, similar to that of SPDX. -- `OpenSUSE packages <#opensuse_>`_ use SPDX license expressions with +- `OpenSUSE packages `__ use SPDX license expressions with SPDX license IDs and a - `list of additional license identifiers <#opensuselist_>`_. + `list of additional license identifiers `__. -- `Gentoo ebuild <#pycode_>`_ uses a ``LICENSE`` variable. - This field is specified in `GLEP-0023 <#glep23_>`_ and in the - `Gentoo development manual <#gentoodev_>`_. +- `Gentoo ebuild `__ uses a ``LICENSE`` variable. + This field is specified in `GLEP-0023 `__ and in the + `Gentoo development manual `__. Gentoo also defines a list of allowed licenses and a license expression syntax, which is rather different from SPDX. -- The `FreeBSD package Makefile <#freebsd_>`_ provides ``LICENSE`` and +- The `FreeBSD package Makefile `__ provides ``LICENSE`` and ``LICENSE_FILE`` fields with a list of custom license symbols. For non-standard licenses, FreeBSD recommends using ``LICENSE=UNKNOWN`` and adding ``LICENSE_NAME`` and ``LICENSE_TEXT`` fields, as well as sophisticated @@ -2432,61 +2550,61 @@ globally in a shared documentation directory (e.g. ``/usr/share/doc``). expression syntax. FreeBSD also recommends the use of ``SPDX-License-Identifier`` in source code files. -- `Arch Linux PKGBUILD <#archinux_>`_ defines its - `own license identifiers <#archlinuxlist_>`_. +- `Arch Linux PKGBUILD `__ defines its + `own license identifiers `__. The value ``'unknown'`` can be used if the license is not defined. -- `OpenWRT ipk packages <#openwrt_>`_ use the ``PKG_LICENSE`` and +- `OpenWRT ipk packages `__ use the ``PKG_LICENSE`` and ``PKG_LICENSE_FILES`` variables and recommend the use of SPDX License identifiers. -- `NixOS uses SPDX identifiers <#nixos_>`_ and some extra license IDs +- `NixOS uses SPDX identifiers `__ and some extra license IDs in its license field. - GNU Guix (based on NixOS) has a single License field, uses its own - `license symbols list <#guix_>`_ and specifies how to use one license or a - `list of them <#guixlicense_>`_. + `license symbols list `__ and specifies how to use one license or a + `list of them `__. -- `Alpine Linux packages <#alpine_>`_ recommend using SPDX identifiers in the +- `Alpine Linux packages `__ recommend using SPDX identifiers in the license field. Language and application packages --------------------------------- -- In Java, `Maven POM <#maven_>`_ defines a ``licenses`` XML tag with a list +- In Java, `Maven POM `__ defines a ``licenses`` XML tag with a list of licenses, each with a name, URL, comments and "distribution" type. This is not mandatory, and the content of each field is not specified. -- The `JavaScript NPM package.json <#npm_>`_ uses a single license field with +- The `JavaScript NPM package.json `__ uses a single license field with a SPDX license expression, or the ``UNLICENSED`` ID if none is specified. A license file can be referenced as an alternative using ``SEE LICENSE IN `` in the single ``license`` field. -- `Rubygems gemspec <#gem_>`_ specifies either a single or list of license +- `Rubygems gemspec `__ specifies either a single or 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 +- `CPAN Perl modules `__ use a single license field, which is either a single or a list of strings. The relationship between the licenses in a list is not specified. There is a list of custom license identifiers plus these generic identifiers: ``open_source``, ``restricted``, ``unrestricted``, ``unknown``. -- `Rust Cargo <#cargo_>`_ specifies the use of an SPDX license expression +- `Rust Cargo `__ specifies the use of an SPDX license expression (v2.1) in the ``license`` field. It also supports an alternative expression syntax using slash-separated SPDX license identifiers, and there is also a - ``license_file`` field. The `crates.io package registry <#cratesio_>`_ + ``license_file`` field. The `crates.io package registry `__ requires that either ``license`` or ``license_file`` fields are set when uploading a package. -- `PHP composer.json <#composer_>`_ uses a ``license`` field with +- `PHP composer.json `__ uses a ``license`` field with an SPDX license ID or ``proprietary``. The ``license`` field is either a single string with resembling the SPDX license expression syntax with ``and`` and ``or`` keywords; or is a list of strings if there is a (disjunctive) choice of licenses. -- `NuGet packages <#nuget_>`_ previously used only a simple license URL, but +- `NuGet packages `__ previously used only a simple license URL, but now specify using a SPDX license expression and/or the path to a license file within the package. The NuGet.org repository states that they only accept license expressions that are "approved by the Open Source Initiative @@ -2496,33 +2614,33 @@ Language and application packages dependencies. Licensing information is left for code authors and other community package managers to document. -- The `Dart/Flutter spec <#flutter_>`_ recommends using a single ``LICENSE`` +- The `Dart/Flutter spec `__ recommends using a single ``LICENSE`` file that should contain all the license texts, each separated by a line with 80 hyphens. -- The `JavaScript Bower <#bower_>`_ ``license`` field is either a single string +- The `JavaScript Bower `__ ``license`` field is either a single string or list of strings using either SPDX license identifiers, or a path/URL to a license file. -- The `Cocoapods podspec <#cocoapod_>`_ ``license`` field is either a single +- The `Cocoapods podspec `__ ``license`` field is either a single string, or a mapping with ``type``, ``file`` and ``text`` keys. This is mandatory unless there is a ``LICENSE``/``LICENCE`` file provided. -- `Haskell Cabal <#cabal_>`_ accepts an SPDX license expression since +- `Haskell Cabal `__ accepts an SPDX license expression since version 2.2. The version of the SPDX license list used is a function of the Cabal version. The specification also provides a mapping between legacy (pre-SPDX) and SPDX license Identifiers. Cabal also specifies a ``license-file(s)`` field that lists license files to be installed with the package. -- `Erlang/Elixir mix/hex package <#mix_>`_ specifies a ``licenses`` field as a +- `Erlang/Elixir mix/hex package `__ specifies a ``licenses`` field as a required list of license strings, and recommends using SPDX license identifiers. -- `D Langanguage dub packages <#dub_>`_ define their own list of license +- `D Langanguage dub packages `__ define their own list of license identifiers and license expression syntax, similar to the SPDX standard. -- The `R Package DESCRIPTION <#cran_>`_ defines its own sophisticated license +- The `R Package DESCRIPTION `__ defines its own sophisticated license expression syntax and list of licenses identifiers. R has a unique way of supporting specifiers for license versions (such as ``LGPL (>= 2.0, < 3)``) in its license expression syntax. @@ -2531,32 +2649,32 @@ Language and application packages Other ecosystems ---------------- -- The ``SPDX-License-Identifier`` `header <#spdxid_>`_ is a simple +- The ``SPDX-License-Identifier`` `header `__ is a simple convention to document the license inside a file. -- The `Free Software Foundation (FSF) <#fsf_>`_ promotes the use of - SPDX license identifiers for clarity in the `GPL <#gnu_>`_ and other +- The `Free Software Foundation (FSF) `__ promotes the use of + SPDX license identifiers for clarity in the `GPL `__ and other versioned free software licenses. -- The Free Software Foundation Europe (FSFE) `REUSE project <#reuse_>`_ +- The Free Software Foundation Europe (FSFE) `REUSE project `__ promotes using ``SPDX-License-Identifier``. -- The `Linux kernel <#linux_>`_ uses ``SPDX-License-Identifier`` +- The `Linux kernel `__ uses ``SPDX-License-Identifier`` and parts of the FSFE REUSE conventions to document its licenses. -- `U-Boot <#uboot_>`_ spearheaded using ``SPDX-License-Identifier`` in code +- `U-Boot `__ spearheaded using ``SPDX-License-Identifier`` in code and now follows the Linux approach. -- The Apache Software Foundation projects use `RDF DOAP <#apache_>`_ with +- The Apache Software Foundation projects use `RDF DOAP `__ with a single license field pointing to SPDX license identifiers. -- The `Eclipse Foundation <#eclipse_>`_ promotes using +- The `Eclipse Foundation `__ promotes using ``SPDX-license-Identifiers``. -- The `ClearlyDefined project <#clearlydefined_>`_ promotes using SPDX +- The `ClearlyDefined project `__ promotes using SPDX license identifiers and expressions to improve license clarity. -- The `Android Open Source Project <#android_>`_ uses ``MODULE_LICENSE_XXX`` +- The `Android Open Source Project `__ uses ``MODULE_LICENSE_XXX`` empty tag files, where ``XXX`` is a license code such as ``BSD``, ``APACHE``, ``GPL``, etc. It also uses a ``NOTICE`` file that contains license and notice texts. @@ -2565,107 +2683,107 @@ Other ecosystems References ========== -.. _#alpine: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#license -.. _#android: https://github.com/aosp-mirror/platform_external_tcpdump/blob/android-platform-12.0.0_r1/MODULE_LICENSE_BSD -.. _#apache: https://svn.apache.org/repos/asf/allura/doap_Allura.rdf -.. _#archinux: https://wiki.archlinux.org/title/PKGBUILD#license -.. _#archlinuxlist: https://archlinux.org/packages/core/any/licenses/files/ -.. _#badclassifiers: https://github.com/pypa/trove-classifiers/issues/17#issuecomment-385027197 -.. _#bower: https://github.com/bower/spec/blob/b00c4403e22e3f6177c410ed3391b9259687e461/json.md#license -.. _#cabal: https://cabal.readthedocs.io/en/3.6/cabal-package.html?highlight=license#pkg-field-license -.. _#cargo: https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata -.. _#cc0: https://creativecommons.org/publicdomain/zero/1.0/ -.. _#cdstats: https://clearlydefined.io/stats -.. _#choosealicense: https://choosealicense.com/ -.. _#choosealicenselist: https://choosealicense.com/licenses/ -.. _#chooseamitlicense: https://choosealicense.com/licenses/mit/ -.. _#classifierissue: https://github.com/pypa/trove-classifiers/issues/17 -.. _#classifiers: https://pypi.org/classifiers -.. _#classifiersrepo: https://github.com/pypa/trove-classifiers -.. _#clearlydefined: https://clearlydefined.io -.. _#cocoapod: https://guides.cocoapods.org/syntax/podspec.html#license -.. _#composer: https://getcomposer.org/doc/04-schema.md#license -.. _#conda: https://docs.conda.io/projects/conda-build/en/stable/resources/define-metadata.html#about-section -.. _#coremetadataspec: https://packaging.python.org/specifications/core-metadata -.. _#cran: https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Licensing -.. _#cratesio: https://doc.rust-lang.org/cargo/reference/registries.html#publish -.. _#dep5: https://dep-team.pages.debian.net/deps/dep5/ -.. _#dontchoosealicense: https://choosealicense.com/no-permission/ -.. _#dub: https://dub.pm/package-format-json.html#licenses -.. _#eclipse: https://www.eclipse.org/legal/epl-2.0/faq.php -.. _#fedora: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ -.. _#fedoralicense: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_valid_license_short_names -.. _#fedoralist: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses -.. _#fedoratext: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text -.. _#flit: https://flit.readthedocs.io/en/stable/pyproject_toml.html -.. _#flutter: https://flutter.dev/docs/development/packages-and-plugins/developing-packages#adding-licenses-to-the-license-file -.. _#freebsd: https://docs.freebsd.org/en/books/porters-handbook/makefiles/#licenses -.. _#fsf: https://www.fsf.org/blogs/rms/rms-article-for-claritys-sake-please-dont-say-licensed-under-gnu-gpl-2 -.. _#gem: https://guides.rubygems.org/specification-reference/#license= -.. _#gentoo: https://devmanual.gentoo.org/ebuild-writing/variables/index.html#license -.. _#gentoodev: https://devmanual.gentoo.org/general-concepts/licenses/index.html -.. _#glep23: https://www.gentoo.org/glep/glep-0023.html -.. _#globmodule: https://docs.python.org/3/library/glob.html -.. _#gnu: https://www.gnu.org/licenses/identify-licenses-clearly.html -.. _#guix: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/licenses.scm?h=v1.3.0 -.. _#guixlicense: https://guix.gnu.org/manual/en/html_node/package-Reference.html#index-license_002c-of-packages -.. _#installedspec: https://packaging.python.org/specifications/recording-installed-packages/ -.. _#interopissue: https://github.com/pypa/interoperability-peps/issues/46 -.. _#licenseexplib: https://github.com/nexB/license-expression/ -.. _#licensefield: https://packaging.python.org/guides/distributing-packages-using-setuptools/#license -.. _#linux: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst -.. _#maven: https://maven.apache.org/pom.html#Licenses -.. _#mitlicense: https://opensource.org/licenses/MIT -.. _#mix: https://hex.pm/docs/publish -.. _#nixos: https://github.com/NixOS/nixpkgs/blob/21.05/lib/licenses.nix -.. _#npm: https://docs.npmjs.com/cli/v8/configuring-npm/package-json#license -.. _#nuget: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl -.. _#numpyissue: https://github.com/numpy/numpy/issues/8689 -.. _#opensuse: https://en.opensuse.org/openSUSE:Packaging_guidelines#Licensing -.. _#opensuselist: https://docs.google.com/spreadsheets/d/14AdaJ6cmU0kvQ4ulq9pWpjdZL5tkR03exRSYJmPGdfs/pub -.. _#openwrt: https://openwrt.org/docs/guide-developer/packages#buildpackage_variables -.. _#osi: https://opensource.org -.. _#packagingguidetxt: https://packaging.python.org/guides/distributing-packages-using-setuptools/#license-txt -.. _#packagingissue: https://github.com/pypa/packaging-problems/issues/41 -.. _#packaginglicense: https://github.com/pypa/packaging/blob/21.2/LICENSE -.. _#packagingtutkey: https://packaging.python.org/tutorials/packaging-projects/#configuring-metadata -.. _#packagingtuttxt: https://packaging.python.org/tutorials/packaging-projects/#creating-a-license -.. _#pbr: https://docs.openstack.org/pbr/latest/user/features.html -.. _#pep621spec: https://packaging.python.org/specifications/declaring-project-metadata/ -.. _#pepissue: https://github.com/pombredanne/spdx-pypi-pep/issues/1 -.. _#perl: https://metacpan.org/pod/CPAN::Meta::Spec#license -.. _#pipsetup: https://github.com/pypa/pip/blob/21.3.1/setup.cfg#L114 -.. _#poetry: https://python-poetry.org/docs/pyproject/#license -.. _#pycode: https://github.com/search?l=Python&q=%22__license__%22&type=Code -.. _#pypi: https://pypi.org/ -.. _#pypugdistributionpackage: https://packaging.python.org/en/latest/glossary/#term-Distribution-Package -.. _#pypugglossary: https://packaging.python.org/glossary/ -.. _#pypugproject: https://packaging.python.org/en/latest/glossary/#term-Project -.. _#pytorch: https://pypi.org/project/torch/ -.. _#reuse: https://reuse.software/ -.. _#reusediscussion: https://github.com/pombredanne/spdx-pypi-pep/issues/7 -.. _#samplesetupcfg: https://github.com/pypa/sampleproject/blob/3a836905fbd687af334db16b16c37cf51dcbc99c/setup.cfg -.. _#samplesetuppy: https://github.com/pypa/sampleproject/blob/3a836905fbd687af334db16b16c37cf51dcbc99c/setup.py#L98 -.. _#scancodetk: https://github.com/nexB/scancode-toolkit -.. _#scipyissue: https://github.com/scipy/scipy/issues/7093 -.. _#sdistspec: https://packaging.python.org/specifications/source-distribution-format/ -.. _#setuptools5911: https://github.com/pypa/setuptools/blob/v59.1.1/setup.cfg -.. _#setuptoolsfiles: https://github.com/pypa/setuptools/issues/2739 -.. _#setuptoolspep639: https://github.com/pypa/setuptools/pull/2645 -.. _#setuptoolssdist: https://github.com/pypa/setuptools/pull/1767 -.. _#spdx: https://spdx.dev/ -.. _#spdxid: https://spdx.dev/ids/ -.. _#spdxlist: https://spdx.org/licenses/ -.. _#spdxpression: https://spdx.github.io/spdx-spec/SPDX-license-expressions/ -.. _#spdxpy: https://github.com/spdx/tools-python/ -.. _#spdxtutorial: https://github.com/david-a-wheeler/spdx-tutorial -.. _#spdxversion: https://github.com/pombredanne/spdx-pypi-pep/issues/6 -.. _#uboot: https://www.denx.de/wiki/U-Boot/Licensing -.. _#unlicense: https://unlicense.org/ -.. _#wheelfiles: https://github.com/pypa/wheel/issues/138 -.. _#wheelproject: https://wheel.readthedocs.io/en/stable/ -.. _#wheels: https://github.com/pypa/wheel/blob/0.37.0/docs/user_guide.rst#including-license-files-in-the-generated-wheel-file -.. _#wheelspec: https://packaging.python.org/specifications/binary-distribution-format/ +.. _alpine: https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#license +.. _android: https://github.com/aosp-mirror/platform_external_tcpdump/blob/android-platform-12.0.0_r1/MODULE_LICENSE_BSD +.. _apache: https://svn.apache.org/repos/asf/allura/doap_Allura.rdf +.. _archinux: https://wiki.archlinux.org/title/PKGBUILD#license +.. _archlinuxlist: https://archlinux.org/packages/core/any/licenses/files/ +.. _badclassifiers: https://github.com/pypa/trove-classifiers/issues/17#issuecomment-385027197 +.. _bower: https://github.com/bower/spec/blob/b00c4403e22e3f6177c410ed3391b9259687e461/json.md#license +.. _cabal: https://cabal.readthedocs.io/en/3.6/cabal-package.html?highlight=license#pkg-field-license +.. _cargo: https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata +.. _cc0: https://creativecommons.org/publicdomain/zero/1.0/ +.. _cdstats: https://clearlydefined.io/stats +.. _choosealicense: https://choosealicense.com/ +.. _choosealicenselist: https://choosealicense.com/licenses/ +.. _chooseamitlicense: https://choosealicense.com/licenses/mit/ +.. _classifierissue: https://github.com/pypa/trove-classifiers/issues/17 +.. _classifiers: https://pypi.org/classifiers +.. _classifiersrepo: https://github.com/pypa/trove-classifiers +.. _clearlydefined: https://clearlydefined.io +.. _cocoapod: https://guides.cocoapods.org/syntax/podspec.html#license +.. _composer: https://getcomposer.org/doc/04-schema.md#license +.. _conda: https://docs.conda.io/projects/conda-build/en/stable/resources/define-metadata.html#about-section +.. _coremetadataspec: https://packaging.python.org/specifications/core-metadata +.. _cran: https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Licensing +.. _cratesio: https://doc.rust-lang.org/cargo/reference/registries.html#publish +.. _dep5: https://dep-team.pages.debian.net/deps/dep5/ +.. _dontchoosealicense: https://choosealicense.com/no-permission/ +.. _dub: https://dub.pm/package-format-json.html#licenses +.. _eclipse: https://www.eclipse.org/legal/epl-2.0/faq.php +.. _fedora: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ +.. _fedoralicense: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_valid_license_short_names +.. _fedoralist: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses +.. _fedoratext: https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text +.. _flit: https://flit.readthedocs.io/en/stable/pyproject_toml.html +.. _flutter: https://flutter.dev/docs/development/packages-and-plugins/developing-packages#adding-licenses-to-the-license-file +.. _freebsd: https://docs.freebsd.org/en/books/porters-handbook/makefiles/#licenses +.. _fsf: https://www.fsf.org/blogs/rms/rms-article-for-claritys-sake-please-dont-say-licensed-under-gnu-gpl-2 +.. _gem: https://guides.rubygems.org/specification-reference/#license= +.. _gentoo: https://devmanual.gentoo.org/ebuild-writing/variables/index.html#license +.. _gentoodev: https://devmanual.gentoo.org/general-concepts/licenses/index.html +.. _glep23: https://www.gentoo.org/glep/glep-0023.html +.. _globmodule: https://docs.python.org/3/library/glob.html +.. _gnu: https://www.gnu.org/licenses/identify-licenses-clearly.html +.. _guix: https://git.savannah.gnu.org/cgit/guix.git/tree/guix/licenses.scm?h=v1.3.0 +.. _guixlicense: https://guix.gnu.org/manual/en/html_node/package-Reference.html#index-license_002c-of-packages +.. _installedspec: https://packaging.python.org/specifications/recording-installed-packages/ +.. _interopissue: https://github.com/pypa/interoperability-peps/issues/46 +.. _licenseexplib: https://github.com/nexB/license-expression/ +.. _licensefield: https://packaging.python.org/guides/distributing-packages-using-setuptools/#license +.. _linux: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst +.. _maven: https://maven.apache.org/pom.html#Licenses +.. _mitlicense: https://opensource.org/licenses/MIT +.. _mix: https://hex.pm/docs/publish +.. _nixos: https://github.com/NixOS/nixpkgs/blob/21.05/lib/licenses.nix +.. _npm: https://docs.npmjs.com/cli/v8/configuring-npm/package-json#license +.. _nuget: https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl +.. _numpyissue: https://github.com/numpy/numpy/issues/8689 +.. _opensuse: https://en.opensuse.org/openSUSE:Packaging_guidelines#Licensing +.. _opensuselist: https://docs.google.com/spreadsheets/d/14AdaJ6cmU0kvQ4ulq9pWpjdZL5tkR03exRSYJmPGdfs/pub +.. _openwrt: https://openwrt.org/docs/guide-developer/packages#buildpackage_variables +.. _osi: https://opensource.org +.. _packagingguidetxt: https://packaging.python.org/guides/distributing-packages-using-setuptools/#license-txt +.. _packagingissue: https://github.com/pypa/packaging-problems/issues/41 +.. _packaginglicense: https://github.com/pypa/packaging/blob/21.2/LICENSE +.. _packagingtutkey: https://packaging.python.org/tutorials/packaging-projects/#configuring-metadata +.. _packagingtuttxt: https://packaging.python.org/tutorials/packaging-projects/#creating-a-license +.. _pbr: https://docs.openstack.org/pbr/latest/user/features.html +.. _pep621spec: https://packaging.python.org/specifications/declaring-project-metadata/ +.. _pepissue: https://github.com/pombredanne/spdx-pypi-pep/issues/1 +.. _perl: https://metacpan.org/pod/CPAN::Meta::Spec#license +.. _pipsetup: https://github.com/pypa/pip/blob/21.3.1/setup.cfg#L114 +.. _poetry: https://python-poetry.org/docs/pyproject/#license +.. _pycode: https://github.com/search?l=Python&q=%22__license__%22&type=Code +.. _pypi: https://pypi.org/ +.. _pypugdistributionpackage: https://packaging.python.org/en/latest/glossary/#term-Distribution-Package +.. _pypugglossary: https://packaging.python.org/glossary/ +.. _pypugproject: https://packaging.python.org/en/latest/glossary/#term-Project +.. _pytorch: https://pypi.org/project/torch/ +.. _reuse: https://reuse.software/ +.. _reusediscussion: https://github.com/pombredanne/spdx-pypi-pep/issues/7 +.. _samplesetupcfg: https://github.com/pypa/sampleproject/blob/3a836905fbd687af334db16b16c37cf51dcbc99c/setup.cfg +.. _samplesetuppy: https://github.com/pypa/sampleproject/blob/3a836905fbd687af334db16b16c37cf51dcbc99c/setup.py#L98 +.. _scancodetk: https://github.com/nexB/scancode-toolkit +.. _scipyissue: https://github.com/scipy/scipy/issues/7093 +.. _sdistspec: https://packaging.python.org/specifications/source-distribution-format/ +.. _setuptools5911: https://github.com/pypa/setuptools/blob/v59.1.1/setup.cfg +.. _setuptoolsfiles: https://github.com/pypa/setuptools/issues/2739 +.. _setuptoolspep639: https://github.com/pypa/setuptools/pull/2645 +.. _setuptoolssdist: https://github.com/pypa/setuptools/pull/1767 +.. _spdx: https://spdx.dev/ +.. _spdxid: https://spdx.dev/ids/ +.. _spdxlist: https://spdx.org/licenses/ +.. _spdxpression: https://spdx.github.io/spdx-spec/SPDX-license-expressions/ +.. _spdxpy: https://github.com/spdx/tools-python/ +.. _spdxtutorial: https://github.com/david-a-wheeler/spdx-tutorial +.. _spdxversion: https://github.com/pombredanne/spdx-pypi-pep/issues/6 +.. _uboot: https://www.denx.de/wiki/U-Boot/Licensing +.. _unlicense: https://unlicense.org/ +.. _wheelfiles: https://github.com/pypa/wheel/issues/138 +.. _wheelproject: https://wheel.readthedocs.io/en/stable/ +.. _wheels: https://github.com/pypa/wheel/blob/0.37.0/docs/user_guide.rst#including-license-files-in-the-generated-wheel-file +.. _wheelspec: https://packaging.python.org/specifications/binary-distribution-format/ Acknowledgments @@ -2685,14 +2803,4 @@ Copyright ========= This document is placed in the public domain or under the -`CC0-1.0-Universal license <#cc0_>`_, whichever is more permissive. - - - -.. - Local Variables: - mode: indented-text - indent-tabs-mode: nil - sentence-end-double-space: t - fill-column: 80 - End: +`CC0-1.0-Universal license `__, whichever is more permissive.