minor issues in `writing-pyproject-toml`

[tar-ancalime]

Issue Description

In https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license-and-license-files there might be some possible issues:

1. As per PEP 639 licenses should be declared with two fields:

   This reads a bit as if both fields need to be given, but this doesn't seem to follow from PEP 639, unless I've overseen something.

2. The table there says, that setuptools support it since 77.0.3, but setuptools itself seems to claim that it already worked with 77.0.0 ("Support for project.license-files and SPDX license expressions in project.license (PEP 639) were introduced in version 77.0.0."), and AFAICS this is actually the case.

Regards.

Code of Conduct

• I am aware that participants in this repository must follow the PSF Code of Conduct.
  One cannot reasonably assume people to accept a lengthy potentially legally binding document without legal advice for a mere bug report.

[webknjaz]

cc @befeleme

[sinoroc]

I agree that the phrasing regarding licenses is unclear. I noticed the same thing some days ago, it reads like both fields are necessary.

---

One cannot reasonably assume people to accept a lengthy potentially legally binding document without legal advice for a mere bug report.

It is about whether or not you know that there is a code of conduct (and since you read the sentence, you know, and you could check the box). If contributors agree with it or not is not up for debate (in this context). Contributors do not have the choice of agreeing with it or not. What really happens is that if a contributor infringes the code of conduct, then moderators will act accordingly, that's it. For example, the contribution gets deleted by moderators. We do not want contributors to (potentially falsely) claim that they did not know that there is a code of conduct.

[DimitriPapadopoulos]

Additionally, the interpretation where both fields would be needed contradicts section Creating a LICENSE:

Most build backends automatically include license files in packages. See your backend’s documentation for more details.

Obviously, license cannot be avoided, as it wouldn't make sense for a backend to define a default licence. On the other hand, a default glob value for license-files picks up most licence file names. The backends I know of do provide a default value, typically ['LICEN[CS]E*', 'COPYING*', 'NOTICE*', 'AUTHORS*'].

[DimitriPapadopoulos]

As for setuptools version 77.0.0 vs. 77.0.3, I guess it is implied that versions 77.0.0, 77.0.1 and 77.0.2 have bugs annoying enough to suggest version ≥ 77.0.3 for PEP 639 support. See NEWS.rst:

v77.0.3

Bugfixes

• Temporarily convert error for license glob patterns containing ../ into a deprecation warning to allow an accomodation period. (#4896)
• Better error messages for packaging.licenses import errors in environments with packaging<24.2. The import statement was also deferred to spare users that are not using license expressions. (#4898)
• Avoided eagerly raising an exception when license-files is defined simultaneously inside and outside of pyproject.toml. Instead we rely on the existing deprecation error. (#4899)

The same is true of other backends. See for example the flit Release history:

• 3.11: Support for SPDX license expressions and multiple license files, as detailed in PEP 639:
• 3.12: Support for license expressions using the AND and OR operators (PR #731).
• not released yet: Support WITH in SPDX license expressions flit#735