pypa
Remove deprecated classifier
Summary of changes
A possible additional step is to add a SPDX license expression like license = "MIT" to the [project] table in PyPI.
This PR does not implement this additional step because as far as I understand, would need a very complex compound SPDX expression to cope with the vendored packages: MIT AND APACHE-2 AND LGPL-3.0-or-later AND PSF-2.0.... Moreover this expression would need reviewing/updating everytime the vendored dependencies are updated.
Closes
Pull Request Checklist
- [ ] Changes have tests
- [ ] News fragment added in
newsfragments/. (See documentation for details)
Summary of changes
A possible additional step is to add a SPDX license expression like license = "MIT" to the [project] table in PyPI.
This PR does not implement this additional step because as far as I understand, would need a very complex compound SPDX expression to cope with the vendored packages: MIT AND APACHE-2 AND LGPL-3.0-or-later AND PSF-2.0.... Moreover this expression would need reviewing/updating everytime the vendored dependencies are updated.
In my opinion, we should set the SPDX identifier in pyproject.toml and remove the LICENSE file (as proposed here). Currently, PyPI lists the license for this project as MIT, which is correct. It does have vendored packages, but those packages are clearly bundled and carry their own metadata, so I'm strongly opposed to reflecting their licenses in Setuptools' own metadata. If we get to a stage where lawyers start asking us to present vendored packages' licenses in Setuptools' metadata, I'll probably just stop vendoring packages. Feel free to add the SPDX identifier or not in this PR.
Currently, PyPI lists the license for this project as MIT, which is correct. It does have vendored packages, but those packages are clearly bundled and carry their own metadata, so I'm strongly opposed to reflecting their licenses in Setuptools' own metadata.
IMNAL but that's how I understand it as well. If the license of the vendored project is compatible, just including the vendored code doesn't change the project license. There are a lot of closed-source project out there which just list all their included open source codes licenses (mostly MIT). That doesn't make the closed-source MIT licensed now though. Not complete sure about GPL licenses, as those, in principle also add constraints for redistributing. That might not matter much in the end since setuptools itself is MIT and open source, so anyone would be free to redistribute a copy of it under GPL (if the original MIT license is included).
remove the LICENSE file (as proposed here)
My suggestion would be to keep it. Yes, it might be redundant at least to some extent. Then again some external project might require all included code to be shipped with license files. The file isn't that big either.
I believe these are only deprecated if you use the license expression; otherwise, there's no way to determine the package license. I don't think you are supposed to remove the classifier without adding License-Expression to replace it. https://peps.python.org/pep-0639/#deprecate-license-classifiers clearly states "replaced", and even has specific rules for warning if both are set.
Feel free to add the SPDX identifier or not in this PR.
I think I will leave this for a separated PR (together with removing the LICENSE file, if we go for that direction).
My suggestion would be to keep it. Yes, it might be redundant at least to some extent. Then again some external project might require all included code to be shipped with license files. The file isn't that big either.
Yeah, I am also a bit scared of removing the file, don't know what are the implications from a legal stand point. The license file states exactly what are the terms of the license. On the other hand, a SPDX index, while a convention, is not immediate and people must be aware about how to find the license information and how the SPDX correspondence works [^1]. I would be more relax to remove it if a specialised lawyer told us that it is safe to do so. Not sure if PSF has resources to provide that advice (¿?)
I believe these are only deprecated if you use the license expression; otherwise, there's no way to determine the package license. I don't think you are supposed to remove the classifier without adding License-Expression to replace it. https://peps.python.org/pep-0639/#deprecate-license-classifiers clearly states "replaced", and even has specific rules for warning if both are set.
The PEP text does say that tools may issue a deprecation warning and suggest a replacement even if the license expression is not set. Although that is a MAY, not a SHOULD.
[^1]: E.g. devs from other communities simply embedding all the python code and not creating a proper Python package may not even be aware of pyproject.toml as a place to find that info. In that sense, the deprecation warning regardless of using license expression is legit. The removal is not.
Not sure if PSF has resources to provide that advice (¿?)
They might. In the last year's discussion of copyright lines, @EXiMiOUS mentioned some PSF legal mailing list: https://github.com/python/cpython/issues/126133#issuecomment-2470818250. And @hugovk mentioned emailing them. Perhaps, they'd have a better pointer on where to write.
My thoughts:
The licence says that the copyright notice and permission notice must be included somewhere:
https://github.com/pypa/setuptools/blob/6ead555c5fb29bc57fe6105b1bffc163f56fd558/LICENSE#L8-L9
(The copyright notice is missing but that's another matter.)
And including them in a dedicated file is a good way to achieve that.
The SPDX licence expression is metadata about the licence, not the licence itself. The licence expression can say MIT, so you can look up the permission notice, but doesn't say anything about the copyright notice.
I expect you would get feedback from users if the licence file is removed. I got similar feedback this week after I got the copyright filename wrong, which caused License-File to be missing from the package metadata: https://github.com/termcolor/termcolor/issues/99.
I agree the classifier should be replaced by a licence expression, and not just removed.
I'd also be in favor of coupling this change with SPDX.
I am personally not comfortable right now with SPDX for the setuptools repository, because it is not trivial to maintain the compound license expression for setuptools in particular.
Now, I may be interpret the standard wrong. If I can have confirmation that it is not necessary for a project to produce accurate compound licenses in the case of subdirectories being licensed using a a different license than the overall project (and if this confirmation comes with an indication of where to read that in the standard), I can consider adding the change in this PR.
IMO, the classifier should not be removed without using the license key string value/License-Expression metadata field as defined by PEP 639. We all know classifiers aren't too precise, but using them was in the guidelines before the PEP.
Yeah, I am also a bit scared of removing the file, don't know what are the implications from a legal stand point.
Not exactly a legal implication, but as a Fedora package maintainer I would be asking to include it back again, as roughly described in the skeleton PR.
Also, regarding SPDX, the Fedora lawyers issued the expression creation guidelines that say that License: tag expression should be an enumeration of all licenses found in the source code of the package (source). I know they've cooperated closely with the SPDX team during the last few years of the effort to migrate to the standard. I don't know if there any other valid approaches/interpretation of the standard.
Thank you very much @befeleme.
tag expression should be an enumeration of all licenses found in the source code of the package
I understand the motivation, but I don't think this is realistic or maintainable in the case of projects that have vendored code, that is why I am reluctant in adding it.
I am happy to ship all the license files, so that the correct licensing information is discoverable, but deriving and maintaining a complete SPDX license expression (specially when the bundled files can vary between updates) is not something I wish to be working on.
Seems the license classifier was accidentally removed in https://github.com/pypa/setuptools/commit/4e1e89392de5cb405e7844cdc8b20fc2755dbaba. Would it make sense to revert https://github.com/jaraco/skeleton/pull/170 for the time being?
Seems the license classifier was accidentally removed in 4e1e893. Would it make sense to revert jaraco/skeleton#170 for the time being?
I created a PR to temporarily re-add the license declaration until a proper SPDX license expression is added. https://github.com/pypa/setuptools/pull/4957
I am personally not comfortable right now with SPDX for the setuptools repository, because it is not trivial to maintain the compound license expression for setuptools in particular.
I'm going to make the executive decision that it's not necessary to create a compound expression. The previous license identifier didn't include a compound expression (or otherwise attempt to reflect the licenses of vendored packages), so neither does the SPDX. The vendored packages carry their own license metadata, so I consider that a suitably accurate reflection of the intention of the license of Setuptools code and its vendored packages.
Since this issue was implemented at the skeleton level, it's now moot for this project, but thanks for raising it!
I'll follow up on the SPDX concern in jaraco/skeleton#171. Whatever the resolution there should apply to Setuptools along with other packages.