PEP 639: Improving license clarity with better package metadata

Packaging
143

As a scientific Python developer and docs writer/copyeditor following this proposal with great interest and looking forward to seeing it accepted in a timely manner, I’d be happy to pitch in and help with a PR addressing the relatively mechanical updates if that would help move things along promptly and wouldn’t duplicate work already done by @pombredanne . It does appear that the change to use the License-Expression field requires several major content revisions to be made, which I assume @pombredanne would want to handle. These seem to be:

  • Update the prose to reflect that the same field is not being re-used, and explain why adding a new one was chosen
  • Replace the License-Expression field with re-using the License field in the Rejected ideas section and summarize the rationale as discussed and agreed here
  • Decide on and document the backward-compatibility implications and the migration plan as described below

The more mechanical changes that would be more appropriate for someone like me to help with, include:

  • The referenced version number should be updated to 2.3 and the updated version to 2.2 throughout the PEP, and 2.2 added to the references section
  • References to the License field should be updated to refer to the License-Expression field, where appropriate
  • The PEP’s title, structure, metadata and phrasing needs to be updated to reflect that used in PEP 643 per @pf_moore , that it no longer represents a canonical spec but a proposal to update the actual spec
  • We might want to update the “License Files in wheels and setuptools” section a bit to reflect the additional names added in pypa/wheel#251 that provide fairly comprehensive coverage of most common license files (full disclosure: I contributed that PR)
  • Use consistent case (either Title Case or Sentence case) throughout the headings; they are currently a mish-mash of both

In addition, the following technical changes could be considered, though they are not so clear-cut:

  • Should the “replaces” field and other links be updated to point to PEP 643 (Metadata v2.2) ? That PEP formally updates the metadata spec to 2.2, but unlike the others isn’t titled following the pattern Metadata for Python Software Packages X.Y, doesn’t specify it “replaces” the previous metadata spec, doesn’t list the previous specs and the fact that it describes the changes in v2.2 is buried in the prose. Therefore, if that PEP is referenced as-is, it would be a “dead-end” for readers and not describe the remainder of the metadata specification, so it seems either the link to PEP 566 be retained, or that PR updated to at least link to the reference the previous metadata specs. Clarified per @pf_moore and moved above that this PEP needs to be reframed to reflect the new convention in PEP 643
  • The title can simply bumped to reflect the new version, but since the PEP focuses on one specific topic in detail, is there a reason it isn’t titled as on the thread here? As an average developer, the latter would be much clearer at a glance what it describes than having to remember what a particular version happens to contain, but maybe that has already been discussed and decided. Clarified (I think) per @pf_moore and moved above that the PEP’s title should reflect it as a topical proposal for the metadata spec, not a new spec itself