Hi, I think that the PSFL is a great license and has served Python very well. However I think it can be improved upon to equally be able to serve the broader Python community. Some of these improvements will probably require involvement from Packaging, but I think that work can only start if/ when the PSF wishes to move forward. Obligatory IANAL, I have only tried to use the PSFL both professionally and in hobby pursuits and come up against barriers.
OSI approval -
The gold standard for open source projects, however it is very unclear (to me) if the PSFL is or is not approved. According to trove classifiers it is; the trove classifier is License :: OSI Approved :: Python Software Foundation License. According to Wikipedia it is on OSI's approved licenses list. On SPDX it does not get the OSI Approved? tick. It does appear on the OSI site but does not get the badge of approval. Further confusing this point, PSFL can be found on this page which states The following licenses have been approved by the OSI but also appears on this other page under the statemet Licenses in this group are specific to their authors and cannot be reused by others.
Reuse by those not associated with the PSF -
That last point by OSI is one I have heard elsewhere and is where I think the PSF could make the biggest difference. The PSFL, obviously, has a lot of language specific to this organization and its trademarks. Reusing this license would of course require replacing those values, but its not so easy as with other popular licenses. Consider BSD-3 where the values needing replaced are both contained to the first line and stubbed out with tokens that are easily replaceable. In the PSFL there are more values and they are more spread out.
It is my understanding that the text of a license agreement is also copyrighted, not always under the same terms as the license itself. So although one could go and manually change the year and copyright holder, doing so may actually violate another copyright. And to what extent can the PSFL be changed? aGPL includes the copyright for the license text in the same body but explicitly disallows changing any part of it. Would the PSF allow re-wording? What about referenced to āPythonā in the license - if an individual is releasing software related to the language, a new or modified interpreter, are they allowed to keep this trademark in their license?
Use by package authors -
This is mainly capturing some data from the python ecosystem. There are currently 482 projects on PyPI that are tagged with License :: OSI Approved :: Python Software Foundation License. Most of these are not associate with the PSF but could appear to claim association by using a license that in both the name and in the only official body mention the PSF. I have checked just a few of them, but it appears that when using this classifier projects either donāt include a LICENSE file, or when they do it is a license written BSD-style. I donāt see any projects attempting to copy the actual text.
For other language communities, the best practice is often to follow the license that the language uses, unless or until you have a reason to deviate. That ship has probably sailed for Python, and maybe was never going to occur with the high level of contributions from non-traditional programming disciplines that have their own licensing best practices. But changes to this license might make it easier for those coming from other programming communities and being used to following the community when it comes to choosing a license. It would be nice to see the PSFL projects approach the numbers returned for āBSDā, āMITā, āApacheā, or ā*GPL*ā which all show ā10,000+ā results on PyPI.
What are the fundamental differences between the PSF-2.0 and the various BSD versions (Wikipedia says itās āBSD-likeā)? Is there a particular issue that PSF-2.0 solves that other licenses donāt?
Iām trying to understand what advantage there actually is in making the license āgenericā, versus just pushing people towards a more appropriate license.
The PSF license really shouldnāt be used by anyone other than Python itself. Itās existence is based entirely on historical requirements of where Python was developed, not because it is in any way provides a unique feature compared to other open source licenses.
I would just use BSD-3, Apache, or MIT if you wanted a similar license.
Thanks Brett. I am fine if this is the official stance on the license. But then I think we could do more to steer users into choosing one of those appropriate licenses over the PSFL. Or maybe you feel that onus is mostly on the package maintainer? As mentioned above some several hundred packages use this license, often as their only license classifier. Some of these packages are very popular and may encourage consumers to use the same license on their own module, especially if it was an extension.
One place that reusing the PSFL rather than a similar license such as BSD would be advantageous is in releasing derived works. Specifically, releasing an interpreter variant, whether one that looks like CPython or one that is generally a drop-in replacement but maybe doesnāt share code with CPython. Being able to use the same license means being able to switch interpreters without a new legal audit. It also means that such an interpreter can be released without having to be dual-licensed. As an actual example, Jython is released under the PSFL (full license text, only partially modified).
The OSI states
Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
It is unclear to me if this is possible with the PSFL. It does have a clause about derived works, but says nothing about the license covering any changed or added components.
This is my main use-case. Modifying CPython for fun (recompiling my forkās grammar) and profit (fixing CVEs for a company) I would like to share these changes using the same license, but it doesnāt seem right under current circumstances.
This changes the discussion! CPython is covered by a stack of licenses, the most recent of which is the PSF license (if I understand the situation correctly). Projects can use the PSF License if they want (but as mentioned this has no benefit compared to other more popular licenses), but really should not use the Python license.
It doesnāt need to say that. As a āpermissiveā license, there is no requirement that derived works be distributed under the same license as the original work.
Anyone who makes a derived work can choose to distribute their modified version under the same license, but they can also choose to distribute under any license that is compatible with the original license.
If/when more pieces of the stdlib are deprecated/removed, I expect more third-parties starting to take care of them, so it would be nice to give them some advice. Giving legal-related advice is always problematic, and Iām not a lawyer, but I see what seems to work for Python: all the licences are in a big list. Each licence says in its own words that some pieces of its text must be preserved; thatās satisfied by simply copying the whole text.
The PSF licence agreement is written specifically for Python. We donāt recommend using it for other projects.
If you reuse code from Python, you might need to include a copy of the PSF licence agreement (and other relevant licences on this page), just like Python does with its incorporated software. But we donāt recommend using Pythonās license as the only license of your project.
(For general licence suggestions, see for example choosealicense.com.)
I donāt think I can just add such a note. Do you think itās it a good idea to ask SC or PSF legal for opinions on such a note?
In general, when copying code from somewhere else, you have to keep
all copyright notices in place and include the license for that code
in your distribution.
You can license your code in the distribution under different terms,
unless one of the licenses you include is a copy-left one, which then
forces you to license your code under the copy-left license.
Note that you cannot relicense 3rd party code, unless you have a
special license agreement with the author which allows you to do
so. The PSF does have this via the contrib agreements for contributed
code; but not necessarily for included code such as e.g. he expat code.
See doc/license.rst for details.
If you want to make your distribution compatible with the Python
license, BSD or MIT are good choices. Those are generic licenses,
so can be used on arbitrary code. Thereās no need to turn the
Python license or the PSF license v2 into a generic one.
This isnāt really true. Yes, Python can be redistributed, retaining the PSFL, and any changed/ added work can be under any different license but the new work cannot be under a PSFL. So there is no choice, currently derived works must include all the original licenses and add a new license type, which may be very similar but nonetheless will have different terms.
If this is how the PSF wants its license to be used that is fine, but authors of derived works do not have the choice to distribute their work under the same terms as Python AFAICT.
I donāt believe it is clear. I will raise this with OSI directly.
Itās not; I think almost everyone here is agreeing loudly on how the PSF license should be handled.
My point is to make it clear to others, who might just be starting out with a project and have no idea how licensing works. If they choose wrong, it might bite them years later when their project becomes popular.
But Iām not comfortable with putting a a note on the license page without legal approval.