> Maybe an issue could be filed to propose to adopt a machine-readable > license format. Maybe that of Debian's packages: > https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ which > itself uses the SPDX License List, i.e., https://spdx.org/licenses/
That would be a massive improvement. There are two places in the metadata to add a license. The one here[1] is the one that does always appear to have a consistent format like License :: OSI Approved :: GNU General Public License v2 (GPLv2) License :: CeCILL-B Free Software License Agreement (CECILL-B) License :: OSI Approved :: MIT License so it seems like the inconsistently formatted licenses are deprecated, but unless someone goes and updates the licenses of older packages or PyPI removes packages that don't conform there is still this problem. Another challenge is that even with the newer license format, multiple license statements are allowed. If multiple license statements indicated dual licensing then this would not a be a problem, but this package[2] seems to indicate otherwise. In the older "license" field it says "Artistic-License-2.0 + Forced-Fairplay-Constraints", which indicates that it is non-free, but it's not machine readable. The newer, "classifiers field has two license statements: License :: OSI Approved :: Artistic License License :: Free To Use But Restricted "Artistic License" is already too vague, because it does not specify the version and version 1.0 is non FSF approved, but this could be addressed by Debian's format. However, allowing multiple license statements no matter how specific they are is a problem if one of those is a free license and the software is not free. [1] https://packaging.python.org/tutorials/packaging-projects/ [2] https://pypi.org/pypi/yamldata/json
signature.asc
Description: PGP signature
