License metadata changes is no longer easily machine parseable

[tapetersen]

The changes in latest release to the License metadata field is no longer a known Classifier according to https://packaging.python.org/en/latest/specifications/core-metadata/#license which makes it hard to accept without whitelisting this package's license exact wording.

From what I understand from the wording and spec just moving this to License-Expression instead of License would be valid and express the same as described by https://packaging.python.org/en/latest/specifications/core-metadata/#license-expression

If that doesn't sound like a problem I'll provide a PR later (unless you'll just fix it yourself)

[tapetersen]

Ok reading more of the spec I see some conflicting (or at least to me confusing/contradicting) statements about the license key under the project table between https://packaging.python.org/en/latest/specifications/pyproject-toml/#license and the pep https://peps.python.org/pep-0639/#add-string-value-to-license-key

Feel free too ignore this until I've checked where the incompatibility is between the metadata here, the packaging spec, the pep or just the tool we use to interpret the resulting fields.

Or just close as at least I don't really even see a way to declare this in a way that is standard and parseable according to some official rules anywhere.

[ronf]

Yeah, I agree there's inconsistency here. While https://packaging.python.org/en/latest/specifications/core-metadata/#license mentions a "License" keyword being deprecated in favor of "License-Expression", and the latter being designed to be machine-readable, it's not clear to me where you'd put such a declaration. As you noted, the pyproject.toml spec at https://packaging.python.org/en/latest/specifications/pyproject-toml/#license only mentions a "license" keyword, which can contain either text or a reference to a file, and I don't see any mention in that spec about how to specify "License-Expression", so I'm not sure what change I can make here.

Digging a bit deeper, I did find a reference to in PEP 639, but it seems to suggest that pyproject.toml should continue to use "license", but no longer use the "text" and "file" variants described in the spec above, which seems like it would break backward compatibility. Also, this PEP seems to only be provisionally accepted at this point, and I'm not sure which build tools support what it is proposing.

[tapetersen]

Something similar happened with a release of attrs with corresponding issue here and for them relevant fix in the comment.
python-attrs/attrs#1386 (comment)

They also note that support for PEP 639 in twine is comming soon and should probably fix licence-expression support.

In the meantime if you don't object I think adding both of the 2 licenses as classifiers would allow current tools and pypi to handle the info reasonably (not ideal as there are no real way to signify if both licenses must be adhered to or just either or but i've seen the practice in other projects).

I could do a pr for the changes but somewhat unfamiliar with the publishing and testing if it works as expected/desired on pypi.

[ronf]

Given that PEP 639 still isn't fully accepted and we're only just now starting to see some tools (like twine) support it, I think it may be a bit too bleeding edge to make this change in AsyncSSH right now.

Also, including both may not be a good idea, as PEP 639 explicitly disallows it:

For all newly-uploaded distribution archives that include a License-Expression field, the Python Package Index (PyPI) MUST reject any that specify both License and License-Expression fields.