Add remaining deprecated licenses. #552
Conversation
…es need to be updated Signed-off-by: Gary O'Neall <[email protected]>
Signed-off-by: Gary O'Neall <[email protected]>
These are now updated. |
| @@ -0,0 +1,311 @@ | |||
| <?xml version="1.0" encoding="UTF-8"?> | |||
| <SPDXLicenseCollection xmlns="http://www.spdx.org/license"> | |||
| <license isOsiApproved="true" licenseId="GPL-2.0+" isDeprecated="true" deprecatedVersion="2.0rc2" | |||
There was a problem hiding this comment.
I'd rather not use RC versions in deprecatedVersion, since those are a lower tier than non-RC versions. For example, if a license was marked as deprecated in 2.0rc2 but we changed our minds and removed the deprecation by 2.0, I'd consider the license “never deprecated”. If that argument makes sense, I think we want to use deprecatedVersion="2.0" for the licenses where you currently have 2.0rc2.
There was a problem hiding this comment.
2.0rc2 was an actual version/release. I can't remember the details of all that now, but we can rewrite history, so this needs to be left as is. :)
There was a problem hiding this comment.
2.0rc2 was an actual version/release. I can't remember the details of all that now, but we can rewrite history, so this needs to be left as is. :)
I think you meant “can't”. I'm not contesting the existence of the rc2 tag, I just think that tag was a pre-release (i.e. release candidate) and not a release. From SemVer (which we don't formally follow, but which serves as a good example of conventional use):
Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.
Are you aware of any consumers (e.g. the SPDX spec) that reference the 2.0-rc2 license list? I'd have expected consumers to wait and reference the normal 2.0 release.
The XSD suggests (buggily) that we only want a single <notes> element (more details on this in the previous commit). And the information contained in the <notes> sections I'm removing is redundant, because: * Licenses with a release date in their <notes> entry had that same release date in the license title. I don't see a need to include that release date as unstrucutured information in two places, and the license title is clearly the more important location. * Whether the license is only or or-later is covered explicitly in the long name and implicitly in the new deprecation notice (e.g. as added in 55b6fc4, Update comments to reflect the new GPL license ID's, 2017-12-23, spdx#552). Once we get explicit obsoleted-by markup [1], those deprecation notices will become machine readable. So I don't think we need to call out the versioning again in the notes. [1]: spdx#392
The XSD suggests (buggily) that we only want a single <notes> element (more details on this in the previous commit). And the information contained in the <notes> sections I'm removing is redundant, because: * Licenses with a release date in their <notes> entry had that same release date in the license title. I don't see a need to include that release date as unstrucutured information in two places, and the license title is clearly the more important location. * Whether the license is only or or-later is covered explicitly in the long name and implicitly in the new deprecation notice (e.g. as added in 55b6fc4, Update comments to reflect the new GPL license ID's, 2017-12-23, spdx#552). Once we get explicit obsoleted-by markup [1], those deprecation notices will become machine readable. So I don't think we need to call out the versioning again in the notes. [1]: spdx#392
|
With this PR merged, can someone with write access delete branch |
The XSD suggests (buggily) that we only want a single <notes> element (more details on this in the previous commit). And the information contained in the <notes> sections I'm removing is redundant, because: * Licenses with a release date in their <notes> entry had that same release date in the license title. I don't see a need to include that release date as unstrucutured information in two places, and the license title is clearly the more important location. * Whether the license is only or or-later is covered explicitly in the long name and implicitly in the new deprecation notice (e.g. as added in 55b6fc4, Update comments to reflect the new GPL license ID's, 2017-12-23, spdx#552). Once we get explicit obsoleted-by markup [1], those deprecation notices will become machine readable. So I don't think we need to call out the versioning again in the notes. [1]: spdx#392
Note: the notes for the GPL licenses need to be updated once the new GPL license ID have been added.
Resolves issue #544
Signed-off-by: Gary O'Neall [email protected]