Add new License-Expression field. Bump to version 2.2

[pombredanne]

License expressions provide a better way to express the license of a
distribution using a well defined syntax and well known license ids
from SPDX.

Document that License and Classifiers will no longer deal with license
metadata in the future.

Bump metadata specification version to 2.2

Signed-off-by: Philippe Ombredanne pombredanne@nexb.com

[pombredanne]

This is a proposal to add support for SPDX license expressions following the discussion in https://github.com/pypa/warehouse/issues/2996

There are few things to discuss:

1. We could reuse the License string instead OR we could name the tag SPDX-License-Identifier . I chose License-Expression as a name for now.

2. Should we also reference the inclusion of license texts? Include more than one license file or other arbitrary files in metadata wheel#138

3. There are some constraints in the short term for dealing with licenses that are not on the SPDX license list. This includes the commonpublic domain dedications and any kind of proprietary licenses. A solution might be the emerging SPDX notion of "license namespaces".
   Another one would be to support a few extra license ids to capture these (that's the way npm has dealt with this). But that would be break using strictly the SPDX spec.

4. What is the list of tools that would be impacted? I would to review and start working on patches for the primary ones in parallel of this being reviewed

[pombredanne]

Also how would we deal with deprecation for spec fields and for tools using these: especially Classifiers.. AFAIK they are validated strictly when doing an upload to Pypi. If we were to deprecate and remove all the license classifiers in the future, how would this be handled? a strict rejection? a warning?

[pradyunsg]

Hmm... My understanding is that we'd still use the PEP process to track updates to the metadata specification.

The specification is living on packaging.python.org, because it's a good place to hold the "current state" of the specification, which is better than having to look at multiple PEPs to figure it out.

[pfmoore]

+1. This certainly sounds like a change that warrants wider discussion and publicity than a warehouse ticket and a PR here.

On a more specific note, as a package author I've no idea what SPDX is. Nor have I any interest in it - my interest in licensing for my personal projects doesn't go much beyond "do what you like with it, don't sue me, and beyond that (e.g. if you work out how to make millions off my work) I haven't really thought things through". If we're going to mandate something like this, I think we need a lot better guidance for people who frankly don't care about licensing. So I'd like a broader discussion on how we ensure this proposal caters for producers of license information as well as for consumers (who obviously have a need for precise and accurate information).

[pombredanne]

@pradyunsg @pfmoore this makes sense.
Let me restart a proper PEP draft (from pombredanne/spdx-pypi-pep#1 ) and bring up the topic for a proper packaging discussion at https://discuss.python.org/

@pfmoore re:

Nor have I any interest in it - my interest in licensing for my personal projects doesn't go much beyond "do what you like with it, don't sue me, and beyond that (e.g. if you work out how to make millions off my work) I haven't really thought things through". If we're going to mandate something like this, I think we need a lot better guidance for people who frankly don't care about licensing.

That's fair and definitely something to make clear and easy!

[pradyunsg]

Awesome! Thanks @pombredanne!

[pfmoore]

Fantastic - thanks for this :-)

[pombredanne]

I am closing this PR for now, while the draft PEP is being worked on pombredanne/spdx-pypi-pep#2
If this is completed and approved, a new PR will be made here to update the Core metadata spec according to this new PEP.