Use a standard license file format #126
Conversation
|
Thank you Can you squash the commits so we can see it as a rename and get the diff, instead of being two files without any related history? Thank you :) |
|
My org is blocking the squashed commit from being pushed so there might be a few days delay while I get that worked out, but I will comment here when it's done. |
patgarz
force-pushed
the
standard-license-file
branch
from
82760d3 to
e37b70f
Compare
patgarz
force-pushed
the
standard-license-file
branch
from
e37b70f to
e174a15
Compare
|
Alright! Finally. Sorry for the delay, I think this looks good now:
|
|
This MR is reported closing #1116, which was requesting to include the license in the package - I assume the sdist. This MR changes the name and some wording in the file. Does the file changed this way get included in the sdist? |
|
Apologies for the late reply, I've been out of the country for a few weeks --- Yes, I can confirm that python setup.py sdist --formats gztar
tar -xvf dist/setproctitle-1.3.2.tar.gz -C dist
|
|
Hey @dvarrazzo , just pinging to ensure this didn't get lost. If there are any other questions pending let me know. Thanks! |
This PR adds a file named
LICENSE, which is the standard format that both GitHub and many code scanners use to autodetect and categorize licenses in projects. The addedLICENSEfile uses the autogenerated GitHub format for the BSD 3-Clause license, which is differs in mostly semantics from the currentCOPYRIGHTfile. The one significant change is the third clause now restricts endorsements that use the copyright holder or contributors, rather than just the copyright holder, which I believe is the intended language anyways.The benefits of using a standard license in the expected format can be seen in this example repository, where the license name is listed in the sidebar and also in detail when clicked. It will also allow the package to show up with the proper license in enterprise code scan tools, which increases the likelihood it will be used by enterprise programmers.
Possible variations on this PR:
COPYRIGHTfile to match the proposedLICENSEfile (two duplicate files, new text)LICENSEfile, but have it match the currentCOPYRIGHTfile (two duplicate files, current text)COPYRIGHTfile as a separate, slightly different file (two files, different text)Let me know if you'd prefer any of the above over the current proposition. I recommend this state (remove
COPYRIGHT, addLICENSEin standard format) as it matches GitHub recommendations with all the benefits of auto-license-categorization and does not cause confusion or later errors in future copyright updates by having two separate files indicating the same information. However, I can understand wanting to keep backwards compatibility, so my second recommendation would be variation 1, where we updateCOPYRIGHTto have the new text as well.closes #116