Use SPDX License ID correctly

[Software Package Data Exchange (SPDX)](https://spdx.org/) is an open standard for communication software bill of material information.

According to the [SPDX License List](https://spdx.org/licenses) `Apache-2.0` is an unambiguous short identifier for the [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0), which holds for the requests project.

This PR proposes to use this SPDX Identifier rather than `Apache 2.0` (without hyphen). Note that the proposed change does not change the license of the project but rather declares it unambiguously in a machine-readable format. As a result, the packaged version on PyPi will also be updated once requests is built again and all metadata crawlers will benefit from the change.

I'm relatively indifferent. I can't find any notable Python packages using Apache 2.0 with this approach, they're all using `Apache 2.0`. It's hard to tell if this is an alternatively established standard, or if everyone has been copying us. I'll need to do a little more digging before we merge this.

`__license__` isn't standardized or supposed (or not supposed) to be SPDX. Likewise the license text is from the Apache foundation itself. The license field in PyPI metadata is also free form. The classifiers are what are standardized and what I believe uses SPDX. If those are right this is superfluous and unnecessary 

Thanks a lot for your responses.

@nateprewitt
I've investigated license metadata of packages in a recent project and caught this issue that way. Some other Python packages do the following.
* [Connexion](https://github.com/spec-first/connexion/blob/main/setup.py) declares the full name of the license `Apache License Version 2.0`, which is more verbose but also unambiguous.
* [Cryptography](https://github.com/pyca/cryptography/blob/main/setup.cfg) uses a valid SPDX expression for their dual-license model: `BSD-3-Clause OR Apache-2.0`. Note that both sides of the disjunction are SPDX Identifiers.
* [Packaging](https://github.com/pypa/packaging/blob/main/packaging/__about__.py) does the same thing `BSD-2-Clause or Apache-2.0`.

This is just a selection of some major packages that I frequently use and there are many more examples.

@sigmavirus24 
Of course, `__license__` has barely any semantics. However, the main reason why I created this PR is that [setup.py](https://github.com/psf/requests/blob/main/setup.py) refers to `__license__` and uses its content as a metadata field. As shown above, the community has (to a certain degree) agreed on using SPDX and even [Apache](https://www.apache.org/licenses/LICENSE-2.0) refers to the SPDX IDs explicitly.
SPDX helps to automate SBOM creation which has a huge impact on processes in industry as well as the adaption of OS Software in Industry.

Imho, classifiers cannot solve this issue: Firstly, the existing classifier is not really useful, since a human must conclude which exact License Text is meant by `Apache Software License`. Secondly, [PEP 639](https://peps.python.org/pep-0639/) even deprecates the `license :: `classifiers.

> Thanks a lot for your responses.
> This is just a selection of some major packages that I frequently use and there are many more examples.

The fact that they are major means they've already had other people lie to them about the semantics of the license attribute in python packaging metadata.

> @sigmavirus24 
> Of course, `__license__` has barely any semantics. However, the main reason why I created this PR is that [setup.py](https://github.com/psf/requests/blob/main/setup.py) refers to `__license__` and uses its content as a metadata field. 

If you read my response closely that's what I'm talking about. The license field in python packaging metadata is not SPDX and cannot be. PyPI isn't the only repository and even it allows closed source and proprietary licenses that have no SPDX classifier. It's intended to be free form text as Cryptography uses it. 

>As shown above, the community has (to a certain degree) agreed on using SPDX and even [Apache](https://www.apache.org/licenses/LICENSE-2.0) refers to the SPDX IDs explicitly.

Check the history of that page. I'm willing to bet it didn't when this project started using the license. 

> SPDX helps to automate SBOM creation which has a huge impact on processes in industry as well as the adaption of OS Software in Industry.

I'm well aware of it and the fragile way most companies implement it as well as the fragile solutions sold by others.

> Imho, classifiers cannot solve this issue: Firstly, the existing classifier is not really useful, since a human must conclude which exact License Text is meant by `Apache Software License`. Secondly, [PEP 639](https://peps.python.org/pep-0639/) even deprecates the `license :: `classifiers.

That's disappointing as those classifiers are the only reliable source of that information. That PEP is only a draft though. It hasn't been accepted. It may well never be accepted and had no weight on this conversation as such. Also that PEP would deprecate the license field you want us to put SPDX in. In other words, you want us to do what you want based off an unaccepted pep (from 2019) deprecating the exact thing you want us to change.


---
Disclaimer: responding in the middle of the night from my phone while helping anewborn connect sleep cycles. Please excuse brevity and typos 

First of all, I have to admit that PEP 639 was really not a helpful argument. I completely missed the fact that it has not even been accepted yet. Please excuse the confusion.

The classifiers may be standardized to a certain extent but they often remain imprecise (for instance, they don't tell the exact version of a BSD License or Apache License). One can at least deduce whether a license is permissive or copy-left.

We can also agree that the `license` metadata key is just a plain string without any SPDX semantics.
For that reason, one could remain the PR to somethink like "Make value of license key in metadata more useful". There is obviously no _correct_ usage of that `license` metadata key.

However, I still believe that `Apache-2.0` is more expressive than `Apache 2.0` since it is at least a standardized term. Developers who spot SPDX IDs everyday will consider this as helpful, other people will likely not care.

May I ask for what reason have you originally decided on `Apache 2.0`?

Finally, I cannot resolve your initial argument: no semantics of that key -> any efforts in changing the content are "superfluous and unnecessary". So this PR may not the right place to discuss such fundamental question because noone will resolve this dilemma in the foreseeable future.

> I think we can go back and forth for quite a while on the volatility/usefulness of parsing the license field. Ideally PyPI would provide exact trove-classifiers to unambiguously define the license, or we’d propose an PEP to get an alternative mechanism setup.

Actually trove classifiers are easy to propose, easy to adopt, and as far as I understood - low overhead for PyPI. I see no reason they couldn't be made more helpful and potentially include the appropriate SPDX information especially since I believe they're indexed for search (where license is not)

> 
> That’s a long process though. For the time being, I see cryptography did recently make [this change](https://github.com/pyca/cryptography/pull/7050/files) as well. I’m fine following if this is a direction the community wants to move.

I hesitate to say that it's the direction the community is moving in. 

Quoting the SPDX wiki: ( https://wiki.spdx.org/view/SPDX_FAQ )

> How does one represent a file or package that is dual licensed (i.e., a license choice)?
> SPDX license information can be represented using conjunctive or disjunctive regular expressions. For example, a file that is dual licensed under either the GPL-2.0 or MIT would be represented using the following disjunctive expression: (GPL-2.0 or MIT).
> How does one represent a file that is licensed under two or more licenses?
> SPDX license information can be represented using conjunctive or disjunctive regular expressions. For example, a file that is subject to the Apache-2.0, MIT and GPL-2.0 would be represented using the following conjunctive expression: (Apache-2.0 and MIT and GPL-2.0).

As such Cryptography would have to include parenthesis to be a valid classifier and yet that seems sufficient that some tools can handle the absence but no tools can handle a space instead of a hyphen?

I'm arguing this change because every time a standard like this comes along someone wants to change the metadata and it breaks someone else. 

Given there's no way to enforce this attribute is SPDX compliant in the tooling we rely on our might rely on, there's no preventing a regression. I'm okay justifying the license text with what the ASF now uses (compared to what it was when Kenneth (likely illegally) switched to it). I just see little value in encouraging PRs to tweak this every few years for a non-semantic field that may end up deprecated anyway. I'd also expect there are people that will try to edit every other reference to Apache 2.0 to the hyphenated version in a misguided effort to help. 

Off-topic, but parenthesis in the case of cryptography are [not required](https://spdx.dev/ids/) to be a valid SPDX expression.

> I think we can go back and forth for quite a while on the volatility/usefulness of parsing the license field. Ideally PyPI would provide exact trove-classifiers to unambiguously define the license, or we’d propose an PEP to get an alternative mechanism setup.

That's exactly my point.

But I also understand your concerns well for avoiding spam of PRs fixing missing hypens or introducing community trends (although I strongly believe that SPDX is more than a trend) without having a standard to follow.

> Off-topic, but parenthesis in the case of cryptography are [not required](https://spdx.dev/ids/) to be a valid SPDX expression.
> 
> > I think we can go back and forth for quite a while on the volatility/usefulness of parsing the license field. Ideally PyPI would provide exact trove-classifiers to unambiguously define the license, or we’d propose an PEP to get an alternative mechanism setup.
> 
> That's exactly my point.
> 
> But I also understand your concerns well for avoiding spam of PRs fixing missing hypens or introducing community trends (although I strongly believe that SPDX is more than a trend) without having a standard to follow.

People said openstack wasn't a trend but it's decreasing in popularity and such while the next trend (Kiss) is on the ascent. And yes OS had quite a number of good years there just as SPDX had been gaining popularity for years now. 

Alright, given we have some strong contention on this and as I originally said, I'm not particularly opinionated, I'm going to propose we table this PR for the time being.

Let's see how PEP 639 plays out, it looks like Ofek and some other well-known maintainers are already starting to adopt. That will likely be the path going forward, and we'll have definitive guidance on what changes _need_ to be made. Thanks for starting this dicussion @dmholtz, and feel free to check back in when the PEP has a final decision.