From the SPDX Asia team calls, there has been some discussion about whether a new field is needed for communicating that a set of delivered software is intended for use as a prerequisite to another set of software.

It might be helpful to include an example showing whether (and to what extent) this can already be done via Relationships between Packages, rather than creating a new field.

Patching software, showing how to illustrate this.

Example 7 is not well formed SPDX because PackageName is not defined in the schema. That should simply be "name". That is one of many errors with that example. I think it's the same with anything that begins with "Package".

In example2, in hello-bin-v2, the ExternalDocumentRef correctly refers to the hash for hello-src-v2, but the document URI is for hello-src-v1. (Argh.) It should be fixed, in a new hello-bin-v3 document.

Looking at the examples for Go I noticed they used a syntax what is not mentioned in the SPDX spec:
https://spdx.github.io/spdx-spec/package-information/#77-package-download-location-field

Is this a valid entry for the Download Location field? If so, can I be pointed to the appropriate section of the spec. If not, is this something that is planned in a draft of an upcoming revision?

Similar to example 2, but there are now two separate C source files, compiled into separate binaries which are dynamically linked at run-time.

As with example 2, two separate SPDX documents - one for sources and one for binaries; binary doc references back to sources doc

Would be useful to have an C language example to demonstrate:

• original source file;
• patch file for it;
• post-patch file, after patch has been applied

representing these as Files as well as Snippets within the post-patch file, with Relationships among them.

cc @kestewart

Should start adding some examples of SPDX documents for Python:

• simple example with just standard library
• example with PyPI dependency
• example with transitive PyPI dependencies

It would be great to see the specific tooling calls used to create each SBOM in the repo to understand how the different styles and specific sets of info are built out.

Or, if they are created manually, it would be worth specifying that somewhere.

It looks like many (perhaps all) of the tag-value examples have the FileName as an absolute path, with / as the prefix.

According to Section 8.1.1 of the spec, filenames should be relative, prefixed with ./ instead.

Should start adding some examples of SPDX documents for Java:

• simple example with just standard library
• talk to others in SPDX community re: direct and indirect dependencies

Files example7-bin.spdx.json, example7-go-module.spdx.json, and example7-golang.spdx.json (lines 24 and 40) have property

"filesAnalyzed": "false"

Boolean types should have JSON Boolean values ("filesAnalyzed": false), not string values.

Since SPDX covers many different use cases with several different stakeholders, it would help to organize the examples so that someone interested in a specific set of use cases can find the examples easily.

For example, someone interested in security may not be interested in the licensing profiles and visa-versa.

I would propose creating separate directories for each of the profiles.

The current examples are more "Software" oriented and covers the area of how different types of artifacts would be represented - I would propose moving all of the examples under Software.

We could create a separate README for each directory which summarizes the examples.

The top level README could point to the different directories and summarize the profile.

Currently, the PackageDownloadLocation examples are in the format given by GitHub for SSH access, e.g. for example5:

PackageDownloadLocation: [email protected]:swinslow/spdx-examples.git#example5/content/src

However, this is incorrect according to the SPDX 2.2 spec. I'm not certain I follow how to represent the SSH access version (or if it's even possible to do so), but it looks like it should be done via HTTPS instead, e.g.:

PackageDownloadLocation: git+https://github.com/swinslow/spdx-examples.git#example5/content/src

The examples should be updated to fix this error, as they won't parse correctly in the current form.

Same as example 1, but sources and binaries in two separate packages

Two separate SPDX documents - one for sources and one for binaries; binary doc references back to sources doc

The golang JSON example defines creators as an array of objects with properties for "Tool", "Person":

    "creators": [{
			"Person": "Nisha K ([email protected])"
		}]
	},

While the SPDX Spec JSON example uses the tag/value string representation:

"creators" : [ "Tool: LicenseFind-1.0", "Organization: ExampleCodeInspect ()", "Person: Jane Doe ()" ],

As discussed at https://github.com/spdx/tools-java/issues/21 and swinslow/cmake-spdx#8 (and maybe elsewhere), the spec is arguably ambiguous about whether External Document References can only use SHA1 or whether they can use other checksum formats.

The examples in this repo use SHA256. However, based on the discussions at the links above, it looks like they should be SHA1 instead. So these should be corrected.

In example2, https://github.com/swinslow/spdx-examples/blob/ae99a44f757d89053f3e069c8cc5477db6429bce/example2/spdx/example2-src.spdx#L47 refers to SPDXRef-Package-hello.

However, the package identifier in this document should be SPDXRef-Package-hello-src.

This should be updated and the doc version bumped, and then the binary SPDX document's ExternalDocumentRef will need the updated version and hash (and the binary doc's version will also need to be bumped).

see also spdx/spdx-spec#473

File: https://github.com/spdx/spdx-examples/blob/master/example6/spdx2.2/example6-lib.spdx#L16

Error when trying to parse:
Only one PackageSupplier allowed, extra at line: 16

SPDX 2.3 spec for the PackageSupplier field specifies "Single line of text with one of the following: ..."

Is there any way to configure the parser to correctly parse a .spdx document with multiple PackageSupplier lines?

Migrating from @jlovejoy's PR in spdx/license-list-XML#1102, content from that PR below.

To be discussed further, just placing here to move out of license-list-XML

This is a working document to capture licensing examples found "in the wild" and how they would be mapped using the SPDX specification license fields

NOTE TO REMOVE: This is not where this information should ultimately be located, but just putting it here to get it written and can move as appropriate later!!

1. Github example

scenario:

