Make proprietary license classifier harder to add by accident

[snydergd]

We run all our components through Sonatype's quality checking tools automatically. It checks for known vulnerabilities, quality issues, and license issues. It is set up to block licenses that are not free. When it blocks something, we investigate and ensure we can accept any risk before unblocking. Sometimes this takes considerable time and involves multiple people - delaying progress. I don't think we are alone at all in doing this.

Today by coincidence, we had two packages get blocked for having proprietary licenses. Looking at the home pages for the components, it was quite clear that they were distributed under Apache 2.0. Their pyproject.toml files listed "Apache 2.0" as the license, and even had a classifier listed explicitly for the license. I couldn't even find the word "Proprietary" when searching the repository. After some looking, I discovered that evidently poetry adds the proprietary license classifier when it doesn't know what the license value represents. In this case, I think that it was looking for "Apache-2.0", but found "Apache 2.0".

I created issues in these projects and at least in one it appears it was not intended. I'm assuming this is also the case for the other. Here are those issues with some more details: z3z1ma/dbt-osmosis#74, Bachmann1234/diff_cover#353

To summarize -- I think Poetry's handling of the license value is causing some wasted time and could be improved.

Ideas to make better:

• Poetry stops defaulting to the proprietary classifier and instead only allows valid values (or "proprietary" maybe) when the value is supplied
• Poetry recognize a few different variations of the license, such as "Apache 2.0" besides the standard "Apache-2.0"

Does anyone have any thoughts on these ideas or better ideas to help make this better?