-
Notifications
You must be signed in to change notification settings - Fork 593
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
Deprecated SPDX license (GPL-2.0+) #950
Comments
This was only an example of deprecated license. "GPL-1.0+" should be replaced by "GPL-1.0-or-later" "LGPL-2.0+" should be replaced by "LGPL-2.0-or-later" "AGPL-1.0+" should be replaced by "AGPL-1.0-or-later" "GPL-1.0" should be replaced by "GPL-1.0-only" "LGPL-2.0" should be replaced by "LGPL-2.0-only" "AGPL-1.0" should be replaced by "AGPL-1.0-only" |
The complete list of deprecated licenses can be found at the bottom of the SPDX licenses list page: |
I'm wondering if these replacements can be calculated automatically without us maintaining our own list of replacements. 🤔 (cc: @jonasagx) From reading through https://spdx.org/licenses/, it really does seem like when this happens, the only fields in the license object that change are a) the ID, and b) fields derived from the ID. In fact, this page even describes these as "license ID deprecations", specifically. Looking at GPL v3.0 for example, here's the deprecated license object: {
"reference": "https://spdx.org/licenses/GPL-3.0.html",
"isDeprecatedLicenseId": true,
"detailsUrl": "https://spdx.org/licenses/GPL-3.0.json",
"referenceNumber": 110,
"name": "GNU General Public License v3.0 only",
"licenseId": "GPL-3.0",
"seeAlso": [
"https://www.gnu.org/licenses/gpl-3.0-standalone.html",
"https://opensource.org/licenses/GPL-3.0"
],
"isOsiApproved": true,
"isFsfLibre": true
} ... and here's the updated license: {
"reference": "https://spdx.org/licenses/GPL-3.0-only.html",
"isDeprecatedLicenseId": false,
"detailsUrl": "https://spdx.org/licenses/GPL-3.0-only.json",
"referenceNumber": 27,
"name": "GNU General Public License v3.0 only", // <-- same value
"licenseId": "GPL-3.0-only",
"seeAlso": [
"https://www.gnu.org/licenses/gpl-3.0-standalone.html", // <-- same value
"https://opensource.org/licenses/GPL-3.0" // <-- same value
],
"isOsiApproved": true, // <-- same value
"isFsfLibre": true // <-- same value
} Could it make sense to find a deprecated license's corresponding updated license via a match on one or all of these "same value" fields? Normally I'd try to stay away from using non "ID" fields when finding matches, but this seems like a unique case where we cannot rely on ID fields (by definition), yet the supplier of the data is committing to not changing the other fields' values. |
I have hacked the code as follows, but I do not know if it is the right way to do it:
|
I appreciate the extra info and descriptions @vargenau. I see a couple different heuristics on how to re-map deprecated license:
Do 1 & 2 only apply to L/GPL licenses?
Dan's strategy is general (it covers case 1 & 2), works better long term, and for other licenses, but it requires more refactoring of the code generation part. So I am moving on with it. |
Any progress on fixing the issue? |
What happened:
The PackageLicenseConcluded and PackageLicenseDeclaredfor contain a deprecated license "GPL-2.0+".
What you expected to happen:
"GPL-2.0+" should be replaced by "GPL-2.0-or-later"
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:
syft version
:cat /etc/os-release
or similar):The text was updated successfully, but these errors were encountered: