Add comment about where to get SPDX License identifier

[gene1wood]

Currently the setup.py file says to choose a license but doesn't give a hint as to what type of value should go in the license argument.

This patch adds to the comment a link to the Software Package Data Exchange license list which is where the license values are standardized.

[gene1wood]

The Travis CI run failed because Flake8 dropped support for Python 2.6 last week. sampleproject is configured in Travis CI to use Python 2.6 and so Flake8 now fails.

This is not an issue with this PR, it's a conflict within the tox config that says to test flake8 on Python 2.6

[gene1wood]

I've submitted PR #48 which fixes the tox config that's causing flake8 failures.

[gene1wood]

Now that #51 is merged these Tox checks should pass so I'll close and re-open this PR to trigger a rebuild.

[pfmoore]

I thought the OSI was the place to find out about licenses? I don't think we want to get involved in a "whose definition is best" debate. In particular note that the classifiers mention "OSI Approved".

I don't know enough about licensing to state what's right here, but I don't think this project is the place to try to educate people in the subject.

[dstufft]

It would honestly probably be better to just have people omit the license="" value and only just the classifiers.

[pfmoore]

Agreed. Is there a list of valid classifiers? Because if so, that's the best place to point people for "what licenses are available to choose/specify". (I don't think we should be getting into licensing discussions beyond that).

[dstufft]

Yea, but it's kind of crappy: https://pypi.python.org/pypi?%3Aaction=list_classifiers

Beyond that, linking to https://choosealicense.com/ might be a reasonable thing to do.

[pfmoore]

Beyond that, linking to https://choosealicense.com/ might be a reasonable thing to do.

That site seems like a nice simple overview. I'd be OK with that.

[gene1wood]

I thought the OSI was the place to find out about licenses?

So from my read of the examples of the use of this license argument in setuptools the intent is for the value to be the SPDX identifier of the license. I came to this conclusion through the following path

First I looked at what values are out there

• The Python Packaging Authority's Packaging and Distributing Projects document and sampleproject use an example value of MIT in their setuptools.setup arguments
• The an_example_pypi_project document uses an example value of BSD in their setuptools.setup arguments
• A statistical breakdown of all pypi license values shows top values like MIT, BSD, GPL, GPLv3 etc

I gathered that the value that should go here should be a very short description of the license, not the trove classifier value for the license as that's supposed to go in the classifiers section.

Then I tried to find out where these acronyms where coming from. I quickly found that the standardized way in which licenses are identified produces the exact short acronym versions that I was seeing. That standardized means of identifying licenses is the Software Package Data Exchange standard, built by the associated workgroup hosted by the Linux Foundation.

I further found that this mapping of trove classifier to SPDX ID was provided by the license pypi package

In summary the OSI does produce most of the licenses found in the pypi trove classifier but not all of them. More importantly, the OSI doesn't define these standardized short names or IDs for licenses (OSI and non OSI), SPDX does.

I don't think we want to get involved in a "whose definition is best" debate.

Totally agree. The SPDX is not an alternative to the OSI, it's a standard by which OSI and non-OSI licenses can be uniquely identified from a machine readable perspective.

In particular note that the classifiers mention "OSI Approved".

If you look at the trove classifiers you'll notice that the majority of licenses are indeed "OSI Approved" but not all. Of the 66 trove classifier licenses 77% are OSI Approved and 23% are not.

I don't think this project is the place to try to educate people in the subject.

My goal in adding this note is the same goal as all the other comments in the sample project, to help people (like myself) know what value is supposed to go in each field. Since this field is supposed to contain an SPDX ID it seems reasonable to point the reader to this fact, in the same way that we point the reader at the trove classifiers as well. For myself, since I'd never heard of SPDX, it was difficult to figure out how to convert the trove classifier license I intended to use into the right string that should go in the license argument.

Beyond that, linking to https://choosealicense.com/ might be a reasonable thing to do.

I totally agree we should link to choosealicense.com. It's exactly what I use when I'm building a setup.py for a project. Problem is, that site is useful for picking your license but not in determining what value is supposed to go in the license argument. If you take a look at, for example, the Apache License 2.0 page on the site it doesn't mention either the trove classifier name ("Apache Software License") or the SPDX ID ("Apache-2.0")

@pfmoore, @dstufft, would you like me to add a commit in with an additional link to choosealicense.com and if so what do you think about putting it in the line before the comment I'm proposing. This way the reader first sees choosealicense.com, picks out a license, then finds SPDX, looks up the ID for the license argument, and then sees the trove classifiers, picks out the trove classifier string for the classifiers argument. 1, 2, 3.

[pfmoore]

@gene1wood First of all, thanks for doing all that research. But in practice, the "license" field is intended to just be a free text description - maybe people tend to use these SPDX classifiers, but that's not a requirement. It seems that the field is basically either a duplicate of the classifier, or a place to put something arbitrary that doesn't have a classifier.

I'm inclined to agree with @dstufft that we omit setting license at all in the sample project, and stick with having a license classifier. The comment before the license classifier could say something like

# Pick your license as you wish (see https://choosealicense.com/ if you're unsure)

That should cover the sort of audience we're aiming at here.

[gene1wood]

Ok. Removing the field sounds fine. Or if it is a free text field, a comment indicating that its free text would be good I think since it looks like it's been interpreted by package builders as non-free-text.