• you have a package with 10 files
• 1 of these files = LICENSE.txt file with a copy of the MIT license
• the other 9 files have no licensing information whatsoever

license info:

at package level:

• Declared Licensem= MIT
• Concluded License = MIT
• Comments on License
• • The package level license is MIT and no other license information is found.

at file level:

• Declared License
• • LICENSE.txt file = MIT
• • other 9 files = NONE
• Concluded License
• • LICENSE.txt file = MIT
• • other 9 files = MIT
• Comments on License
• • LICENSE.txt file = (no comment necessary)
• • other 9 files = The package level license is MIT and no other license information is found.

1. NAME example

scenario:

• xyz

license info:

at package level:

• Declared License
• • LICENSE.txt file =
• • other 9 files =
• Concluded License
• • LICENSE.txt file =
• • other 9 files =
• Comments on License
• • LICENSE.txt file =
• • other 9 files =
    at file level:
• Declared License
• • LICENSE.txt file =
• • other 9 files =
• Concluded License
• • LICENSE.txt file =
• • other 9 files =
• Comments on License
• • LICENSE.txt file =
• • other 9 files =

The Example7 JSON files have properties packageName, packageVersion, packageLicenseConcluded, packageLicenseDeclared and packageCopyrightText.

The SPDX spec does not give any JSON examples, but the JSON Examples file has properties name, versionInfo, licenseConcluded, licenseDeclared, and copyrightText.

In the absence of JSON definitions in the spec, the properties here should omit prefixes to agree with those in the JSON Examples:

      "name": "example.com/hello",
      "versionInfo": "1.16.4",
      "licenseConcluded": "NOASSERTION",
      "licenseDeclared": "NOASSERTION",
      "copyrightText": "NOASSERTION"

The SPDX spec definition of SPDXID says:

Format	"SPDXRef-"[idstring]
where [idstring] is a unique string containing letters, numbers, ., and/or -.

"SPDXID": "SPDXRef-go-module-example.com/hello", contains an invalid character "/".

In my opinion, these examples got creators (nearly) right - (a single map or list of maps) to reflect the RDF example from the spec:

RDF:

<CreationInfo>
    <creator> Person: Jane Doe () </creator>
    <creator> Organization: ExampleCodeInspect () </creator>
    <creator> Tool: LicenseFind-1.0 </creator>
</CreationInfo>

JSON:

    "creators": {
        "Person": "Nisha K ([email protected])"
    }

and the JSON example file using a list of strings "creators" : [ "Tool: LicenseFind-1.0", "Organization: ExampleCodeInspect ()", "Person: Jane Doe ()" ], should be changed to a map:

    "creators" : {
      "Tool": "LicenseFind-1.0",
      "Organization": "ExampleCodeInspect ()",
      "Person": "Jane Doe ()"
    },

The example SPDX documents use a DocumentNamespace with the format https://swinslow.net/spdx-examples/example[number]/[name]-v[version]

These documents currently can't be found at https://swinslow.net/spdx-examples/ -- however, they should be available there, including prior versions.

Application depends on having system libc (and probably other binaries) available in order to execute properly.

For example - time 1.9 expects glibc to execute.

See illustration of dependency tree in:
https://drive.google.com/drive/u/0/folders/1Z364N234jrs36pjDT8xcS5hUGjRmMTN9

Example would be having a Document which has binary and sources, and SDPX document has relationship DESCRIBES binary, and the source components are referenced by relationships in the document.

The files in example8/ and example10/ contain invalid SPDXIDs.

In examplemaven-0.0.1.spdx.json there are some typos where the packages SPDXID start with SPDXREf-.. instead of SPDXRef-...

• Affected packages:
  • SPDXREf-log4jslf4jbinding
  • SPDXREf-log4jslf4jApi
  • SPDXREf-log4jApi
  • SPDXREf-log4jImpl
  • SPDXREf-example

In hello-source.spdx.json the document SPDXID is lowercase SPDXRef-Document instead of uppercase SPDXRef-DOCUMENT as described in the spec.

Raised as a question on the SPDX tech email list from Oliver Fendt:

...
Sometimes you find in a package (lets assume the declared license is A) in some subdirectory (lets assume SUB-DIR-X) a README file with the following wording: “the files in this directory are licensed under license C”, but none of the files in this directory contain any license information and do not contain any reference to the README file in this directory.
...

Response in the email thread:

...
In SPDX, you can use the SPDX Package to represent a subdirectory of files within a larger package.

In [the above] scenario, one approach would be to create an SPDX package – if it doesn’t have a logical name, you could call it something like “C licensed files” with a declared license of C. Then use the “contains” relationship from the parent package to the subdirectory.
...

This could be implemented using the tools-java CI.

For CI/CD, it would be helpful to run all of the examples in this repo through the SPDX tools validator at PR / push, to make sure they're actually valid SPDX :)

Should start adding some examples of SPDX documents for Golang:

• simple example with just standard library
• example with vendored single third party dependency
• example with vendored transitive third party dependencies
• examples with each of the above, using Go modules instead of vendor/ directory

As per the documentation, SPDX Documents can be in one of the following formats: tag/value (.spdx), JSON(.spdx.json), YAML(.spdx.yml), RDF/xml(spdx.rdf) and spreadsheets (.xls).

Currently there are only tag/value and JSON examples in the repo.

I tried to use this repo to find examples because I am integrating the Spdx-Java-Library into my project, and would need to use files in all formats for testing purposes.

For example6, the example6-lib.spdx document is missing a mandatory DESCRIBES relationship which should point to the first package (SPDXRef-Package-godist).

Check the other SPDX docs as well.