✨ feat(build): publish a third-party notices file - #3266
Merged
Merged
Conversation
virtualenv already satisfies its MIT obligations: every embedded pip and setuptools wheel carries its own MIT notice inside its own .dist-info/licenses/ directory, redistributed unmodified. What was missing was discoverability, not compliance - nothing at the top level told a downstream auditor those notices existed or where to find them without unzipping a bundled wheel to check. tasks/upgrade_wheels.py now writes THIRD-PARTY-NOTICES.md alongside embed/__init__.py, reading the same BUNDLE_SHA256 table so a wheel bump keeps it current with no separate update step. Only the licence of the wheel virtualenv itself redistributes is reproduced; whatever that wheel in turn vendors already carries its own licence inside it and stays there rather than being duplicated at the top level. Identical licence text across bundled versions of the same package collapses into one section listing every matching filename. LICENSE itself is untouched. Appending third-party text to it is what breaks GitHub's own licence detection on repositories that try it, so the notices live in a separate file instead and are declared alongside LICENSE through PEP 639 license-files rather than folded into it. The regression test locates THIRD-PARTY-NOTICES.md relative to its own file rather than through BUNDLE_FOLDER: a non-editable install puts the installed package under site-packages with no relationship to the checkout, so deriving the repo root from the installed package's own runtime path only worked by coincidence in an editable dev environment and failed outright under CI's real install.
gaborbernat
force-pushed
the
third-party-notices
branch
from
September 19, 2026 07:49
4701b51 to
1f0d064
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
virtualenv already satisfies its MIT obligations. 📄 Every embedded pip and setuptools wheel carries its own MIT notice inside its own
.dist-info/licenses/directory, and virtualenv redistributes that wheel unmodified, notice included. What was missing was discoverability, not compliance: nothing at the top level told a downstream auditor those notices existed or where to find them without unzipping a bundled wheel to check.tasks/upgrade_wheels.pynow writesTHIRD-PARTY-NOTICES.mdalongsideembed/__init__.py, reading the sameBUNDLE_SHA256table so a wheel bump keeps it current with no separate update step. Only the licence of the wheel virtualenv itself redistributes gets reproduced; whatever that wheel in turn vendors already carries its own licence inside it, so duplicating those at the top level would only add churn on every bump for no benefit. Identical licence text across bundled versions of the same package collapses into one section listing every matching filename, which is whypip-26.0.1andpip-26.2.1share a section today.LICENSEitself stays untouched. GitHub's own guidance warns that a licence file complicated by appended text can stop its detector from naming a licence at all, showing "View license" in the sidebar instead, which is exactly what happens on projects that append third-party text to their ownLICENSE. The notices live in a separate file and are declared alongsideLICENSEthrough PEP 639license-filesrather than folded into it.A unit test asserts every currently bundled distribution has a section in the checked-in file, so a wheel bump that forgets to regenerate it fails loudly instead of silently drifting.