-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add identifiers and splits #3
Conversation
Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
Signed-off-by: Gary O'Neall <gary@sourceauditor.com>
Ammended PR with identifiers up through the letter N - I'll add some more later tonight or tomorrow |
pull.py
Outdated
'Condor': {'spdx': 'Condor-1.1'}, | ||
'ECL2.0': {'spdx': 'ECL-2.0'}, | ||
'eCos11': {'spdx': 'RHeCos-1.1'}, | ||
'eCos2.0': {'spdx': 'eCos-2.0'}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This SPDX ID is deprecated in favor of GPL-2.0+ WITH eCos-exception-2.0
. I'd rather use the modern license expression.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to allow license expressions for the 'spdx' tag or restrict it to the license ID's only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to allow license expressions for the 'spdx' tag...
Yes, I think we do. If someone finds GPL-2.0+ WITH eCos-exception-2.0
content, they should be able to determine its FSF tags without going through a deprecated SPDX ID.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK - I'll add it to the amended PR - coming up soon
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed eCos2.0, but left ecos11 since RHeCos-1.1 is not marked as deprecated.
pull.py
Outdated
'ModifiedBSD': {'spdx': 'BSD-3-Clause'}, | ||
'MPL': {'spdx': 'MPL-1.1'}, | ||
'MPL-2.0': {'spdx':'MPL-2.0'}, | ||
'ms-pl': {'spdx': 'MPL-1.1'}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is FSF's Microsoft Public License (Ms-PL), which is SPDX's MS-PL. SPDX's MPL-1.1 is the Mozilla Public License 1.1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops - that must have been a typo. Good catch.
pull.py
Outdated
'NCSA': {'spdx':'NCSA'}, | ||
'newOpenLDAP': {'spdx': 'OLDAP-2.7'}, | ||
'Nokia': {'spdx': 'Nokia'}, | ||
'NoLicense': {'spdx': 'UNSPECIFIED'}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I read the FSF's NoLicense
entry as "all rights reserved". NOASSERTION
is different, and I don't see UNSPECIFIED
in the spec. I expect I think the equivalent SPDX expression is NoLicense
has no SPDX equivalent at the moment.NONE
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree - I'll amend the PR
Also, can you drop the |
…e license IDs as some of these required judgement as to the associated SPDX license ID
… into add-identifiers-go
@wking Hold off on merging the PR - I made a mistaking and I'm currently fighting git to get the fix added |
OK - Everything should be added and all review comments addressed. Please review - especially those SPDX identifiers with comments. I also added a file to track the FSF licenses which do not have associated SPDX license ID's or expressions. |
BTW - you may want to squash the commits - I added quite a few commits as part of the PR to make it easier to find specific changes during the review. |
unassociated-license-ids.md
Outdated
@@ -0,0 +1,47 @@ | |||
# The following FSF license tags did not have any obvious match to an SPDX license |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need this in version control, because you can generate it from licenses.json
with jq
. Can we remove it here? And if you like open an issue with a list of unchecked boxes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
jq
for this is:
$ jq -r 'to_entries[] | select(.value.identifiers.spdx | not) | .key' licenses.json
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll replace it with an issue since some of the items have comments that would not be retained by using jq.
pull.py
Outdated
'Zend': {'spdx': 'Zend-2.0'}, | ||
'Zimbra': {'spdx': 'Zimbra-1.3'}, | ||
'ZLib': {'spdx': 'Zlib'}, | ||
'Zope': {'spdx': 'ZPL-1.1'}, # Note the FSF refers to version 1.0 and SPDX uses version 1.1 - it should be verified that 1.1 should be included |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather leave these inexact matches off. If someone is looking up GPL-compat in this API, for example, false negatives are much less problematic than false positives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to take a more conservative approach, I would remove the SPDX ID's for Zope and Ruby. I consider SISSL to be an internal inconsistency on the FSF website and I believe they intend it to match the referenced SPDX license.
In your review comment, you included Zlib, Zimbra and Zend. I'm assuming your comment only referred to Zope - let me know that is incorrect or if there are other license matches that concern you.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In your review comment, you included Zlib, Zimbra and Zend. I'm assuming your comment only referred to Zope - let me know that is incorrect or if there are other license matches that concern you.
I'd rather have this bulk PR only cover exact matches. Can you drop anything you consider questionable and file those in per-license(-group) PRs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done - I already removed the matches I consider questionable and added them to the list of FSF license ids without an associated SPDX license ID.
pull.py
Outdated
@@ -47,6 +47,20 @@ | |||
'CC-BY-ND-3.0', | |||
'CC-BY-ND-4.0', | |||
], | |||
'CC-BY': [ # any version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any CC-BY
slug on their page. This link should not take you to any specific entry: https://www.gnu.org/licenses/license-list.html#CC-BY
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added checks in master
's pull.py
to watch out for this sort of thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just pushed a correction for this and CC-BY-SA to the pull request branch
…se matches to the spdx license list and remove the unassociated-license-ids.md file per pull request review
Amended PR to address last 2 review comments. |
'OSL-2.1', | ||
'OSL-3.0', | ||
], | ||
'RPL': [ # any version - Note that FSF website does not state any version, but references version 1.3 in the URL. It is assumed that it also covers version 1.1 and 1.5, but this should be verified with FSF. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The FSF at least occasionally says “any version” when that's their intention. Until we get clarity on this, can we drop it from this PR (and the associated RPL-*
IDENTIFIERS
entries) and come back to them in follow-up work?
], | ||
'Unicode': [ # any version | ||
'Unicode-DFS-2015', | ||
'Unicode-DFS-2016', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is another case where the FSF doesn't say “any version”. The version they link is from 2012 (based on the copyright) and differs from Unicode-DFS-2015
at least in:
the above copyright notice(s) and this permission notice appear with all copies of the Data Files or Software,
this copyright and permission notice appear with all copies of the Data Files or Software,
Until we get clarity on this, can we drop it from this PR (and the associated Unicode-DFS-*
IDENTIFIERS
entries) and come back to them in follow-up work?
], | ||
'W3C': [ # any version | ||
'W3C', | ||
'W3C-20150513', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is another case where the FSF doesn't say “any version”. The version they link is from 2002-12-31 (based on the URI) which matches our W3C
. Our W3C-19980720
, on the other hand, has “This W3C Work”, and our W3C-20150513
has “Permission to copy, modify, and distribute this work”. Until we get clarity on this, can we drop the SPLITS
entry from this PR (and all but the W3C
IDENTIFIERS
entries) and come back to them in follow-up work?
'W3C-20150513', | ||
'W3C-19980720', | ||
], | ||
'Zope2.0': [ # Versions 2.0 and later |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The FSF wording for this isn't “Versions 2.0 and later”, it's “versions 2.0 and 2.1”.
'FreeBSDDL': ['FreeBSD'], # unify (multi-tag) | ||
# FIXME: still working through this | ||
'NPL': [ #any version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The FSF wording for this isn't “any version”, it's “versions 1.0 and 1.1”.
@@ -57,8 +57,40 @@ | |||
'FDLv1.2', | |||
'FDLv1.3', | |||
], | |||
'FreeArt': [ # any version | |||
'LAL-1.2', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is another case where the FSF doesn't say “any version”. The version they link is 1.3. Until we get clarity on this, can we drop the SPLITS
entry (and the associated LAL-1.2
IDENTIFIERS
entry) and come back to them in follow-up work?
They also link the English translation, while we currently include only the canonical French version. Until we sort out translations (spdx/license-list-XML#438), we should remove the LAL-1.3
IDENTIFIERS
entry as well.
@wking I'm not going to have much time to work on this today - do you mind taking the PR and adding your recommended changes above? They all seem reasonable. |
Done (with a few more as well) in my
If that looks acceptable to you, let me know, and I'll push it and close this PR. Then we can open follow-up issues/PRs for the questionable splits and identifiers. |
I pushed 50e1556 → ef88572 to my branch fixing the |
@goneall, have you had time to look over my |
@wking Just reviewed it, looks fine to me. |
Merged and published the ef88572 reroll. |
Made some progress going through the fsf web pages and adding SPDX identifiers.
The attached file has a list of FSF ID's that do not have obvious matches in SPDX followed by a list of code snippets that need to be investigated and competed.
list.txt