Abstract

This PEP defines a specification how licenses are documented in the Pythonprojects.

To achieve that, it:

• Adopts theSPDX license expression syntax as ameans of expressing the license for a Python project.
• Defines how to include license files within the projects, source and builtdistributions.
• Specifies the necessary changes toCore Metadata andthe correspondingPyproject Metadata keys
• Describes the necessary changes tothesource distribution (sdist),built distribution (wheel) andinstalled project standards.

This will make license declaration simpler and less ambiguous forpackage authors to create, end users to understand,and tools to programmatically process.

The changes will update theCore Metadata specification to version 2.4.

Goals

This PEP’s scope is limited to covering new mechanisms for documentingthe license of adistribution package, specifically defining:

• A means of specifying a SPDXlicense expression.
• A method of including license texts indistribution packagesand installedProjects.

The changes that this PEP requires have been designed to minimize impact andmaximize backward compatibility.

Non-Goals

This PEP doesn’t recommend any particular license to be chosen by anyparticular package author.

If projects decide not to use the new fields, no additional restrictions areimposed by this PEP when uploading to PyPI.

This PEP also is not about license documentation for individual files,though this is asurveyed topicin an appendix, nor does it intend to cover cases where thesource distribution andbinary distribution packages don’t havethe same licenses.

Motivation

Software must be licensed in order for anyone other than its creator todownload, use, share and modify it.Today, there are multiple fields where licensesare documented inCore Metadata,and there are limitations to what can be expressed in each of them.This often leads to confusion both for package authorsand end users, including distribution re-packagers.

This has triggered a number of license-related discussions and issues,including onoutdated and ambiguous PyPI classifiers,license interoperability with other ecosystems,too many confusing license metadata options,limited support for license files in the Wheel project, andthe lack of precise license metadata.

As a result, on average, Python packages tend to have more ambiguous andmissing license information than other common ecosystems. This is supported bythestatistics page of theClearlyDefined project, anOpen Source Initiative effort to helpimprove licensing clarity of other FOSS projects, covering all packagesfrom PyPI, Maven, npm and Rubygems.

The current license classifiers could be extended to include the full range ofthe SPDX identifiers while deprecating the ambiguous classifiers(such asLicense::OSIApproved::BSDLicense).

However, there are multiple arguments against such an approach:

• It requires a great effort to duplicate the SPDX license list and keep it insync.
• It is a hard break in backward compatibility, forcing package authorsto update to new classifiers immediately when PyPI deprecates the old ones.
• It only covers packages under a single license;it doesn’t address projects that vendor dependencies (e.g. Setuptools),offer a choice of licenses (e.g. Packaging) or were relicensed,adapt code from other projects or contain fonts, images,examples, binaries or other assets under other licenses.
• It requires both authors and tools understand and implement the PyPI-specificclassifier system.
• It does not provide as clear an indicator that a packagehas adopted the new system, and should be treated accordingly.

Rationale

A survey was conducted to map the existing license metadatadefinitions in thePython ecosystem and avariety of other packaging systems, Linux distributions,language ecosystems and applications.

The takeaways from the survey have guided the recommendations of this PEP:

• SPDX and SPDX-like syntaxes are the most popularlicense expressionsin many modern package systems.
• Most Free and Open Source Software licenses require package authors toinclude their full text in aDistribution Package.

Therefore, this PEP introduces two new Core Metadata fields:

• License-Expression thatprovides an unambiguous way to express the license of a packageusing SPDX license expressions.
• License-File thatoffers a standardized way to include the full text of the license(s)with the package when distributed,and allows other tools consuming theCore Metadatato locate adistribution archive’s license files.

Furthermore, this specification builds uponexisting practice in theSetuptools andWheel projects.An up-to-date version of the current draft of this PEP isimplemented in theHatch packaging tool, and an earlier draft of thelicense files portionisimplemented in Setuptools.

Terminology

The keywords “MUST”, “MUST NOT”, “REQUIRED”,“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”in this document are to be interpreted as described inRFC 2119.

Specification

The changes necessary to implement this PEP include:

• additions toCore Metadata,as defined in thespecification.
• additions to the author-providedproject source metadata,as defined in thespecification.
• additions to thesource distribution (sdist), built distribution (wheel) and installed projectspecifications.
• guide for toolshandling and converting legacy license metadata to licenseexpressions, to ensure the results are consistent and correct.

Note that the guidance on errors and warnings is for tools’ default behavior;they MAY operate more strictly if users explicitly configure them to do so,such as by a CLI flag or a configuration option.

MITBSD-3-ClauseMIT AND (Apache-2.0 OR BSD-2-Clause)MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause)GPL-3.0-only WITH Classpath-Exception-2.0 OR BSD-3-ClauseLicenseRef-Special-License OR CC0-1.0 OR UnlicenseLicenseRef-Proprietary

