The license behind CPython and the standard library. Permissive, but a derivative work you distribute has to include a brief summary of your changes.
On this page
What it does
PSF-2.0 is the Python Software Foundation License Agreement, the license on CPython and the standard library. SPDX also lists a separate Python-2.0 identifier with the same practical duties, and this guide covers both, so a component page for either one links here. It is written as an agreement with the PSF rather than a bare permission grant. You may use it commercially, modify it, keep your changes closed and redistribute in source or binary form. Two conditions apply. Retain the PSF copyright notice and license text in every copy. Include a brief summary of the changes you made in any derivative work you make available to others, which is clause 3.
Details
The change summary is the clause people miss, and it only bites when you patch. Vendoring a fixed standard-library module counts as a derivative work, and so does shipping a patched CPython inside a desktop app. The summary has to travel with both. Everything else behaves like MIT: no copyleft, no network trigger, no linking rules. The other thing to watch is scope. This license covers CPython and the standard library, not the packages you install from PyPI, which carry their own licenses.
Pros
- Easy to drop into a closed, paid product. Procurement has seen this family hundreds of times.
- No copyleft on your own files. You keep your source private.
Cons
- The notice duty is easy to miss in a desktop, mobile, or container build. A web page is not a substitute for notices inside the artifact.
- Buyers who want an express patent grant will ask you to prefer Apache-2.0 over a short MIT-style text.
What it allows and requires
Choose a category to see the full grant in one scannable list. Permissions show what the license allows, limits show what it withholds, and obligations show the conditions your release process must satisfy.
Permissions
Commercial use
You may ship the code inside a paid product. The license does not restrict commercial use.
Modify
You may change the code, including keeping those changes private, unless a later obligation says otherwise.
Distribute
You may give copies to others. Distribution is what usually turns notice and source duties into real work.
Sublicense
You may include the code under your own product terms, so long as you still meet this license's conditions.
Private use
Use inside your company, including internal forks, does not by itself trigger distribution duties.
Limits
Hold liable
The authors disclaim warranty. Recipients cannot hold them liable for damages arising from the software, except where law forbids that disclaimer.
Use trademark
The license is not a trademark license. Names, logos and product marks stay with their owners unless a separate grant says otherwise.
Patent grant
The text does not grant patents. If buyers want an express patent grant, Apache-2.0 is the usual alternative.
GPL combine
PSF-2.0 is GPL-incompatible. Mixing Python's own files into a GPL work needs care; the two grants do not automatically stack.
Obligations
Include copyright
Keep the copyright line with every copy or substantial portion you distribute.
Include license
Keep the license text with every copy or substantial portion you distribute. A web page is not a substitute for notices inside a shipped artifact.
What PSF-2.0 requires when you ship
When a copy that includes PSF-2.0 code leaves your company, the grant is broad and the paperwork is easy to miss. Distribution here means an installer, a mobile binary, a container image, or an SDK another team embeds. Work this list against the artifact you actually hand over, not against a README. A hosted service that never gives out a copy still belongs on the record, but the notice duty does not fire until a copy exists.
You are meeting the terms for a plain install once the PSF copyright notice and license text sit on the component. They then travel with every copy you distribute.
You are meeting the terms for a bundled runtime, such as a desktop app that embeds CPython, when the license text ships inside that artifact.
You are meeting the change condition when a derivative work you distribute carries a short, plain description of what you changed, next to the license text. A purely internal patch carries no summary duty.
You are done for a hosted service that never distributes the interpreter. Nothing in the license triggers on running Python for your users.
You have read the identifier correctly when you know this guide also covers Python-2.0, which SPDX lists separately and the catalog carries as its own row.
The duties named in PSF-2.0
The license text itself is short. These are the named conditions. They follow the code, including files you vendor into your own repository and transitive packages in the lockfile.
Include copyright
Keep the copyright line with every copy or substantial portion you distribute.
Include license
Keep the license text with every copy or substantial portion you distribute. A web page is not a substitute for notices inside a shipped artifact.
Things to be aware of
- Skipping the change summary when vendoring a patched standard-library module. A one-line note in the file is enough, and leaving it out is not.
- Assuming this license covers everything installed from PyPI. Each package has its own license, most often MIT, BSD or Apache-2.0.
- Treating the old Python 1.6b1 terms as the same license. Those were incompatible with the GPL, while PSF-2.0 and later are not.
What the Python Software Foundation License 2.0 does not do
Search results often flatten Python Software Foundation License 2.0 into a slogan. These are the usual misreads. PSF-2.0 is a grant with conditions, not a permission to skip the paperwork below.
- the Python Software Foundation License 2.0 does not require you to publish your own source. Combining it with closed code is the point of the grant.
- the Python Software Foundation License 2.0 does not mean "no obligations." The copyright line and license text still have to travel with copies you hand to other people.
- It is not a patent license unless the text says so. MIT-family grants say nothing about patents.
How PSF-2.0 differs from nearby licenses
These licenses are often confused with PSF-2.0, but their release duties differ. Each row summarizes what the license requires when you ship. Open the linked page for the full checklist.
- PSF-2.0
- The license behind CPython and the standard library. Permissive, but a derivative work you distribute has to include a brief summary of your changes.
- MIT
- MIT lets you ship the code inside a closed, paid product. The one condition is that the copyright line and license text travel with every copy.
- Apache-2.0
- Permissive like MIT, plus an express patent grant. The catch is the NOTICE file: it has to travel inside the binaries you ship.
- GPL-2.0-or-later
- GPL-2.0 asks for source when you hand someone a binary. Running it on your own servers triggers nothing. The trigger is shipping a copy, not merely using it.
Common questions about Python Software Foundation License 2.0
Answers to common questions about what Python Software Foundation License 2.0 requires, when its duties apply, and what evidence belongs with a release.
What is the Python Software Foundation License 2.0?
PSF-2.0 is the Python Software Foundation License Agreement, the license on CPython and the standard library. SPDX also lists a separate Python-2.0 identifier with the same practical duties, and this guide covers both, so a component page for either one links here. It is written as an agreement with the PSF rather than a bare permission grant. You may use it commercially, modify it, keep your changes closed and redistribute in source or binary form. Two conditions apply. Retain the PSF copyright notice and license text in every copy. Include a brief summary of the changes you made in any derivative work you make available to others, which is clause 3.
What does PSF-2.0 require when you ship a product?
You are meeting the terms for a plain install once the PSF copyright notice and license text sit on the component. They then travel with every copy you distribute. You are meeting the terms for a bundled runtime, such as a desktop app that embeds CPython, when the license text ships inside that artifact. You are meeting the change condition when a derivative work you distribute carries a short, plain description of what you changed, next to the license text. A purely internal patch carries no summary duty. You are done for a hosted service that never distributes the interpreter. Nothing in the license triggers on running Python for your users. You have read the identifier correctly when you know this guide also covers Python-2.0, which SPDX lists separately and the catalog carries as its own row.
Does PSF-2.0 require me to open my own source?
It is not a patent license unless the text says so. MIT-family grants say nothing about patents.
How do I attribute PSF-2.0 in a product I ship?
Attribution for PSF-2.0 means the copyright line and the license text travel with every copy a recipient actually gets. That can be an about screen, a licenses file inside the installer, or a notice in the container image. A public page helps a buyer audit the inventory. It does not replace notices inside the artifact. If you copied files into your own repository, the header on those files still has to stay.
Is a website notice enough for PSF-2.0?
No. PSF-2.0 talks about copies. A public attestation page is the honest list for procurement. The condition is met when the notices sit in the material you hand over. Put them in the installer, the about screen, or a licenses file inside the binary, then keep the same texts on the page.
Do transitive PSF-2.0 dependencies count?
Yes. The condition follows the code, not the package you chose by name. If the lockfile pulled in PSF-2.0 transitively and you distribute that tree, those notices travel too. Listing only direct dependencies is how teams miss the duty.
How is PSF-2.0 different from MIT License?
PSF-2.0 asks this: The license behind CPython and the standard library. Permissive, but a derivative work you distribute has to include a brief summary of your changes. MIT License asks this: MIT lets you ship the code inside a closed, paid product. The one condition is that the copyright line and license text travel with every copy. Open the MIT License page for what that license requires when you ship. Do not treat the SPDX ids as interchangeable because the short names look similar.
Where do I record PSF-2.0 for a buyer?
A component declaring either PSF-2.0 or Python-2.0 resolves against its own catalog row, and both link to this guide. Both are notice licenses, so license text has to be attached before a component counts as live on your published page. SourceTrust fetches the artifact from PyPI, extracts the license file and fills the text in when it matches the declared id. Nothing in the product tracks your change summary, so that stays a note you write and keep with the code.
Where do I record PSF-2.0 for a buyer?
A component declaring either PSF-2.0 or Python-2.0 resolves against its own catalog row, and both link to this guide. Both are notice licenses, so license text has to be attached before a component counts as live on your published page.
SourceTrust fetches the artifact from PyPI, extracts the license file and fills the text in when it matches the declared id. Nothing in the product tracks your change summary, so that stays a note you write and keep with the code.
Read /docs/auto-fetch-license.
See also
The hub is the pillar for this cluster. Sibling licenses are the other spokes. Product FAQ links explain how SourceTrust records the duty, not the license text itself.
Practical guidance for procurement review, not legal advice. Confirm high-stakes use with counsel.