Fundamentals 9 min read

Simplifying CPython Copyright Notices: Lessons from Issue gh-126133

The article examines CPython issue gh‑126133 where Hugo van Kemenade proposed simplifying the project's copyright notice by keeping only the first publication year, discusses legal feedback from the PSF, compares practices of major open‑source projects, and concludes with the accepted change merged into the main branch.

DevOps Engineer

Jan 20, 2025

Simplifying CPython Copyright Notices: Lessons from Issue gh-126133

While browsing the CPython repository I discovered Issue gh-126133 , in which Hugo van Kemenade, the release manager for Python 3.14 & 3.15, suggested stopping the yearly update of the copyright notice.

In my own release duties I also update the PSF copyright each January, so I was very interested in this proposal.

The article walks through Hugo's reasoning, the discussion within the CPython community, and how the idea was eventually accepted and merged into the main branch.

Hugo's proposal

Every January the repository updates the PSF copyright line:

With 2025 approaching, Hugo asked whether the PSF could allow a copyright statement that does not require yearly changes.

He suggested alternatives such as:

Hugo listed many previous PRs that updated the year, many of which were duplicate and wasted developer time, describing the work as tedious and possibly unnecessary.

He also pointed out that many large projects have stopped updating the year, for example:

These either show only the first year, omit the year entirely, or end with “present”. Hugo asked whether CPython could adopt a similar approach.

Gregory P. Smith, a member of the Python Steering Council, advised that the full statement should not be removed, that Hugo should seek guidance from the PSF (the copyright holder), and that a clear policy should be added to the development guide to handle such requests.

PSF legal response

The PSF explained that a copyright notice is optional and informational; the historic requirement to include a notice has been removed by international treaties, so the form of the notice does not affect the holder’s rights.

Nevertheless, a notice can be useful. According to the U.S. Copyright Office, an effective notice includes the © symbol (or the word “copyright”/“copr.”), the year of first publication, and the name of the rights holder.

For works that have been revised many times, multiple dates or date ranges may appear. For instance, a file created in 2015 and revised in 2017, 2018, 2019, and 2022 could be shown as:

Using a range like 2015‑2022 is common but loses detail about which years actually had revisions.

Updating the end‑year each time adds no special meaning and using “‑present” is not recommended.

Both of Hugo’s suggested formats that include a year are acceptable; however, omitting the first‑publication year is not advised because it is a required element of a valid notice.

The PSF also noted that “Python Software Foundation” may not accurately describe all contributors, and suggested alternatives such as “FOO project contributors” or “authors listed in the contributors file”.

In short, there is no perfect solution, but the notice is not critical; choose a reasonable format and apply it consistently.

This was the full reply from PSF legal.

Some participants suggested that Hugo should obtain approval from the PSF board, but the legal team clarified that the board only handles topics that require full board involvement; legal counsel was consulted for this matter.

The answer received up‑votes and reactions from Hugo and others.

Ultimately, Hugo’s proposal—“include only the first‑publication year and delete the end year”—was merged into CPython’s main branch (see https://github.com/python/cpython/pull/126236 ).

Summary

From this issue we learn that, like Python, Google, Microsoft, and Netflix, we can simplify copyright notices by keeping only the first publication year.

I am not a lawyer, so this is not legal advice.

If it works for Python, Google, Microsoft, and Netflix, it should work for us as well.

Open-source Software Licensing CPython copyright legal

Written by

DevOps Engineer

DevOps engineer, Pythonista and FOSS contributor. Created cpp-linter, commit-check, etc.; contributed to PyPA.

0 followers

Reader feedback

How this landed with the community

Rate this article

Was this worth your time?

Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.