Use-it-after-midnightApache-2.0 OR 2-BSD-ClauseLicenseRef-License with spacesLicenseRef-License_with_underscores

[project]license="MIT"[project]license="MIT AND (Apache-2.0 OR BSD-2-clause)"[project]license="MIT OR GPL-2.0-or-later OR (FSFUL AND BSD-2-Clause)"[project]license="LicenseRef-Proprietary"

[project]license-files=["LICEN[CS]E*","AUTHORS*"][project]license-files=["licenses/LICENSE.MIT","licenses/LICENSE.CC0"][project]license-files=["LICENSE.txt","licenses/*"][project]license-files=[]

[project]license-files=["..\LICENSE.MIT"]

[project]license-files=["LICEN{CSE*"]

Backwards Compatibility

Adding a newLicense-Expression Core Metadata field and a top-level stringvalue for thelicense key in thepyproject.toml[project] tableunambiguously means support for the specification in this PEP. This avoids therisk of new tooling misinterpreting a license expression as a free-form licensedescription or vice versa.

The legacy deprecated Core MetadataLicense field,license key tablesubkeys (text andfile) in thepyproject.toml[project] tableand license classifiers retain backwards compatibility. A removal isleft to a future PEP and a new version of the Core Metadata specification.

Specification of the newLicense-File Core Metadata field and adding thefiles in the distribution is designed to be largely backwards-compatible withthe existing use of that field in many packaging tools.The newlicense-files key in the[project] table ofpyproject.toml will only have an effect once users and tools adopt it.

This PEP specifies that license files should be placed in a dedicatedlicenses subdir of.dist-info directory. This is new and ensures thatwheels following this PEP will have differently-located licenses relative tothose produced via the previous installer-specific behavior. This is furthersupported by a new metadata version.

This also resolves current issues where license files are accidentallyreplaced if they have the same names in different places, making wheelsundistributable without noticing. It also prevents conflicts with othermetadata files in the same directory.

The additions will be made to the source distribution (sdist), builtdistribution (wheel) and installed project specifications. They documentbehaviors allowed under their current specifications, and gate them behind thenew metadata version.

This PEP proposes PyPI implement validation of the newLicense-Expression andLicense-File fields, which has no effect onnew and existing packages uploaded unless they explicitly opt in to usingthese new fields and fail to follow the specification correctly.Therefore, this does not have a backward compatibility impact, and guaranteesforward compatibility by ensuring all distributions uploaded to PyPI with thenew fields conform to the specification.

Security Implications

This PEP has no foreseen security implications: theLicense-Expressionfield is a plain string and theLicense-File fields are file paths.Neither introduces any known new security concerns.

How to Teach This

A majority of packages use a single license which makes the case simple:a single license identifier is a valid license expression.

Users of packaging tools will learn the valid license expression of theirpackage through the messages issued by the tools when they detect invalidones, or when the deprecatedLicense field or license classifiers are used.

If an invalidLicense-Expression is used, the users will not be ableto publish their package to PyPI and an error message will help themunderstand they need to use SPDX identifiers.It will be possible to generate a distribution with incorrect license metadata,but not to publish one on PyPI or any other index server that enforcesLicense-Expression validity.For authors using the now-deprecatedLicense field or license classifiers,packaging tools may warn them and inform them of the replacement,License-Expression.

Tools may also help with the conversion and suggest a license expression inmany common cases:

• The appendixAppendix: Mapping License Classifiers to SPDX Identifiers providestool authors with recommendation on how to suggest a license expressionproduced from legacy classifiers.
• Tools may be able to suggest how to update an existingLicense valuein project source metadata and convert that to a license expression,as alsospecified in this PEP.

Reference Implementation

Tools will need to support parsing and validating license expressions in theLicense-Expression field if they decide to implement this part of thespecification.It’s up to the tools whether they prefer to implement the validation on theirside (e.g. likehatch) or use one of the availablePython libraries (e.g.license-expression).This PEP does not mandate using any specific library and leaves it to thetools authors to choose the best implementation for their projects.

Rejected Ideas

Many alternative ideas were proposed and after a careful consideration,rejected. The exhaustive list including the rationale for rejecting can be foundin aseparate page.

Appendices

A list of auxiliary documents is provided:

• DetailedLicensing Examples,
• User Scenarios,
• License Documentation in Python and Other Projects,
• Mapping License Classifiers to SPDX Identifiers,
• Rejected Ideas in detail.

Acknowledgments

• Alyssa Coghlan
• Kevin P. Fleming
• Pradyun Gedam
• Oleg Grenrus
• Dustin Ingram
• Chris Jerdonek
• Cyril Roelandt
• Luis Villa
• Seth M. Larson
• Ofek Lev

Copyright

This document is placed in the public domain or under theCC0-1.0-Universal license, whichever is more permissive.