From 7e46cc83742711512a3e27929e7c533d0214ec32 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 15 Aug 2019 16:03:07 +0200 Subject: [PATCH 01/40] Add PEP draft for SPDX license expressions Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 155 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 155 insertions(+) create mode 100644 pep-9999.rst diff --git a/pep-9999.rst b/pep-9999.rst new file mode 100644 index 00000000000..d4266fa9d64 --- /dev/null +++ b/pep-9999.rst @@ -0,0 +1,155 @@ +PEP: 9999 +Title: Metadata for Python Software Packages 2.2 +Version: $Revision$ +Last-Modified: $Date$ +Author: Philippe Ombredanne +BDFL-Delegate: +Discussions-To: distutils-sig +Status: +Type: Standards Track +Content-Type: text/x-rst +Created: 15-Aug-2018 +Python-Version: 3.x +Post-History: +Replaces: 566 +Resolution: + +Abstract +======== + +This PEP describes the changes between versions 2.1 and 2.2 of the core +metadata specification for Python packages. Version 2.1 is specified in PEP +566. + +The key and only change introduced in this PEP is how license is documented in +package medata. + +Software is licensed and providing accurate licensing information to Python +packages users is an important matter. Yet, license metadata are limited often +leading to some confusion. + +- There are two overlapping places where a license can be documented leading to + confusion for packagers: license-related `Classifiers` and the `License` + attribute. + +- Furthermore, it is difficult to convey anything but simple licensing using + these two fields. License information expressiveness and clarity when creating + packages will help packagers and users alike. + +License expressions provide a better way to express the license of a +distribution using a well defined syntax and well known license ids from SPDX. + +This PEP was started based on several discussions and in particular: + +- ``_ +- ``_ +- ``_ +- ``_ + +Fields +====== + +The canonical source for the names and semantics of each of the supported +metadata fields is the `Core Metadata Specification`_ document. + +The details for the update to the `Core Metadata Specification`_ document are +in this `Core Metadata Specification pull request`_. + + +New in Version 2.2 +------------------ + +License-Expression (optional) +::::::::::::::::::::::::::::: + +A string containing a license expression using the SPDX license expression +syntax and SPDX-listed license identifiers so that user can express accurately +the licensing of a package in a way that is both easy to read for humans and +easy to process automatically by tools. + +A string containing a license expression using `SPDX license expression syntax and +identifiers `__ that indicates the license(s) covering the +distribution. The license expressions are specified in the `SPDX specification +`_. +SPDX also publishes a companion `list of license ids `_ +for use in license expressions. + +Note: this field is not case sensitive though the normalized representation of +an SPDX license expression has a well defined case. + +Examples:: + + License-Expression: BSD-3-Clause + + License-Expression: MIT OR GPL-2.0-or-later AND (FSFUL AND BSD-2-Clause) + + License-Expression: GPL-3.0-or-later WITH Classpath-Exception-2.0 OR BSD-3-Clause + + +Tools `should` validate that this field contains a valid license expression +and `should` report a warning if the field contains an invalid expression. + + +Changed in Version 2.2 +---------------------- + +License +::::::: + +This field will be deprecated in the future and its documentation has been +updated accordingly. Tools are encouraged to provide a warning when this field +is used. + +Classifiers +::::::::::: + +The use of license-related classifiers in this field will be deprecated in the +future and its documentation has been updated accordingly. Tools are encouraged +to provide a warning when this field is used with license-related classifiers. + + +Summary of Differences From PEP 566 +=================================== + +* Metadata-Version is now 2.2. + +* Added one new field: ``License-Expression`` + +* Updated the documentation of two fields: ``License`` and ``Classifiers`` + + +References +========== + +This document specifies version 2.2 of the metadata format. +Version 1.0 is specified in PEP 241. +Version 1.1 is specified in PEP 314. +Version 1.2 is specified in PEP 345. +Version 2.0, while not formally accepted, was specified in PEP 426. +Version 2.1 is specified in PEP 566. + +.. _`Core Metadata Specification`: + https://packaging.python.org/specifications/core-metadata/ + +.. _`Core Metadata Specification pull request`: + https://github.com/pypa/packaging.python.org/pull/635/ + + +Copyright +========= + +This document has been placed in the public domain. + + +Acknowledgements +================ + + + +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 80 + End: From 1eaec3a1d5c2c35970ea3d7a68f43c2980f40b99 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 15 Aug 2019 16:07:07 +0200 Subject: [PATCH 02/40] Add reference to another license-related ticket https://github.com/pypa/packaging-problems/issues/41 Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index d4266fa9d64..7c41838037f 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -41,10 +41,12 @@ distribution using a well defined syntax and well known license ids from SPDX. This PEP was started based on several discussions and in particular: -- ``_ -- ``_ -- ``_ -- ``_ +- ``_ +- ``_ +- ``_ +- ``_ +- ``_ + Fields ====== From 0f1d0b7e108b19e2e15e7f7d3782699a0ce5fa7d Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 15 Aug 2019 16:22:51 +0200 Subject: [PATCH 03/40] Add proper Draft status Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index 7c41838037f..ba94b80021e 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -5,7 +5,7 @@ Last-Modified: $Date$ Author: Philippe Ombredanne BDFL-Delegate: Discussions-To: distutils-sig -Status: +Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 15-Aug-2018 From fd9895e2fd7884b27bc8bfae9a7e7c9e81f66e2c Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 15 Aug 2019 16:56:19 +0200 Subject: [PATCH 04/40] Direct PEP discussions to discuss.python.org Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index ba94b80021e..64e76e57a11 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -4,7 +4,7 @@ Version: $Revision$ Last-Modified: $Date$ Author: Philippe Ombredanne BDFL-Delegate: -Discussions-To: distutils-sig +Discussions-To: https://discuss.python.org/t/improving-license-clarity-with-better-package-metadata Status: Draft Type: Standards Track Content-Type: text/x-rst From 43c0c1e0bb416b28ca86fa0b4c023a5f1494fffe Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 15 Aug 2019 18:10:54 +0200 Subject: [PATCH 05/40] Adopt latest PEP copyright conventions Reported-by: Aliaksei Urbanski @Jamim Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index 64e76e57a11..59cf675aa30 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -140,7 +140,8 @@ Version 2.1 is specified in PEP 566. Copyright ========= -This document has been placed in the public domain. +This document is placed in the public domain or under the +CC0-1.0-Universal license, whichever is more permissive. Acknowledgements From 86119d42c3db9b69ce0d8be201286e37e2d98762 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 15 Aug 2019 19:48:23 +0200 Subject: [PATCH 06/40] Add @pf_moore as BDFL delegate. And fix minor typo Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index 59cf675aa30..104ce6dc60b 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -2,8 +2,8 @@ PEP: 9999 Title: Metadata for Python Software Packages 2.2 Version: $Revision$ Last-Modified: $Date$ -Author: Philippe Ombredanne -BDFL-Delegate: +Author: Philippe Ombredanne +BDFL-Delegate: Paul Moore Discussions-To: https://discuss.python.org/t/improving-license-clarity-with-better-package-metadata Status: Draft Type: Standards Track @@ -22,7 +22,7 @@ metadata specification for Python packages. Version 2.1 is specified in PEP 566. The key and only change introduced in this PEP is how license is documented in -package medata. +package metadata. Software is licensed and providing accurate licensing information to Python packages users is an important matter. Yet, license metadata are limited often From e1b027ddf5e47585d1c19b27498cad8af817c936 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Mon, 19 Aug 2019 08:30:03 +0200 Subject: [PATCH 07/40] Add Paul Moore as a PEP sponsor CC: @pfmoore Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 1 + 1 file changed, 1 insertion(+) diff --git a/pep-9999.rst b/pep-9999.rst index 104ce6dc60b..f4b3cd5a9ac 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -3,6 +3,7 @@ Title: Metadata for Python Software Packages 2.2 Version: $Revision$ Last-Modified: $Date$ Author: Philippe Ombredanne +Sponsor: Paul Moore BDFL-Delegate: Paul Moore Discussions-To: https://discuss.python.org/t/improving-license-clarity-with-better-package-metadata Status: Draft From 1e0516182a51463993b1253129b31489098a808b Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Mon, 19 Aug 2019 08:33:48 +0200 Subject: [PATCH 08/40] Reuse License Field. Add License-File. Do not deprecate the License field with a new field. Instead reuse License and provide backward compatibility. Also add License-File field already in use in wheel and setuptools. Integrates latest feedback Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 341 +++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 278 insertions(+), 63 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index f4b3cd5a9ac..0a6482093d6 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -13,34 +13,85 @@ Created: 15-Aug-2018 Python-Version: 3.x Post-History: Replaces: 566 -Resolution: +Resolution: + Abstract ======== -This PEP describes the changes between versions 2.1 and 2.2 of the core -metadata specification for Python packages. Version 2.1 is specified in PEP -566. +This PEP describes the changes between versions 2.1 and 2.2 of the `Core +Metadata Specification`_ for Python packages. Version 2.1 is specified in PEP 566. -The key and only change introduced in this PEP is how license is documented in -package metadata. +The changes introduced in this PEP update how license is documented in Core +metadata using simple yet rich `SPDX License Expression` strings such that +license documentation is simpler and less ambiguous: -Software is licensed and providing accurate licensing information to Python -packages users is an important matter. Yet, license metadata are limited often -leading to some confusion. +- for package authors to create, +- for package users to read and understand, and, +- for tools to process package license information mechanically. + +These changes have been designed have a minimal impact and to be backward +compatible with v2.1. They are embrassing emerging new ways to document licenses +that are already in use in some tools (e.g. `license_file` field) or by some +authors (e.g. license expressions in the `license` field). All the packages that +conform with the v2.1 of core metadata specification are also conformaing and +valid with this v2.2. + +Beyond this Core metadata specification update, this PEP comes with: + +- recommendations for Publishing tools to update how they should soft validate + the `license` and `classifier` fields to report informational warnings to user + when packages uses older style of license documentation conventions. + +- a reference library to parse and validate `License Expression` such that tools + can easily parse, validate and build correct license expressions. + +Finally it is the intent of the PEP authors to work closely with tools authors +to implement to recommended `License` field validation and warnings specified +in this PEP. + + +What this PEP is not about and possible future PEPs +=================================================== + +This PEP and its authors are neutral with regards to using this or that license. -- There are two overlapping places where a license can be documented leading to - confusion for packagers: license-related `Classifiers` and the `License` - attribute. +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 proprietary license. -- Furthermore, it is difficult to convey anything but simple licensing using - these two fields. License information expressiveness and clarity when creating - packages will help packagers and users alike. +Therefore this PEP makes no recommendation to force using certain licenses or +or even certain license documentation conventions and does not recommend any +license at all (including any license restriction when uploading to Pypi). -License expressions provide a better way to express the license of a -distribution using a well defined syntax and well known license ids from SPDX. +Instead it only enacts in documentation some common and/or improved practices +alreday in use, and recommend that Publishing tools should gently nag users with +informational warnings when they do not follow this PEP recommendations. -This PEP was started based on several discussions and in particular: +However, it is the intention of the authors of this PEP to consider further +related but separate PEPs in the future such as: + + - making the existing `License` and new `License-File` fields mandatory + including stricter enforcement in tools and in Pypi uploads. + + - restricting the upload of packages using non-FOSS (Free or open + source software) licenses to the public Pypi index. + + +Rationale +========= + +Software is licensed and providing accurate licensing information to Python +packages users is an important matter. Today, there are multiple places where +license is documented in package metadata and there are limitations to what can +be documented. This is often leading to confusion or a lack of clarity both for +package authors and package users. + +Several package authors have expressed difficulty and/or frustrations with the +possibilities to express licensing in package metadata. This also applies +to distro packager. This has triggered several license-related discussions and +issues and in particular: - ``_ - ``_ @@ -48,67 +99,200 @@ This PEP was started based on several discussions and in particular: - ``_ - ``_ +And on average, Python packages tend to have more ambiguous or missing license +information than other main application package formats (such as npm, Maven or +Gem) as can be seen of the `stats page of the ClearlyDefined project +_`. (ClearlyDefined is an open source project +to help improve clarity of other open source projecs and is incubating at the +`OSI _`. + +For reference, a mini survey of existing license metadata definitions in use in +Python today and documented in several other system/distro and application +package formats is provided at the bottom of this PEP. -Fields -====== +There are a few takeaways from this survey: + +- Many modern package formats use some form of license expression syntax to + optionally combine more than one license identifiers together. SPDX and + SPDX-like syntaxes are the most popular in use. + +- SPDX license ids are becomming a de-facto way to reference common licenses + everywhere, whether or not a license expression syntax is used. But they often + need to be supplemented with extra license ids or conventions to accept + extra or generic licenses such as "Proprietary" or "Public domain" not tracked + by SPDX. + +- Several package format support documenting both a license expression and + the paths of the corresponding files that contain the license text. Most + free and open source software licenses require to include their full text in + a distribution. + +These considerations have guided the updates proposed in this PEP. + +License expressions provide a simpler way to express the license of a +distribution using a well defined syntax and well known license ids. + +Over time, recommending the usage of these expressions will help Python +package publishers improve the clarity of their license documentation to the +benefit of packages authors, consumers and redistributors. + + +Core Metadata Specification updates +=================================== The canonical source for the names and semantics of each of the supported metadata fields is the `Core Metadata Specification`_ document. -The details for the update to the `Core Metadata Specification`_ document are -in this `Core Metadata Specification pull request`_. +The details of the updates considered to the `Core Metadata Specification`_ +document as part of his PEP are detailed here and will be added to the +canonical source once this PEP is approved. + + +Added in Version 2.2 +-------------------- + +License-File (multiple use) +::::::::::::::::::::::::::: + +The is a string that is a package-root relative path 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. + +Note that this is field already exists in `wheel` and `setuptools` with this +behaviour. Therefore this addition to the Core metadata is only recognizing +and documenting an existing practice as used in `wheels` (with the `license_file` +and `license_files` `setup.cfg` `[metadata]` entries) and in `setuptools` +`license_file` `setup()` argument. + + +Changed in Version 2.2 +---------------------- +License (optional) +:::::::::::::::::: -New in Version 2.2 ------------------- +Text indicating the license covering the distribution. This text can be either +a valid `License Expression` (as defined below) or any free text. -License-Expression (optional) -::::::::::::::::::::::::::::: +Publishing tools SHOULD issue an informational warning if this field is empty +or missing or is not a valid `License Expression` as defined here. Build tools +MAY issue such a warning too. -A string containing a license expression using the SPDX license expression -syntax and SPDX-listed license identifiers so that user can express accurately -the licensing of a package in a way that is both easy to read for humans and -easy to process automatically by tools. -A string containing a license expression using `SPDX license expression syntax and -identifiers `__ that indicates the license(s) covering the -distribution. The license expressions are specified in the `SPDX specification -`_. -SPDX also publishes a companion `list of license ids `_ -for use in license expressions. +License Expression +'''''''''''''''''' -Note: this field is not case sensitive though the normalized representation of -an SPDX license expression has a well defined case. +A `License Expression` is a string using the SPDX license expression syntax +as documented in the `SPDX specification`_ using either `Version 2.1 +`_ +or a later compatible version. + +As an extension to the SPDX license expression syntax, a `License Expression` can +use the following license identifiers: + +- any SPDX-listed license short-form identifiers that are published in the + `SPDX License List`_ using either Version 3.6 of this list or any later + compatible version. Note that the SPDX working group never removes any + license identifiers: instead they may only one as obsolete. + +- the `Public-Domain` and `Proprietary` strings to support generic ids that are + not available in the SPDX license list. + +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 field does not contain a license + expression or if the license expression syntax is invalid or the license + identifiers are unknown or the license identifiers have been marked as + obsolete in the `SPDX License List`_. + +- 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. + +License expression examples:: + + License: MIT + + License: BSD-3-Clause + + License: MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause) + + License: GPL-3.0-only WITH Classpath-Exception-2.0 OR BSD-3-Clause + + License: This software may only be obtained by sending the + author a postcard, and then the user promises not + to redistribute it. + + License: Proprietary AND Public-Domain + + +Classifier (multiple use) +::::::::::::::::::::::::: + +Each entry is a string giving a single classification value for the distribution. +Classifiers are described in PEP 301. Examples:: - License-Expression: BSD-3-Clause + Classifier: Development Status :: 4 - Beta + Classifier: Environment :: Console (Text Based) - License-Expression: MIT OR GPL-2.0-or-later AND (FSFUL AND BSD-2-Clause) +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. - License-Expression: GPL-3.0-or-later WITH Classpath-Exception-2.0 OR BSD-3-Clause +If the `License` field is present and contains a valid License Expression, +publishing tools MUST NOT also provide any licensing related Classifiers entries. +However, for compatibility with existing publishing and installation processes, +licensing related Classifiers entries SHOULD continue to be accepted if the +License field is absent or does not contain a valid License Expression. -Tools `should` validate that this field contains a valid license expression -and `should` report a warning if the field contains an invalid expression. +Publishing tools MAY infer a License Expression from the provided Classifiers +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 a +future PEP. -Changed in Version 2.2 ----------------------- -License -::::::: +Mapping legacy Classifiers to new License expressions +''''''''''''''''''''''''''''''''''''''''''''''''''''' -This field will be deprecated in the future and its documentation has been -updated accordingly. Tools are encouraged to provide a warning when this field -is used. +Publishing tools MAY infer or suggest an equivalent `License Expression` from +the provided License or Classifiers information if they are able to do so +unambiguously. For instance, if a package only has this license classifier:: -Classifiers -::::::::::: + Classifier: `License :: OSI Approved :: MIT License` -The use of license-related classifiers in this field will be deprecated in the -future and its documentation has been updated accordingly. Tools are encouraged -to provide a warning when this field is used with license-related classifiers. +Then the corresponding value for License using a valid license expression to +suggest would be:: + + License: MIT + + +Here are mappings guidelines for the legacy classifiers: + +- Classifier `License :: Other/Proprietary License` becomes License: `Proprietary` expression. + +- Classifier `License :: Public Domain` becomes License: `Public-Domain` 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`, `License :: Free for non-commercial use`, + `License :: Freely Distributable`, `License :: Free To Use But Restricted`, + and `License :: Freeware` are mapped to the generic License: `Proprietary` expression. + +The remainder of the `Classifiers` using a `License::` prefix map to a simple +single license expression using the corresponding SPDX license identifiers. Summary of Differences From PEP 566 @@ -116,26 +300,51 @@ Summary of Differences From PEP 566 * Metadata-Version is now 2.2. -* Added one new field: ``License-Expression`` +* Added one new field: ``License-File`` * Updated the documentation of two fields: ``License`` and ``Classifiers`` +License Expression Library Reference implementation +=================================================== + +To be succesful, `License Expression` need to be supported in tools. + +The `license-expression library`_ provides a Python reference implementation +library to handle `License Expressions` including parsing, validating and +formatting `License Expressions` using flexible list of license symbols +(including SPDX license identifiers and 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, the ScanCode toolkit and the FSFE Reuse.software +project. + +If this PEP is accepted, the Python packaging authority should consider +adopting the `license-expression library`_ as one of its own tools +_. + + References ========== This document specifies version 2.2 of the metadata format. -Version 1.0 is specified in PEP 241. -Version 1.1 is specified in PEP 314. -Version 1.2 is specified in PEP 345. -Version 2.0, while not formally accepted, was specified in PEP 426. -Version 2.1 is specified in PEP 566. + +- Version 1.0 is specified in PEP 241. +- Version 1.1 is specified in PEP 314. +- Version 1.2 is specified in PEP 345. +- Version 2.0, while not formally accepted, was specified in PEP 426. +- Version 2.1 is specified in PEP 566. .. _`Core Metadata Specification`: https://packaging.python.org/specifications/core-metadata/ -.. _`Core Metadata Specification pull request`: - https://github.com/pypa/packaging.python.org/pull/635/ +.. _`SPDX License List`: + https://spdx.org/licenses/ + +.. _`SPDX Specification`: + https://spdx.org/specifications + +.. _`license-expression library`: + https://github.com/nexB/license-expression/ Copyright @@ -148,6 +357,12 @@ CC0-1.0-Universal license, whichever is more permissive. Acknowledgements ================ +- Luis Villa +- Cyril Roelandt +- Kevin P. Fleming +- Nick Coghlan + + .. From 08859dc19ad17d437182f9170a536cfc70733b67 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Mon, 19 Aug 2019 08:37:32 +0200 Subject: [PATCH 09/40] Add packaging license metadata survey sections Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 288 ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 287 insertions(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index 0a6482093d6..bb18b188fc4 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -323,6 +323,293 @@ adopting the `license-expression library`_ as one of its own tools _. +Surveying how we document licenses today in Python +================================================== + +There are multiple ways used or recommended to document Python package +licenses today: + + +In Core metadata +---------------- + +There are two overlapping Core metadata fields to document a license: the +license-related `Classifiers _` prefixed with +`License::` and the `License +_` +field as free text. + +The Core metadata documentation `License` field documentation is currently:: + + License (optional) + :::::::::::::::::: + + Text indicating the license covering the distribution where the license + is not a selection from the "License" Trove classifiers. See + "Classifier" below. This field may also be used to specify a + particular version of a license which is named via the ``Classifier`` + field, or to indicate a variation or exception to such a license. + + Examples:: + + License: This software may only be obtained by sending the + author a postcard, and then the user promises not + to redistribute it. + + License: GPL version 3, excluding DRM provisions + +Even though there are two fields, it is at times difficult to convey anything +but simpler licensing. For instance some `Classifiers` lack accuracy (GPL +without a version) and when you have multiple License-related classifiers it is +not clear if this is a choice or all these apply and which ones. Furthermore, +the list of available license-related `Classifiers` is often out-of-date. + + +In the pypa sample project +-------------------------- + +The latest pypa sample project recommends only to use `Classifiers in setup.py +_` +and does not list the `license` field in its example `setup.py`. + + +The License files in wheels and setuptools +------------------------------------------ + +Betyond 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 `wheels _`, + license files are automatically added to the `.dist-info` directory if they + match one of a few common license file name patterns (e.g. LICENSE, COPYING). + Alternatively a package author can specify a list of license files paths to + include in the built whell 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 this is still in common use + (See for instance _ + + - In `setuptools _`, + a `license_file` attribute is use to add a single license file to a source + distribution. This singular version is still honored by `wheels` for backward + compability. + + - Using a `LICENSE.txt file _` + is encouraged in the packaging guide paired with a `MANIFEST.in` entry + to ensure that the license file is included in a built source distribution + (sdist). + + +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__`. +See https://github.com/search?l=Python&q=%22__license__%22&type=Code for examples. + +This convention (dunder global variables) is recognized by the built-in `help()` +function and the standard `pydoc` module. The dunder variable(s) will show up +in the help() DATA section for a module. + + +Surveying how other package formats document licenses +===================================================== + +Here is a quick survey of how things are done elsewhere. + +License in Linux distro packages +-------------------------------- + +Note: in most cases the license texts of the most common licenses are included +globally once in a shared documentation directory. + +- Debian document package licenses with `machine readable copyright files + _`. This specification + define its own license expression syntax very similar to the SDPX syntax and + a list of common license identifiers. + +- Fedora `RPM packages _` + specifies how to include `License Texts + _.` + and the `License + _` + field` that must be filled with an appropriate license Short License + identifier(s) from an extensive list of "Good Licenses" identifiers listed on + the `Fedora Licensing page + _`. + Fedora also defines ist own license expression syntax very similar to the SDPX syntax + +- OpenSuse `RPMs packages _` + use SPDX license expressions with a either SPDX license ids or list of extra + license ids that are `not listed in SPDX and or are mapped to SPDX ids + _`. + +- Gentoo ebuild use a `LICENSE variable _` + This field is specified in `GLEP-0023 _` + and in the `development manual _`. + Gentoo defines a license expressions syntax and a list of `allowed + licenses _`. The + expression syntax is rather different from SPDX. + +- FreeBSD `package Makefile + _` + provide a LICENSE and a LICENSE_FILE field with a list of custom license symbols. + For non-standard licenses, FreeBSD recommend to use LICENSE=UNKNOWN and + add LICENSE_NAME and LICENSE_TEXT fields, as well as sophisticated + LICENSE_PERMS to qualify the license permissoins and LICENSE_GROUPS to document + a license grouping. The LICENSE_COMB allows to document more than one license + and how they apply together, forming a custom license expression syntax. + FreeBSD also recommends the use of SPDX-License-Identifier in source code files. + +- Archlinux `PKGBUILD _ + defines its own `license identifiers + _`. It seesm validated + mandatory and 'unknown' can be used if the license is not defined. + +- OpenWRT `ipk packages _` + use PKG_LICENSE and PKG_LICENSE_FILES variables and recommend the use of + SPDX identifiers. + +- nixos `uses SPDX identifiers _` + and some extras custom license identifiers in its license field. + +- GUIX (based on nixos) has a single License field, uses its own `license symbols + list _ + and specifies to use `one license or a list of these + _`. + +- Alpine Linux `apk packages _` + recommend the use of SPDX identifiers in the license field. This is not validated. + + +License in Language and Application packages +-------------------------------------------- + +- `pbr _` uses the + same data as setuptools but always stored setup.cfg. + +- Conda `package manifest _` + has support for a license and a license_file field as well as a + `license_family` grouping. + +- In Java, `Maven POM _` defines a + licenses XML tag with a list of license items each with name, url, comments + and "disribution" type. This is not mandatory and the content of each field is + not specified. + +- JavaScript `npm package.json _` + use a single license field with SPDX license expression or the `UNLICENSED` + identifier if no license is specified. A license file can be referenced as an + alternative using "SEE LICENSE IN ". + +- Rubygems `gemspec _` + specifies a singular license string or a list of licenses strings. The relationship + between multiple license is not specified. They recommend using SPDX license identifiers + +- CPAN Perl `modules _` use + a single license field wich 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 these generic ids: + open_source, restricted, unrestricted, unknown. + +- Rust `Cargo _` + specifies the use an SPDX license expession (v2.1) in the license field. + They also support an alternative expression synatx using slash-separated + SPDX license ids. There is a license_file field too. + The crates.io `package registry + +` + requires that either `license` or `license_file` is set when you upload a + package. + +- PHP Composer `composer.json _` + is overall similar to the npm package.json, but license information is different. + They use an SPDX License identifiers or "proprietary". + The License field is either a single string that can use something + which resemble SPDX license expression syntax with "and" and "or" keywords; + or this is a list of strings if there is a choice of licenses (aka. "disjunctive"). + +- NuGet `packages _` + were using only a simple license URL and are now specifying to use an SPDX + License expressions and/or the path to a license file within the package. + The NuGet.org repository states that they only accepts license expressions + that are approved by the Open Source Initiative or the Free Software Foundation. + +- Golang has no provision for any metadata beside what is needed for dependencies. + Licensing is left to community package managers. + +- Dart/Flutter `spec _` + recommends to use a single LICENSE file that should contain multiple + license texts each separated by a line with 80 hyphens. + +- JavaScript Bower `bower.json _` + license field is either a single string or a list of strings using either + SPDX license identifier or path/url to a license. + +- Cocoaposds `podspec _` + license is either a single string or a mapping with type, file an text keys. + This is mandatory unless there is a LICENSE/LICENCE fie provided. + +- Haskell `Cabal _` + specified a single string with a list of accepted licenses. And also provides + a `mapping between their license and SPDX identifiers + _`. + +- Erlang/Elixir `mix/hex package ` specifies a + licenses field as a required list of license srtings. It is recommended to + use SPDX License identifier. + +- D lang `dub packages _` + define their own list of license identifiers and their own license expression + syntax: both are very similar to SPDX conventions. + +- R Package `DESCRIPTION _` + defines its own sophisticated license expression syntax and list of licenses. + R has a unique way to support specifiers for license versions such as `LGPL (>= 2.0, < 3)` + in its license expression syntax. + + +Some convention used elsewhere +------------------------------ + +- `SPDX-License-Identifier _` is + simple convention to document license inside a code file. + +- The Free Software Foundation (FSF) promotes using SPDX license ids for clarity + in the GPL and other versioned free software licenses. + See https://www.gnu.org/licenses/identify-licenses-clearly.html + amd https://www.fsf.org/blogs/rms/rms-article-for-claritys-sake-please-dont-say-licensed-under-gnu-gpl-2 + +- The Free Software Foundation Europe (FSFE) `Reuse project + _` promotes using SPDX-License-Identifier. + +- The Linux kernel uses SPDX-License-Identifier and parts of the FSFE Reuse + conventions. + See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst + +- U-Boot spearheaded using SPDX license identifiers in code and now follows the + Linux ways https://www.denx.de/wiki/U-Boot/Licensing + +- The Apache Software Foundation projects use RDF DOAP + such as in https://svn.apache.org/repos/asf/allura/doap_Allura.rdf + with a single license field pointing to SPDX license ids. + +- The Eclipse Foundation promotes using file-level SPDX-license-Identifiers. + +- The `ClearlyDefined project _` promotes using + SPDX license ids and expressions to improve license clarity. + +- The Android Open Source Project use MODULE_LICENSE_XXX empty tag files where + XXX is a license code such as + `BSD _`, + APACHE, GPL, etc. and LICENSE file. + + + + References ========== @@ -363,7 +650,6 @@ Acknowledgements - Nick Coghlan - .. Local Variables: From 89fad3b30a20cedc78deffbdf63292402128e9d7 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Mon, 19 Aug 2019 08:56:25 +0200 Subject: [PATCH 10/40] Add poetry and flit references CC: @takluyver and @sdispater Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index bb18b188fc4..5f75207990b 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -416,6 +416,23 @@ function and the standard `pydoc` module. The dunder variable(s) will show up in the help() DATA section for a module. +In some other packaging tools +----------------------------- + +- Conda `package manifest _` + has support for a license and a license_file field as well as a + `license_family` grouping. + +- `flit _` recommends to use Classifiers + instead of License (per the current metadata spec). + +- `pbr _` uses the + same data as setuptools but always stored setup.cfg. + +- poetry specifies the use of the `license _` + field in pyproject.toml with SPDX license ids. + + Surveying how other package formats document licenses ===================================================== @@ -489,13 +506,6 @@ globally once in a shared documentation directory. License in Language and Application packages -------------------------------------------- -- `pbr _` uses the - same data as setuptools but always stored setup.cfg. - -- Conda `package manifest _` - has support for a license and a license_file field as well as a - `license_family` grouping. - - In Java, `Maven POM _` defines a licenses XML tag with a list of license items each with name, url, comments and "disribution" type. This is not mandatory and the content of each field is From dbde90a100aba961c87fff96bc3f12a67d1ec305 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Mon, 19 Aug 2019 14:56:12 +0200 Subject: [PATCH 11/40] Fix typo Reported-by: Pradyun Gedam @pradyunsg Signed-off-by: Philippe Ombredanne Co-Authored-By: Pradyun Gedam --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index 5f75207990b..82e5596e01c 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -31,7 +31,7 @@ license documentation is simpler and less ambiguous: - for tools to process package license information mechanically. These changes have been designed have a minimal impact and to be backward -compatible with v2.1. They are embrassing emerging new ways to document licenses +compatible with v2.1. They are embracing emerging new ways to document licenses that are already in use in some tools (e.g. `license_file` field) or by some authors (e.g. license expressions in the `license` field). All the packages that conform with the v2.1 of core metadata specification are also conformaing and From b0681c406f689d51e862c41c7246136428241be0 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Mon, 19 Aug 2019 14:56:12 +0200 Subject: [PATCH 12/40] Fix typo and improve subtitle Reported-by: Pradyun Gedam Co-Authored-By: Pradyun Gedam Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index 82e5596e01c..0fe46724e9f 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -308,7 +308,7 @@ Summary of Differences From PEP 566 License Expression Library Reference implementation =================================================== -To be succesful, `License Expression` need to be supported in tools. +To be succesfull, `License Expression` need to be supported in tools. The `license-expression library`_ provides a Python reference implementation library to handle `License Expressions` including parsing, validating and @@ -376,7 +376,7 @@ and does not list the `license` field in its example `setup.py`. The License files in wheels and setuptools ------------------------------------------ -Betyond a license code or qualifier, license text files are documented and +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: @@ -582,8 +582,8 @@ License in Language and Application packages in its license expression syntax. -Some convention used elsewhere ------------------------------- +Conventions used by other ecosystems +------------------------------------ - `SPDX-License-Identifier _` is simple convention to document license inside a code file. From 5ebad29649ef2d222c2d903f967d008675958853 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Mon, 19 Aug 2019 15:07:19 +0200 Subject: [PATCH 13/40] Fix typo Reported-by: Pradyun Gedam Signed-off-by: Philippe Ombredanne Co-Authored-By: Pradyun Gedam --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index 0fe46724e9f..917049c3dad 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -116,7 +116,7 @@ There are a few takeaways from this survey: optionally combine more than one license identifiers together. SPDX and SPDX-like syntaxes are the most popular in use. -- SPDX license ids are becomming a de-facto way to reference common licenses +- SPDX license ids are becoming a de-facto way to reference common licenses everywhere, whether or not a license expression syntax is used. But they often need to be supplemented with extra license ids or conventions to accept extra or generic licenses such as "Proprietary" or "Public domain" not tracked From fb91d460ea4bfd5e6cebc56ea7a617f341df541d Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Mon, 19 Aug 2019 15:08:24 +0200 Subject: [PATCH 14/40] Fix typo Reported-by: Pradyun Gedam Co-Authored-By: Pradyun Gedam Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index 917049c3dad..a078e8dd641 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -308,7 +308,7 @@ Summary of Differences From PEP 566 License Expression Library Reference implementation =================================================== -To be succesfull, `License Expression` need to be supported in tools. +To be successfull, `License Expression` need to be supported in tools. The `license-expression library`_ provides a Python reference implementation library to handle `License Expressions` including parsing, validating and From 3824483edc13439034e2858c181b272e220a877b Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Sun, 25 Aug 2019 22:59:39 +0200 Subject: [PATCH 15/40] Use appendix and use footnotes for links Also improve formatting Reported-by: Pradyun Gedam @pradyunsg Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 626 ++++++++++++++++++++++++++------------------------- 1 file changed, 322 insertions(+), 304 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index a078e8dd641..67c9c2b6fd1 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -20,9 +20,10 @@ Abstract ======== This PEP describes the changes between versions 2.1 and 2.2 of the `Core -Metadata Specification`_ for Python packages. Version 2.1 is specified in PEP 566. +Metadata Specification` [#cms]_ for Python packages. Version 2.1 is specified in +PEP 566. -The changes introduced in this PEP update how license is documented in Core +The main change introduced in this PEP update how license is documented in Core metadata using simple yet rich `SPDX License Expression` strings such that license documentation is simpler and less ambiguous: @@ -33,22 +34,23 @@ license documentation is simpler and less ambiguous: These changes have been designed have a minimal impact and to be backward compatible with v2.1. They are embracing emerging new ways to document licenses that are already in use in some tools (e.g. `license_file` field) or by some -authors (e.g. license expressions in the `license` field). All the packages that -conform with the v2.1 of core metadata specification are also conformaing and -valid with this v2.2. +authors (e.g. using SPDX license expressions in the `license` field). All the +packages that conform with the v2.1 of core metadata specification are also +conformaing and valid with this v2.2 core metadata specification. -Beyond this Core metadata specification update, this PEP comes with: +Beyond this metadata specification update, this PEP contains: -- recommendations for Publishing tools to update how they should soft validate - the `license` and `classifier` fields to report informational warnings to user - when packages uses older style of license documentation conventions. +- recommendations for Publishing to soft validate the `License` and `Classifier` + fields and report informational warnings when a package uses an older, + non-structured style of license documentation conventions. -- a reference library to parse and validate `License Expression` such that tools - can easily parse, validate and build correct license expressions. +- informational appendixes that contain surveys of how we document license + today in Python packages and elewhere, and a Python library to parse, validate + and and build correct license expressions. Finally it is the intent of the PEP authors to work closely with tools authors -to implement to recommended `License` field validation and warnings specified -in this PEP. +to implement to recommended `License` field validation and warnings specified in +this PEP. What this PEP is not about and possible future PEPs @@ -61,22 +63,22 @@ 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 proprietary license. -Therefore this PEP makes no recommendation to force using certain licenses or -or even certain license documentation conventions and does not recommend any +Therefore this PEP makes no recommendation to force using certain licenses or or +even certain license documentation conventions and does not recommend any license at all (including any license restriction when uploading to Pypi). Instead it only enacts in documentation some common and/or improved practices -alreday in use, and recommend that Publishing tools should gently nag users with +already in use, and recommend that Publishing tools should gently nag users with informational warnings when they do not follow this PEP recommendations. However, it is the intention of the authors of this PEP to consider further related but separate PEPs in the future such as: - - making the existing `License` and new `License-File` fields mandatory - including stricter enforcement in tools and in Pypi uploads. + - make the existing `License` and new `License-File` fields mandatory + including stricter enforcement in tools and Pypi publishing. - - restricting the upload of packages using non-FOSS (Free or open - source software) licenses to the public Pypi index. + - restrict the upload of packages to the public Pypi index to the packaes using + only FOSS (Free and open source software) licenses. Rationale @@ -89,26 +91,27 @@ 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 distro packager. This has triggered several license-related discussions and -issues and in particular: - -- ``_ -- ``_ -- ``_ -- ``_ -- ``_ - -And on average, Python packages tend to have more ambiguous or missing license -information than other main application package formats (such as npm, Maven or -Gem) as can be seen of the `stats page of the ClearlyDefined project -_`. (ClearlyDefined is an open source project -to help improve clarity of other open source projecs and is incubating at the -`OSI _`. +possibilities to express licensing in package metadata. This also applies to +Liux distribution packagers. This has triggered several license-related +discussions and issues and in particular: + +- https://github.com/pypa/warehouse/issues/2996 +- https://github.com/pypa/interoperability-peps/issues/46 +- https://github.com/pypa/packaging-problems/issues/41 +- https://github.com/pypa/wheel/issues/138 +- https://github.com/pombredanne/spdx-pypi-pep/issues/1 + +On average, Python packages tend to have more ambiguous or missing license +information than other common application package formats (such as npm, Maven or +Gem) as can be seen in the statistics [#cdstats]_ page of the ClearlyDefined +[#cd]_ project that cover all packages from Pypi, Maven, npm and Rubygems. +ClearlyDefined is an open source project to help improve clarity of other open +source projecs and is incubating at the OSI (Open Source Initiative) [#osi]_. For reference, a mini survey of existing license metadata definitions in use in Python today and documented in several other system/distro and application -package formats is provided at the bottom of this PEP. +package formats is provided as an informative Appendinx at the bottom of this +PEP. There are a few takeaways from this survey: @@ -118,32 +121,32 @@ There are a few takeaways from this survey: - SPDX license ids are becoming a de-facto way to reference common licenses everywhere, whether or not a license expression syntax is used. But they often - need to be supplemented with extra license ids or conventions to accept - extra or generic licenses such as "Proprietary" or "Public domain" not tracked - by SPDX. + need to be supplemented with extra license ids or conventions to accept extra + or generic licenses such as "Proprietary" or "Public domain" not tracked by + SPDX. - Several package format 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. + the paths of the corresponding files that contain the license text. Most free + and open source software licenses require to include their full text in a + distribution. These considerations have guided the updates proposed in this PEP. License expressions provide a simpler way to express the license of a distribution using a well defined syntax and well known license ids. -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. +Over time, recommending the usage of these expressions will help Python package +publishers improve the clarity of their license documentation to the benefit of +packages authors, consumers and redistributors. Core Metadata Specification updates =================================== The canonical source for the names and semantics of each of the supported -metadata fields is the `Core Metadata Specification`_ document. +metadata fields is the Core Metadata Specification [#cms]_ document. -The details of the updates considered to the `Core Metadata Specification`_ +The details of the updates considered to the Core Metadata Specification [#cms]_ document as part of his PEP are detailed here and will be added to the canonical source once this PEP is approved. @@ -157,12 +160,12 @@ License-File (multiple use) The is a string that is a package-root relative path 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. +Build tools should honor this field and include the corresponding license +file(s) in the built package. Note that this is field already exists in `wheel` and `setuptools` with this -behaviour. Therefore this addition to the Core metadata is only recognizing -and documenting an existing practice as used in `wheels` (with the `license_file` +behaviour. Therefore this addition to the Core metadata is only recognizing and +documenting an existing practice as used in `wheels` (with the `license_file` and `license_files` `setup.cfg` `[metadata]` entries) and in `setuptools` `license_file` `setup()` argument. @@ -173,28 +176,27 @@ Changed in Version 2.2 License (optional) :::::::::::::::::: -Text indicating the license covering the distribution. This text can be either -a valid `License Expression` (as defined below) or any free text. +Text indicating the license covering the distribution. This text can be either a +valid `License Expression` (as defined below) or any free text. -Publishing tools SHOULD issue an informational warning if this field is empty -or missing or is not a valid `License Expression` as defined here. Build tools -MAY issue such a warning too. +Publishing tools SHOULD issue an informational warning if this field is empty or +missing or is not a valid `License Expression` as defined here. Build tools MAY +issue such a warning too. License Expression '''''''''''''''''' -A `License Expression` is a string using the SPDX license expression syntax -as documented in the `SPDX specification`_ using either `Version 2.1 -`_ -or a later compatible version. +A `License Expression` is a string using the SPDX license expression syntax as +documented in the SPDX specification [#spdx]_ using either Version 2.1 +[#spdx21]_ or a later compatible version. -As an extension to the SPDX license expression syntax, a `License Expression` can -use the following license identifiers: +As an extension to the SPDX license expression syntax, a `License Expression` +can use the following license identifiers: - any SPDX-listed license short-form identifiers that are published in the - `SPDX License List`_ using either Version 3.6 of this list or any later - compatible version. Note that the SPDX working group never removes any + SPDX License List [#spdxlist]_ using either Version 3.6 of this list or any + later compatible version. Note that the SPDX working group never removes any license identifiers: instead they may only one as obsolete. - the `Public-Domain` and `Proprietary` strings to support generic ids that are @@ -208,7 +210,7 @@ expression, tools: - SHOULD report an informational warning if field does not contain a license expression or if the license expression syntax is invalid or the license identifiers are unknown or the license identifiers have been marked as - obsolete in the `SPDX License List`_. + obsolete 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 @@ -234,20 +236,21 @@ License expression examples:: Classifier (multiple use) ::::::::::::::::::::::::: -Each entry is a string giving a single classification value for the distribution. -Classifiers are described in PEP 301. +Each entry is a string giving a single classification value for the +distribution. Classifiers are described in PEP 301. Examples:: Classifier: Development Status :: 4 - Beta Classifier: Environment :: Console (Text Based) -Tools SHOULD issue an informational warning if this field contains a -licensing related Classifier string starting with the `License::` prefix and -SHOULD suggest the use of a `License Expression` in the `License` field instead. +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 Classifiers entries. +publishing tools MUST NOT also provide any licensing related Classifiers entries +[#classif]_. However, for compatibility with existing publishing and installation processes, licensing related Classifiers entries SHOULD continue to be accepted if the @@ -289,7 +292,8 @@ Here are mappings guidelines for the legacy classifiers: - The generic and sometimes ambiguous Classifiers `License :: Free For Educational Use`, `License :: Free For Home Use`, `License :: Free for non-commercial use`, `License :: Freely Distributable`, `License :: Free To Use But Restricted`, - and `License :: Freeware` are mapped to the generic License: `Proprietary` expression. + and `License :: Freeware` are mapped to the generic License: `Proprietary` + expression. The remainder of the `Classifiers` using a `License::` prefix map to a simple single license expression using the corresponding SPDX license identifiers. @@ -299,32 +303,27 @@ Summary of Differences From PEP 566 =================================== * Metadata-Version is now 2.2. - * Added one new field: ``License-File`` - * Updated the documentation of two fields: ``License`` and ``Classifiers`` -License Expression Library Reference implementation -=================================================== +Appendix 1. License Expression Library sample implementation +============================================================ -To be successfull, `License Expression` need to be supported in tools. +To be successfull, tools need to support parsing and validating `License +Expressions`. -The `license-expression library`_ provides a Python reference implementation +The `license-expression library` [#licexp]_ provides a Python implementation library to handle `License Expressions` including parsing, validating and formatting `License Expressions` using flexible list of license symbols -(including SPDX license identifiers and 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, the ScanCode toolkit and the FSFE Reuse.software -project. - -If this PEP is accepted, the Python packaging authority should consider -adopting the `license-expression library`_ as one of its own tools -_. +(including SPDX license identifiers and 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, the ScanCode toolkit and the FSFE Reuse project +[#reuse]_. -Surveying how we document licenses today in Python -================================================== +Appendix 2. Surveying how we document licenses today in Python +============================================================== There are multiple ways used or recommended to document Python package licenses today: @@ -334,10 +333,9 @@ In Core metadata ---------------- There are two overlapping Core metadata fields to document a license: the -license-related `Classifiers _` prefixed with -`License::` and the `License -_` -field as free text. +license-related `Classifiers` strings [#classif]_ prefixed with `License::` and +the `License` field as free text [#licfield]_. + The Core metadata documentation `License` field documentation is currently:: @@ -368,9 +366,8 @@ the list of available license-related `Classifiers` is often out-of-date. In the pypa sample project -------------------------- -The latest pypa sample project recommends only to use `Classifiers in setup.py -_` -and does not list the `license` field in its example `setup.py`. +The latest pypa sample project recommends only to use Classifiers in setup.py +and does not list the `license` field in its example `setup.py` [#samplesetup]_. The License files in wheels and setuptools @@ -380,25 +377,22 @@ 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 `wheels _`, - license files are automatically added to the `.dist-info` directory if they - match one of a few common license file name patterns (e.g. LICENSE, COPYING). - Alternatively a package author can specify a list of license files paths to - include in the built whell 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 this is still in common use - (See for instance _ +- 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 (e.g. + LICENSE, COPYING). Alternatively a package author can specify a list of + license files paths to include in the built whell 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 this is still in common use. See [#pipsetup]_ for + instance. - - In `setuptools _`, - a `license_file` attribute is use to add a single license file to a source - distribution. This singular version is still honored by `wheels` for backward - compability. +- In setuptools [#setuptoolssdist]_, a `license_file` attribute is use to add + a single license file to a source distribution. This singular version is + still honored by `wheels` for backward compability. - - Using a `LICENSE.txt file _` - is encouraged in the packaging guide paired with a `MANIFEST.in` entry - to ensure that the license file is included in a built source distribution - (sdist). +- Using a LICENSE.txt file [#packaging]_ is encouraged in the packaging guide + paired with a `MANIFEST.in` entry to ensure that the license file is included + in a built source distribution (sdist). In Python code files @@ -406,218 +400,186 @@ 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__`. -See https://github.com/search?l=Python&q=%22__license__%22&type=Code for examples. +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__` +[#pycode]_. This convention (dunder global variables) is recognized by the built-in `help()` -function and the standard `pydoc` module. The dunder variable(s) will show up -in the help() DATA section for a module. +function and the standard `pydoc` module. The dunder variable(s) will show up in +the help() DATA section for a module. In some other packaging tools ----------------------------- -- Conda `package manifest _` - has support for a license and a license_file field as well as a - `license_family` grouping. +- Conda package manifest [#conda]_ has support for `license` and`license_file` + fields as well as a `license_family` license grouping field. -- `flit _` recommends to use Classifiers - instead of License (per the current metadata spec). +- flit [#flit]_ recommends to use Classifiers instead of License (as per the + current metadata spec). -- `pbr _` uses the - same data as setuptools but always stored setup.cfg. +- pbr [#pbr]_ uses similar data as setuptools but always stored setup.cfg. -- poetry specifies the use of the `license _` - field in pyproject.toml with SPDX license ids. +- poetry [#poetry]_ specifies the use of the `license ` field in + `pyproject.toml` with SPDX license ids. -Surveying how other package formats document licenses -===================================================== +Appendix 3. Surveying how other package formats document licenses +================================================================= -Here is a quick survey of how things are done elsewhere. +Here is a survey of how things are done elsewhere. -License in Linux distro packages --------------------------------- +License in Linux distroibution packages +--------------------------------------- Note: in most cases the license texts of the most common licenses are included -globally once in a shared documentation directory. - -- Debian document package licenses with `machine readable copyright files - _`. This specification - define its own license expression syntax very similar to the SDPX syntax and - a list of common license identifiers. - -- Fedora `RPM packages _` - specifies how to include `License Texts - _.` - and the `License - _` - field` that must be filled with an appropriate license Short License - identifier(s) from an extensive list of "Good Licenses" identifiers listed on - the `Fedora Licensing page - _`. - Fedora also defines ist own license expression syntax very similar to the SDPX syntax - -- OpenSuse `RPMs packages _` - use SPDX license expressions with a either SPDX license ids or list of extra - license ids that are `not listed in SPDX and or are mapped to SPDX ids - _`. - -- Gentoo ebuild use a `LICENSE variable _` - This field is specified in `GLEP-0023 _` - and in the `development manual _`. - Gentoo defines a license expressions syntax and a list of `allowed - licenses _`. The - expression syntax is rather different from SPDX. - -- FreeBSD `package Makefile - _` - provide a LICENSE and a LICENSE_FILE field with a list of custom license symbols. - For non-standard licenses, FreeBSD recommend to use LICENSE=UNKNOWN and - add LICENSE_NAME and LICENSE_TEXT fields, as well as sophisticated - LICENSE_PERMS to qualify the license permissoins and LICENSE_GROUPS to document - a license grouping. The LICENSE_COMB allows to document more than one license - and how they apply together, forming a custom license expression syntax. - FreeBSD also recommends the use of SPDX-License-Identifier in source code files. - -- Archlinux `PKGBUILD _ - defines its own `license identifiers - _`. It seesm validated - mandatory and 'unknown' can be used if the license is not defined. - -- OpenWRT `ipk packages _` - use PKG_LICENSE and PKG_LICENSE_FILES variables and recommend the use of - SPDX identifiers. - -- nixos `uses SPDX identifiers _` - and some extras custom license identifiers in its license field. - -- GUIX (based on nixos) has a single License field, uses its own `license symbols - list _ - and specifies to use `one license or a list of these - _`. - -- Alpine Linux `apk packages _` - recommend the use of SPDX identifiers in the license field. This is not validated. +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 ids. + +- Fedora RPM packages [#fedora]_ specifies 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 ist own + license expression syntax very similar to the SDPX syntax. + +- OpenSuse RPMs packages [#opensuse]_ use SPDX license expressions with a either + SPDX license ids and a list of extra license ids [#opensuselist]_. + +- Gentoo ebuild use 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 + 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 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 + permissoins and LICENSE_GROUPS to document a license grouping. The + LICENSE_COMB allows to document more than one license and how they apply + together, forming a custom license expression syntax. FreeBSD also recommends + the use of SPDX-License-Identifier in source code files. + +- Archlinux PKGBUILD [#archinux]_ define its own license identifiers + [#archlinuxlist]_. 'unknown' can be used if the license is not defined. + +- OpenWRT ipk packages [#openwrt]_ use the `PKG_LICENSE` and `PKG_LICENSE_FILES` + variables and recommend the use of SPDX License ids. + +- nixos uses SPDX identifiers [#nixos]_ and some extras license identifiers in + its license field. + +- GUIX (based on nixos) has a single License field, uses its own license + symbols list [#guix]_ and specifies to use one license or a list of licenses + [#guixlic]_. +- Alpine Linux apk packages [#alpine]_ recommend using SPDX identifiers in its + license field. License in Language and Application packages -------------------------------------------- -- In Java, `Maven POM _` defines a - licenses XML tag with a list of license items each with name, url, comments - and "disribution" type. This is not mandatory and the content of each field is - not specified. - -- JavaScript `npm package.json _` - use a single license field with SPDX license expression or the `UNLICENSED` - identifier if no license is specified. A license file can be referenced as an - alternative using "SEE LICENSE IN ". - -- Rubygems `gemspec _` - specifies a singular license string or a list of licenses strings. The relationship - between multiple license is not specified. They recommend using SPDX license identifiers - -- CPAN Perl `modules _` use - a single license field wich 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 these generic ids: - open_source, restricted, unrestricted, unknown. - -- Rust `Cargo _` - specifies the use an SPDX license expession (v2.1) in the license field. - They also support an alternative expression synatx using slash-separated - SPDX license ids. There is a license_file field too. - The crates.io `package registry - +` - requires that either `license` or `license_file` is set when you upload a - package. - -- PHP Composer `composer.json _` - is overall similar to the npm package.json, but license information is different. - They use an SPDX License identifiers or "proprietary". - The License field is either a single string that can use something - which resemble SPDX license expression syntax with "and" and "or" keywords; - or this is a list of strings if there is a choice of licenses (aka. "disjunctive"). - -- NuGet `packages _` - were using only a simple license URL and are now specifying to use an SPDX - License expressions and/or the path to a license file within the package. - The NuGet.org repository states that they only accepts license expressions - that are approved by the Open Source Initiative or the Free Software Foundation. - -- Golang has no provision for any metadata beside what is needed for dependencies. - Licensing is left to community package managers. - -- Dart/Flutter `spec _` - recommends to use a single LICENSE file that should contain multiple - license texts each separated by a line with 80 hyphens. - -- JavaScript Bower `bower.json _` - license field is either a single string or a list of strings using either - SPDX license identifier or path/url to a license. - -- Cocoaposds `podspec _` - license is either a single string or a mapping with type, file an text keys. - This is mandatory unless there is a LICENSE/LICENCE fie provided. - -- Haskell `Cabal _` - specified a single string with a list of accepted licenses. And also provides - a `mapping between their license and SPDX identifiers - _`. - -- Erlang/Elixir `mix/hex package ` specifies a - licenses field as a required list of license srtings. It is recommended to - use SPDX License identifier. - -- D lang `dub packages _` - define their own list of license identifiers and their own license expression - syntax: both are very similar to SPDX conventions. - -- R Package `DESCRIPTION _` - defines its own sophisticated license expression syntax and list of licenses. - R has a unique way to support specifiers for license versions such as `LGPL (>= 2.0, < 3)` - in its license expression syntax. +- In Java, Maven POM [#maven]_ defines a licenses XML tag with a list of license + items each with name, url, comments and "disribution" type. This is not + mandatory and the content of each field is not specified. + +- JavaScript npm package.json [#npm]_ use a single license field with SPDX + license expression or the `UNLICENSED` id if no license 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 singular license string for a list + of licenses strings. The relationship between multiple licenses in a list is + not specified. They recommend using SPDX license ids. + +- CPAN Perl modules [#perl]_ use a single license field wich 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 + these generic ids: open_source, restricted, unrestricted, unknown. + +- Rust Cargo [#cargo]_ specifies the use an SPDX license expession (v2.1) in the + license field. They also support an alternative expression synatx using slash- + separated SPDX license ids. There is a license_file field too. The crates.io + package registry [#cratesio]_ requires that either `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 SPDX license expression syntax with "and" and + "or" keywords; or this is a list of strings if there is a choice of licenses + (aka. a "disjunctive" choice of license). + +- NuGet packages [#nuget]_ were using only a simple license URL and are now + specifying to use an SPDX License expressions and/or the path to a license + file within the package. The NuGet.org repository states that they only + accepts license expressions that are `approved by the Open Source Initiative + or the Free Software Foundation.` + +- Golang has no provision for any metadata beyond dependencies. Licensing + information is left to community package managers. + +- Dart/Flutter spec [#flutter]_ recommends to use a single LICENSE file that + should contain multiple license texts each separated by a line with 80 + hyphens. + +- JavaScript Bower [#bower]_ license field is either a single string or a list + of strings using either SPDX license identifier or a path or a URL to a + license file. + +- Cocoapods podspec [#cocoapod]_ license is either a single string or a mapping + with type, file an text keys. This is mandatory unless there is a LICENSE or + LICENCE fie provided. + +- Haskell Cabal [#cabal]_ specifies a single string with a list of accepted + licenses. And also provides a mapping between their license and SPDX license + ids [#caballist]_. + +- Erlang/Elixir mix/hex package [#mix]_ specifies a licenses field as a required + list of license srtings and recommends to use SPDX License ids. + +- D lang dub packages [#dub]_ define their own list of license identifiers and + their own license expression syntax: both are very similar to SPDX + conventions. + +- R Package DESCRIPTION [#cran]_ defines its own sophisticated license + expression syntax and list of licenses. R has a unique way to support + specifiers for license versions such as `LGPL (>= 2.0, < 3)` in its license + expression syntax. Conventions used by other ecosystems ------------------------------------ -- `SPDX-License-Identifier _` is - simple convention to document license inside a code file. +- `SPDX-License-Identifier` [#spdxids]_ is simple convention to document the + license inside a code file. - The Free Software Foundation (FSF) promotes using SPDX license ids for clarity - in the GPL and other versioned free software licenses. - See https://www.gnu.org/licenses/identify-licenses-clearly.html - amd https://www.fsf.org/blogs/rms/rms-article-for-claritys-sake-please-dont-say-licensed-under-gnu-gpl-2 + in the GPL and other versioned free software licenses [#gnu]_ [#fsf]_. -- The Free Software Foundation Europe (FSFE) `Reuse project - _` promotes using SPDX-License-Identifier. +- The Free Software Foundation Europe (FSFE) Reuse project [#reuse]_ promotes + using `SPDX-License-Identifier`. -- The Linux kernel uses SPDX-License-Identifier and parts of the FSFE Reuse - conventions. - See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst +- The Linux kernel uses `SPDX-License-Identifier` and parts of the FSFE Reuse + conventions to document its license(s) [#linux]_. - U-Boot spearheaded using SPDX license identifiers in code and now follows the - Linux ways https://www.denx.de/wiki/U-Boot/Licensing + Linux ways [#uboot]_. -- The Apache Software Foundation projects use RDF DOAP - such as in https://svn.apache.org/repos/asf/allura/doap_Allura.rdf - with a single license field pointing to SPDX license ids. +- The Apache Software Foundation projects use RDF DOAP [#apache]_ with a single + license field pointing to SPDX license ids. -- The Eclipse Foundation promotes using file-level SPDX-license-Identifiers. +- The Eclipse Foundation promotes using `SPDX-license-Identifiers` [#eclipse]_ -- The `ClearlyDefined project _` promotes using - SPDX license ids and expressions to improve license clarity. +- The ClearlyDefined project [#cd]_ promotes using SPDX license ids and + expressions to improve license clarity. - The Android Open Source Project use MODULE_LICENSE_XXX empty tag files where - XXX is a license code such as - `BSD _`, - APACHE, GPL, etc. and LICENSE file. - - + XXX is a license code such as BSD [#android]_, APACHE, GPL, etc. a NOTICE file + for license text. References @@ -631,33 +593,89 @@ This document specifies version 2.2 of the metadata format. - Version 2.0, while not formally accepted, was specified in PEP 426. - Version 2.1 is specified in PEP 566. -.. _`Core Metadata Specification`: - https://packaging.python.org/specifications/core-metadata/ - -.. _`SPDX License List`: - https://spdx.org/licenses/ - -.. _`SPDX Specification`: - https://spdx.org/specifications - -.. _`license-expression library`: - https://github.com/nexB/license-expression/ +.. [#cms] Live Core Metadata specification web page https://packaging.python.org/specifications/core-metadata +.. [#cdstats] ClearlyDefined project statistics page https://clearlydefined.io/stats +.. [#cd] ClearlyDefined https://clearlydefined.io +.. [#osi] OSI http://opensource.org +.. [#classif] https://pypi.org/classifiers +.. [#spdxlist] https://spdx.org/licenses +.. [#spdx] https://spdx.org +.. [#spdx21] https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60 +.. [#wheels] https://github.com/pypa/wheel/blob/b8b21a5720df98703716d3cd981d8886393228fa/docs/user_guide.rst#including-license-files-in-the-generated-wheel-file +.. [#reuse] https://reuse.software/ +.. [#licexp] https://github.com/nexB/license-expression/ +.. [#licfield] https://packaging.python.org/guides/distributing-packages-using-setuptools/?highlight=MANIFEST.in#license +.. [#samplesetup] https://github.com/pypa/sampleproject/blob/b0d3f3eeef4e5668d7b59448b43c0f1914d9afc6/setup.py#L103 +.. [#pipsetup] https://github.com/pypa/pip/blob/476606425a08c66b9c9d326994ff5cf3f770926a/setup.cfg#L40 +.. [#setuptoolssdist] https://github.com/pypa/setuptools/blob/97e8ad4f5ff7793729e9c8be38e0901e3ad8d09e/setuptools/command/sdist.py#L202 +.. [#packaging] https://packaging.python.org/guides/distributing-packages-using-setuptools/?highlight=MANIFEST.in#license-txt +.. [#pycode] https://github.com/search?l=Python&q=%22__license__%22&type=Code +.. [#conda] https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#about-section +.. [#flit] https://github.com/takluyver/flit +.. [#poetry] https://poetry.eustace.io/docs/pyproject/#license +.. [#pbr] https://docs.openstack.org/pbr/latest/user/features.html +.. [#dep5] https://dep-team.pages.debian.net/deps/dep5/ +.. [#fedora] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ +.. [#fedoratext] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text +.. [#fedoralic] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_valid_license_short_names +.. [#fedoralist] https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses +.. [#opensuse] https://en.opensuse.org/openSUSE:Packaging_guidelines#Licensing +.. [#opensuselist] https://docs.google.com/spreadsheets/d/14AdaJ6cmU0kvQ4ulq9pWpjdZL5tkR03exRSYJmPGdfs/pub +.. [#gentoo] https://devmanual.gentoo.org/ebuild-writing/variables/index.html#license +.. [#glep23] https://www.gentoo.org/glep/glep-0023.html +.. [#gentoodev] https://devmanual.gentoo.org/general-concepts/licenses/index.html +.. [#freebsd] https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/licenses.html +.. [#archinux] https://wiki.archlinux.org/index.php/PKGBUILD#license +.. [#archlinuxlist] https://wiki.archlinux.org/index.php/PKGBUILD#license +.. [#openwrt] https://openwrt.org/docs/guide-developer/packages#buildpackage_variables +.. [#nixos] https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix +.. [#guix] http://git.savannah.gnu.org/cgit/guix.git/tree/guix/licenses.scm +.. [#guixlic] https://guix.gnu.org/manual/en/html_node/package-Reference.html#index-license_002c-of-packages +.. [#alpine] https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#license +.. [#maven] https://maven.apache.org/pom.html#Licenses +.. [#npm] https://docs.npmjs.com/files/package.json#license +.. [#gem] https://guides.rubygems.org/specification-reference/#license= +.. [#perl] https://metacpan.org/pod/CPAN::Meta::Spec#license +.. [#cargo] https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata +.. [#cratesio] https://doc.rust-lang.org/cargo/reference/registries.html#publish +.. [#composer] https://getcomposer.org/doc/04-schema.md#license +.. [#nuget] https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl +.. [#flutter] https://flutter.dev/docs/development/packages-and-plugins/developing-packages#adding-licenses-to-the-license-file +.. [#bower] https://github.com/bower/spec/blob/master/json.md#license +.. [#cocoapod] https://guides.cocoapods.org/syntax/podspec.html#license +.. [#cabal] http://hackage.haskell.org/package/Cabal-3.0.0.0/docs/Distribution-License.html +.. [#caballist] http://hackage.haskell.org/package/Cabal-3.0.0.0/docs/Distribution-SPDX-LicenseReference.html#t:LicenseRef +.. [#mix] https://hex.pm/docs/publish +.. [#dub] https://dub.pm/package-format-json.html#licenses +.. [#cran] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Licensing +.. [#spdxids] https://spdx.org/using-spdx-license-identifier +.. [#gnu] https://www.gnu.org/licenses/identify-licenses-clearly.html +.. [#fsf] https://www.fsf.org/blogs/rms/rms-article-for-claritys-sake-please-dont-say-licensed-under-gnu-gpl-2 +.. [#linux] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst +.. [#uboot] https://www.denx.de/wiki/U-Boot/Licensing +.. [#apache] https://svn.apache.org/repos/asf/allura/doap_Allura.rdf +.. [#eclipse] https://www.eclipse.org/legal/epl-2.0/faq.php +.. [#android] https://github.com/aosp-mirror/platform_external_tcpdump/blob/master/MODULE_LICENSE_BSD +.. [#cc0] https://creativecommons.org/publicdomain/zero/1.0/ Copyright ========= -This document is placed in the public domain or under the -CC0-1.0-Universal license, whichever is more permissive. +This document is placed in the public domain or under the CC0-1.0-Universal +license [#cc0]_, whichever is more permissive. Acknowledgements ================ -- Luis Villa -- Cyril Roelandt -- Kevin P. Fleming - Nick Coghlan +- Kevin P. Fleming +- Pradyun Gedam +- Dustin Ingram +- Chris Jerdonek +- Cyril Roelandt +- Luis Villa From bb8e3c19e3544de7e532e890037f73a8fba16c6e Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Mon, 26 Aug 2019 15:25:59 +0200 Subject: [PATCH 16/40] Add new sections and improve existing sections - Refactor intro with new and improved abstract, scope, non-scope, motivation and rationale sections - Add new Backwards Compatibility, Security and How to Teach sections - Move Reference Implementation out of appendix as its own section - Add new Rejected ideas section - Add new License Expression example using setuptools in Appendix Reported-by: Chris Jerdonek @cjerdonek Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 310 ++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 248 insertions(+), 62 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index 67c9c2b6fd1..22626e1a1dd 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -23,66 +23,93 @@ This PEP describes the changes between versions 2.1 and 2.2 of the `Core Metadata Specification` [#cms]_ for Python packages. Version 2.1 is specified in PEP 566. -The main change introduced in this PEP update how license is documented in Core -metadata using simple yet rich `SPDX License Expression` strings such that -license documentation is simpler and less ambiguous: +The primary change introduced in this PEP update how license is documented in +Core metadata in the `License` field with `License Expression` strings using +SPDX license ids [#spdxlist]_ such that license documentation is simpler and less +ambiguous: - for package authors to create, - for package users to read and understand, and, - for tools to process package license information mechanically. -These changes have been designed have a minimal impact and to be backward -compatible with v2.1. They are embracing emerging new ways to document licenses -that are already in use in some tools (e.g. `license_file` field) or by some -authors (e.g. using SPDX license expressions in the `license` field). All the -packages that conform with the v2.1 of core metadata specification are also -conformaing and valid with this v2.2 core metadata specification. +The other changes include: + +- specifying a `License File` field already used in wheels and setuptools to + include license files in built packages. +- defining how tools can validate license expressions and report warnings to + users for invalid expressions (but still accept any string as `License`). + + +Scope +===== + +This PEP scope is strictly about how we document the license of a package: + +- with an improved and structured way to document a license expression, and, +- by including license texts in a built package. + +The metadata specification changes have been designed to have a minimal impact +and to be backward compatible with v2.1. They are embracing emerging new ways +to document licenses that are already in use in some tools (e.g. by adding +`license_file` field already used in wheel and setuptools) or by some package +authors (e.g. storing an SPDX license expressions in the existing `license` +field). + +All the packages that conform with the v2.1 of core metadata specification are +also conformaing and valid with this v2.2 core metadata specification. Beyond this metadata specification update, this PEP contains: -- recommendations for Publishing to soft 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 package 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 license - today in Python packages and elewhere, and a Python library to parse, validate - and and build correct license expressions. + today in Python packages and elsewhere, and a reference Python library to + parse, validate and build correct license expressions. -Finally it is the intent of the PEP authors to work closely with tools authors -to implement to recommended `License` field validation and warnings specified in +It is the intent of the PEP authors to work closely with tools authors to +implement to recommended `License` field validation and warnings specified in this PEP. -What this PEP is not about and possible future PEPs -=================================================== +What this PEP is not about +========================== This PEP and its authors are neutral with regards to using this or that license. -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 proprietary license. +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. -Therefore this PEP makes no recommendation to force using certain licenses or or -even certain license documentation conventions and does not recommend any +Therefore this PEP makes no recommendation to force using certain licenses or +using certain license documentation conventions and does not recommend any license at all (including any license restriction when uploading to Pypi). Instead it only enacts in documentation some common and/or improved practices already in use, and recommend that Publishing tools should gently nag users with informational warnings when they do not follow this PEP recommendations. -However, it is the intention of the authors of this PEP to consider further +This PEP is not about documenting license in code files, even though this is a +surveyed topic in Appendix. + + +Possible future PEPs +==================== + +It is the intention of the authors of this PEP to consider the submission of related but separate PEPs in the future such as: - - make the existing `License` and new `License-File` fields mandatory + - making the existing `License` and new `License-File` fields mandatory including stricter enforcement in tools and Pypi publishing. - - restrict the upload of packages to the public Pypi index to the packaes using - only FOSS (Free and open source software) licenses. + - restricting the upload of packages to the public Pypi index to the packaes + using only FOSS (Free and open source software) licenses. -Rationale -========= +Motivation +========== Software is licensed and providing accurate licensing information to Python packages users is an important matter. Today, there are multiple places where @@ -106,15 +133,20 @@ information than other common application package formats (such as npm, Maven or Gem) as can be seen in the statistics [#cdstats]_ page of the ClearlyDefined [#cd]_ project that cover all packages from Pypi, Maven, npm and Rubygems. ClearlyDefined is an open source project to help improve clarity of other open -source projecs and is incubating at the OSI (Open Source Initiative) [#osi]_. +source projecs that is incubating at the OSI (Open Source Initiative) [#osi]_. + + +Rationale +========= -For reference, a mini survey of existing license metadata definitions in use in -Python today and documented in several other system/distro and application -package formats is provided as an informative Appendinx at the bottom of this -PEP. +A mini survey of existing license metadata definitions in use in Python today +and documented in several other system/distro and application package formats is +provided as an informative Appendix in this PEP. There are a few takeaways from this 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 SPDX-like syntaxes are the most popular in use. @@ -130,10 +162,11 @@ There are a few takeaways from this survey: and open source software licenses require to include their full text in a distribution. -These considerations have guided the updates proposed in this PEP. +These considerations have guided the design and updates proposed in this PEP. -License expressions provide a simpler way to express the license of a -distribution using a well defined syntax and well known license ids. +Reusing the existing `license` field with license expressions will provide a an +intuitive and more structured way to express the license of a distribution using +a well defined syntax and well known license ids. Over time, recommending the usage of these expressions will help Python package publishers improve the clarity of their license documentation to the benefit of @@ -177,22 +210,24 @@ License (optional) :::::::::::::::::: Text indicating the license covering the distribution. This text can be either a -valid `License Expression` (as defined below) or any free text. +valid `License Expression` as defined here or any free text. Publishing tools SHOULD issue an informational warning if this field is empty or missing or is not a valid `License Expression` as defined here. Build tools MAY issue such a warning too. -License Expression -'''''''''''''''''' +License Expression syntax +''''''''''''''''''''''''' A `License Expression` is a string using the SPDX license expression syntax as -documented in the SPDX specification [#spdx]_ using either Version 2.1 -[#spdx21]_ or a later compatible version. +documented in the SPDX specification [#spdx]_ using either Version 2.1 +[#spdx21]_ or a later compatible version. SPDX is a working group at the Linux +Foundation that defines a standard way to exchange package information. -As an extension to the SPDX license expression syntax, a `License Expression` -can use the following license identifiers: +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.6 of this list or any @@ -265,7 +300,7 @@ instead. Note that the licensing related Classifiers may be deprecated in a future PEP. -Mapping legacy Classifiers to new License expressions +Mapping legacy Classifiers to new License Expressions ''''''''''''''''''''''''''''''''''''''''''''''''''''' Publishing tools MAY infer or suggest an equivalent `License Expression` from @@ -307,19 +342,165 @@ Summary of Differences From PEP 566 * Updated the documentation of two fields: ``License`` and ``Classifiers`` -Appendix 1. License Expression Library sample implementation -============================================================ +Backwards Compatibility +======================= + +The reuse of the `License` field means that we keep backward compatibility. The +specification of the `License File(s)` field is only writing down the practices +of the wheels and setuptools tools and is backward compatibile with their +support for that field. + +The "soft" validation of the `License` field when it does not contain a valid +license expression and when legacy license-related `Classifiers` are used means +that we can gently prepare users for a 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. + + +How to Teach Users to use License Expressions +============================================= + +The simple cases are simple: a single single license id is a valid license +expression and a large majority of packages use a single license. + +The plan to teach users of packaging tools how to use the license with a valid +license expressions is to have tool issue warning messages when they detect an +incorrect license expressions or when a license-related classifier is used in +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. + +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. -To be successfull, tools need to support parsing and validating `License -Expressions`. +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). -The `license-expression library` [#licexp]_ provides a Python implementation -library to handle `License Expressions` including parsing, validating and -formatting `License Expressions` using flexible list of license symbols -(including SPDX license identifiers and 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, the ScanCode toolkit and the FSFE Reuse project -[#reuse]_. + +Reference Implementation +======================== + +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 ids and any extra ids 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. + +Adding a new field would introduce backward incompatible changes when the +`License` field would be retired later and require to have a 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 +for license expression) and possibly be a source of confusion. Alos, users are +less likely to start using a new field than make small adjustments to their use +of existing fields. + + +2. mapping licenses used in the license expression to specific files in the + license files (or vice versa). + +This would require using a mapping (two parallel lists would be too prone to +alignment errors) and a mapping would bring extra complication to how license +are documented by adding an additional nesting level. + +A mapping would be needed as you cannot guarantee that all expressions (e.g. a +GPL with an exception may be in a single file) or all the license keys have a +single license file and that any expression does not have more than one. (e.g. +an Apache license LICENSE and its NOTICE file for instance are tow distinct +file). Yet in most cases, there is a simpler `one license`, `one or more +license files`. In the rarer and more complex cases where there are many 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 id, 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 +string, it’s a list, it’s a mapping!) but this could be a source of confusion. +This is what has been done for instance in npm (historically) and in Rubygems +(still today) and as result you need to test the type of the metadata field +before using it in code and users are confused about when to use a list or a +string. + + +3. mapping licenses to specific source files and/or directories of source files + (or vice versa). + +File-level notices is not considered as part of the scope of this PEP and the +existing the `SPDX-License-Identifier` [#spdxids]_ convention can be used and +may not need further specification as a PEP. + + +Appendix 1. License Expression example +====================================== + +The current version of setuptools metadata [#setuptools412]_ does not use the +`License` field. It uses instead these license-related information:: + + license_file = LICENSE + classifiers = + License :: OSI Approved :: MIT License + +The simplest migration to this PEP would consist in using this instead:: + + license = MIT + license_files = + 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:: + + appdirs==1.4.3 + packaging==16.8 + pyparsing==2.2.1 + six==1.10.0 + +These are using these license expressions:: + + appdirs: MIT + pyparsing: MIT + six: MIT + packaging: Apache-2.0 OR BSD-2-Clause + +Therefore, a comprehensive license documentation covering both setuptools proper +and its vendored packages could contain these metadata, combining all the +license expressions in one expression:: + + license = MIT AND (Apache-2.0 OR BSD-2-Clause) + license_files = + LICENSE.MIT + LICENSE.packaging + +Here we would assume that the LICENSE.MIT file contains the text of the MIT +license used by setuptools, appdirs, pyparsing and six, and that the +LICENSE.packaging file contains the texts of the Apache and BSD license and its +license choice notice [#packlic]_. Appendix 2. Surveying how we document licenses today in Python @@ -390,7 +571,7 @@ possible source of confusion: a single license file to a source distribution. This singular version is still honored by `wheels` for backward compability. -- Using a LICENSE.txt file [#packaging]_ is encouraged in the packaging guide +- Using a LICENSE.txt file is encouraged in the packaging guide [#packaging]_ paired with a `MANIFEST.in` entry to ensure that the license file is included in a built source distribution (sdist). @@ -480,6 +661,7 @@ globally once in a shared documentation directory (e.g. /usr/share/doc). - Alpine Linux apk packages [#alpine]_ recommend using SPDX identifiers in its license field. + License in Language and Application packages -------------------------------------------- @@ -593,10 +775,10 @@ This document specifies version 2.2 of the metadata format. - Version 2.0, while not formally accepted, was specified in PEP 426. - Version 2.1 is specified in PEP 566. -.. [#cms] Live Core Metadata specification web page https://packaging.python.org/specifications/core-metadata -.. [#cdstats] ClearlyDefined project statistics page https://clearlydefined.io/stats -.. [#cd] ClearlyDefined https://clearlydefined.io -.. [#osi] OSI http://opensource.org +.. [#cms] https://packaging.python.org/specifications/core-metadata +.. [#cdstats] https://clearlydefined.io/stats +.. [#cd] https://clearlydefined.io +.. [#osi] http://opensource.org .. [#classif] https://pypi.org/classifiers .. [#spdxlist] https://spdx.org/licenses .. [#spdx] https://spdx.org @@ -604,12 +786,16 @@ This document specifies version 2.2 of the metadata format. .. [#wheels] https://github.com/pypa/wheel/blob/b8b21a5720df98703716d3cd981d8886393228fa/docs/user_guide.rst#including-license-files-in-the-generated-wheel-file .. [#reuse] https://reuse.software/ .. [#licexp] https://github.com/nexB/license-expression/ +.. [#spdxpy] https://github.com/spdx/tools-python/ +.. [#scancodetk] https://github.com/nexB/scancode-toolkit .. [#licfield] https://packaging.python.org/guides/distributing-packages-using-setuptools/?highlight=MANIFEST.in#license .. [#samplesetup] https://github.com/pypa/sampleproject/blob/b0d3f3eeef4e5668d7b59448b43c0f1914d9afc6/setup.py#L103 .. [#pipsetup] https://github.com/pypa/pip/blob/476606425a08c66b9c9d326994ff5cf3f770926a/setup.cfg#L40 .. [#setuptoolssdist] https://github.com/pypa/setuptools/blob/97e8ad4f5ff7793729e9c8be38e0901e3ad8d09e/setuptools/command/sdist.py#L202 .. [#packaging] https://packaging.python.org/guides/distributing-packages-using-setuptools/?highlight=MANIFEST.in#license-txt .. [#pycode] https://github.com/search?l=Python&q=%22__license__%22&type=Code +.. [#setuptools412] https://github.com/pypa/setuptools/blob/v41.2.0/setup.cfg#L20 +.. [#packlic] https://github.com/pypa/packaging/blob/19.1/LICENSE .. [#conda] https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#about-section .. [#flit] https://github.com/takluyver/flit .. [#poetry] https://poetry.eustace.io/docs/pyproject/#license From 0cb7f269fb157c95f8a5dfb07cc3e4a2554d6b21 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Mon, 26 Aug 2019 16:25:37 +0200 Subject: [PATCH 17/40] Fix typo Reported-By: Pradyun Gedam Signed-off-by: Philippe Ombredanne Co-Authored-By: Pradyun Gedam --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index 22626e1a1dd..ac47e9d019d 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -85,7 +85,7 @@ libre software license or a proprietary license. Therefore this PEP makes no recommendation to force using certain licenses or using certain license documentation conventions and does not recommend any -license at all (including any license restriction when uploading to Pypi). +license at all (including any license restriction when uploading to PyPI). Instead it only enacts in documentation some common and/or improved practices already in use, and recommend that Publishing tools should gently nag users with From 8a352cf968ec32642c2b44a68bf3ef4cbc0cc8e2 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Mon, 26 Aug 2019 16:25:59 +0200 Subject: [PATCH 18/40] Fix typo Reported-By: Pradyun Gedam Signed-off-by: Philippe Ombredanne Co-Authored-By: Pradyun Gedam --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index ac47e9d019d..c669d90479b 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -611,7 +611,7 @@ Appendix 3. Surveying how other package formats document licenses Here is a survey of how things are done elsewhere. -License in Linux distroibution packages +License in Linux distribution packages --------------------------------------- Note: in most cases the license texts of the most common licenses are included From f26c8e466beb982da68868b1245cf61066d76f48 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Mon, 26 Aug 2019 16:26:37 +0200 Subject: [PATCH 19/40] Improve presentation Reported-By: Pradyun Gedam Signed-off-by: Philippe Ombredanne Co-Authored-By: Pradyun Gedam --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index c669d90479b..c8cc5c2da7f 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -594,7 +594,7 @@ the help() DATA section for a module. In some other packaging tools ----------------------------- -- Conda package manifest [#conda]_ has support for `license` and`license_file` +- `Conda package manifest` [#conda]_ has support for `license` and`license_file` fields as well as a `license_family` license grouping field. - flit [#flit]_ recommends to use Classifiers instead of License (as per the From c98cd136c0616803e3c543fe5f8ef48adfa51e9f Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Mon, 26 Aug 2019 16:26:59 +0200 Subject: [PATCH 20/40] Improve style Reported-By: Pradyun Gedam Signed-off-by: Philippe Ombredanne Co-Authored-By: Pradyun Gedam --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index c8cc5c2da7f..d0f2f56c7f3 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -588,7 +588,7 @@ named after one of the lower cased Core metadata field such as `__license__` This convention (dunder global variables) is recognized by the built-in `help()` function and the standard `pydoc` module. The dunder variable(s) will show up in -the help() DATA section for a module. +the `help()` DATA section for a module. In some other packaging tools From 463712436dc4f443c8ef6785324f8d926d2c345c Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 29 Aug 2019 15:44:52 +0200 Subject: [PATCH 21/40] Move setuptools and wheel notes on license-file out Reported-by: Nick Coghlan @ncoghlan Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index d0f2f56c7f3..e8cf536c395 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -196,12 +196,6 @@ 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. -Note that this is field already exists in `wheel` and `setuptools` with this -behaviour. Therefore this addition to the Core metadata is only recognizing and -documenting an existing practice as used in `wheels` (with the `license_file` -and `license_files` `setup.cfg` `[metadata]` entries) and in `setuptools` -`license_file` `setup()` argument. - Changed in Version 2.2 ---------------------- @@ -575,6 +569,12 @@ possible source of confusion: paired with a `MANIFEST.in` entry to ensure that the license file is included in a built source distribution (sdist). +Note: the License-File(s) field proposed in this already exists in `wheel` and +`setuptools` with the same behaviour as explained above. This PEP is only +recognizing and documenting the existing practice as used in `wheels` (with the +`license_file` and `license_files` `setup.cfg` `[metadata]` entries) and in +`setuptools` `license_file` `setup()` argument. + In Python code files -------------------- From 161354c4992114554a4d993f62c09a7f3a9ac6e8 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 29 Aug 2019 15:47:34 +0200 Subject: [PATCH 22/40] Clarify and discourage use of public domain Reported-by: Nick Coghlan @ncoghlan Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index e8cf536c395..21ff81524dd 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -313,7 +313,12 @@ Here are mappings guidelines for the legacy classifiers: - Classifier `License :: Other/Proprietary License` becomes License: `Proprietary` expression. -- Classifier `License :: Public Domain` becomes License: `Public-Domain` expression. +- Classifier `License :: Public Domain` becomes License: `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 + 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. @@ -324,6 +329,9 @@ Here are mappings guidelines for the legacy classifiers: and `License :: Freeware` are mapped to the generic License: `Proprietary` expression. +- Classifiers `License :: GUST*` have no mapping to SPDX license ids 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. @@ -843,6 +851,7 @@ This document specifies version 2.2 of the metadata format. .. [#eclipse] https://www.eclipse.org/legal/epl-2.0/faq.php .. [#android] https://github.com/aosp-mirror/platform_external_tcpdump/blob/master/MODULE_LICENSE_BSD .. [#cc0] https://creativecommons.org/publicdomain/zero/1.0/ +.. [#unlic] https://unlicense.org/ Copyright From 67a5e0425484a672c6a78076bdbd04d436683139 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 29 Aug 2019 16:04:22 +0200 Subject: [PATCH 23/40] Fix typo Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index 21ff81524dd..ea135adf346 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -157,7 +157,7 @@ There are a few takeaways from this survey: or generic licenses such as "Proprietary" or "Public domain" not tracked by SPDX. -- Several package format support documenting both a license expression and +- 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. From e900fc9c6c0a0503cc58970df7305e06da386359 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 29 Aug 2019 16:47:42 +0200 Subject: [PATCH 24/40] Fix typos and clarify multi classifiers migrations Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index ea135adf346..73d1fe8a4a1 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -164,7 +164,7 @@ There are a few takeaways from this survey: These considerations have guided the design and updates proposed in this PEP. -Reusing the existing `license` field with license expressions will provide a an +Reusing the existing `License` field with license expressions will provide an intuitive and more structured way to express the license of a distribution using a well defined syntax and well known license ids. @@ -180,7 +180,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 his PEP are detailed here and will be added to the +document as part of this PEP are detailed here and will be added to the canonical source once this PEP is approved. @@ -190,10 +190,10 @@ Added in Version 2.2 License-File (multiple use) ::::::::::::::::::::::::::: -The is a string that is a package-root 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 package-root relative path 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 +Build tools SHOULD honor this field and include the corresponding license file(s) in the built package. @@ -226,7 +226,7 @@ identifiers: - any SPDX-listed license short-form identifiers that are published in the SPDX License List [#spdxlist]_ using either Version 3.6 of this list or any later compatible version. Note that the SPDX working group never removes any - license identifiers: instead they may only one as obsolete. + license identifiers: instead they may only mark one as "obsolete". - the `Public-Domain` and `Proprietary` strings to support generic ids that are not available in the SPDX license list. @@ -282,7 +282,7 @@ publishing tools MUST NOT also provide any licensing related Classifiers entries [#classif]_. However, for compatibility with existing publishing and installation processes, -licensing related Classifiers entries SHOULD continue to be accepted if the +licensing-related Classifiers entries SHOULD continue to be accepted if the License field is absent or does not contain a valid License Expression. Publishing tools MAY infer a License Expression from the provided Classifiers @@ -335,6 +335,12 @@ Here are mappings guidelines for the legacy classifiers: The remainder of the `Classifiers` using a `License::` prefix map to a simple single 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. + Summary of Differences From PEP 566 =================================== From 453b65c4236b0c11f8f265dfc70d36e0eaf47e17 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 29 Aug 2019 16:50:24 +0200 Subject: [PATCH 25/40] Report warning for expression case The case does nt matter, but there is a canonical case: if the case is the not the standard canonical case, tools should issue a warning. Reported-by: Oleg Grenrus @phadej Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index 73d1fe8a4a1..1e4eb534c40 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -234,16 +234,20 @@ identifiers: When processing the `License` field to determine if it contains a valid license expression, tools: -- MUST ignore the case of the `License` field. +- MUST ignore the case of the `License` field -- SHOULD report an informational warning if field does not contain a license - expression or if the license expression syntax is invalid or the license - identifiers are unknown or the license identifiers have been marked as - obsolete in the SPDX License List [#spdxlist]_. +- SHOULD report an informational warning if ither of this 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 or the license identifiers have been marked as obsolete 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 WITH keywords. And SHOULD report an informational warning if the reference + case is not used. License expression examples:: @@ -873,6 +877,7 @@ Acknowledgements - Nick Coghlan - Kevin P. Fleming - Pradyun Gedam +- Oleg Grenrus - Dustin Ingram - Chris Jerdonek - Cyril Roelandt From fcaaf6bf4d5cc739da6c3b29e46a8abb73cc0721 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 29 Aug 2019 16:53:12 +0200 Subject: [PATCH 26/40] Use deprecated not obsolete per SPDX Reported-by: Oleg Grenrus @phadej Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index 1e4eb534c40..53e57dda018 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -241,8 +241,8 @@ expression, tools: - 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 or the license identifiers have been marked as obsolete in the SPDX - License List [#spdxlist]_ + unknown 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 From ad39305542b016e1f7a512c83768814d5fadc92c Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 29 Aug 2019 17:01:32 +0200 Subject: [PATCH 27/40] Correct Cabal that uses SPDX expressions Cabal uses both expressions and license files as proposed in this PEP Reported-by: Oleg Grenrus @phadej Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index 53e57dda018..038ce1d0bb2 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -734,9 +734,11 @@ License in Language and Application packages with type, file an text keys. This is mandatory unless there is a LICENSE or LICENCE fie provided. -- Haskell Cabal [#cabal]_ specifies a single string with a list of accepted - licenses. And also provides a mapping between their license and SPDX license - ids [#caballist]_. +- Haskell Cabal [#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 pre-SPDX Legacy license + Identifiers and SPDX ids. Cabal also specifies a `license-file(s)` field that + list 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 srtings and recommends to use SPDX License ids. @@ -847,8 +849,7 @@ This document specifies version 2.2 of the metadata format. .. [#flutter] https://flutter.dev/docs/development/packages-and-plugins/developing-packages#adding-licenses-to-the-license-file .. [#bower] https://github.com/bower/spec/blob/master/json.md#license .. [#cocoapod] https://guides.cocoapods.org/syntax/podspec.html#license -.. [#cabal] http://hackage.haskell.org/package/Cabal-3.0.0.0/docs/Distribution-License.html -.. [#caballist] http://hackage.haskell.org/package/Cabal-3.0.0.0/docs/Distribution-SPDX-LicenseReference.html#t:LicenseRef +.. [#cabal] https://cabal.readthedocs.io/en/latest/developing-packages.html#pkg-field-license .. [#mix] https://hex.pm/docs/publish .. [#dub] https://dub.pm/package-format-json.html#licenses .. [#cran] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Licensing From fdef4fdfc6e52ad0933f0c8d283273a7b7cc00d3 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 29 Aug 2019 17:23:28 +0200 Subject: [PATCH 28/40] Fix typo Reported-by: Oleg Grenrus @phadej Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index 038ce1d0bb2..83b97bdc6c7 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -104,7 +104,7 @@ related but separate PEPs in the future such as: - making the existing `License` and new `License-File` fields mandatory including stricter enforcement in tools and Pypi publishing. - - restricting the upload of packages to the public Pypi index to the packaes + - restricting the upload of packages to the public Pypi index to the packages using only FOSS (Free and open source software) licenses. From f07819c5adde4662bd8645b44cad394ea7b94ae7 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Thu, 5 Sep 2019 16:22:29 +0200 Subject: [PATCH 29/40] Use LicenseRef- prefix for non-standard SPDX ids This help endsure that the expressions is fully parseable by a conforming license expression processor Reported-by: Oleg Grenrus @phadej Reported-by: Nick Coghlan @ncoghlan Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 30 ++++++++++++++---------------- 1 file changed, 14 insertions(+), 16 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index 83b97bdc6c7..b987128ae20 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -152,10 +152,7 @@ There are a few takeaways from this survey: SPDX-like syntaxes are the most popular in use. - SPDX license ids are becoming a de-facto way to reference common licenses - everywhere, whether or not a license expression syntax is used. But they often - need to be supplemented with extra license ids or conventions to accept extra - or generic licenses such as "Proprietary" or "Public domain" not tracked by - SPDX. + 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 @@ -228,8 +225,8 @@ identifiers: later compatible version. Note that the SPDX working group never removes any license identifiers: instead they may only mark one as "obsolete". -- the `Public-Domain` and `Proprietary` strings to support generic ids that are - not available in the SPDX license list. +- the `LicenseRef-Public-Domain` and `LicenseRef-Proprietary` strings to support + generic ids that are not available in the SPDX license list. When processing the `License` field to determine if it contains a valid license expression, tools: @@ -241,8 +238,8 @@ expression, tools: - 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 or the license identifiers have been marked as deprecated in the - SPDX License List [#spdxlist]_ + 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 @@ -263,7 +260,7 @@ License expression examples:: author a postcard, and then the user promises not to redistribute it. - License: Proprietary AND Public-Domain + License: LicenseRef-Proprietary AND LicenseRef-Public-Domain Classifier (multiple use) @@ -315,9 +312,10 @@ suggest would be:: Here are mappings guidelines for the legacy classifiers: -- Classifier `License :: Other/Proprietary License` becomes License: `Proprietary` expression. +- Classifier `License :: Other/Proprietary License` becomes License: + `LicenseRef-Proprietary` expression. -- Classifier `License :: Public Domain` becomes License: `Public-Domain` +- 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 @@ -327,11 +325,11 @@ Here are mappings guidelines for the legacy classifiers: - 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`, `License :: Free for non-commercial use`, - `License :: Freely Distributable`, `License :: Free To Use But Restricted`, - and `License :: Freeware` are mapped to the generic License: `Proprietary` - expression. +- The generic and sometimes ambiguous Classifiers + `License :: Free For Educational Use`, `License :: Free For Home Use`, + `License :: Free for non-commercial use`, `License :: Freely Distributable`, + `License :: Free To Use But Restricted`, and `License :: Freeware` are mapped + to the generic License: `LicenseRef-Proprietary` expression. - Classifiers `License :: GUST*` have no mapping to SPDX license ids for now and no package uses them in PyPI as of the writing of this PEP. From 4e5bc7460dfab67bca95cb8129a12226cbed4aef Mon Sep 17 00:00:00 2001 From: Cyril Roelandt Date: Sun, 8 Sep 2019 02:40:47 +0200 Subject: [PATCH 30/40] Fix typos. --- pep-9999.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index b987128ae20..76d11e6d037 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -56,7 +56,7 @@ authors (e.g. storing an SPDX license expressions in the existing `license` field). All the packages that conform with the v2.1 of core metadata specification are -also conformaing and valid with this v2.2 core metadata specification. +also conforming and valid with this v2.2 core metadata specification. Beyond this metadata specification update, this PEP contains: @@ -377,8 +377,8 @@ any new security concern. How to Teach Users to use License Expressions ============================================= -The simple cases are simple: a single 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 id is a valid license expression +and a large majority of packages use a single license. The plan to teach users of packaging tools how to use the license with a valid license expressions is to have tool issue warning messages when they detect an @@ -667,10 +667,10 @@ globally once in a shared documentation directory (e.g. /usr/share/doc). - OpenWRT ipk packages [#openwrt]_ use the `PKG_LICENSE` and `PKG_LICENSE_FILES` variables and recommend the use of SPDX License ids. -- nixos uses SPDX identifiers [#nixos]_ and some extras license identifiers in +- NixOS uses SPDX identifiers [#nixos]_ and some extras license identifiers in its license field. -- GUIX (based on nixos) has a single License field, uses its own license +- 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]_. From 2560779e8134d9a9c3a9ff0c4acf7c19f5c1861d Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Fri, 4 Oct 2019 15:56:01 +0200 Subject: [PATCH 31/40] Fix typo and add BSD* distributions reference Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index 76d11e6d037..59a5b4e551b 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -119,7 +119,7 @@ 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 -Liux distribution packagers. This has triggered several license-related +Linux and BSD* distribution packagers. This has triggered several license-related discussions and issues and in particular: - https://github.com/pypa/warehouse/issues/2996 From 1ff69d5c28555a66e7f1e96cda3e6803affbc37d Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Fri, 4 Oct 2019 16:43:58 +0200 Subject: [PATCH 32/40] Fix typo and improve grammar Reported-by: Nick Coghlan @ncoghlan Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index 59a5b4e551b..b99e9fe66fb 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -233,7 +233,7 @@ expression, tools: - MUST ignore the case of the `License` field -- SHOULD report an informational warning if ither of this 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, From 27b8863676d54957b8227c87b88b7503a61ecaa2 Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Mon, 7 Oct 2019 23:17:58 +0530 Subject: [PATCH 33/40] Copy Edits for initial sections --- pep-9999.rst | 79 +++++++++++++++++++++++++--------------------------- 1 file changed, 38 insertions(+), 41 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index b99e9fe66fb..18e14647dcd 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -25,7 +25,7 @@ PEP 566. The primary change introduced in this PEP update how license is documented in Core metadata in the `License` field with `License Expression` strings using -SPDX license ids [#spdxlist]_ such that license documentation is simpler and less +SPDX license IDs [#spdxlist]_ such that license documentation is simpler and less ambiguous: - for package authors to create, @@ -34,33 +34,30 @@ ambiguous: The other changes include: -- specifying a `License File` field already used in wheels and setuptools to - include license files in built packages. +- specifying a `License-File` field which is already used by `wheel` and + `setuptools` to include license files in built distributions. - defining how tools can validate license expressions and report warnings to users for invalid expressions (but still accept any string as `License`). -Scope +Goals ===== -This PEP scope is strictly about how we document the license of a package: +This PEP's scope is limited strictly to how we document the license of a +package distribution: - with an improved and structured way to document a license expression, and, - by including license texts in a built package. -The metadata specification changes have been designed to have a minimal impact -and to be backward compatible with v2.1. They are embracing emerging new ways -to document licenses that are already in use in some tools (e.g. by adding -`license_file` field already used in wheel and setuptools) or by some package -authors (e.g. storing an SPDX license expressions in the existing `license` -field). +The changes have been designed to have a 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 `Licence-File` +field already used in wheel and setuptools) or by some package authors +(e.g. storing an SPDX license expressions in the existing `License` field). -All the packages that conform with the v2.1 of core metadata specification are -also conforming and valid with this v2.2 core metadata specification. +In addition to an update to the metadata specification, this PEP contains: -Beyond this metadata specification update, this PEP contains: - -- recommendations for package Publishing tools on how to validate the `License` +- 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. @@ -68,44 +65,44 @@ Beyond this metadata specification update, this PEP contains: 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 tools authors to -implement to recommended `License` field validation and warnings specified in -this PEP. +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. -What this PEP is not about -========================== +Non-Goals +========= -This PEP and its authors are neutral with regards to using this or that license. +This PEP is neutral regarding the choice of various licenses. In particular, the SPDX license expression syntax proposed in this PEP provides simpler and more expressive conventions to document more accurately any kind of license that applies to a Python package, whether under an open source, free or libre software license or a proprietary license. -Therefore this PEP makes no recommendation to force using certain licenses or -using certain license documentation conventions and does not recommend any -license at all (including any license restriction when uploading to PyPI). +This PEP makes no recommendation for certain licenses or require the use of +certain license documentation conventions. This PEP also does not impose any +restrictions when uploading to PyPI. -Instead it only enacts in documentation some common and/or improved practices -already in use, and recommend that Publishing tools should gently nag users with -informational warnings when they do not follow this PEP recommendations. +Instead, this PEP is intended to document common practices already in use, +and recommends that Publishing tools should gently nag users with informational +warnings when they do not follow this PEP recommendations. This PEP is not about documenting license in code files, even though this is a surveyed topic in Appendix. Possible future PEPs -==================== +-------------------- It is the intention of the authors of this PEP to consider the submission of related but separate PEPs in the future such as: - - making the existing `License` and new `License-File` fields mandatory - including stricter enforcement in tools and Pypi publishing. + - make `License` and new `License-File` fields mandatory including + stricter enforcement in tools and PyPI publishing. - - restricting the upload of packages to the public Pypi index to the packages - using only FOSS (Free and open source software) licenses. + - require uploads to PyPI to use only FOSS (Free and Open Source software) + licenses. Motivation @@ -131,7 +128,7 @@ discussions and issues and in particular: 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. +[#cd]_ project that cover all packages from PyPI, Maven, npm and Rubygems. ClearlyDefined is an open source project to help improve clarity of other open source projecs that is incubating at the OSI (Open Source Initiative) [#osi]_. @@ -141,17 +138,17 @@ Rationale A mini survey of existing license metadata definitions in use in Python today and documented in several other system/distro and application package formats is -provided as an informative Appendix in this PEP. +provided in Appendix 2, of this PEP. -There are a few takeaways from this survey: +There are a few takeaways from the survey: -- Most package formats use a single `license` field. +- 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 SPDX-like syntaxes are the most popular in use. -- SPDX license ids are becoming a de-facto way to reference common licenses +- SPDX license IDs 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 @@ -159,11 +156,11 @@ There are a few takeaways from this survey: and open source software licenses require to include their full text in a distribution. -These considerations have guided the design and updates proposed in this PEP. +These considerations have guided the design and recommendations of this PEP. -Reusing the existing `License` field with license expressions will provide an +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 -a well defined syntax and well known license ids. +a well-defined syntax and well-known license ID. Over time, recommending the usage of these expressions will help Python package publishers improve the clarity of their license documentation to the benefit of From 3a7f4f64b7acaafb921e1dcb180f96ea10807fc8 Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Mon, 7 Oct 2019 23:23:03 +0530 Subject: [PATCH 34/40] Reword a paragraph --- pep-9999.rst | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index 18e14647dcd..306702951e4 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -49,11 +49,12 @@ package distribution: - with an improved and structured way to document a license expression, and, - by including license texts in a built package. -The changes have been designed to have a 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 `Licence-File` -field already used in wheel and setuptools) or by some package authors -(e.g. storing an SPDX license expressions in the existing `License` field). +The core metadata specification updates that are part of this PEP, have been +designed to have a 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 `Licence-File` field already used in +`wheel` and `setuptools`) or by some package authors (e.g. storing an SPDX +license expressions in the existing `License` field). In addition to an update to the metadata specification, this PEP contains: From c579fa7a24b3e4211344e1bfefc4b110df86a4f7 Mon Sep 17 00:00:00 2001 From: Pradyun Gedam Date: Mon, 7 Oct 2019 23:23:37 +0530 Subject: [PATCH 35/40] Update pep-9999.rst --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index 306702951e4..0faa581c814 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -50,7 +50,7 @@ package distribution: - by including license texts in a built package. The core metadata specification updates that are part of this PEP, have been -designed to have a minimal impact and to be backward compatible with v2.1. +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 `Licence-File` field already used in `wheel` and `setuptools`) or by some package authors (e.g. storing an SPDX From 798fb09d3ef6d70788b1f1f153d38c6af12f63d4 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Tue, 8 Oct 2019 12:12:25 +0200 Subject: [PATCH 36/40] Fix typo Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index 0faa581c814..a9adcb033eb 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -54,7 +54,7 @@ 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 `Licence-File` field already used in `wheel` and `setuptools`) or by some package authors (e.g. storing an SPDX -license expressions in the existing `License` field). +license expression in the existing `License` field). In addition to an update to the metadata specification, this PEP contains: From 8b6e17271016e30b226eae8cd24f912ffcdf6466 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Sat, 18 Jul 2020 08:33:54 +0200 Subject: [PATCH 37/40] Remove erroneous leading spaces Reported-by: Pradyun Gedam @pradyunsg Signed-off-by: Philippe Ombredanne Co-authored-by: Pradyun Gedam --- pep-9999.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index a9adcb033eb..a89e1ca74e4 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -99,11 +99,11 @@ Possible future PEPs It is the intention of the authors of this PEP to consider the submission of related but separate PEPs in the future such as: - - make `License` and new `License-File` fields mandatory including - stricter enforcement in tools and PyPI publishing. +- make `License` and new `License-File` fields mandatory including + stricter enforcement in tools and PyPI publishing. - - require uploads to PyPI to use only FOSS (Free and Open Source software) - licenses. +- require uploads to PyPI to use only FOSS (Free and Open Source software) + licenses. Motivation From 14e61c8330de9c2daa18e1bbdde07282f68e379b Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Sun, 27 Sep 2020 11:54:29 +0200 Subject: [PATCH 38/40] Update SPDX license list and spec versions Use latest SPDX spec 2.2 and SPDX license list 3.10 Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index a89e1ca74e4..20d751c4825 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -210,8 +210,8 @@ License Expression syntax ''''''''''''''''''''''''' A `License Expression` is a string using the SPDX license expression syntax as -documented in the SPDX specification [#spdx]_ using either Version 2.1 -[#spdx21]_ or a later compatible version. SPDX is a working group at the Linux +documented in the SPDX specification [#spdx]_ using either Version 2.2 +[#spdx22]_ or a later compatible version. SPDX is a working group at the Linux Foundation that defines a standard way to exchange package information. When used in the `License` field and as a specialization of the SPDX license @@ -219,7 +219,7 @@ 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.6 of this list or any + 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 one as "obsolete". @@ -798,7 +798,7 @@ This document specifies version 2.2 of the metadata format. .. [#classif] https://pypi.org/classifiers .. [#spdxlist] https://spdx.org/licenses .. [#spdx] https://spdx.org -.. [#spdx21] https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60 +.. [#spdx22] https://spdx.github.io/spdx-spec/appendix-IV-SPDX-license-expressions/ .. [#wheels] https://github.com/pypa/wheel/blob/b8b21a5720df98703716d3cd981d8886393228fa/docs/user_guide.rst#including-license-files-in-the-generated-wheel-file .. [#reuse] https://reuse.software/ .. [#licexp] https://github.com/nexB/license-expression/ From 5722ba03cdbd788da0b276afabd0fb173b577349 Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Sun, 27 Sep 2020 14:16:50 +0200 Subject: [PATCH 39/40] Fix typos and formatting Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 151 ++++++++++++++++++++++++++------------------------- 1 file changed, 76 insertions(+), 75 deletions(-) diff --git a/pep-9999.rst b/pep-9999.rst index 20d751c4825..fd36c7f9f34 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -23,7 +23,7 @@ This PEP describes the changes between versions 2.1 and 2.2 of the `Core Metadata Specification` [#cms]_ for Python packages. Version 2.1 is specified in PEP 566. -The primary change introduced in this PEP update how license is documented in +The primary change introduced in this PEP updates how license is documented in Core metadata in the `License` field with `License Expression` strings using SPDX license IDs [#spdxlist]_ such that license documentation is simpler and less ambiguous: @@ -131,7 +131,7 @@ information than other common application package formats (such as npm, Maven or Gem) as can be seen in the statistics [#cdstats]_ page of the ClearlyDefined [#cd]_ project that cover all packages from PyPI, Maven, npm and Rubygems. ClearlyDefined is an open source project to help improve clarity of other open -source projecs that is incubating at the OSI (Open Source Initiative) [#osi]_. +source projects that is incubating at the OSI (Open Source Initiative) [#osi]_. Rationale @@ -354,8 +354,8 @@ Backwards Compatibility ======================= The reuse of the `License` field means that we keep backward compatibility. The -specification of the `License File(s)` field is only writing down the practices -of the wheels and setuptools tools and is backward compatibile with their +specification of the `License-File` field is only writing down the practices +of the `wheels` 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 @@ -425,7 +425,7 @@ Adding a new field would introduce backward incompatible changes when the `License` field would be retired later and require to have a 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 -for license expression) and possibly be a source of confusion. Alos, users are +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. @@ -442,11 +442,11 @@ 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 tow distinct file). Yet in most cases, there is a simpler `one license`, `one or more -license files`. In the rarer and more complex cases where there are many 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 id, but you -are not forcing the more complex data model (e.g. a mapping) on everyone that -may not need it. +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 +id, 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 string, it’s a list, it’s a mapping!) but this could be a source of confusion. @@ -467,7 +467,7 @@ may not need further specification as a PEP. Appendix 1. License Expression example ====================================== -The current version of setuptools metadata [#setuptools412]_ does not use the +The current version of `setuptools` metadata [#setuptools5030]_ does not use the `License` field. It uses instead these license-related information:: license_file = LICENSE @@ -485,16 +485,16 @@ bundled in that are vendored in the `setuptools/_vendor/` and `pkg_resources/_vendor` directories:: appdirs==1.4.3 - packaging==16.8 + packaging==20.4 pyparsing==2.2.1 - six==1.10.0 + ordered-set==3.1.1 These are using these license expressions:: appdirs: MIT - pyparsing: MIT - six: MIT packaging: Apache-2.0 OR BSD-2-Clause + pyparsing: MIT + ordered-set: MIT Therefore, a comprehensive license documentation covering both setuptools proper and its vendored packages could contain these metadata, combining all the @@ -505,10 +505,10 @@ license expressions in one expression:: LICENSE.MIT LICENSE.packaging -Here we would assume that the LICENSE.MIT file contains the text of the MIT -license used by setuptools, appdirs, pyparsing and six, and that the -LICENSE.packaging file contains the texts of the Apache and BSD license and its -license choice notice [#packlic]_. +Here we would assume that the `LICENSE.MIT` file contains the text of the MIT +license and the copyrights used by `setuptools`, `appdirs`, `pyparsing` and +`ordered-set`, and that the `LICENSE.packaging` file contains the texts of the +Apache and BSD license, its copyrights and its license choice notice [#packlic]_. Appendix 2. Surveying how we document licenses today in Python @@ -552,10 +552,10 @@ not clear if this is a choice or all these apply and which ones. Furthermore, the list of available license-related `Classifiers` is often out-of-date. -In the pypa sample project +In the PyPA sample project -------------------------- -The latest pypa sample project recommends only to use Classifiers in setup.py +The latest PyPA sample project recommends only to use Classifiers in setup.py and does not list the `license` field in its example `setup.py` [#samplesetup]_. @@ -567,23 +567,23 @@ included in a built package either implicitly or explicitly and this is another 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 (e.g. - LICENSE, COPYING). Alternatively a package author can specify a list of - license files paths to include in the built whell using in the + 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_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 this is still in common use. See [#pipsetup]_ for + that is now deprecated but is still in common use. See [#pipsetup]_ for instance. -- In setuptools [#setuptoolssdist]_, a `license_file` attribute is use to add +- In `setuptools` [#setuptoolssdist]_, a `license_file` attribute is used to add a single license file to a source distribution. This singular version is - still honored by `wheels` for backward compability. + still honored by `wheels` for backward compatibility. - Using a LICENSE.txt file is encouraged in the packaging guide [#packaging]_ paired with a `MANIFEST.in` entry to ensure that the license file is included in a built source distribution (sdist). -Note: the License-File(s) field proposed in this already exists in `wheel` and +Note: the License-File field proposed in this PEP already exists in `wheel` and `setuptools` with the same behaviour as explained above. This PEP is only recognizing and documenting the existing practice as used in `wheels` (with the `license_file` and `license_files` `setup.cfg` `[metadata]` entries) and in @@ -595,8 +595,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 +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__` [#pycode]_. @@ -605,18 +605,18 @@ function and the standard `pydoc` module. The dunder variable(s) will show up in the `help()` DATA section for a module. -In some other packaging tools ------------------------------ +In some other Python packaging tools +------------------------------------ - `Conda package manifest` [#conda]_ has support for `license` and`license_file` fields as well as a `license_family` license grouping field. -- flit [#flit]_ recommends to use Classifiers instead of License (as per the +- `flit` [#flit]_ recommends to use Classifiers instead of License (as per the current metadata spec). -- pbr [#pbr]_ uses similar data as setuptools but always stored setup.cfg. +- `pbr` [#pbr]_ uses similar data as setuptools but always stored setup.cfg. -- poetry [#poetry]_ specifies the use of the `license ` field in +- `poetry` [#poetry]_ specifies the use of the `license ` field in `pyproject.toml` with SPDX license ids. @@ -654,7 +654,7 @@ globally once in a shared documentation directory (e.g. /usr/share/doc). field with a list of custom license symbols. For non-standard licenses, FreeBSD recommend to use LICENSE=UNKNOWN and add LICENSE_NAME and LICENSE_TEXT fields, as well as sophisticated LICENSE_PERMS to qualify the license - permissoins and LICENSE_GROUPS to document a license grouping. The + permissions and LICENSE_GROUPS to document a license grouping. The LICENSE_COMB allows to document more than one license and how they apply together, forming a custom license expression syntax. FreeBSD also recommends the use of SPDX-License-Identifier in source code files. @@ -680,7 +680,7 @@ License in Language and Application packages -------------------------------------------- - In Java, Maven POM [#maven]_ defines a licenses XML tag with a list of license - items each with name, url, comments and "disribution" type. This is not + items each with a name, URL, comments and "distribution" type. This is not mandatory and the content of each field is not specified. - JavaScript npm package.json [#npm]_ use a single license field with SPDX @@ -692,59 +692,59 @@ License in Language and Application packages of licenses strings. The relationship between multiple licenses in a list is not specified. They recommend using SPDX license ids. -- CPAN Perl modules [#perl]_ use a single license field wich is either a single +- 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 these generic ids: open_source, restricted, unrestricted, unknown. -- Rust Cargo [#cargo]_ specifies the use an SPDX license expession (v2.1) in the - license field. They also support an alternative expression synatx using slash- - separated SPDX license ids. There is a license_file field too. The crates.io - package registry [#cratesio]_ requires that either `license` or `license_file` - fields are set when you upload a package. +- Rust Cargo [#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 ids. There is also a `license_file` field. The + crates.io package registry [#cratesio]_ requires that either `license` or + `license_file` fields are set when you upload a package. -- 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 SPDX license expression syntax with "and" and - "or" keywords; or this is a list of strings if there is a choice of licenses - (aka. a "disjunctive" choice of license). +- 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 + licenses (aka. a "disjunctive" choice of license). - NuGet packages [#nuget]_ were using only a simple license URL and are now - specifying to use an SPDX License expressions and/or the path to a license + specifying to use an SPDX License expression and/or the path to a license file within the package. The NuGet.org repository states that they only accepts license expressions that are `approved by the Open Source Initiative or the Free Software Foundation.` -- Golang has no provision for any metadata beyond dependencies. Licensing - information is left to community package managers. +- Go language modules `go.mod` have no provision for any metadata beyond + dependencies. Licensing information is left for code authors and other + community package managers to document. - Dart/Flutter spec [#flutter]_ recommends to use a single LICENSE file that - should contain multiple license texts each separated by a line with 80 + should contain all the license texts each separated by a line with 80 hyphens. -- JavaScript Bower [#bower]_ license field is either a single string or a list - of strings using either SPDX license identifier or a path or a URL to a +- 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 license file. -- Cocoapods podspec [#cocoapod]_ license is either a single string or a mapping - with type, file an text keys. This is mandatory unless there is a LICENSE or - LICENCE fie provided. +- Cocoapods podspec [#cocoapod]_ `license` field is either a single string or a + mapping with attributes of type, file and text keys. This is mandatory unless + there is a LICENSE or LICENCE file provided. - Haskell Cabal [#cabal]_ accepts an SPDX license expression since version 2.2. - The version of the SPDX license list used is a function of the cabal version. + The version of the SPDX license list used is a function of the `cabal` version. The specification also provides a mapping between pre-SPDX Legacy license Identifiers and SPDX ids. Cabal also specifies a `license-file(s)` field that - list license files that will be installed with the package. + 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 srtings and recommends to use SPDX License ids. +- Erlang/Elixir mix/hex package [#mix]_ specifies a `licenses` field as a + required list of license strings and recommends to use SPDX License ids. -- D lang dub packages [#dub]_ define their own list of license identifiers and - their own license expression syntax: both are very similar to SPDX - conventions. +- D lang dub package [#dub]_ defines its own list of license identifiers and + its own license expression syntax and both are similar to SPDX the conventions. - R Package DESCRIPTION [#cran]_ defines its own sophisticated license - expression syntax and list of licenses. R has a unique way to support + expression syntax and list of licenses ids. R has a unique way to support specifiers for license versions such as `LGPL (>= 2.0, < 3)` in its license expression syntax. @@ -752,19 +752,19 @@ License in Language and Application packages Conventions used by other ecosystems ------------------------------------ -- `SPDX-License-Identifier` [#spdxids]_ is simple convention to document the +- `SPDX-License-Identifier` [#spdxids]_ is a simple convention to document the license inside a code file. - The Free Software Foundation (FSF) promotes using SPDX license ids for clarity in the GPL and other versioned free software licenses [#gnu]_ [#fsf]_. -- The Free Software Foundation Europe (FSFE) Reuse project [#reuse]_ promotes +- The Free Software Foundation Europe (FSFE) REUSE project [#reuse]_ promotes using `SPDX-License-Identifier`. -- The Linux kernel uses `SPDX-License-Identifier` and parts of the FSFE Reuse - conventions to document its license(s) [#linux]_. +- The Linux kernel uses `SPDX-License-Identifier` and parts of the FSFE REUSE + conventions to document its licenses [#linux]_. -- U-Boot spearheaded using SPDX license identifiers in code and now follows the +- U-Boot spearheaded using `SPDX-License-Identifier` in code and now follows the Linux ways [#uboot]_. - The Apache Software Foundation projects use RDF DOAP [#apache]_ with a single @@ -775,9 +775,10 @@ Conventions used by other ecosystems - The ClearlyDefined project [#cd]_ promotes using SPDX license ids and expressions to improve license clarity. -- The Android Open Source Project use MODULE_LICENSE_XXX empty tag files where - XXX is a license code such as BSD [#android]_, APACHE, GPL, etc. a NOTICE file - for license text. +- The Android Open Source Project [#android]_ use MODULE_LICENSE_XXX empty tag + files where XXX is a license code such as BSD , APACHE, GPL, etc. And + side-by-side with this MODULE_LICENSE file there is a NOTICE file that + contains license and notices texts. References @@ -805,12 +806,12 @@ This document specifies version 2.2 of the metadata format. .. [#spdxpy] https://github.com/spdx/tools-python/ .. [#scancodetk] https://github.com/nexB/scancode-toolkit .. [#licfield] https://packaging.python.org/guides/distributing-packages-using-setuptools/?highlight=MANIFEST.in#license -.. [#samplesetup] https://github.com/pypa/sampleproject/blob/b0d3f3eeef4e5668d7b59448b43c0f1914d9afc6/setup.py#L103 +.. [#samplesetup] https://github.com/pypa/sampleproject/blob/52966defd6a61e97295b0bb82cd3474ac3e11c7a/setup.py#L98 .. [#pipsetup] https://github.com/pypa/pip/blob/476606425a08c66b9c9d326994ff5cf3f770926a/setup.cfg#L40 .. [#setuptoolssdist] https://github.com/pypa/setuptools/blob/97e8ad4f5ff7793729e9c8be38e0901e3ad8d09e/setuptools/command/sdist.py#L202 .. [#packaging] https://packaging.python.org/guides/distributing-packages-using-setuptools/?highlight=MANIFEST.in#license-txt .. [#pycode] https://github.com/search?l=Python&q=%22__license__%22&type=Code -.. [#setuptools412] https://github.com/pypa/setuptools/blob/v41.2.0/setup.cfg#L20 +.. [#setuptools5030] https://github.com/pypa/setuptools/blob/v50.3.0/setup.cfg#L17 .. [#packlic] https://github.com/pypa/packaging/blob/19.1/LICENSE .. [#conda] https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#about-section .. [#flit] https://github.com/takluyver/flit From 14a961166922c597c86c19a90ca63ae362d5bf1c Mon Sep 17 00:00:00 2001 From: Philippe Ombredanne Date: Sun, 27 Sep 2020 19:11:15 +0200 Subject: [PATCH 40/40] Clarify License file path definition MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reported-by: Miro Hrončok @hroncok Signed-off-by: Philippe Ombredanne --- pep-9999.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pep-9999.rst b/pep-9999.rst index fd36c7f9f34..42a4000a2e7 100644 --- a/pep-9999.rst +++ b/pep-9999.rst @@ -185,7 +185,7 @@ Added in Version 2.2 License-File (multiple use) ::::::::::::::::::::::::::: -The License-File is a string that is a package-root relative path to a license +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. Build tools SHOULD honor this field and include the corresponding license