From 9770cbc52c8ef143b8bb6d12f8aaad8a1058fa1d Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 17 Oct 2025 02:14:56 +0800 Subject: [PATCH 01/16] Use ISO shall: license-matching-guidelines-and-templates Signed-off-by: Arthit Suriyawongkul --- ...cense-matching-guidelines-and-templates.md | 34 ++++++++++--------- 1 file changed, 18 insertions(+), 16 deletions(-) diff --git a/docs/annexes/license-matching-guidelines-and-templates.md b/docs/annexes/license-matching-guidelines-and-templates.md index 8ef8425f17..170106ca86 100644 --- a/docs/annexes/license-matching-guidelines-and-templates.md +++ b/docs/annexes/license-matching-guidelines-and-templates.md @@ -3,7 +3,9 @@ ## 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 @@ -31,15 +33,15 @@ To ensure that when matching licenses and exceptions to the SPDX License List, t ### 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. +License and exception text shall be the same verbatim text (except for the guidelines stated here). The text shall be in the same order, e.g., differently ordered paragraphs shall not be considered a match. ### 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. +Matched text shall only include that found in the vetted license or exception text. Where a license or exception found includes additional text or clauses, this shall not be considered a match. ### 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. +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 shall 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, @@ -59,9 +61,9 @@ The original replaceable text appears on the SPDX License List webpage in red te ### 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 regard 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. +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 regard 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 shall be a positive license match. -The license should be considered a match if the text indicated is present and matches OR the text indicated is missing altogether. +The license shall be considered a match if the text indicated is present and matches, or the text indicated is missing altogether. The following XML tag is used to implement this guideline: `` @@ -78,7 +80,7 @@ To avoid the possibility of a non-match due to different spacing of words, line ### Guideline -All whitespace should be treated as a single blank space. +All whitespace shall be treated as a single blank space. XML files do not require specific markup to implement this guideline. @@ -90,7 +92,7 @@ To avoid the possibility of a non-match due to lowercase or uppercase letters in ### Guideline -All uppercase and lowercase letters should be treated as lowercase letters. +All uppercase and lowercase letters shall be treated as lowercase letters. XML files do not require specific markup to implement this guideline. @@ -104,15 +106,15 @@ XML files do not require specific markup to implement this guideline, unless to ### Guideline: punctuation -Punctuation should be matched, unless otherwise stated in these guidelines or unless specific markup is added. +Punctuation shall be matched, unless otherwise stated in these guidelines or unless specific markup is added. ### Guideline: hyphens, dashes -Any hyphen, dash, en dash, em dash, or other variation should be considered equivalent. +Any hyphen, dash, en dash, em dash, or other variation shall be considered equivalent. ### Guideline: quotes -Any variation of quotations (single, double, curly, etc.) should be considered equivalent. +Any variation of quotations (single, double, curly, etc.) shall be considered equivalent. ## Code comment indicators or separators @@ -125,13 +127,13 @@ e.g., `---`, `===`, `___`, or `***`. ### 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. +Any kind of code comment indicator or prefix which occurs at the beginning of each line in a matchable section shall be ignored for matching purposes. XML files do not require specific markup to implement this guideline. ### Guideline -A non-letter character repeated 3 or more times to establish a visual separation should be ignored for matching purposes. +A non-letter character repeated 3 or more times to establish a visual separation shall be ignored for matching purposes. XML files do not require specific markup to implement this guideline. @@ -171,7 +173,7 @@ By having a rule regarding the use of "©", "(c)", or "copyright", we avoid the ### Guideline -"©", "(c)", or "Copyright" should be considered equivalent and interchangeable. +"©", "(c)", or "Copyright" shall 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, @@ -181,7 +183,7 @@ see implementation of that guideline in [Copyright notice](#copyright-notice). ### 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. +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 shall be ignored because it is not part of the substantive license text. ### Guideline @@ -226,7 +228,7 @@ To avoid a license mismatch due to a difference in a hyperlink protocol (e.g. HT ### Guideline -`http://` and `https://` should be considered equivalent. +`http://` and `https://` shall be considered equivalent. XML files do not require specific markup to implement this guideline. @@ -260,7 +262,7 @@ A legacy template is composed of text with zero or more rules embedded in it. A rule is a variable section of a license wrapped between double angle brackets `<<>>` and is composed of 4 fields. Each field is separated with a semi-colon `;`. -Rules cannot be embedded within other rules. +Rules shall not be embedded within other rules. Rule fields begin with a case sensitive tag followed by an equal sign `=`. Rule fields: From 2f515c79b039e13cc112030dd5265bdfcb18ddf7 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 17 Oct 2025 02:22:21 +0800 Subject: [PATCH 02/16] Use ISO shall: serializations Signed-off-by: Arthit Suriyawongkul --- docs/serializations.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/serializations.md b/docs/serializations.md index 484109ef11..82da3c8f11 100644 --- a/docs/serializations.md +++ b/docs/serializations.md @@ -45,23 +45,23 @@ Canonical serialization is in JSON format, as defined in with the following additional characteristics: - No line breaks -- Key names MUST be wrapped in double quotes +- Key names shall be wrapped in double quotes - No whitespace outside of strings -- `true`, `false` and `null`: the literal names must be lowercase; no other +- `true`, `false` and `null`: the literal names shall be lowercase; no other literal names are allowed - Integers: represented in base 10 using decimal digits. This designates an integer component that may be prefixed with an optional minus sign. Leading zeros are not allowed. - Strings: UTF-8 representation without specific normalization. A string begins and ends with quotation marks (%x22). Any Unicode characters may be - placed within the quotation marks, except for the two characters that MUST be + placed within the quotation marks, except for the two characters that shall be escaped by a reverse solidus: quotation mark, reverse solidus, and the control characters (U+0000 through U+001F). - Arrays: An array structure is represented as square brackets surrounding zero or more items. Items are separated by commas. - Objects: An object structure is represented as a pair of curly brackets surrounding zero or more name/value pairs (or members). A name is a string - containing only ASCII characters (0x21-0x7F). The names within an object must + containing only ASCII characters (0x21-0x7F). The names within an object shall be unique. A single colon comes after each name, separating the name from the value. A single comma separates a value from a following name. The name/value pairs are ordered by name. @@ -85,9 +85,9 @@ that can be natively represented within the chosen serialization format these native mechanisms. All remaining properties shall be serialized within the SpdxDocument element itself. -A serialization must not contain more than one SpdxDocument. +A serialization shall not contain more than one SpdxDocument. -A given instance of serialization must not define more than one SpdxDocument +A given instance of serialization shall not define more than one SpdxDocument element. ## Serialization in SPDX 3 JSON @@ -102,13 +102,13 @@ It may be parsed – not serialized – using standard JSON-LD libraries. JSON-LD contexts allow JSON documents to use simple, human-readable, locally defined terms while ensuring data interoperability across different systems. -The SPDX global JSON-LD context file must be used universally for all SPDX +The SPDX global JSON-LD context file shall be used universally for all SPDX documents in JSON-LD format that adhere to a specific SPDX version. SPDX global JSON-LD context file is available at: -All SPDX documents in JSON-LD format must include a reference to the SPDX +All SPDX documents in JSON-LD format shall include a reference to the SPDX global context file at the top level. This reference is achieved using the following JSON construct: @@ -130,11 +130,11 @@ the context. An SPDX serialization in JSON-LD format is considered conformant to the SPDX specification if it adheres to the following two validation criteria: -- Structural validation: The JSON-LD document must structurally validate +- Structural validation: The JSON-LD document shall structurally validate against the SPDX 3 JSON Schema. This schema defines the expected structure of the JSON-LD document, including the required elements, data types, and permissible values. -- Semantic validation: The JSON-LD document must successfully validate against +- Semantic validation: The JSON-LD document shall successfully validate against the SPDX 3 OWL ontology. This ontology defines the expected relationships and constraints between SPDX elements. The SPDX 3 OWL ontology also incorporates SHACL shape restrictions to further specify these constraints. From e68cf2f52122c4d3d54169dbfcda23d56de02770 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 17 Oct 2025 02:11:09 +0800 Subject: [PATCH 03/16] Use ISO shall: pkg-url-specification Signed-off-by: Arthit Suriyawongkul --- docs/annexes/pkg-url-specification.md | 78 ++++++++++++++------------- 1 file changed, 40 insertions(+), 38 deletions(-) diff --git a/docs/annexes/pkg-url-specification.md b/docs/annexes/pkg-url-specification.md index 548e5f8c3f..415e297ca9 100644 --- a/docs/annexes/pkg-url-specification.md +++ b/docs/annexes/pkg-url-specification.md @@ -43,7 +43,7 @@ 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 . -A _purl_ must not contain a URL Authority i.e. there is no +A _purl_ shall not contain a URL Authority i.e. there is no support for username, password, host and port components. A `namespace` segment may sometimes look like a host but its interpretation is specific to a type. @@ -59,24 +59,24 @@ 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, +separator characters and non-ASCII characters shall be encoded in UTF-8, and then percent-encoded as defined in RFC 3986 . Use these rules for percent-encoding and decoding _purl_ components: -- the type must NOT be encoded and must NOT contain separators -- the `#`, `?`, `@` and `:` characters must NOT be encoded when used as separators. They may need to be encoded elsewhere -- the `:` scheme and type separator does not need to and must NOT be encoded. It is unambiguous unencoded everywhere -- the `/` used as type/namespace/name and subpath segments separator does not need to and must NOT be percent-encoded. It is unambiguous unencoded everywhere -- the `@` version separator must be encoded as `%40` elsewhere -- the `?` qualifiers separator must be encoded as `%3F` elsewhere -- the `=` qualifiers key/value separator must NOT be encoded -- the `#` subpath separator must be encoded as `%23` elsewhere -- All non-ASCII characters must be encoded as UTF-8 and then percent-encoded +- the type shall not be encoded and shall not contain separators +- the `#`, `?`, `@` and `:` characters shall not be encoded when used as separators. They may need to be encoded elsewhere +- the `:` scheme and type separator does not need to and shall not be encoded. It is unambiguous unencoded everywhere +- the `/` used as type/namespace/name and subpath segments separator does not need to and shall not be percent-encoded. It is unambiguous unencoded everywhere +- the `@` version separator shall be encoded as `%40` elsewhere +- the `?` qualifiers separator shall be encoded as `%3F` elsewhere +- the `=` qualifiers key/value separator shall not be encoded +- the `#` subpath separator shall be encoded as `%23` elsewhere +- All non-ASCII characters shall be encoded as UTF-8 and then percent-encoded It is OK to percent-encode any _purl_ components, except for the type. Producers and consumers of _purl_ data -must always percent-decode and percent-encode +shall always percent-decode and percent-encode components and component segments as explained in the "How to produce and consume _purl_ data" section. @@ -85,7 +85,7 @@ as explained in the "How to produce and consume _purl_ data" section. A _purl_ string is an ASCII URL string composed of seven components. Some components are allowed to use other characters beyond ASCII: these -components must then be UTF-8-encoded strings and percent-encoded as +components shall then be UTF-8-encoded strings and percent-encoded as defined in the "Character encoding" section. The rules for each component are: @@ -93,39 +93,41 @@ The rules for each component are: ### Rules for scheme - The scheme is a constant with the value "`pkg`" -- Since a _purl_ never contains a URL Authority, its scheme must not be suffixed with double slash as in `pkg://` and should use instead `pkg:`. -- _purl_ parsers must accept URLs such as 'pkg://' and must ignore the '//'. -- _purl_ builders must not create invalid URLs with such double slash '//'. +- Since a _purl_ never contains a URL Authority, its scheme shall not be suffixed with double slash as in `pkg://` and shall use instead `pkg:`. +- _purl_ parsers shall accept URLs such as 'pkg://' and shall ignore the '//'. +- _purl_ builders shall not create invalid URLs with such double slash '//'. - The scheme is followed by a ':' separator. -- For example, the two purls `pkg:gem/ruby-advisory-db-check@0.12.4` and `pkg://gem/ruby-advisory-db-check@0.12.4` are strictly equivalent. The first is in canonical form while the second is an acceptable _purl_ but is an invalid URI/URL per RFC3986. + +For example, the two purls `pkg:gem/ruby-advisory-db-check@0.12.4` and `pkg://gem/ruby-advisory-db-check@0.12.4` are strictly equivalent. +The first is in canonical form while the second is an acceptable _purl_ but is an invalid URI/URL per RFC 3986. ### Rules for type - The package type is composed only of ASCII letters and numbers, `.`, `+` and `-` (period, plus, and dash). -- The type cannot start with a number. -- The type cannot contain spaces. -- The type must not be percent-encoded. +- The type shall not start with a number. +- The type shall not contain spaces. +- The type shall not be percent-encoded. - The type is case insensitive, with the canonical form being lowercase. ### Rules for namespace - The optional namespace contains zero or more segments, separated by slash `/`. -- Leading and trailing slashes `/` are not significant and should be stripped in the canonical form. They are not part of the namespace. -- Each namespace segment must be a percent-encoded string. -- When percent-decoded, a segment must not contain a slash `/` and must not be empty. -- A URL host or Authority must NOT be used as a namespace. Use instead a `repository_url` qualifier. Note however that for some types, the namespace may look like a host. +- Leading and trailing slashes `/` are not significant and shall be stripped in the canonical form. They are not part of the namespace. +- Each namespace segment shall be a percent-encoded string. +- When percent-decoded, a segment shall not contain a slash `/` and shall not be empty. +- A URL host or Authority shall not be used as a namespace. Use instead a `repository_url` qualifier. Note however that for some types, the namespace may look like a host. ### Rules for name - The name is prefixed by a slash `/` separator when the namespace is not empty. - This slash `/` is not part of the name. -- A name must be a percent-encoded string. +- A name shall be a percent-encoded string. ### Rules for version - The version is prefixed by a at-sign `@` separator when not empty. - This at-sign `@` is not part of the version. -- A version must be a percent-encoded string. +- A version shall be a percent-encoded string. - A version is a plain and opaque string. Some package types use versioning conventions such as SemVer for NPMs or NEVRA conventions for RPMS. A type may define a procedure to compare and sort versions, but there is no reliable and uniform way to do such comparison consistently. ### Rules for qualifiers @@ -134,14 +136,14 @@ The rules for each component are: - This `?` is not part of the qualifiers. - This is a string composed of zero or more key=value pairs each separated by an ampersand `&`. A key and value are separated by an equal `=` character. - These `&` are not part of the key=value pairs. -- Each key must be unique within the keys of the qualifiers string. -- A value cannot be an empty string; a key=value pair with an empty value is the same as no key/value at all for this key. -- Each key must be composed only of ASCII letters and numbers, `.`, `-` and `\_` (period, dash and underscore). -- A key cannot start with a number. -- A key must NOT be percent-encoded. +- Each key shall be unique within the keys of the qualifiers string. +- A value shall not be an empty string; a key=value pair with an empty value is the same as no key/value at all for this key. +- Each key shall be composed only of ASCII letters and numbers, `.`, `-` and `\_` (period, dash and underscore). +- A key shall not start with a number. +- A key shall not be percent-encoded. - A key is case insensitive, with the canonical form being lowercase. -- A key cannot contain spaces. -- A value must be a percent-encoded string. +- A key shall not contain spaces. +- A value shall be a percent-encoded string. - The `=` separator is neither part of the key nor of the value. ### Rules for subpath @@ -149,10 +151,10 @@ The rules for each component are: - The subpath string is prefixed by a `#` separator when not empty. - This `#` is not part of the subpath. - The subpath contains zero or more segments, separated by slash `/`. -- Leading and trailing slashes `/` are not significant and should be stripped in the canonical form. -- Each subpath segment must be a percent-encoded string. -- When percent-decoded, a segment must not contain a `/`, must not be any of `..` or `.`, and must not be empty. -- The subpath must be interpreted as relative to the root of the package. +- Leading and trailing slashes `/` are not significant and shall be stripped in the canonical form. +- Each subpath segment shall be a percent-encoded string. +- When percent-decoded, a segment shall not contain a `/`, shall not be any of `..` or `.`, and shall not be empty. +- The subpath shall be interpreted as relative to the root of the package. ## Known types @@ -306,7 +308,7 @@ To parse a _purl_ string in its components: 1. This list of keys/values is the qualifiers. 1. Split the remainder once from left on `:`; the right side is the remainder. -1. The left side lowercased is the scheme. It should be exactly "`pkg:`". +1. The left side lowercased is the scheme. It shall be exactly "`pkg:`". 1. Strip the remainder from leading and trailing `/`. 1. Split this once from left on `/`; the right side is the remainder. 1. The left side lowercased is the type. From 0fa12356657d1e031f9b91c9ff8267df9ed171f2 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 17 Oct 2025 02:33:36 +0800 Subject: [PATCH 04/16] ISO edit: Lowercasing: Profile --> profile Signed-off-by: Arthit Suriyawongkul --- docs/annexes/rdf-model.md | 48 +++++++++--------- docs/conformance.md | 104 +++++++++++++++++++------------------- 2 files changed, 76 insertions(+), 76 deletions(-) diff --git a/docs/annexes/rdf-model.md b/docs/annexes/rdf-model.md index b538b0c033..b8cebbf05d 100644 --- a/docs/annexes/rdf-model.md +++ b/docs/annexes/rdf-model.md @@ -8,43 +8,43 @@ and is published in online at ## Diagrams -### Core Profile +### Core profile -[![Core Profile diagram][fig_core]][fig_core] +[![Core profile diagram][fig_core]][fig_core] -### Software Profile +### Software profile -[![Software Profile diagram][fig_software]][fig_software] +[![Software profile diagram][fig_software]][fig_software] -### Security Profile +### Security profile -[![Security Profile diagram][fig_security]][fig_security] +[![Security profile diagram][fig_security]][fig_security] -### Licensing Profile +### Licensing profile -[![Licensing Profile diagram][fig_licensing]][fig_licensing] +[![Licensing profile diagram][fig_licensing]][fig_licensing] -### Dataset Profile +### Dataset profile -[![Dataset Profile diagram][fig_dataset]][fig_dataset] +[![Dataset profile diagram][fig_dataset]][fig_dataset] -### AI Profile +### AI profile -[![AI Profile diagram][fig_ai]][fig_ai] +[![AI profile diagram][fig_ai]][fig_ai] -### Build Profile +### Build profile -[![Build Profile diagram][fig_build]][fig_build] +[![Build profile diagram][fig_build]][fig_build] -### Extension Profile +### Extension profile -[![Extension Profile diagram][fig_extension]][fig_extension] +[![Extension profile diagram][fig_extension]][fig_extension] -[fig_ai]: ../images/model-AI.png "SPDX 3.1 AI Profile diagram" -[fig_build]: ../images/model-Build.png "SPDX 3.1 Build Profile diagram" -[fig_core]: ../images/model-Core.png "SPDX 3.1 Core Profile diagram" -[fig_dataset]: ../images/model-Dataset.png "SPDX 3.1 Dataset Profile diagram" -[fig_extension]: ../images/model-Extension.png "SPDX 3.1 Extension Profile diagram" -[fig_licensing]: ../images/model-Licensing.png "SPDX 3.1 Licensing Profile diagram" -[fig_security]: ../images/model-Security.png "SPDX 3.1 Security Profile diagram" -[fig_software]: ../images/model-Software.png "SPDX 3.1 Software Profile diagram" +[fig_ai]: ../images/model-AI.png "SPDX 3.1 AI profile diagram" +[fig_build]: ../images/model-Build.png "SPDX 3.1 Build profile diagram" +[fig_core]: ../images/model-Core.png "SPDX 3.1 Core profile diagram" +[fig_dataset]: ../images/model-Dataset.png "SPDX 3.1 Dataset profile diagram" +[fig_extension]: ../images/model-Extension.png "SPDX 3.1 Extension profile diagram" +[fig_licensing]: ../images/model-Licensing.png "SPDX 3.1 Licensing profile diagram" +[fig_security]: ../images/model-Security.png "SPDX 3.1 Security profile diagram" +[fig_software]: ../images/model-Software.png "SPDX 3.1 Software profile diagram" diff --git a/docs/conformance.md b/docs/conformance.md index 0f5940cbc4..fa94877808 100644 --- a/docs/conformance.md +++ b/docs/conformance.md @@ -22,64 +22,64 @@ 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 document. -## 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 -defines the following nine compliance points, defined as “Profiles”: +defines the following nine compliance points, defined as “profiles”: -- Core Profile -- Software Profile -- Security Profile -- Licensing Profile -- Dataset Profile -- AI Profile -- Build Profile -- Lite Profile -- Extension Profile +- Core profile +- Software profile +- Security profile +- Licensing profile +- Dataset profile +- AI profile +- Build profile +- Lite profile +- Extension profile -The Core Profile is mandatory. All others are optional. +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 +The Core profile includes the definitions of classes properties and vocabularies usable by all SPDX profiles when producing or consuming SPDX content. Although the classes, properties and vocabularies are somewhat extensive, the required fields are rather minimal to allow maximum flexibility while meeting minimum SBOM requirements. Software that conforms to the SPDX -specification at the Core Profile compliance point shall be able to import and +specification at the Core profile compliance point shall be able to import and export serialized documents that conform with one of the defined SPDX serialization formats. -Conformance to the Core Profile compliance point is mandatory for all other +Conformance to the Core profile compliance point is mandatory for all other SPDX profiles. -This compliance point, in combination with the Software Profile compliance +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 +The Software profile includes the definitions of classes, properties and vocabularies for referring to and conveying information about software and is usable by all SPDX profiles when producing or consuming SPDX content. -Software that conforms to the SPDX specification at the Software Profile +Software that conforms to the SPDX specification at the Software profile compliance point shall be able to import and export serialized documents that conform with one of the SPDX serialization formats defined SPDX serialization formats. -Conformance to the Software Profile compliance point does not entail support +Conformance to the Software profile compliance point does not entail support for the Licensing, Dataset, AI, Build, Lite, or Extension profiles of the SPDX. -This compliance point, in combination with the Core Profile compliance point, +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 +The Security profile captures security-related information when producing or consuming SPDX content. Software that conforms to the SPDX specification at the security profile @@ -91,16 +91,16 @@ vulnerabilities that may exist, the severity of those vulnerabilities, and a mechanism to express how a vulnerability may affect a specific software element including if a fix is available. -Conformance to the Security Profile compliance point does not entail support +Conformance to the Security profile compliance point does not entail support for the Licensing, Dataset, AI, Build, Lite, or Extension profiles of the 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 +The Licensing profile includes capturing details relevant to software licensing and intellectual property information when producing or consuming SPDX content. Specifically, software that conforms to the SPDX specification at the Licensing profile compliance point shall be able to import and export serialized @@ -109,12 +109,12 @@ serialization formats, including the classes and fields that comprise the SPDX License Expression syntax and that relate to the [SPDX License List](https://spdx.org/licenses/). -There are two associated profiles, the SimpleLicensing Profile +There are two associated profiles, the SimpleLicensing profile and the ExpandedLicensing profiles. Both allow expression of the same information, albeit in different ways. -Conformance to the Licensing Profile compliance point does not entail support +Conformance to the Licensing profile compliance point does not entail support for the Software, Security, Dataset, AI, Build, Lite, or Extension profiles of the SPDX. @@ -123,36 +123,36 @@ 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 +The Dataset profile captures the relevant information about the datasets used in an AI system or other applications when producing or consuming SPDX content. -Software that conforms to the SPDX specification at the Dataset Profile +Software that conforms to the SPDX specification at the Dataset profile compliance point shall be able to import and export serialized documents that conform with one of the SPDX serialization formats defined SPDX serialization formats, including details such as dataset names, versions, sources, associated metadata, licensing information, and any other relevant attributes. -The Dataset Profile can covey a description or summary of a dataset, including +The Dataset profile can covey a description or summary of a dataset, including metadata, characteristics, and statistical information about the data. -The Dataset Profile can convey insights into the structure, format, content, +The Dataset profile can convey insights into the structure, format, content, and properties of a dataset, helping users understand and analyze the data more effectively. -Conformance to the Dataset Profile compliance point does not entail support +Conformance to the Dataset profile compliance point does not entail support for the Software, Licensing, Security, AI, Build, Lite, or Extension profiles 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 +The AI profile captures an inventory list of software components and dependencies associated with an AI system when producing or consuming SPDX content. -Software that conforms to the SPDX specification at the AI Profile compliance +Software that conforms to the SPDX specification at the AI profile compliance point shall be able to import and export serialized documents that conform with one of the SPDX serialization formats defined SPDX serialization formats, including the information about software components and dependencies associated @@ -162,19 +162,19 @@ components used to build or deploy the AI system, along with relevant information about their versions, licenses, and useful security references including ethical and security information. -Conformance to the AI Profile compliance point does not entail support for the +Conformance to the AI profile compliance point does not entail support for the Software, Licensing, Security, Dataset, Build, Lite, or Extension profiles of 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 +The Build profile captures build-related information when producing or consuming SPDX content. -Software that conforms to the SPDX specification at the Build Profile +Software that conforms to the SPDX specification at the Build profile compliance point shall be able to import and export serialized documents that conform with one of the SPDX serialization formats defined SPDX serialization formats, including associated definitions to help express how software is @@ -182,38 +182,38 @@ generated and transformed. This includes encoding the inputs, outputs, procedures/instructions, environments and actors from the build process along with the associated evidence. -Conformance to the Build Profile compliance point does not entail support for +Conformance to the Build profile compliance point does not entail support for the Software, Licensing, Security, Dataset, AI, Lite, or Extension profiles of 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 +The Lite profile captures the minimum set of information required for license compliance in the software supply chain for producing or consuming SPDX content. -Software that conforms to the SPDX specification at the Lite Profile +Software that conforms to the SPDX specification at the Lite profile compliance point shall be able to import and export serialized documents that conform with one of the SPDX serialization formats defined SPDX serialization formats, including creation of the SBOM, package lists with licensing and other related items, and their relationships. -Conformance to the Lite Profile compliance point does not entail support for +Conformance to the Lite profile compliance point does not entail support for the Software, Licensing, Security, Dataset, AI, Build, or Extension profiles 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 +The Extension profile captures extended tailored information when producing or consuming non-standard SPDX content in three ways: -- Support Profile-based extended characterization of Elements. Enables +- Support profile-based extended characterization of Elements. Enables specification and expression of Element characterization extensions within any profile and namespace of SPDX without requiring changes to other profiles or namespaces and without requiring local subclassing of remote classes @@ -236,13 +236,13 @@ consuming non-standard SPDX content in three ways: definition of gap solution that can be used as submission for revision to the SPDX standard. -Software that conforms to the SPDX specification at the Extension Profile +Software that conforms to the SPDX specification at the Extension profile compliance point shall be able to import and export serialized documents that conform with one of the SPDX serialization formats defined SPDX serialization formats, including the abstract Extension class serving as the base for all defined Extension subclasses. -Conformance to the Extension Profile compliance point does not entail support +Conformance to the Extension profile compliance point does not entail support for the Licensing, Security, Dataset, AI, Build, or profiles of the SPDX but is expected to be used in combination with the other profiles to extend them. From 4189d9d3ae586158c5ac82570129ca5af2e3bb85 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 17 Oct 2025 02:40:56 +0800 Subject: [PATCH 05/16] Update version (3.1) and year (2025) in copyright notice Signed-off-by: Arthit Suriyawongkul --- docs/conformance.md | 8 ++++---- docs/front/copyright.md | 2 +- submissions/ISO/front/iso-foreword.md | 2 +- submissions/OMG/front/cover.md | 4 +--- submissions/OMG/front/second-page.md | 5 ++--- 5 files changed, 9 insertions(+), 12 deletions(-) diff --git a/docs/conformance.md b/docs/conformance.md index fa94877808..4f6a3eaab6 100644 --- a/docs/conformance.md +++ b/docs/conformance.md @@ -257,17 +257,17 @@ To be designated an SPDX document, a file shall comply with the requirements of License, as stated in the [SPDX Trademark Page](https://spdx.dev/trademark). The official copyright notice that shall be used with any verbatim reproduction and/or distribution of -this SPDX Specification 3.0.1 is: +this SPDX Specification 3.1 is: -"Official SPDX® Specification 3.0.1 Copyright © 2010--2024 Linux Foundation and its Contributors. +"Official SPDX® Specification 3.1 Copyright © 2010--2025 Linux Foundation and its Contributors. Licensed under the Community Specification License 1.0. All other rights are expressly reserved." The official copyright notice that shall be used with any non-verbatim reproduction and/or distribution -of this SPDX Specification 3.0.1, including without limitation any partial use or combining this SPDX +of this SPDX Specification 3.1, including without limitation any partial use or combining this SPDX Specification with another work, is: "This is not an official SPDX Specification. Portions herein have been reproduced from SPDX® -Specification 3.0.1 found at spdx.dev. These portions are Copyright © 2010--2024 Linux Foundation and +Specification 3.1 found at spdx.dev. These portions are Copyright © 2010--2025 Linux Foundation and its Contributors, and are licensed under the Community Specification License 1.0 by the Linux Foundation and its Contributors. All other rights are expressly reserved by Linux Foundation and its Contributors." diff --git a/docs/front/copyright.md b/docs/front/copyright.md index 8c108d7392..49df723613 100644 --- a/docs/front/copyright.md +++ b/docs/front/copyright.md @@ -1,6 +1,6 @@ # Use of Specification - Terms, Conditions & Notices -Copyright © 2010-2024, The Linux Foundation and its Contributors, +Copyright © 2010-2025, The Linux Foundation and its Contributors, including SPDX Model contributions from OMG and its Contributors. This work is licensed under the diff --git a/submissions/ISO/front/iso-foreword.md b/submissions/ISO/front/iso-foreword.md index 539149dd5d..b2ad5a0a69 100644 --- a/submissions/ISO/front/iso-foreword.md +++ b/submissions/ISO/front/iso-foreword.md @@ -38,7 +38,7 @@ In the IEC, see This document was prepared by [The Linux Foundation](https://www.linuxfoundation.org/) and its Contributors under the [SPDX Working Group](https://spdx.dev/) -(as SPDX® Specification v3.0.1) +(as SPDX® Specification v3.1) and drafted in accordance with its editorial rules. Its preparation and publication has been made in coordination with related efforts with the [Object Management Group (OMG)](https://www.omg.org/). diff --git a/submissions/OMG/front/cover.md b/submissions/OMG/front/cover.md index 3c4e2c6e97..77ff1c2287 100644 --- a/submissions/OMG/front/cover.md +++ b/submissions/OMG/front/cover.md @@ -1,3 +1 @@ - -# The System Package Data Exchange (SPDX) Specification Version 3.0.1 - +# The System Package Data Exchange (SPDX) Specification Version 3.1 diff --git a/submissions/OMG/front/second-page.md b/submissions/OMG/front/second-page.md index 514a5ac91c..7a63157c8e 100644 --- a/submissions/OMG/front/second-page.md +++ b/submissions/OMG/front/second-page.md @@ -1,6 +1,6 @@ -# The System Package Data Exchange™ (SPDX®) Specification Version 3.0.1 +# The System Package Data Exchange™ (SPDX®) Specification Version 3.1 -Copyright © 2010-2024, The Linux Foundation and its Contributors, +Copyright © 2010-2025, The Linux Foundation and its Contributors, including SPDX Model contributions from OMG and its Contributors. ## Use of Specification - Terms, Conditions & Notices @@ -28,4 +28,3 @@ Software developed under the terms of the licenses under which this specification is issued may claim compliance or conformance with this specification if and only if the software provider complies with the SPDX Trademark License given above. - From 3a94cbbbd85b2d3ec5e12e5f7f93e22ee7e134d2 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 17 Oct 2025 17:44:36 +0800 Subject: [PATCH 06/16] Use en dash between years Signed-off-by: Arthit Suriyawongkul --- docs/conformance.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/conformance.md b/docs/conformance.md index 4f6a3eaab6..c8adf200f8 100644 --- a/docs/conformance.md +++ b/docs/conformance.md @@ -259,7 +259,7 @@ License, as stated in the [SPDX Trademark Page](https://spdx.dev/trademark). The official copyright notice that shall be used with any verbatim reproduction and/or distribution of this SPDX Specification 3.1 is: -"Official SPDX® Specification 3.1 Copyright © 2010--2025 Linux Foundation and its Contributors. +"Official SPDX® Specification 3.1 Copyright © 2010–2025 Linux Foundation and its Contributors. Licensed under the Community Specification License 1.0. All other rights are expressly reserved." The official copyright notice that shall be used with any non-verbatim reproduction and/or distribution @@ -267,7 +267,7 @@ of this SPDX Specification 3.1, including without limitation any partial use or Specification with another work, is: "This is not an official SPDX Specification. Portions herein have been reproduced from SPDX® -Specification 3.1 found at spdx.dev. These portions are Copyright © 2010--2025 Linux Foundation and +Specification 3.1 found at spdx.dev. These portions are Copyright © 2010–2025 Linux Foundation and its Contributors, and are licensed under the Community Specification License 1.0 by the Linux Foundation and its Contributors. All other rights are expressly reserved by Linux Foundation and its Contributors." From 3f3666338c1b898966c24f2b99fa5c4ee3669c6b Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 17 Oct 2025 17:46:51 +0800 Subject: [PATCH 07/16] Use en dash between years Signed-off-by: Arthit Suriyawongkul --- docs/front/copyright.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/front/copyright.md b/docs/front/copyright.md index 49df723613..42a79544df 100644 --- a/docs/front/copyright.md +++ b/docs/front/copyright.md @@ -1,6 +1,6 @@ # Use of Specification - Terms, Conditions & Notices -Copyright © 2010-2025, The Linux Foundation and its Contributors, +Copyright © 2010–2025, The Linux Foundation and its Contributors, including SPDX Model contributions from OMG and its Contributors. This work is licensed under the From 6c2f9090c8c31cc5c98ea272d85d84279a9b8fc7 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 17 Oct 2025 17:49:42 +0800 Subject: [PATCH 08/16] Revert version and year changes Signed-off-by: Arthit Suriyawongkul --- submissions/OMG/front/second-page.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/submissions/OMG/front/second-page.md b/submissions/OMG/front/second-page.md index 7a63157c8e..815663b8e8 100644 --- a/submissions/OMG/front/second-page.md +++ b/submissions/OMG/front/second-page.md @@ -1,6 +1,6 @@ -# The System Package Data Exchange™ (SPDX®) Specification Version 3.1 +# The System Package Data Exchange™ (SPDX®) Specification Version 3.0.1 -Copyright © 2010-2025, The Linux Foundation and its Contributors, +Copyright © 2010–2024, The Linux Foundation and its Contributors, including SPDX Model contributions from OMG and its Contributors. ## Use of Specification - Terms, Conditions & Notices From 99b820cf486aba5e7e0831777d1304343ccac406 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 17 Oct 2025 17:50:46 +0800 Subject: [PATCH 09/16] Revert version change Signed-off-by: Arthit Suriyawongkul --- submissions/OMG/front/cover.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/submissions/OMG/front/cover.md b/submissions/OMG/front/cover.md index 77ff1c2287..d37daea25e 100644 --- a/submissions/OMG/front/cover.md +++ b/submissions/OMG/front/cover.md @@ -1 +1 @@ -# The System Package Data Exchange (SPDX) Specification Version 3.1 +# The System Package Data Exchange (SPDX) Specification Version 3.0.1 From e0bccd8862e692483b0d429f9c946af96ed3e37d Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 17 Oct 2025 17:51:54 +0800 Subject: [PATCH 10/16] Revert version change Signed-off-by: Arthit Suriyawongkul --- submissions/ISO/front/iso-foreword.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/submissions/ISO/front/iso-foreword.md b/submissions/ISO/front/iso-foreword.md index b2ad5a0a69..539149dd5d 100644 --- a/submissions/ISO/front/iso-foreword.md +++ b/submissions/ISO/front/iso-foreword.md @@ -38,7 +38,7 @@ In the IEC, see This document was prepared by [The Linux Foundation](https://www.linuxfoundation.org/) and its Contributors under the [SPDX Working Group](https://spdx.dev/) -(as SPDX® Specification v3.1) +(as SPDX® Specification v3.0.1) and drafted in accordance with its editorial rules. Its preparation and publication has been made in coordination with related efforts with the [Object Management Group (OMG)](https://www.omg.org/). From 3d374ff03758259b633ffe721eb63513a8fd613d Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Tue, 21 Oct 2025 15:31:50 +0100 Subject: [PATCH 11/16] Put back extra new lines Signed-off-by: Arthit Suriyawongkul --- submissions/OMG/front/cover.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/submissions/OMG/front/cover.md b/submissions/OMG/front/cover.md index d37daea25e..3c4e2c6e97 100644 --- a/submissions/OMG/front/cover.md +++ b/submissions/OMG/front/cover.md @@ -1 +1,3 @@ + # The System Package Data Exchange (SPDX) Specification Version 3.0.1 + From be31a267d7cf7f8dae571b2f72e9e7321e242079 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Tue, 21 Oct 2025 15:32:51 +0100 Subject: [PATCH 12/16] Put back extra new lines and not using en dash Signed-off-by: Arthit Suriyawongkul --- submissions/OMG/front/second-page.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/submissions/OMG/front/second-page.md b/submissions/OMG/front/second-page.md index 815663b8e8..514a5ac91c 100644 --- a/submissions/OMG/front/second-page.md +++ b/submissions/OMG/front/second-page.md @@ -1,6 +1,6 @@ # The System Package Data Exchange™ (SPDX®) Specification Version 3.0.1 -Copyright © 2010–2024, The Linux Foundation and its Contributors, +Copyright © 2010-2024, The Linux Foundation and its Contributors, including SPDX Model contributions from OMG and its Contributors. ## Use of Specification - Terms, Conditions & Notices @@ -28,3 +28,4 @@ Software developed under the terms of the licenses under which this specification is issued may claim compliance or conformance with this specification if and only if the software provider complies with the SPDX Trademark License given above. + From c6e8ed203e8795b40f4db1660caae2e967a3320c Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 17 Oct 2025 08:42:53 +0200 Subject: [PATCH 13/16] Use ISO shall: spdx-lite Also fix few typos and missing words Signed-off-by: Arthit Suriyawongkul --- docs/annexes/spdx-lite.md | 55 ++++++++++++++++++++++++--------------- 1 file changed, 34 insertions(+), 21 deletions(-) diff --git a/docs/annexes/spdx-lite.md b/docs/annexes/spdx-lite.md index 7361a4c9c5..df433ce528 100644 --- a/docs/annexes/spdx-lite.md +++ b/docs/annexes/spdx-lite.md @@ -2,8 +2,10 @@ ## Explanation of the Lite profile -The Lite profile is designed to make it quick and easy to start a Software Bill of Materials -in situations where a company may have limited capacity for introducing new items into their processes. +The Lite profile is designed to make it quick and easy to start a +Software Bill of Materials in situations where a company may have limited +capacity for introducing new items into their processes. + The Lite profile captures the minimum set of information required for license compliance in the software supply chain. It contains information about the creation of the SBOM, @@ -11,17 +13,19 @@ package lists with licensing and other related information, and their relationships. All elements in Lite profile are essential for complying with licenses. -It is easy to use a SPDX document with the Lite profile +It is easy to use an SPDX document with the Lite profile for anyone who does not have enough knowledge about licensing information -and easy to import license information from former versions of SPDX Lite format files. +and easy to import license information from former versions of SPDX Lite format +files. + The Lite profile offers the flexibility to be used either alone or in combination with other SPDX profiles -as a SPDX document in the software supply chain. +as an SPDX document in the software supply chain. ## Mandatory and recommended properties -The Lite profile specifies that some properties MUST be present -and some others SHOULD be present, as much as possible. +The Lite profile specifies that some properties shall be present +and some others should be present, as much as possible. The following lists collect and present this information for every class present in the SPDX data, @@ -32,22 +36,22 @@ The lists of properties are in alphabetical order, for easy reference. - Mandatory 1. creationInfo - 1. element (may be multiple), MUST have at least one /Software/Sbom object - 1. rootElement (may be multiple), SHOULD be objects of type /Software/Sbom + 1. element (may be multiple), shall have at least one /Software/Sbom object + 1. rootElement (may be multiple), should be objects of type /Software/Sbom 1. spdxId - Recommended 1. comment 1. dataLicense 1. name 1. namespaceMap (may be multiple) - 1. verifiedUsing (may be multiple), SHOULD be objects of type /Core/Hash + 1. verifiedUsing (may be multiple), should be objects of type /Core/Hash ### /Software/Sbom - Mandatory 1. creationInfo - 1. element (may be multiple), MUST have at least one /Software/Package object - 1. rootElement (may be multiple), SHOULD be objects of type /Software/Package + 1. element (may be multiple), shall have at least one /Software/Package object + 1. rootElement (may be multiple), should be objects of type /Software/Package 1. spdxId - Recommended 1. sbomType (may be multiple) @@ -60,26 +64,34 @@ The lists of properties are in alphabetical order, for easy reference. 1. name 1. packageVersion 1. spdxId - 1. suppliedBy, SHOULD be an object of type /Core/Agent + 1. suppliedBy, should be an object of type /Core/Agent - Recommended 1. attributionText (may be multiple) 1. builtTime 1. comment 1. downloadLocation 1. homepage - 1. originatedBy (may be multiple), SHOULD be objects of type /Core/Agent + 1. originatedBy (may be multiple), should be objects of type /Core/Agent 1. packageUrl 1. releaseTime 1. supportLevel (may be multiple) 1. validUntilTime - 1. verifiedUsing (may be multiple), SHOULD be objects of type /Core/Hash + 1. verifiedUsing (may be multiple), should be objects of type /Core/Hash -However, there MUST be at least a “downloadLocation” or “packageUrl” property. +However, there shall be at least a “downloadLocation” or “packageUrl” property. 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 shall exist + exactly one `/Core/Relationship` object + of type `hasConcludedLicense` + having that element as its `from` property and + a `/SimpleLicensing/AnyLicenseInfo` object as its `to` property. +1. for every `/Software/Package` object shall exist + exactly one `/Core/Relationship` object + of type `hasDeclaredLicense` + having that element as its `from` property and + a `/SimpleLicensing/AnyLicenseInfo` object as its `to` property. ### /Core/Hash @@ -110,7 +122,7 @@ Additionally: ### /Core/Agent (createdBy, suppliedBy, originatedBy) - Mandatory - 1. creationInfo, SHOULD be “BlankNode” + 1. creationInfo, should be “BlankNode” 1. name 1. spdxId - Recommended @@ -120,8 +132,9 @@ 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.*” - where * is any supported patch version of the SPDX specification + 1. createdBy (may be multiple), should be objects of type /Core/Agent + 1. specVersion, shall be a fixed string, “3.1.*” - where \* is + any supported patch version of the SPDX specification - Recommended 1. comment From 6b1b3556c3f64f146bd0b4e578647a95c1db5d09 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Fri, 17 Oct 2025 20:14:32 +0100 Subject: [PATCH 14/16] Update docs/annexes/spdx-lite.md Co-authored-by: Alexios Zavras (zvr) Signed-off-by: Arthit Suriyawongkul --- docs/annexes/spdx-lite.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/annexes/spdx-lite.md b/docs/annexes/spdx-lite.md index df433ce528..8211502564 100644 --- a/docs/annexes/spdx-lite.md +++ b/docs/annexes/spdx-lite.md @@ -133,7 +133,7 @@ Additionally: - Mandatory 1. created 1. createdBy (may be multiple), should be objects of type /Core/Agent - 1. specVersion, shall be a fixed string, “3.1.*” - where \* is + 1. specVersion, shall be a fixed string, “3.1.n” - where n is any supported patch version of the SPDX specification - Recommended 1. comment From 8cb272b2549a0214e3049f52df633dba4b8c4c2b Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Wed, 29 Oct 2025 18:17:49 +0000 Subject: [PATCH 15/16] Apply suggestion on (C) Signed-off-by: Arthit Suriyawongkul Co-authored-by: Alexios Zavras (zvr) Signed-off-by: Arthit Suriyawongkul --- docs/annexes/license-matching-guidelines-and-templates.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/annexes/license-matching-guidelines-and-templates.md b/docs/annexes/license-matching-guidelines-and-templates.md index 170106ca86..45bafad8d9 100644 --- a/docs/annexes/license-matching-guidelines-and-templates.md +++ b/docs/annexes/license-matching-guidelines-and-templates.md @@ -173,7 +173,7 @@ By having a rule regarding the use of "©", "(c)", or "copyright", we avoid the ### Guideline -"©", "(c)", or "Copyright" shall be considered equivalent and interchangeable. +"©", "(C)", "(c)", or "Copyright" shall 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, From 2103b615d55fb135978468e4ceed99e0207e6cb1 Mon Sep 17 00:00:00 2001 From: Arthit Suriyawongkul Date: Wed, 29 Oct 2025 18:20:32 +0000 Subject: [PATCH 16/16] Revise introduction Signed-off-by: Arthit Suriyiawongkul Signed-off-by: Arthit Suriyawongkul --- docs/annexes/license-matching-guidelines-and-templates.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/docs/annexes/license-matching-guidelines-and-templates.md b/docs/annexes/license-matching-guidelines-and-templates.md index 45bafad8d9..2319f37207 100644 --- a/docs/annexes/license-matching-guidelines-and-templates.md +++ b/docs/annexes/license-matching-guidelines-and-templates.md @@ -3,9 +3,7 @@ ## 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