From 3d504fb2c7ed26dc55282837d2a6b0e0f66408ce Mon Sep 17 00:00:00 2001 From: Alexios Zavras Date: Sat, 1 Jun 2024 10:53:29 +0200 Subject: [PATCH 1/2] Adds a new annex on license matching Signed-off-by: Alexios Zavras --- ...cense-matching-guidelines-and-templates.md | 223 ++++++++++++++++++ mkdocs.yml | 1 + 2 files changed, 224 insertions(+) create mode 100644 docs/annexes/license-matching-guidelines-and-templates.md diff --git a/docs/annexes/license-matching-guidelines-and-templates.md b/docs/annexes/license-matching-guidelines-and-templates.md new file mode 100644 index 0000000000..bb7f5611f9 --- /dev/null +++ b/docs/annexes/license-matching-guidelines-and-templates.md @@ -0,0 +1,223 @@ +# Annex C License matching guidelines and templates (Informative) + +## C.1 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. 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. + +## C.2 How these guidelines are applied + +### C.2.1 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. + +### C.2.2 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. (see [explanation of SPDX License List fields](https://github.com/spdx/license-list-XML/blob/master/DOCS/license-fields.md) for more info). + +The following XML tag is used to implement this guideline: `` + +## C.3 Substantive text + +### C.3.1 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. + +### C.3.2 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. + +### C.3.3 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. + +### C.3.4 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). + +The following XML tag is used to implement this guideline. `` with 2 attributes: + +* `match` - a POSIX extended regular expression (ERE) to match the replaceable text +* `name` - an identifier for the variable text unique to the license XML document + +The original text is enclosed within the beginning and ending alt tags. + +For example: `Copyright Linux Foundation` + +The original replaceable text appears on the SPDX License List webpage in red text. + +### C.3.5 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. + +The license should 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: `` + +For example: `Apache License Version 2.0, January 2004 http://www.apache.org/licenses/` + +Omittable text appears on the SPDX License List webpage in blue text. + +## C.4 Whitespace + +### C.4.1 Purpose + +To avoid the possibility of a non-match due to different spacing of words, line breaks, or paragraphs. + +### C.4.2 Guideline + +All whitespace should be treated as a single blank space. + +XML files do not require specific markup to implement this guideline. + +## C.5 Capitalization + +### C.5.1 Purpose + +To avoid the possibility of a non-match due to lowercase or uppercase letters in otherwise the same words. + +### C.5.2 Guideline + +All uppercase and lowercase letters should be treated as lowercase letters. + +XML files do not require specific markup to implement this guideline. + +## C.6 Punctuation + +### C.6.1 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. + +### C.6.2 Guideline: punctuation + +Punctuation should be matched, unless otherwise stated in these guidelines or unless specific markup is added. + +### C.6.3 Guideline: hyphens, dashes + +Any hyphen, dash, en dash, em dash, or other variation should be considered equivalent. + +### C.6.4 Guideline: Quotes + +Any variation of quotations (single, double, curly, etc.) should be considered equivalent. + +## C.7 Code Comment Indicators or Separators + +### C.7.1 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 ***. + +### C.7.2 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. + +### C.7.3 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. + +## C.8 Bullets and numbering + +### C.8.1 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. + +### C.8.2 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. + +The following XML tag is used to implement this guideline: `` + +For example: `1.0` + +## C.9 Varietal word spelling + +### C.9.1 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. + +### C.9.2 Guideline + +The words in each line of the text file available at are considered equivalent and interchangeable. + +XML files do not require specific markup to implement this guideline. + +## C.10 Copyright symbol + +### C.10.1 Purpose + +By having a rule regarding the use of "©", "(c)", or "copyright", we avoid the possibility of a mismatch based on these variations. + +### C.10.2 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 below. + +## C.11 Copyright notice + +### C.11.1 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. + +### C.11.2 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." + +The following XML tag is used to implement this guideline: `` + +For example: `Copyright 2022 Linux Foundation` + +## C.12 License name or title + +### C.12.1 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. + +### C.12.2 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. + +The following XML tag is used to implement this guideline: `` + +For example: `Attribution Assurance License` + +## C.13 Extraneous text at the end of a license + +### C.13.1 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. + +### C.13.2 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 section C.3.5. + +## C.14 HTTP Protocol + +### C.14.1 Purpose + +To avoid a license mismatch due to a difference in a hyperlink protocol (e.g. http vs. https). + +### C.14.2 Guideline + +HTTP:// and HTTPS:// should be considered equivalent. + +XML files do not require specific markup to implement this guideline. + +## C.15 SPDX License list + +### C.15.1 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 found in the [license-list-XML](https://github.com/spdx/license-list-XML) repo, users are encouraged to use the published versions in the [license-list-data](https://github.com/spdx/license-list-data) repository. The license-list-data repository is tagged by release. Only tagged released versions of the license list are considered stable. + +### C.15.2 License List XML format + +A full schema for the License List XML can be found at https://github.com/spdx/license-list-XML/blob/master/schema/ListedLicense.xsd. + diff --git a/mkdocs.yml b/mkdocs.yml index 1b55e4facd..d0b088f7b4 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -330,6 +330,7 @@ nav: - 'Getting started with SPDX 3': annexes/getting-started.md - 'RDF Object Model and Identifier Syntax': annexes/RDF-object-model-and-identifier-syntax.md - 'SPDX License Expressions': annexes/SPDX-license-expressions.md + - 'SPDX license list matching guidelines': annexes/license-matching-guidelines-and-templates.md - 'Using SPDX short identifiers in Source Files': annexes/using-SPDX-short-identifiers-in-source-files.md - 'Using SPDX to comply with norms, standards and regulation': annexes/using-SPDX-to-comply-with-industry-guidance.md - 'Including Security Information in SPDX': annexes/including-security-information-in-SPDX.md From 86ac9482cfe0935194f71f0ace0721d5e17f9936 Mon Sep 17 00:00:00 2001 From: Alexios Zavras Date: Sun, 2 Jun 2024 00:26:32 +0200 Subject: [PATCH 2/2] Adds pkg-url spec as an annex Signed-off-by: Alexios Zavras --- docs/annexes/pkg-url-specification.md | 375 ++++++++++++++++++++++++++ mkdocs.yml | 1 + 2 files changed, 376 insertions(+) create mode 100644 docs/annexes/pkg-url-specification.md diff --git a/docs/annexes/pkg-url-specification.md b/docs/annexes/pkg-url-specification.md new file mode 100644 index 0000000000..cfd13da3df --- /dev/null +++ b/docs/annexes/pkg-url-specification.md @@ -0,0 +1,375 @@ +# Annex E: Package URL specification v1 (Normative) + +## E.1 Introduction + +The Package URL core specification defines a versioned and formalized +format, syntax, and rules used to represent and validate package URLs. + +A package URL or _purl_ is an attempt to standardize existing approaches +to reliably identify the location of software packages. + +A _purl_ is a URL string used to identify the location of a +software package in a mostly universal and uniform way across +programming languages, package managers, packaging conventions, tools, +APIs and databases. + +Such a package URL is useful to reliably reference the same software +package using a simple and expressive syntax and conventions based on +familiar URLs. + +## E.2 Syntax definition + +_purl_ stands for **package URL**. + +A _purl_ is a URL composed of seven components: + + scheme:type/namespace/name@version?qualifiers#subpath + +Components are separated by a specific character for unambiguous parsing. + +The definition for each components is: + +- **scheme**: this is the URL scheme with the constant value of "`pkg`". One of the primary reason for this single scheme is to facilitate the future official registration of the "`pkg`" scheme for package URLs. Required. +- **type**: the package type or package protocol such as maven, npm, nuget, gem, pypi, etc. Required. +- **namespace**: some name prefix such as a Maven groupid, a Docker image owner, a GitHub user or organization. Optional and type-specific. +- **name**: the name of the package. Required. +- **version**: the version of the package. Optional. +- **qualifiers**: extra qualifying data for a package such as an OS, architecture, a distribution, etc. Optional and type-specific. +- **subpath**: extra subpath within a package, relative to the package root. Optional. + +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 . + +A _purl_ must 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. + +The _purl_ components are mapped to the following URL components: + +- _purl_ scheme: this is a URL scheme with a constant value: `pkg` +- _purl_ type, namespace, name and version components: these are collectively mapped to a URL path +- _purl_ qualifiers: this maps to a URL query +- _purl_ subpath: this is a URL fragment + +## E.3 Character encoding + +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 . + +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 + +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 +components and component segments +as explained in the "How to produce and consume _purl_ data" section. + +## E.4 Rules for each component + +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 +defined in the "Character encoding" section. + +The rules for each component are: + +### E.4.1 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 '//'. +- 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. + +### E.4.2 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 is case insensitive, with the canonical form being lowercase. + +### E.4.3 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. + +### E.4.4 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. + +### E.4.5 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 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. + +### E.4.6 Rules for qualifiers + +- The qualifiers string is prefixed by a `?` separator when not empty. +- 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. +- A key is case insensitive, with the canonical form being lowercase. +- A key cannot contain spaces. +- A value must be a percent-encoded string. +- The `=` separator is neither part of the key nor of the value. + +### E.4.7 Rules for subpath + +- 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. + +## E.5 Known types + +There are several known _purl_ package type definitions. +The current list of known types is: +`alpm`, +`apk`, +`bitbucket`, +`bitnami`, +`cargo`, +`cocoapods`, +`composer`, +`conan`, +`conda`, +`cpan`, +`cran`, +`deb`, +`docker`, +`gem`, +`generic`, +`github`, +`golang`, +`hackage`, +`hex`, +`huggingface`, +`luarocks`, +`maven`, +`mlflow`, +`npm`, +`nuget`, +`oci`, +`pub`, +`pypi`, +`qpkg`, +`rpm`, +`swid`, and +`swift`. + +The list, with definitions for each type, +is maintained in the file named `PURL-TYPES.rst` +in the online repository +https://github.com/package-url/purl-spec. + +## E.6 Known qualifiers key/value pairs + +Qualifiers should be limited to the bare minimum +for proper package identification, +to ensure that a _purl_ stays compact and readable in most cases. +Separate external attributes stored outside of a _purl_ +are the preferred mechanism to convey extra long and optional information. +API, database or web form. + +The following keys are valid for use in all package types: + +- `repository_url` is an extra URL for an alternative, non-default package repository or registry. + The default repository or registry of each type is documented in the "Known types" section. +- `download_url` is an extra URL for a direct package web download URL. +- `vcs_url` is an extra URL for a package version control system URL. +- `file_name` is an extra file name of a package archive. +- `checksum` is a qualifier for one or more checksums stored as a comma-separated list. + Each item in the list is in form of algorithm:hex\_value (all lowercase), + such as `sha1:ad9503c3e994a4f611a4892f2e67ac82df727086`. + +## E.7 How to produce and consume _purl_ data + +The following provides rules to be followed +when building or deconstructing _purl_ instances. + +### E.7.1 How to build _purl_ string from its components + +Building a _purl_ ASCII string works from left to right, from type to subpath. + +To build a _purl_ string from its components: + +1. Start a _purl_ string with the "`pkg:`" scheme as a lowercase ASCII string +1. Append the type string to the _purl_ as a lowercase ASCII string +1. Append `/` to the _purl_ +1. If the namespace is not empty: + + 1. Strip the namespace from leading and trailing `/` + 1. Split on `/` as segments + 1. Apply type-specific normalization to each segment, if needed + 1. Encode each segment in UTF-8-encoding + 1. Percent-encode each segment + 1. Join the segments with `/` + 1. Append this to the _purl_ + 1. Append `/` to the _purl_ + +1. Strip the name from leading and trailing `/` +1. Apply type-specific normalization to the name, if needed +1. Encode the name in UTF-8-encoding +1. Percent-encode the name +1. Append the percent-encoded name to the _purl_ +1. If the version is not empty: + + 1. Append `@` to the _purl_ + 1. Encode the version in UTF-8-encoding + 1. Percent-encode the version + 1. Append the percent-encoded version to the _purl_ + +1. If the qualifiers are not empty and not composed only of key/value pairs where the value is empty: + + 1. Append `?` to the _purl_ + 1. Discard any pair where the value is empty + 1. Encode each value in UTF-8-encoding + 1. If the key is `checksum` and there are more than one checksums, join the list with `,` to create the qualifier value + 1. Create each qualifier string by joining the lowercased key, the equal `=` sign, and the percent-encoded value + 1. Sort this list of qualifier strings lexicographically + 1. Join this list of sorted qualifier strings with `&` + 1. Append this string to the _purl_ + +1. If the subpath is not empty and not composed only of empty, `.`, and `..` segments: + + 1. Append `#` to the _purl_ + 1. Strip the subpath from leading and trailing `/` + 1. Split the subpath on `/` as a list of segments + 1. Discard empty, `.`, and `..` segments + 1. Encode each segment in UTF-8-encoding + 1. Percent-encode each segment + 1. Join the segments with `/` + 1. Append this string to the _purl_ + +### E.7.2 How to parse a _purl_ string to its components + +Parsing a _purl_ ASCII string into its components works +by splitting the string on different characters. + +To parse a _purl_ string in its components: + +1. Split the _purl_ string once from right on `#`, if present; the left side is the remainder. +1. If the right side is not empty, it contains subpath information: + + 1. Strip it from leading and trailing `/`. + 1. Split this on `/` in a list of segments. + 1. Discard empty, `.`, and `..` segments. + 1. Percent-decode each segment. + 1. UTF-8-decode each of these. + 1. Join segments with `/`. + 1. This is the subpath. + +1. Split the remainder once from right on `?`, if present; the left side is the remainder. +1. If the right side is not empty, it contains qualifiers information: + + 1. Split it on `&` in a list of key=value pairs. + 1. Split each pair once from left on `=` in key and value parts. + 1. The key is the lowercase left side. + 1. Percent-decode the right side. + 1. UTF-8-decode this to get the value. + 1. Discard any key/value pairs where the value is empty. + 1. If the key is `checksum`, split the value on `,` to create a list of checksums. + 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. 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. +1. Split the remainder once from right on `@`, if present; the left side is the remainder. +1. If the right side is not empty, it contains version information: + + 1. Percent-decode the string. + 1. UTF-8-decode this. + 1. This is the version. + +1. Split the remainder once from right on `/`, if present; the left side is the remainder. +1. The right side contains name information. +1. Percent-decode the name string. +1. UTF-8-decode this. +1. Apply type-specific normalization, if needed. +1. This is the name. +1. If the remainder is not empty, it contains namespace information: + + 1. Split the remainder on `/` to a list of segments. + 1. Discard any empty segment. + 1. Percent-decode each segment. + 1. UTF-8-decode each of these. + 1. Apply type-specific normalization to each segment, if needed. + 1. Join segments with `/`. + 1. This is the namespace. + +## E.8 Examples + +The following list includes some valid _purl_ examples: + +- `pkg:bitbucket/birkenfeld/pygments-main@244fd47e07d1014f0aed9c` +- `pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie` +- `pkg:gem/ruby-advisory-db-check@0.12.4` +- `pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c` +- `pkg:golang/google.golang.org/genproto#googleapis/api/annotations` +- `pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources` +- `pkg:npm/foobar@12.3.1` +- `pkg:nuget/EnterpriseLibrary.Common@6.0.1304` +- `pkg:pypi/django@1.11.1` +- `pkg:rpm/fedora/curl@7.50.3-1.fc25?arch=i386&distro=fedora-25` + +## E.9 Original license + +This specification is based on the texts published +in the https://github.com/package-url/purl-spec online repository. +The original license and attribution are reproduced below: + +Copyright (c) the purl authors + +Permission is hereby granted, free of charge, to any person obtaining a copy of +this software and associated documentation files (the "Software"), to deal in +the Software without restriction, including without limitation the rights to +use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of +the Software, and to permit persons to whom the Software is furnished to do so, +subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS +FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR +COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER +IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + diff --git a/mkdocs.yml b/mkdocs.yml index d0b088f7b4..3a73c97b45 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -336,6 +336,7 @@ nav: - 'Including Security Information in SPDX': annexes/including-security-information-in-SPDX.md - 'SPDX Lite': annexes/SPDX-Lite.md - 'Cross-referencing in SPDX 3': annexes/cross-reference.md + - 'Package URL specification': annexes/pkg-url-specification.md - licenses: - 'Creative Commons Attribution License 3.0 Unported': licenses/CC-BY-3.0.md - 'Community Specification License 1.0': licenses/Community-Spec-1.0.md