diff --git a/pep-0639.rst b/pep-0639.rst new file mode 100644 index 00000000000..238dd6d61cd --- /dev/null +++ b/pep-0639.rst @@ -0,0 +1,892 @@ +PEP: 639 +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/2154 +Status: Draft +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` [#cms]_ for Python packages. Version 2.1 is specified in +PEP 566. + +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: + +- for package authors to create, +- for package users to read and understand, and, +- for tools to process package license information mechanically. + +The other changes include: + +- 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`). + + +Goals +===== + +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 core metadata specification updates that are part of this PEP, have been +designed to have minimal impact and to be backward compatible with v2.1. +These changes utilize emerging new ways to document licenses that are already +in use in some tools (e.g. by adding `Licence-File` field already used in +`wheel` and `setuptools`) or by some package authors (e.g. storing an SPDX +license expression in the existing `License` field). + +In addition to an update to the metadata specification, this PEP contains: + +- recommendations for Publishing tools on how to validate the `License` + and `Classifier` fields and report informational warnings when a package uses + an older, non- structured style of license documentation conventions. + +- informational appendixes that contain surveys of how we document license + today in Python packages and elsewhere, and a reference Python library to + parse, validate and build correct license expressions. + +It is the intent of the PEP authors to work closely with tool authors to +implement to recommendations for validation and warnings specified in this +PEP. + + +Non-Goals +========= + +This PEP is neutral regarding the choice of various licenses. + +In particular, the SPDX license expression syntax proposed in this PEP provides +simpler and more expressive conventions to document more accurately any kind of +license that applies to a Python package, whether under an open source, free or +libre software license or a proprietary license. + +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, 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: + +- 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. + + +Motivation +========== + +Software is licensed and providing accurate licensing information to Python +packages users is an important matter. Today, there are multiple places where +license is documented in package metadata and there are limitations to what can +be documented. This is often leading to confusion or a lack of clarity both for +package authors and package users. + +Several package authors have expressed difficulty and/or frustrations with the +possibilities to express licensing in package metadata. This also applies to +Linux and BSD* distribution packagers. This has triggered several license-related +discussions and issues and in particular: + +- 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 projects that is incubating at the OSI (Open Source Initiative) [#osi]_. + + +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 in Appendix 2, of this PEP. + +There are a few takeaways from the survey: + +- Most package formats use a single `License` field. + +- Many modern package formats use some form of license expression syntax to + optionally combine more than one license identifiers together. SPDX and + 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. + +- Several package formats support documenting both a license expression and + the paths of the corresponding files that contain the license text. Most free + and open source software licenses require to include their full text in a + distribution. + +These considerations have guided the design and recommendations of this PEP. + +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 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 +packages authors, consumers and redistributors. + + +Core Metadata Specification updates +=================================== + +The canonical source for the names and semantics of each of the supported +metadata fields is the Core Metadata Specification [#cms]_ document. + +The details of the updates considered to the Core Metadata Specification [#cms]_ +document as part of this PEP are detailed here and will be added to the +canonical source once this PEP is approved. + + +Added in Version 2.2 +-------------------- + +License-File (multiple use) +::::::::::::::::::::::::::: + +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 +file(s) in the built package. + + +Changed in Version 2.2 +---------------------- + +License (optional) +:::::::::::::::::: + +Text indicating the license covering the distribution. This text can be either a +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 syntax +''''''''''''''''''''''''' + +A `License Expression` is a string using the SPDX license expression syntax as +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 +expression definition, a `License Expression` can use the following license +identifiers: + +- any SPDX-listed license short-form identifiers that are published in the + SPDX License List [#spdxlist]_ using either Version 3.10 of this list or any + later compatible version. Note that the SPDX working group never removes any + license identifiers: instead they may only mark one as "obsolete". + +- 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: + +- MUST ignore the case of the `License` field + +- SHOULD report an informational warning if one or more of the following applies: + + - the field does not contain a license expression, + - the license expression syntax is invalid, + - the license expression syntax is valid but some license identifiers are + unknown as defined here or the license identifiers have been marked as + deprecated in the SPDX License List [#spdxlist]_ + +- SHOULD store a case-normalized version of the `License` field using the + reference case for each SPDX license identifier and uppercase for the AND, OR + and WITH keywords. And SHOULD report an informational warning if the reference + case is not used. + +License expression examples:: + + License: MIT + + License: BSD-3-Clause + + License: MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause) + + License: GPL-3.0-only WITH Classpath-Exception-2.0 OR BSD-3-Clause + + License: This software may only be obtained by sending the + author a postcard, and then the user promises not + to redistribute it. + + License: LicenseRef-Proprietary AND LicenseRef-Public-Domain + + +Classifier (multiple use) +::::::::::::::::::::::::: + +Each entry is a string giving a single classification value for the +distribution. Classifiers are described in PEP 301. + +Examples:: + + Classifier: Development Status :: 4 - Beta + Classifier: Environment :: Console (Text Based) + +Tools SHOULD issue an informational warning if this field contains a licensing +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 +[#classif]_. + +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. + +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. + + +Mapping legacy Classifiers to new License Expressions +''''''''''''''''''''''''''''''''''''''''''''''''''''' + +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:: + + Classifier: `License :: OSI Approved :: MIT License` + +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: + `LicenseRef-Proprietary` expression. + +- Classifier `License :: Public Domain` becomes License: `LicenseRef-Public-Domain` + expression, though tools should encourage the use of more explicit and legally + portable licenses identifiers such as `CC0-1.0` [@cc0]_, the `Unlicense` + [#unlic]_: the meaning associated with the term "public domain" is thoroughly + dependent on the specific legal jurisdiction involved and some jurisdictions + have no concept of Public Domain as it exists in the USA. + +- The generic and ambiguous Classifiers `License :: OSI Approved` + and `License :: DFSG approved` do not have an equivalent license expression. + +- The generic and 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. + +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 +=================================== + +* Metadata-Version is now 2.2. +* Added one new field: ``License-File`` +* Updated the documentation of two fields: ``License`` and ``Classifiers`` + + +Backwards Compatibility +======================= + +The reuse of the `License` field means that we keep backward compatibility. The +specification of the `License-File` field is only writing down the practices +of the `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 +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 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. + +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). + + +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. Also, users are +less likely to start using a new field than make small adjustments to their use +of existing fields. + + +2. mapping licenses used in the license expression to specific files in the + license files (or vice versa). + +This would require using a mapping (two parallel lists would be too prone to +alignment errors) and a mapping would bring extra complication to how license +are documented by adding an additional nesting level. + +A mapping would be needed as you cannot guarantee that all expressions (e.g. a +GPL with an exception may be in a single file) or all the license keys have a +single license file and that any expression does not have more than one. (e.g. +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 [#setuptools5030]_ 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==20.4 + pyparsing==2.2.1 + ordered-set==3.1.1 + +These are using these license expressions:: + + appdirs: MIT + packaging: Apache-2.0 OR BSD-2-Clause + pyparsing: MIT + ordered-set: MIT + +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 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 +============================================================== + +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` strings [#classif]_ prefixed with `License::` and +the `License` field as free text [#licfield]_. + + +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` [#samplesetup]_. + + +The License files in wheels and setuptools +------------------------------------------ + +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 [#wheels]_ license files are automatically added to the `.dist-info` + directory if they match one of a few common license file name patterns (such + as LICENSE*, COPYING*). Alternatively a package author can specify a list of + license files paths to include in the built wheel using in the + `license_files` field in the `[metadata]` section of the project's + `setup.cfg`. Previously this was a (singular) `license_file` file attribute + that is now deprecated but is still in common use. See [#pipsetup]_ for + instance. + +- 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 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 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 +`setuptools` `license_file` `setup()` argument. + + +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__` +[#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. + + +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 + current metadata spec). + +- `pbr` [#pbr]_ uses similar data as setuptools but always stored setup.cfg. + +- `poetry` [#poetry]_ specifies the use of the `license ` field in + `pyproject.toml` with SPDX license ids. + + +Appendix 3. Surveying how other package formats document licenses +================================================================= + +Here is a survey of how things are done elsewhere. + +License in Linux distribution packages +--------------------------------------- + +Note: in most cases the license texts of the most common licenses are included +globally once in a shared documentation directory (e.g. /usr/share/doc). + +- Debian document package licenses with machine readable copyright files + [#dep5]_. This specification defines its own license expression syntax that is + very similar to the SDPX syntax and use its own list of license identifiers + 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 + 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. + +- 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. + +- GNU Guix (based on NixOS) has a single License field, uses its own license + symbols list [#guix]_ and specifies to use one license or a list of licenses + [#guixlic]_. + +- Alpine Linux apk packages [#alpine]_ recommend using SPDX identifiers in its + license field. + + +License in Language and Application packages +-------------------------------------------- + +- In Java, Maven POM [#maven]_ defines a licenses XML tag with a list of license + items each with a name, URL, comments and "distribution" type. This is not + mandatory and the content of each field is not specified. + +- JavaScript npm package.json [#npm]_ use a single license field with SPDX + 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 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 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 the SPDX license expression syntax with + "and" and "or" keywords; or this is a list of strings if there is a choice of + licenses (aka. a "disjunctive" choice of license). + +- NuGet packages [#nuget]_ were using only a simple license URL and are now + specifying to use an SPDX License expression and/or the path to a license + file within the package. The NuGet.org repository states that they only + accepts license expressions that are `approved by the Open Source Initiative + or the Free Software Foundation.` + +- 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 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 identifiers, a path or a URL to a + license file. + +- 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 specification also provides a mapping between pre-SPDX Legacy license + Identifiers and SPDX ids. Cabal also specifies a `license-file(s)` field that + lists license files that will be installed with the package. + +- Erlang/Elixir mix/hex package [#mix]_ specifies a `licenses` field as a + required list of license strings and recommends to use SPDX License ids. + +- 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 ids. 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` [#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 + using `SPDX-License-Identifier`. + +- 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-Identifier` in code and now follows the + Linux ways [#uboot]_. + +- The Apache Software Foundation projects use RDF DOAP [#apache]_ with a single + license field pointing to SPDX license ids. + +- The Eclipse Foundation promotes using `SPDX-license-Identifiers` [#eclipse]_ + +- The ClearlyDefined project [#cd]_ promotes using SPDX license ids and + expressions to improve license clarity. + +- 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 +========== + +This document specifies version 2.2 of the metadata format. + +- Version 1.0 is specified in PEP 241. +- Version 1.1 is specified in PEP 314. +- Version 1.2 is specified in PEP 345. +- Version 2.0, while not formally accepted, was specified in PEP 426. +- Version 2.1 is specified in PEP 566. + +.. [#cms] https://packaging.python.org/specifications/core-metadata +.. [#cdstats] https://clearlydefined.io/stats +.. [#cd] https://clearlydefined.io +.. [#osi] http://opensource.org +.. [#classif] https://pypi.org/classifiers +.. [#spdxlist] https://spdx.org/licenses +.. [#spdx] https://spdx.org +.. [#spdx22] https://spdx.github.io/spdx-spec/appendix-IV-SPDX-license-expressions/ +.. [#wheels] https://github.com/pypa/wheel/blob/b8b21a5720df98703716d3cd981d8886393228fa/docs/user_guide.rst#including-license-files-in-the-generated-wheel-file +.. [#reuse] https://reuse.software/ +.. [#licexp] https://github.com/nexB/license-expression/ +.. [#spdxpy] https://github.com/spdx/tools-python/ +.. [#scancodetk] https://github.com/nexB/scancode-toolkit +.. [#licfield] https://packaging.python.org/guides/distributing-packages-using-setuptools/?highlight=MANIFEST.in#license +.. [#samplesetup] https://github.com/pypa/sampleproject/blob/52966defd6a61e97295b0bb82cd3474ac3e11c7a/setup.py#L98 +.. [#pipsetup] https://github.com/pypa/pip/blob/476606425a08c66b9c9d326994ff5cf3f770926a/setup.cfg#L40 +.. [#setuptoolssdist] https://github.com/pypa/setuptools/blob/97e8ad4f5ff7793729e9c8be38e0901e3ad8d09e/setuptools/command/sdist.py#L202 +.. [#packaging] https://packaging.python.org/guides/distributing-packages-using-setuptools/?highlight=MANIFEST.in#license-txt +.. [#pycode] https://github.com/search?l=Python&q=%22__license__%22&type=Code +.. [#setuptools5030] https://github.com/pypa/setuptools/blob/v50.3.0/setup.cfg#L17 +.. [#packlic] https://github.com/pypa/packaging/blob/19.1/LICENSE +.. [#conda] https://docs.conda.io/projects/conda-build/en/latest/resources/define-metadata.html#about-section +.. [#flit] https://github.com/takluyver/flit +.. [#poetry] https://poetry.eustace.io/docs/pyproject/#license +.. [#pbr] https://docs.openstack.org/pbr/latest/user/features.html +.. [#dep5] https://dep-team.pages.debian.net/deps/dep5/ +.. [#fedora] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/ +.. [#fedoratext] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_license_text +.. [#fedoralic] https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/#_valid_license_short_names +.. [#fedoralist] https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses +.. [#opensuse] https://en.opensuse.org/openSUSE:Packaging_guidelines#Licensing +.. [#opensuselist] https://docs.google.com/spreadsheets/d/14AdaJ6cmU0kvQ4ulq9pWpjdZL5tkR03exRSYJmPGdfs/pub +.. [#gentoo] https://devmanual.gentoo.org/ebuild-writing/variables/index.html#license +.. [#glep23] https://www.gentoo.org/glep/glep-0023.html +.. [#gentoodev] https://devmanual.gentoo.org/general-concepts/licenses/index.html +.. [#freebsd] https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/licenses.html +.. [#archinux] https://wiki.archlinux.org/index.php/PKGBUILD#license +.. [#archlinuxlist] https://wiki.archlinux.org/index.php/PKGBUILD#license +.. [#openwrt] https://openwrt.org/docs/guide-developer/packages#buildpackage_variables +.. [#nixos] https://github.com/NixOS/nixpkgs/blob/master/lib/licenses.nix +.. [#guix] http://git.savannah.gnu.org/cgit/guix.git/tree/guix/licenses.scm +.. [#guixlic] https://guix.gnu.org/manual/en/html_node/package-Reference.html#index-license_002c-of-packages +.. [#alpine] https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package#license +.. [#maven] https://maven.apache.org/pom.html#Licenses +.. [#npm] https://docs.npmjs.com/files/package.json#license +.. [#gem] https://guides.rubygems.org/specification-reference/#license= +.. [#perl] https://metacpan.org/pod/CPAN::Meta::Spec#license +.. [#cargo] https://doc.rust-lang.org/cargo/reference/manifest.html#package-metadata +.. [#cratesio] https://doc.rust-lang.org/cargo/reference/registries.html#publish +.. [#composer] https://getcomposer.org/doc/04-schema.md#license +.. [#nuget] https://docs.microsoft.com/en-us/nuget/reference/nuspec#licenseurl +.. [#flutter] https://flutter.dev/docs/development/packages-and-plugins/developing-packages#adding-licenses-to-the-license-file +.. [#bower] https://github.com/bower/spec/blob/master/json.md#license +.. [#cocoapod] https://guides.cocoapods.org/syntax/podspec.html#license +.. [#cabal] https://cabal.readthedocs.io/en/latest/developing-packages.html#pkg-field-license +.. [#mix] https://hex.pm/docs/publish +.. [#dub] https://dub.pm/package-format-json.html#licenses +.. [#cran] https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Licensing +.. [#spdxids] https://spdx.org/using-spdx-license-identifier +.. [#gnu] https://www.gnu.org/licenses/identify-licenses-clearly.html +.. [#fsf] https://www.fsf.org/blogs/rms/rms-article-for-claritys-sake-please-dont-say-licensed-under-gnu-gpl-2 +.. [#linux] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst +.. [#uboot] https://www.denx.de/wiki/U-Boot/Licensing +.. [#apache] https://svn.apache.org/repos/asf/allura/doap_Allura.rdf +.. [#eclipse] https://www.eclipse.org/legal/epl-2.0/faq.php +.. [#android] https://github.com/aosp-mirror/platform_external_tcpdump/blob/master/MODULE_LICENSE_BSD +.. [#cc0] https://creativecommons.org/publicdomain/zero/1.0/ +.. [#unlic] https://unlicense.org/ + + +Copyright +========= + +This document is placed in the public domain or under the CC0-1.0-Universal +license [#cc0]_, whichever is more permissive. + + +Acknowledgements +================ + +- Nick Coghlan +- Kevin P. Fleming +- Pradyun Gedam +- Oleg Grenrus +- Dustin Ingram +- Chris Jerdonek +- Cyril Roelandt +- Luis Villa + + + +.. + Local Variables: + mode: indented-text + indent-tabs-mode: nil + sentence-end-double-space: t + fill-column: 80 + End: