From adfe72bba0cbe746ac823ded1ab62ec20dfd4643 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 6 Sep 2024 12:24:01 +0100 Subject: [PATCH 1/9] Remove heading numbering and fix internal refs Heading numbers are now generated and some existing hard-coded anchors are not updated. - Remove unused heading anchors that based on Heading numbering (` +## SPDX License List matching guidelines The SPDX License List Matching Guidelines provide guidelines to be used for the purposes of matching licenses and license exceptions against those included on the [SPDX License List](https://spdx.org/licenses/). There is no intent here to make a judgment or interpretation, but merely to ensure that when one SPDX user identifies a license as "BSD-3-Clause," for example, it is indeed the same license as what someone else identifies as "BSD-3-Clause" and the same license as what is listed on the SPDX License List. As noted here, some of the matching guidelines are implemented in the XML files of the SPDX License List repository. -## How these guidelines are applied +## How these guidelines are applied -### Purpose +### Purpose To ensure consistent results by different SPDX document creators when matching license information that will be included in the License Information in File field. SPDX document creators or tools may match on the license or exception text itself, the official license header, or the SPDX License List short identifier. -### Guideline: official license headers +### Guideline: official license headers The matching guidelines apply to license and exception text, as well as official license headers. Official license headers are defined by the SPDX License List as specific text specified within the license itself to be put in the header of files. @@ -20,27 +20,27 @@ Official license headers are defined by the SPDX License List as specific text s The following XML tag is used to implement this guideline: `` -## Substantive text +## Substantive text -### Purpose +### Purpose To ensure that when matching licenses and exceptions to the SPDX License List, there is an appropriate balance between matching against the substantive text and disregarding parts of the text that do not alter the substantive text or legal meaning. Further guidelines of what can be disregarded or considered replaceable for purposes of matching are listed below here and in the subsequent specific guidelines. A conservative approach is taken in regard to rules relating to disregarded or replaceable text. -### Guideline: verbatim text +### Guideline: verbatim text License and exception text should be the same verbatim text (except for the guidelines stated here). The text should be in the same order, e.g., differently ordered paragraphs would not be considered a match. -### Guideline: no additional text +### Guideline: no additional text Matched text should only include that found in the vetted license or exception text. Where a license or exception found includes additional text or clauses, this should not be considered a match. -### Guideline: replaceable text +### Guideline: replaceable text Some licenses include text that refers to the specific copyright holder or author, yet the rest of the license is exactly the same. The intent here is to avoid the inclusion of a specific name in one part of the license resulting in a non-match where the license is otherwise an exact match to the legally substantive terms (e.g., the third clause and disclaimer in the BSD licenses, or the third, fourth, and fifth clauses of Apache-1.1). In these cases, there should be a positive license match. The text indicated as such can be replaced with similar values (e.g., a different name or generic term; different date) and still be considered a positive match. -This rule also applies to text-matching in official license headers -(see [Guideline: official license headers](#C.2.2)). +This rule also applies to text-matching in official license headers, +see [Guideline: official license headers](#guideline-official-license-headers). The following XML tag is used to implement this guideline. `` with 2 attributes: @@ -54,7 +54,7 @@ For example: The original replaceable text appears on the SPDX License List webpage in red text. -### Guideline: omittable text +### Guideline: omittable text Some licenses have text that can simply be ignored. The intent here is to avoid the inclusion of certain text that is superfluous or irrelevant in regards to the substantive license text resulting in a non-match where the license is otherwise an exact match (e.g., directions on how to apply the license or other similar exhibits). In these cases, there should be a positive license match. @@ -67,78 +67,78 @@ For example: Omittable text appears on the SPDX License List webpage in blue text. -## Whitespace +## Whitespace -### Purpose +### Purpose To avoid the possibility of a non-match due to different spacing of words, line breaks, or paragraphs. -### Guideline +### Guideline All whitespace should be treated as a single blank space. XML files do not require specific markup to implement this guideline. -## Capitalization +## Capitalization -### Purpose +### Purpose To avoid the possibility of a non-match due to lowercase or uppercase letters in otherwise the same words. -### Guideline +### Guideline All uppercase and lowercase letters should be treated as lowercase letters. XML files do not require specific markup to implement this guideline. -## Punctuation +## Punctuation -### Purpose +### Purpose Because punctuation can change the meaning of a sentence, punctuation needs to be included in the matching process. XML files do not require specific markup to implement this guideline, unless to indicate an exception to the guideline. -### Guideline: punctuation +### Guideline: punctuation Punctuation should be matched, unless otherwise stated in these guidelines or unless specific markup is added. -### Guideline: hyphens, dashes +### Guideline: hyphens, dashes Any hyphen, dash, en dash, em dash, or other variation should be considered equivalent. -### Guideline: Quotes +### Guideline: Quotes Any variation of quotations (single, double, curly, etc.) should be considered equivalent. -## Code Comment Indicators or Separators +## Code Comment Indicators or Separators -### Purpose +### Purpose To avoid the possibility of a non-match due to the existence or absence of code comment indicators placed within the license text, e.g., at the start of each line of text, or repetitive characters to establish a separation of text, e.g., `---`, `===`, `___`, or `***`. -### Guideline +### Guideline Any kind of code comment indicator or prefix which occurs at the beginning of each line in a matchable section should be ignored for matching purposes. XML files do not require specific markup to implement this guideline. -### Guideline +### Guideline A non-letter character repeated 3 or more times to establish a visual separation should be ignored for matching purposes. XML files do not require specific markup to implement this guideline. -## Bullets and numbering +## Bullets and numbering -### Purpose +### Purpose To avoid the possibility of a non-match due to the otherwise same license using bullets instead of numbers, number instead of letter, or no bullets instead of bullet, etc., for a list of clauses. -### Guideline +### Guideline Where a line starts with a bullet, number, letter, or some form of a list item (determined where list item is followed by a space, then the text of the sentence), ignore the list item for matching purposes. @@ -146,13 +146,13 @@ The following XML tag is used to implement this guideline: `` For example: `1.0` -## Varietal word spelling +## Varietal word spelling -### Purpose +### Purpose English uses different spelling for some words. By identifying the spelling variations for words found or likely to be found in licenses, we avoid the possibility of a non-match due to the same word being spelled differently. This list is not meant to be an exhaustive list of all spelling variations, but meant to capture the words most likely to be found in open source software licenses. -### Guideline +### Guideline The words in each line of the text file available at the [equivalent words list](https://spdx.org/licenses/equivalentwords.txt) @@ -160,27 +160,27 @@ are considered equivalent and interchangeable. XML files do not require specific markup to implement this guideline. -## Copyright symbol +## Copyright symbol -### Purpose +### Purpose By having a rule regarding the use of "©", "(c)", or "copyright", we avoid the possibility of a mismatch based on these variations. -### Guideline +### Guideline "©", "(c)", or "Copyright" should be considered equivalent and interchangeable. XML files do not require specific markup to implement this guideline. The copyright symbol is part of the copyright notice, -see implementation of that guideline in [Copyright notice](#C.11). +see implementation of that guideline in [Copyright notice](#copyright-notice). -## Copyright notice +## Copyright notice -### Purpose +### Purpose To avoid a license mismatch merely because the copyright notice (usually found above the actual license or exception text) is different. The copyright notice is important information to be recorded elsewhere in the SPDX document, but for the purposes of matching a license to the SPDX License List, it should be ignored because it is not part of the substantive license text. -### Guideline +### Guideline Ignore copyright notices. A copyright notice consists of the following elements, for example: "2012 Copyright, John Doe. All rights reserved." or "(c) 2012 John Doe." @@ -188,13 +188,13 @@ The following XML tag is used to implement this guideline: `` For example: `Copyright 2022 The Linux Foundation` -## License name or title +## License name or title -### Purpose +### Purpose To avoid a license mismatch merely because the name or title of the license is different than how the license is usually referred to or different than the SPDX full name. This also avoids a mismatch if the title or name of the license is simply not included. -### Guideline +### Guideline Ignore the license name or title for matching purposes, so long as what ignored is the title only and there is no additional substantive text added here. @@ -202,34 +202,34 @@ The following XML tag is used to implement this guideline: `` For example: `Attribution Assurance License` -## Extraneous text at the end of a license +## Extraneous text at the end of a license -### Purpose +### Purpose To avoid a license mismatch merely because extraneous text that appears at the end of the terms of a license is different or missing. This also avoids a mismatch if the extraneous text merely serves as a license notice example and includes a specific copyright holder's name. -### Guideline +### Guideline Ignore any text that occurs after the obvious end of the license and does not include substantive text of the license, for example: text that occurs after a statement such as, "END OF TERMS AND CONDITIONS," or an exhibit or appendix that includes an example or instructions on to how to apply the license to your code. Do not apply this guideline or ignore text that is comprised of additional license terms (e.g., permitted additional terms under GPL-3.0, section 7). To implement this guideline, use the `` XML element tag as described -in [Guideline: omittable text](#C.3.5). +in [Guideline: omittable text](#guideline-omittable-text). -## HTTP protocol +## HTTP protocol -### Purpose +### Purpose To avoid a license mismatch due to a difference in a hyperlink protocol (e.g. HTTP vs. HTTPS). -### Guideline +### Guideline `http://` and `https://` should be considered equivalent. XML files do not require specific markup to implement this guideline. -## SPDX License List +## SPDX License List -### Template access +### Template access The license XML can be accessed in the license-list-data repository under the license-list-XML directory. Although the license list XML files can also be @@ -240,12 +240,12 @@ users are encouraged to use the published versions in the The license-list-data repository is tagged by release. Only tagged released versions of the license list are considered stable. -### License List XML format +### License List XML format A full schema for the License List XML can be found at [SPDX License List XML Schema](https://github.com/spdx/license-list-XML/blob/v3.25.0/schema/ListedLicense.xsd). -### Legacy Text Template format +### Legacy Text Template format Prior to the XML format, a text template was used to express variable and optional text in licenses. @@ -263,7 +263,7 @@ Rule fields begin with a case sensitive tag followed by an equal sign `=`. Rule fields: - **type:** indicates whether the text is replaceable or omittable as per - [Substantive text guidelines](#C.3). + [Substantive text guidelines](#substantive-text). - Indicated by `<>` or - Indicated by `<>` and `<>` respectively. - This field is the first field and is required. diff --git a/docs/annexes/rdf-model.md b/docs/annexes/rdf-model.md index d7dc6b3e9e..07d2545eab 100644 --- a/docs/annexes/rdf-model.md +++ b/docs/annexes/rdf-model.md @@ -6,7 +6,6 @@ The SPDX RDF ontology is expressed in RDF/OWL/SHACL format and is published in online at [SPDX 3.0.1 Model](https://spdx.org/rdf/3.0.1/spdx-model.ttl) - ## Diagrams ### Core and Software Profiles diff --git a/docs/annexes/spdx-license-expressions.md b/docs/annexes/spdx-license-expressions.md index 9626961706..2f2287c8f7 100644 --- a/docs/annexes/spdx-license-expressions.md +++ b/docs/annexes/spdx-license-expressions.md @@ -1,6 +1,6 @@ # SPDX license expressions (Normative) -## Overview +## Overview Often a single license can be used to represent the licensing terms of a source code or binary file, but there are situations where a single license identifier is not sufficient. A common example is when software is offered under a choice of one or more licenses (e.g., GPL-2.0-only OR BSD-3-Clause). Another example is when a set of licenses is needed to represent a binary program constructed by compiling and linking two (or more) different source files each governed by different licenses (e.g., LGPL-2.1-only AND BSD-3-Clause). @@ -48,7 +48,7 @@ There MUST NOT be white space between a license-id and any following `+`. This s In the `tag:value` format, a license expression MUST be on a single line, and MUST NOT include a line break in the middle of the expression. -## Case sensitivity +## Case sensitivity License expression operators (`AND`, `and`, `OR`, `or`, `WITH` and `with`) should be matched in a *case-sensitive* manner, i.e., letters must be all upper case or all lower case. @@ -60,7 +60,7 @@ For user defined license identifiers, only the variable part (after `LicenseRef- The same applies to `AdditionRef-` user defined identifiers. -## Simple license expressions +## Simple license expressions A simple `` is composed one of the following: @@ -80,17 +80,19 @@ DocumentRef-spdx-tool-1.2:LicenseRef-MIT-Style-2 The current set of valid license identifiers can be found in [spdx.org/licenses](https://spdx.org/licenses). -## Composite license expressions +## Composite license expressions -### Introduction +### Introduction More expressive composite license expressions can be constructed using "OR", "AND", and "WITH" operators similar to constructing mathematical expressions using arithmetic operators. For the `tag:value` format, any license expression that consists of more than one license identifier and/or LicenseRef, may optionally be encapsulated by parentheses: "( )". -Nested parentheses can also be used to specify an order of precedence which is discussed in more detail in [D.4.5](#D.4.5). +Nested parentheses can also be used to specify an order of precedence which is +discussed in more detail in +*[Order of precedence and parentheses](#order-of-precedence-and-parentheses)*. -### Disjunctive "OR" operator +### Disjunctive "OR" operator If presented with a choice between two or more licenses, use the disjunctive binary "OR" operator to construct a new license expression, where both the left and right operands are valid license expression values. @@ -114,7 +116,7 @@ LGPL-2.1-only OR MIT OR BSD-3-Clause It is allowed to use the operator in lower case form `or`. -### Conjunctive "AND" operator +### Conjunctive "AND" operator If required to simultaneously comply with two or more licenses, use the conjunctive binary "AND" operator to construct a new license expression, where both the left and right operands are a valid license expression values. @@ -138,7 +140,7 @@ LGPL-2.1-only AND MIT AND BSD-2-Clause It is allowed to use the operator in lower case form `and`. -### Additive "WITH" operator +### Additive "WITH" operator Sometimes license texts are found with additional text, which might or might not modify the original license terms. @@ -156,7 +158,7 @@ The current set of valid license exceptions identifiers can be found in [spdx.or It is allowed to use the operator in lower case form `with`. -### Order of precedence and parentheses +### Order of precedence and parentheses The order of application of the operators in an expression matters (similar to mathematical operators). The default operator order of precedence of a `` a is: @@ -187,7 +189,7 @@ MIT AND (LGPL-2.1-or-later OR BSD-3-Clause) states the OR operator should be applied before the AND operator. That is, one should first select between the LGPL-2.1-or-later or the BSD-3-Clause license before applying the MIT license. -### License expressions in RDF +### License expressions in RDF A conjunctive license can be expressed in RDF via a `` element, with an spdx:member property for each element in the conjunctive license. Two or more members are required. diff --git a/docs/annexes/spdx-lite.md b/docs/annexes/spdx-lite.md index 5e32d7326a..19740c2501 100644 --- a/docs/annexes/spdx-lite.md +++ b/docs/annexes/spdx-lite.md @@ -30,7 +30,7 @@ The lists of properties are in alphabetical order, for easy reference. ### /Core/SpdxDocument -* Mandatory +- Mandatory 1. creationInfo 1. element (may be multiple), MUST have at least one /Core/Sbom object 1. rootElement (may be multiple), SHOULD be objects of type /Core/Sbom @@ -78,8 +78,8 @@ However, there MUST be at least a “downloadLocation” or “packageUrl” pro Additionally: -1. for every /Software/Package object MUST exist exactly one /Core/Relationship object of type `concludedLicense` having that element as its `from` property and an /SimpleLicensing/AnyLicenseInfo as its `to` property. -1. for every /Software/Package object MUST exist exactly one /Core/Relationship object of type `declaredLicense` having that element as its `from` property and /SimpleLicensing/AnyLicenseInfo object as its `to` property. +1. for every /Software/Package object MUST exist exactly one /Core/Relationship object of type `hasConcludedLicense` having that element as its `from` property and an /SimpleLicensing/AnyLicenseInfo as its `to` property. +1. for every /Software/Package object MUST exist exactly one /Core/Relationship object of type `hasDeclaredLicense` having that element as its `from` property and /SimpleLicensing/AnyLicenseInfo object as its `to` property. ### /Core/Hash @@ -121,7 +121,7 @@ Additionally: - Mandatory 1. created 1. createdBy (may be multiple), SHOULD be objects of type /Core/Agent - 1. specVersion, MUST be a fixed string, “3.0.0”. + 1. specVersion, MUST be a fixed string, “3.0.1”. - Recommended 1. comment @@ -145,4 +145,3 @@ Additionally: 1. relationshipType 1. spdxId 1. to (may be multiple) - diff --git a/docs/conformance.md b/docs/conformance.md index 020499d193..c546141883 100644 --- a/docs/conformance.md +++ b/docs/conformance.md @@ -1,6 +1,6 @@ # Conformance -## Alternate notation for some conformance requirements +## Alternate notation for some conformance requirements This standard contains more than a few cardinality assertions, each of which indicates the minimum and maximum number of times a property may appear. @@ -22,7 +22,7 @@ required, and if so, how many occurrences are required; also, whether a feature is permitted, and if so, in what number. As this is the format long familiar to the SPDX community, it has been preserved in this specification. -## Introduction to Profiles +## Introduction to Profiles Profile is the term for a compliance point within the SPDX community across The Linux Foundation and OMG. The System Package Data Exchange (SPDX) specification @@ -40,7 +40,7 @@ defines the following nine compliance points, defined as “Profiles”: The Core Profile is mandatory. All others are optional. -## Core Profile compliance point +## Core Profile compliance point The Core Profile includes the definitions of classes properties and vocabularies usable by all SPDX profiles when producing or consuming SPDX @@ -58,7 +58,7 @@ This compliance point, in combination with the Software Profile compliance point, provides a baseline of functionality that facilitates interchange of the bills of materials information produced by tools supporting SPDX. -## Software Profile compliance point +## Software Profile compliance point The Software Profile includes the definitions of classes, properties and vocabularies for refering to and conveying information about software and is @@ -77,7 +77,7 @@ This compliance point, in combination with the Core Profile compliance point, provides a baseline of functionality that facilitates interchange of the bills of materials information produced by tools supporting SPDX. -## Security Profile compliance point +## Security Profile compliance point The Security Profile captures security-related information when producing or consuming SPDX content. @@ -98,7 +98,7 @@ SPDX. This compliance point facilitates interchange of the security information produced by tools supporting SPDX. -## Licensing Profile compliance point +## Licensing Profile compliance point The Licensing Profile includes capturing details relevant to software licensing and intellectual property information when producing or consuming SPDX content. @@ -123,7 +123,7 @@ expressing which licenses and copyright notices are determined by persons or automated tooling to apply to distributions of software that are produced by tools supporting SPDX. -## Dataset Profile compliance point +## Dataset Profile compliance point The Dataset Profile captures the relevant information about the datasets used in an AI system or other applications when producing or consuming SPDX content. @@ -146,7 +146,7 @@ of the SPDX. This compliance point facilitates interchange of the information about datasets produced by tools supporting SPDX. -## AI Profile compliance point +## AI Profile compliance point The AI Profile captures an inventory list of software components and dependencies associated with an AI system when producing or consuming SPDX @@ -169,7 +169,7 @@ the SPDX. This compliance point facilitates interchange of the AI model related information produced by tools supporting SPDX. -## Build Profile compliance point +## Build Profile compliance point The Build Profile captures build-related information when producing or consuming SPDX content. @@ -189,7 +189,7 @@ the SPDX. This compliance point facilitates interchange of the build information produced by tools supporting SPDX. -## Lite Profile compliance point +## Lite Profile compliance point The Lite Profile captures the minimum set of information required for license compliance in the software supply chain for producing or consuming SPDX @@ -208,7 +208,7 @@ of the SPDX. This compliance point facilitates interchange of minimal licensing information when produced by tools supporting SPDX. -## Extension Profile compliance point +## Extension Profile compliance point The Extension Profile captures extended tailored information when producing or consuming non-standard SPDX content in three ways: diff --git a/docs/serializations.md b/docs/serializations.md index 515a500c89..d86c25a256 100644 --- a/docs/serializations.md +++ b/docs/serializations.md @@ -1,6 +1,6 @@ # Model and serializations -## Overview +## Overview This specification defines the data model of the SPDX standard, describing every piece of information about systems with software components. The data @@ -11,7 +11,7 @@ way to represent and exchange information. The data may be serialized in a variety of formats for storage and transmission. -## RDF serialization +## RDF serialization Since the data model is based on RDF, any SPDX data can be serialized in any of the multiple RDF serialization formats, including but not limited to: @@ -30,7 +30,7 @@ The SPDX specification is accompanied by a that can be used to serialize SPDX in a much simpler and more human-readable JSON-LD format. -## Canonical serialization +## Canonical serialization Canonical serialization is a single, consistent, normalized, deterministic, and reproducible form. @@ -66,7 +66,7 @@ with the following additional characteristics: value. A single comma separates a value from a following name. The name/value pairs are ordered by name. -## Serialization information +## Serialization information A collection of elements may be serialized in multiple formats. From bde9795b4d2e7301fa008630390a1bc31325add3 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 6 Sep 2024 13:20:37 +0100 Subject: [PATCH 2/9] 3.0 - 3.0.1 in diagram image label Signed-off-by: Arthit Suriyawongkul --- docs/annexes/rdf-model.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/annexes/rdf-model.md b/docs/annexes/rdf-model.md index 07d2545eab..b0bee3812c 100644 --- a/docs/annexes/rdf-model.md +++ b/docs/annexes/rdf-model.md @@ -32,9 +32,9 @@ and is published in online at [![Build Profile diagram][fig_build]][fig_build] -[fig_core_software]: ../images/model-core-software.png "SPDX 3.0 Core and Software Profiles diagram" -[fig_ai]: ../images/model-ai.png "SPDX 3.0 AI Profile diagram" -[fig_build]: ../images/model-build.png "SPDX 3.0 Build Profile diagram" -[fig_dataset]: ../images/model-dataset.png "SPDX 3.0 Dataset Profile diagram" -[fig_licensing]: ../images/model-licensing.png "SPDX 3.0 Licensing Profile diagram" -[fig_security]: ../images/model-security.png "SPDX 3.0 Security Profile diagram" +[fig_core_software]: ../images/model-core-software.png "SPDX 3.0.1 Core and Software Profiles diagram" +[fig_ai]: ../images/model-ai.png "SPDX 3.0.1 AI Profile diagram" +[fig_build]: ../images/model-build.png "SPDX 3.0.1 Build Profile diagram" +[fig_dataset]: ../images/model-dataset.png "SPDX 3.0.1 Dataset Profile diagram" +[fig_licensing]: ../images/model-licensing.png "SPDX 3.0.1 Licensing Profile diagram" +[fig_security]: ../images/model-security.png "SPDX 3.0.1 Security Profile diagram" From 7ce9f600ea1e31c8e58d3b21d752535ad3a6d534 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 6 Sep 2024 14:51:27 +0100 Subject: [PATCH 3/9] Remove spdx-lite.md from changeset Signed-off-by: Arthit Suriyawongkul --- docs/annexes/spdx-lite.md | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/docs/annexes/spdx-lite.md b/docs/annexes/spdx-lite.md index 19740c2501..5e32d7326a 100644 --- a/docs/annexes/spdx-lite.md +++ b/docs/annexes/spdx-lite.md @@ -30,7 +30,7 @@ The lists of properties are in alphabetical order, for easy reference. ### /Core/SpdxDocument -- Mandatory +* Mandatory 1. creationInfo 1. element (may be multiple), MUST have at least one /Core/Sbom object 1. rootElement (may be multiple), SHOULD be objects of type /Core/Sbom @@ -78,8 +78,8 @@ However, there MUST be at least a “downloadLocation” or “packageUrl” pro Additionally: -1. for every /Software/Package object MUST exist exactly one /Core/Relationship object of type `hasConcludedLicense` having that element as its `from` property and an /SimpleLicensing/AnyLicenseInfo as its `to` property. -1. for every /Software/Package object MUST exist exactly one /Core/Relationship object of type `hasDeclaredLicense` having that element as its `from` property and /SimpleLicensing/AnyLicenseInfo object as its `to` property. +1. for every /Software/Package object MUST exist exactly one /Core/Relationship object of type `concludedLicense` having that element as its `from` property and an /SimpleLicensing/AnyLicenseInfo as its `to` property. +1. for every /Software/Package object MUST exist exactly one /Core/Relationship object of type `declaredLicense` having that element as its `from` property and /SimpleLicensing/AnyLicenseInfo object as its `to` property. ### /Core/Hash @@ -121,7 +121,7 @@ Additionally: - Mandatory 1. created 1. createdBy (may be multiple), SHOULD be objects of type /Core/Agent - 1. specVersion, MUST be a fixed string, “3.0.1”. + 1. specVersion, MUST be a fixed string, “3.0.0”. - Recommended 1. comment @@ -145,3 +145,4 @@ Additionally: 1. relationshipType 1. spdxId 1. to (may be multiple) + From bfcd93d755362988e247fe91eb259a8e7aed2446 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 6 Sep 2024 15:37:53 +0100 Subject: [PATCH 4/9] Update docs/annexes/spdx-license-expressions.md Co-authored-by: Alexios Zavras (zvr) Signed-off-by: Arthit Suriyawongkul --- docs/annexes/spdx-license-expressions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/annexes/spdx-license-expressions.md b/docs/annexes/spdx-license-expressions.md index 2f2287c8f7..5c97385345 100644 --- a/docs/annexes/spdx-license-expressions.md +++ b/docs/annexes/spdx-license-expressions.md @@ -90,7 +90,7 @@ For the `tag:value` format, any license expression that consists of more than on Nested parentheses can also be used to specify an order of precedence which is discussed in more detail in -*[Order of precedence and parentheses](#order-of-precedence-and-parentheses)*. +[Order of precedence and parentheses](#order-of-precedence-and-parentheses). ### Disjunctive "OR" operator From 0b0fd31735fe4b9bf142f17f5e749e8bc4112b57 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Mon, 9 Sep 2024 11:57:37 +0100 Subject: [PATCH 5/9] Use https://datatracker.ietf.org/doc/rfc* Signed-off-by: Arthit Suriyawongkul --- docs/annexes/pkg-url-specification.md | 4 ++-- docs/serializations.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/annexes/pkg-url-specification.md b/docs/annexes/pkg-url-specification.md index 4f9f380f65..3a9264e80c 100644 --- a/docs/annexes/pkg-url-specification.md +++ b/docs/annexes/pkg-url-specification.md @@ -41,7 +41,7 @@ Components are designed such that they form a hierarchy from the most significant on the left to the least significant components on the right. A _purl_ is a valid URL and URI that conforms to the URL definitions -and specifications in RFC 3986 . +and specifications in RFC 3986 . A _purl_ must not contain a URL Authority i.e. there is no support for username, password, host and port components. @@ -60,7 +60,7 @@ The _purl_ components are mapped to the following URL components: For clarity and simplicity a _purl_ is always an ASCII string. To ensure that there is no ambiguity when parsing a _purl_, separator characters and non-ASCII characters must be encoded in UTF-8, -and then percent-encoded as defined in RFC 3986 . +and then percent-encoded as defined in RFC 3986 . Use these rules for percent-encoding and decoding _purl_ components: diff --git a/docs/serializations.md b/docs/serializations.md index d86c25a256..839f379535 100644 --- a/docs/serializations.md +++ b/docs/serializations.md @@ -41,7 +41,7 @@ The content of the canonical serialization is exactly the same as the JSON-LD serialization of RDF data (see 4.2), just represented in a consistent way. Canonical serialization is in JSON format, as defined in -[RFC 8259 (IETF STD 90)](https://www.rfc-editor.org/info/rfc8259), +[RFC 8259 (IETF STD 90)](https://datatracker.ietf.org/doc/rfc8259/), with the following additional characteristics: - No line breaks From 07e7906fd152806d1d043c221857ca59a43c7aa1 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Mon, 9 Sep 2024 16:20:35 +0100 Subject: [PATCH 6/9] Add trailing / to RFC urls - same as canonical URLs Signed-off-by: Arthit Suriyawongkul --- docs/references.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/references.md b/docs/references.md index 4d07ecd5bf..c2845af89c 100644 --- a/docs/references.md +++ b/docs/references.md @@ -70,72 +70,72 @@ Internet Engineering Task Force, RFC 1320, *The MD4 Message-Digest Algorithm*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc1320](https://datatracker.ietf.org/doc/rfc1320). +[https://datatracker.ietf.org/doc/rfc1320](https://datatracker.ietf.org/doc/rfc1320/). RFC 1321, *The MD5 Message-Digest Algorithm*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc1321](https://datatracker.ietf.org/doc/rfc1321). +[https://datatracker.ietf.org/doc/rfc1321](https://datatracker.ietf.org/doc/rfc1321/). RFC 1950, *ZLIB Compressed Data Format Specification version 3.3*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc1950](https://datatracker.ietf.org/doc/rfc1950). +[https://datatracker.ietf.org/doc/rfc1950](https://datatracker.ietf.org/doc/rfc1950/). RFC 2046, *Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc2046](https://datatracker.ietf.org/doc/rfc2046). +[https://datatracker.ietf.org/doc/rfc2046](https://datatracker.ietf.org/doc/rfc2046/). RFC 3174, *US Secure Hash Algorithm 1 (SHA1)*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc3174](https://datatracker.ietf.org/doc/rfc3174). +[https://datatracker.ietf.org/doc/rfc3174](https://datatracker.ietf.org/doc/rfc3174/). RFC 3696, *Application Techniques for Checking and Transformation of Names*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc3696](https://datatracker.ietf.org/doc/rfc3696). +[https://datatracker.ietf.org/doc/rfc3696](https://datatracker.ietf.org/doc/rfc3696/). RFC 3874, *A 224-bit One-way Hash Function: SHA-224*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc3874](https://datatracker.ietf.org/doc/rfc3874). +[https://datatracker.ietf.org/doc/rfc3874](https://datatracker.ietf.org/doc/rfc3874/). RFC 3986, *Uniform Resource Identifier (URI): Generic Syntax*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc3986](https://datatracker.ietf.org/doc/rfc3986). +[https://datatracker.ietf.org/doc/rfc3986](https://datatracker.ietf.org/doc/rfc3986/). RFC 5234, *Augmented BNF for Syntax Specifications: ABNF*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc5234](https://datatracker.ietf.org/doc/rfc5234). +[https://datatracker.ietf.org/doc/rfc5234](https://datatracker.ietf.org/doc/rfc5234/). RFC 6234, *US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc6234](https://datatracker.ietf.org/doc/rfc6234). +[https://datatracker.ietf.org/doc/rfc6234](https://datatracker.ietf.org/doc/rfc6234/). RFC 7405, *Case-Sensitive String Support in ABNF*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc7405](https://datatracker.ietf.org/doc/rfc7405). +[https://datatracker.ietf.org/doc/rfc7405](https://datatracker.ietf.org/doc/rfc7405/). RFC 7693, *The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc7693](https://datatracker.ietf.org/doc/rfc7693). +[https://datatracker.ietf.org/doc/rfc7693](https://datatracker.ietf.org/doc/rfc7693/). RFC 8259, *The JavaScript Object Notation (JSON) Data Interchange Format*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc8259](https://datatracker.ietf.org/doc/rfc8259). +[https://datatracker.ietf.org/doc/rfc8259](https://datatracker.ietf.org/doc/rfc8259/). RFC 9393, *Concise Software Identification Tags*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc9393](https://datatracker.ietf.org/doc/rfc9393). +[https://datatracker.ietf.org/doc/rfc9393](https://datatracker.ietf.org/doc/rfc9393/). *Semantic Versioning 2.0.0*, Tom Preston-Werner and SemVer contributors, From aec2aabe6c86207cb3966fe7020328cdc846213c Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Mon, 9 Sep 2024 16:33:51 +0100 Subject: [PATCH 7/9] Add trailing / Signed-off-by: Arthit Suriyawongkul --- docs/references.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/docs/references.md b/docs/references.md index c2845af89c..891c28a347 100644 --- a/docs/references.md +++ b/docs/references.md @@ -70,72 +70,72 @@ Internet Engineering Task Force, RFC 1320, *The MD4 Message-Digest Algorithm*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc1320](https://datatracker.ietf.org/doc/rfc1320/). +[https://datatracker.ietf.org/doc/rfc1320/](https://datatracker.ietf.org/doc/rfc1320/). RFC 1321, *The MD5 Message-Digest Algorithm*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc1321](https://datatracker.ietf.org/doc/rfc1321/). +[https://datatracker.ietf.org/doc/rfc1321/](https://datatracker.ietf.org/doc/rfc1321/). RFC 1950, *ZLIB Compressed Data Format Specification version 3.3*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc1950](https://datatracker.ietf.org/doc/rfc1950/). +[https://datatracker.ietf.org/doc/rfc1950/](https://datatracker.ietf.org/doc/rfc1950/). RFC 2046, *Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc2046](https://datatracker.ietf.org/doc/rfc2046/). +[https://datatracker.ietf.org/doc/rfc2046/](https://datatracker.ietf.org/doc/rfc2046/). RFC 3174, *US Secure Hash Algorithm 1 (SHA1)*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc3174](https://datatracker.ietf.org/doc/rfc3174/). +[https://datatracker.ietf.org/doc/rfc3174/](https://datatracker.ietf.org/doc/rfc3174/). RFC 3696, *Application Techniques for Checking and Transformation of Names*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc3696](https://datatracker.ietf.org/doc/rfc3696/). +[https://datatracker.ietf.org/doc/rfc3696/](https://datatracker.ietf.org/doc/rfc3696/). RFC 3874, *A 224-bit One-way Hash Function: SHA-224*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc3874](https://datatracker.ietf.org/doc/rfc3874/). +[https://datatracker.ietf.org/doc/rfc3874/](https://datatracker.ietf.org/doc/rfc3874/). RFC 3986, *Uniform Resource Identifier (URI): Generic Syntax*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc3986](https://datatracker.ietf.org/doc/rfc3986/). +[https://datatracker.ietf.org/doc/rfc3986/](https://datatracker.ietf.org/doc/rfc3986/). RFC 5234, *Augmented BNF for Syntax Specifications: ABNF*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc5234](https://datatracker.ietf.org/doc/rfc5234/). +[https://datatracker.ietf.org/doc/rfc5234/](https://datatracker.ietf.org/doc/rfc5234/). RFC 6234, *US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc6234](https://datatracker.ietf.org/doc/rfc6234/). +[https://datatracker.ietf.org/doc/rfc6234/](https://datatracker.ietf.org/doc/rfc6234/). RFC 7405, *Case-Sensitive String Support in ABNF*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc7405](https://datatracker.ietf.org/doc/rfc7405/). +[https://datatracker.ietf.org/doc/rfc7405/](https://datatracker.ietf.org/doc/rfc7405/). RFC 7693, *The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc7693](https://datatracker.ietf.org/doc/rfc7693/). +[https://datatracker.ietf.org/doc/rfc7693/](https://datatracker.ietf.org/doc/rfc7693/). RFC 8259, *The JavaScript Object Notation (JSON) Data Interchange Format*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc8259](https://datatracker.ietf.org/doc/rfc8259/). +[https://datatracker.ietf.org/doc/rfc8259/](https://datatracker.ietf.org/doc/rfc8259/). RFC 9393, *Concise Software Identification Tags*, Internet Engineering Task Force, -[https://datatracker.ietf.org/doc/rfc9393](https://datatracker.ietf.org/doc/rfc9393/). +[https://datatracker.ietf.org/doc/rfc9393/](https://datatracker.ietf.org/doc/rfc9393/). *Semantic Versioning 2.0.0*, Tom Preston-Werner and SemVer contributors, From 604048f628eb3d7bb7521708e977508de331409e Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Tue, 10 Sep 2024 18:14:18 +0100 Subject: [PATCH 8/9] Add back SLSA SLSA reintroduced because of https://github.com/spdx/spdx-3-model/pull/875 Signed-off-by: Arthit Suriyawongkul --- docs/references.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/references.md b/docs/references.md index 891c28a347..cc1a63c0a3 100644 --- a/docs/references.md +++ b/docs/references.md @@ -141,6 +141,9 @@ Internet Engineering Task Force, Tom Preston-Werner and SemVer contributors, [https://semver.org](https://semver.org). +*SLSA Provenance v0.2*, The Linux Foundation, +[https://slsa.dev/provenance/v0.2](https://slsa.dev/provenance/v0.2). + SoftWare Heritage persistent IDentifiers (SWHIDs), in Draft International Standard *ISO/IEC DIS 18670 Information technology — SoftWare Hash IDentifier (SWHID) Specification V1.2*[https://www.iso.org/standard/89985.html](https://www.iso.org/standard/89985.html), From 7e8db9ed7b26933e37c6c7885ed53bf89e75fcfe Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Tue, 10 Sep 2024 18:17:34 +0100 Subject: [PATCH 9/9] Update SLSA link Signed-off-by: Arthit Suriyawongkul --- docs/references.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/references.md b/docs/references.md index cc1a63c0a3..da05666fd8 100644 --- a/docs/references.md +++ b/docs/references.md @@ -142,7 +142,7 @@ Tom Preston-Werner and SemVer contributors, [https://semver.org](https://semver.org). *SLSA Provenance v0.2*, The Linux Foundation, -[https://slsa.dev/provenance/v0.2](https://slsa.dev/provenance/v0.2). +[https://slsa.dev/spec/v0.2/provenance](https://slsa.dev/spec/v0.2/provenance). SoftWare Heritage persistent IDentifiers (SWHIDs), in Draft International Standard