Should we reuse the license field or add a new license-expression field in the metadata?

[pombredanne]

Originally from #2 (comment)

Moved here as a ticket based on @pradyunsg suggestion to support a more focused discussion:

---

@Conan-Kudo you wrote in #2 (comment)

I think it's perfectly fine to allow people to put SPDX expressions in License, but adding a field that can be optionally used that must be SPDX compliant means that if that field is detected, software can guarantee they can process it that way.

My personal inclination as documented in the current version is to avoid field inflation and reuse the license field. There is no ambiguity at all when this contains a parsable SPDX license expression or not. Since the field is in use and a warning would be issued it provides the proper gentle nagging that will help authors evolve towards a more accurate license documentation. a field that's new and optional is likely to have a lower impact and create a bigger disruption:

We have today two fields used for license (and this is confusing). And we would go to three fields all optional if we add a new one, a likely source of more confusion for authors IMHO.

With that said, if there is a consensus to use a separate field, I will update the draft to use that instead.

@Steap @ncoghlan @pfmoore @cjerdonek @pradyunsg what's your last take on this topic?

This and the freezing the list of licenses discussed in #2 (comment) are IMHO the last two objections/concerns to address and resolve before moving this PEP to an official draft IMHO

[ncoghlan]

IIRC, I was originally one of the folks suggesting a new field, but I've come around to @pombredanne's point of view:

• reusing License means that tools that treat License as an opaque string don't need to change at all
• reusing License means that any projects that have already chosen to publish SPDX identifiers will become compliant automatically
• reusing License means that tools that already check if License is a valid SPDX identifier before falling back to treating it is an opaque string won't need to change
• reusing License creates a potential opportunity to reduce publisher confusion, whereas a new field will necessarily increase it

I also don't think a new field would actually help metadata consumers much, as it would complicate their logic, rather than simplifying it:

if the_new_field_exists_and_is_valid_spdx:
    ... use the new field
elif the_License_field_exists_and_is_valid_spdx:
    ... use the License field
else:
   ... do something else???

Even with a new field, metadata consumers are still going to need to cope with parse failures, and they'd also still need to cope with the new field being missing entirely.

[pombredanne]

@ncoghlan your arguments are much cleaner and clearer than anything I uttered so far ... Thank you.
I will wait a couple days to get more feedback here and on #6 and I will coordinate then with @pfmoore to move this to a bona fide draft PEP.
I will add these #6 and #7 to the rejected ideas section

[pradyunsg]

Yea, I'm on board for reusing it.

My concern was a hypothetical one, where a not-intended-to-be-SPDX License value would be treated as one, but well, that's obviously not a major concern. :P

[vyadh]

Has adding a trove classifier to indicate the state of the license field been considered? That way, PyPI could validate the SPDX expression on submission, and consumers would unambiguously be able to trust the field should be treated as SPDX.