(tl;dr licensing in this repo is unusually messy, let's fix it)

The README declares the Python Packaging User Guide to be licensed under CC BY-SA 3.0, but the repository has no dedicated license file (this is obviously a Bad Thing! for any OSS repo, and especially for this guide which has explaining best practices as a goal). The specifications also contain substantial material imported from PEPs under public-domain or public-domain/CC0 terms, and at least one imported schema has yet another license.

I did some digging into the history. I propose documenting the existing licensing and provenance, fixing missing third-party notices, and adopting REUSE to maintain per-file licensing information (this is a little fiddly to set up, but given how much of a mess licensing is right now, it seems the best choice here). We should decide separately whether to seek more permissive licensing for existing specification contributions.

This is a proposal to establish and maintain accurate records. Adding REUSE metadata would not itself authorize a change to anyone's license - that will need separate action to obtain permission, if we want that.

Licensing history

AI usage declaration: a lot of the digging done here with help of Codex Sol 6.1

The original guide and the current README notice

• The repository began in December 2009 as Tarek Ziadé's Hitchhiker's Guide to Packaging.
• The first dedicated license notice, added in January 2010, specified CC BY-NC-SA 3.0.
• The project became the Python Packaging User Guide in March 2013. In May 2013, the notice changed to CC BY-SA 3.0, removing the noncommercial restriction.
• In January 2014, the license page was deliberately removed and its notice moved into the README. That is still the repository's general license notice today.

The missing license file does not mean the guide has never been licensed: CC BY-SA 3.0, section 4(a) allows providing the license URI instead of a copy of its text. Nevertheless, including the full text and a clear scope statement would make the terms much easier to discover (including by standard tools and GitHub's Community Standards page for this repo) and preserve when redistributing the repository.

One historical question remains: I found the 2013 license-change commit, but no accompanying permission record in the Git history or GitHub discussion I checked. That does not establish that permission was absent; it could have been arranged elsewhere. It would be useful to recover and record the basis for that change from the original maintainers.

• March 20: Marcus Smith proposed replacing the old guide or obtaining permission to copy it.
• March 23: the new repository existed, with the decision about seeding it from the old guide still open.
• July 2: Marcus announced that the old guide had been forked after PyCon.

Those messages and the full thread that they're a part of show the handover history, but no explicit approval to remove the noncommercial restriction (or anything about licensing really).

PEP-derived specifications

The specifications have a different provenance from much of the guide.

Older packaging PEPs commonly have a bare public-domain dedication. Since python/peps#1117, merged in July 2019, PEP 1 has required new PEPs to use public-domain/CC0 terms. The discussion explicitly states that older PEPs were not being relicensed. We therefore need to check individual source notices rather than treating all PEPs as having the same grant.

Some imports initially preserved their source notices, then removed them while adapting the documents to the guide. Examples include:

• PEP 427 / wheel specification.
• PEP 440 / version specifiers.
• PEP 518 / build-system configuration.
• PEP 723 / inline script metadata.

In contrast, the externally managed environments specification still explicitly declares public-domain/CC0 terms.

Removing an imported notice does not erase the original dedication. However, later original contributions made here are not automatically covered by the PEP authors' dedication either. This leaves a distinction between the reusable original material and subsequent additions made under the repository's general CC BY-SA notice, except where more specific terms apply.

Also, not every specification originated in a PEP. For example, the entry-points and .pypirc specifications were written here. We should not automatically label the entire specifications directory as public domain or CC0.

A specific question for the planned manylinux migration is that the current PEP 600 source has no explicit copyright/license section. We should clarify its terms upstream before assigning a CC0 identifier to an imported copy.

Third-party schema licensing

There is at least one concrete exception beyond the guide and PEP licenses:

• #1875 identifies SchemaStore as the source of the pylock JSON schema.
• #1889 imported it here.
• SchemaStore's license at the referenced source revision is Apache-2.0.

I compared the parsed schema at that revision with the current extra/specifications/schemas/pylock.schema.json: only $id differs. We should preserve the Apache license, record the source and modification, and ensure that the relevant information accompanies the published schema resources as well as the source checkout.

The other schemas, executable examples and assets also need their provenance checked; a PEP's license should not be assumed to cover independently imported supporting files.

Website notices and translations

In 2021, contributors reported that the README's CC BY-SA notice contradicted the website footer and Weblate's PSF license setting. The footer was traced to the documentation theme, rather than a documented decision to relicense the guide.

That was a historical footer problem; it should not be interpreted as evidence that the whole repository is available under the PSF license. The current Weblate configuration and any contributor terms still need checking. Translation catalog headers say that they use the guide's license, and the catalogs live on the translation/source branch, so an audit limited to main would miss them.

The tooling is part of this audit too. For example, noxfile.py explicitly declares CC BY-SA 3.0. We should not silently assign MIT or another software license to existing tooling while adding metadata.

Adopting REUSE for accurate license provenance tracking

REUSE supplies a standard, human- and machine-readable way to associate copyright and license information with files, keep the corresponding license texts, and check coverage automatically. It supports several complementary approaches:

These are described in the REUSE specification. Using REUSE does not require putting a header in every documentation file.

There is a relevant ecosystem precedent in meson-python, which uses SPDX headers, REUSE.toml, and pre-commit checks.

For this repository, a hybrid seems appropriate: headers where portability and provenance matter, sidecars for schemas and assets, and path mappings for groups of ordinary documentation once their terms are established.

There are some important limits:

• reuse lint checks coverage and metadata validity, not whether a contributor had permission to make a particular grant. A green check cannot resolve the historical questions above.
• We should not add a blanket override merely to make every file pass. Likewise, automatically assigning the default license to newly imported files could hide third-party exceptions.
• CC-BY-SA-3.0 OR CC0-1.0 would promise a license choice for the material it covers. That would be inaccurate if only the original PEP text has CC0 terms and later additions have CC BY-SA terms. Different portions need their scope explained; snippet annotations may help where boundaries are clear. See REUSE's multi-licensing guidance.
• Bare public-domain dedications should be recorded faithfully, using an appropriate LicenseRef and dedication text where needed, rather than being silently converted into CC0 grants.
• Licensing examples in our documentation must not be mistaken for licenses of the containing page. REUSE supports ignore blocks for such examples.

REUSE metadata also does not automatically produce website notices. We still need a published licensing explanation and suitable attribution for distributed resources.

Alternatives

I favor REUSE because the repository already has enough distinct sources and licenses to benefit from maintained, checked per-file records. We can also generate an SPDX inventory from those records instead of maintaining another inventory separately.

Proposed implementation

I suggest keeping the work reviewable in separate commits or PRs:

1. Record the existing licensing and outstanding questions. Build a provenance inventory covering documentation, PEP imports, schemas, tooling, examples, assets and translations.
2. Add license files and repair third-party notices. Add a root LICENSE explaining the default and exceptions, full texts under LICENSES/, and provenance notices where needed. Update the README to link to the explanation. Possibly add a pyproject.toml with license/license-files under [project].
3. Add REUSE metadata.
4. Add automated checks and contributor instructions. Once coverage is complete, add reuse lint to pre-commit/CI. Explain how to handle an original contribution versus an imported file.
5. Publish the licensing explanation - make it accessible from the rendered guide.

These steps would document the existing situation. Any change that requires additional permission should be reviewed separately, with that permission recorded.

Longer-term specification policy

There are two independent decisions here: how to maintain licensing information, and what terms to use for specifications.

My preferred choice here is to keep ordinary guide content under its existing CC BY-SA terms, while making specifications available under public-domain/CC0 terms (consistently with modern PEPs). That would make specifications easier to reproduce, implement and move between repositories.

For new work, we can establish an explicit contribution policy matching that split between specs and the rest of the guide. For existing substantial CC BY-SA contributions, we need to establish the relevant rights and obtain permission before offering that material under CC0 too.

Uniformly relicensing the entire repository would be a much larger project and is not necessary to fix the immediate documentation and license compliance gaps.

Decisions and help needed

• Do maintainers agree with adopting REUSE?
• Can the original maintainers help recover the permission for the 2013 change from CC BY-NC-SA to CC BY-SA? Cc @qwcode as the author of that commit.
• Who can verify the current Weblate licensing configuration and contributor terms?
• (Probably for the Packaging Council) is public-domain/CC0 terms as the intended direction for specification contributions right?