Merge pull request #77 from bact/fix-paths-version

Fix paths and dead URLs

software/example1/README.md

@@ -14,7 +14,7 @@ content
 One [C source file](content/src/hello.c) with a simple "hello world" program, compiled into a [single binary](content/build/hello) with no dependencies via a [Makefile](content/src/Makefile).
 (Assumed dependencies such as the operating system kernel, C standard library, etc. are not addressed here.)
 
-One [SPDX document](spdx/example1.spdx) showing the Makefile, source file and binary, together as a single package.
+One [SPDX document](spdx2.2/example1.spdx) showing the Makefile, source file and binary, together as a single package.
 
 This assumes of course that all three files are in fact being distributed together as a single package.
 

software/example10/README.md

@@ -1,6 +1,7 @@
 # Example 10
 
 ## Description
+
 This is an example python3 project with a minimal set of dependencies. Included in the `content` folder is the source code and a packaged python package using the [instructions from python.org](https://packaging.python.org/en/latest/tutorials/packaging-projects/). This is but one way of packaging a python project.
 
 ```
@@ -24,13 +25,13 @@ The package was built on a Ubuntu 22 system with Python 3.10 installed. The pack
 
 The `build` package is required to build this project.
 
-```
+```shell
 $ python3 -m pip install --upgrade build
 ```
 
 This downloads some extra packages.
 
-```
+```shell
 $ pip freeze                                                                       build==0.9.0
 packaging==21.3
 pep517==0.13.0
@@ -39,8 +40,9 @@ tomli==2.0.1
 ```
 
 Once done, `cd` into the `hello` directory and run the following:
-```
+
+```shell
 $ python3 -m build
 ```
 
-This will create a `dist` folder within the hello directory. The resulting directory is provided in this repository. 
+This will create a `dist` folder within the hello directory. The resulting directory is provided in this repository.

software/example11/README.md

@@ -28,12 +28,12 @@ The `spdx` directory contains an SBOM describing the source,
 and the binary. They are linked with a GENERATED_FROM relationship.
 
 The source package lists the 3 top level dependencies. Trnasients
-are not included to make thins easier. 
+are not included to make thins easier.
 
 The SBOM structure (outlinedgenerate with
 [bom](https://github.com/kubernetes-sigs/bom)) looks like this:
 
-```
+```shell
 $ bom document outline example11/spdx/sbom.spdx.json
 
  📂 SPDX Document SBOM-SPDX-2d85f548-12fa-46d5-87ce-5e78e5e111f4
@@ -52,6 +52,5 @@ $ bom document outline example11/spdx/sbom.spdx.json
   └ SPDXRef-File-hello-server (hello-server)
      │ 🔗 1 Relationships
      └ GENERATED_FROM PACKAGE hello-server-src (version 0.4.0)
-  
 
-```
+```

software/example2/README.md

@@ -13,13 +13,13 @@ content
 
 The content is identical to [example1](../example1): one [C source file](content/src/hello.c) with a simple "hello world" program, compiled into a [single binary](content/build/hello) with no dependencies via a [Makefile](content/src/Makefile).
 
-However, where example1 had a single SPDX document containing both source and binary, example2 instead has separate SPDX documents for [source](spdx/example2-src.spdx) and [binary](spdx/example2-bin.spdx).
+However, where example1 had a single SPDX document containing both source and binary, example2 instead has separate SPDX documents for [source](spdx2.2/example2-src.spdx) and [binary](spdx2.2/example2-bin.spdx).
 
 This describes a scenario where binary and source are distributed separately, but where we want to be able to reflect the relationships between binary and source packages.
 
 ## Comments
 
-Substantively, this is the same software as in [example1](../example).
+Substantively, this is the same software as in [example1](../example1).
 However, here we are representing the sources and binaries as two separate Packages, on the assumption that we're distributing them separately.
 Because of this, the source Package and binary Package are described in two separate SPDX documents.
 
@@ -31,6 +31,6 @@ Relationships across separate documents are handled via `DocumentRef-` tags, def
 Note that these external document references and relationships cannot be circular: one document can refer to the other, but (to my knowledge) they cannot refer circularly to each other.
 To reference another document in an ExternalDocumentRef definition, you need to specify its hash, so it isn't possible for two documents to refer to one another; each would need to modify its own contents based on the other's hash value.
 
-In the [SPDX document for the binary](spdx/example2-bin.spdx), note how the Relationships at the end of the document include `DocumentRef-hello-src:` as a prefix.
+In the [SPDX document for the binary](spdx2.2/example2-bin.spdx), note how the Relationships at the end of the document include `DocumentRef-hello-src:` as a prefix.
 This uses the `DocumentRef-` defined in the `ExternalDocumentRef` tag at the top of the document.
 This is the mechanism used to refer to SPDX identifiers for elements defined in other SPDX documents.

software/example3/README.md

@@ -19,14 +19,14 @@ This file carries a BSD-3-Clause license.
 The other [contains a main function](content/src/main.c) which dynamically loads and uses the function from the library file.
 This file carries a GPL-3.0-or-later license.
 
-As with example2, there are separate SPDX documents for [source](spdx/example3-src.spdx) and [binary](spdx/example3-bin.spdx).
+As with example2, there are separate SPDX documents for [source](spdx2.2/example3-src.spdx) and [binary](spdx2.2/example3-bin.spdx).
 
 This describes a scenario where there are multiple binary files, and we want to represent the dependency and dynamic-linking relationship between the binary files.
 
 ## Comments
 
-Note that the [binary SPDX document](spdx/example3-bin.spdx) includes the `RUNTIME_DEPENDENCY_OF` relationship between the main binary and the library binary.
-There are many different dependency types of Relationships defined in [v2.2 of the SPDX spec](https://spdx.github.io/spdx-spec/7-relationships-between-SPDX-elements/).
+Note that the [binary SPDX document](spdx2.2/example3-bin.spdx) includes the `RUNTIME_DEPENDENCY_OF` relationship between the main binary and the library binary.
+There are many different dependency types of Relationships defined in [v2.2 of the SPDX spec](https://spdx.github.io/spdx-spec/v2.2.2/relationships-between-SPDX-elements/).
 We could have also used, e.g., `DEPENDENCY_OF` and/or `PREREQUISITE_FOR`.
 `RUNTIME_DEPENDENCY_OF` was chosen here because of the extra specificity that the library is 'required for the execution' of the main binary.
 

software/example4/README.md

@@ -29,7 +29,7 @@ According to `readelf`, the example4 binary `main` relies on two shared librarie
  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 ```
 
-In [`example4-bin.spdx`](spdx/example4-bin.spdx), we can create Package Information sections for each of `libdl` and `libc`.
+In [`example4-bin.spdx`](spdx2.2/example4-bin.spdx), we can create Package Information sections for each of `libdl` and `libc`.
 Keep in mind that these are _not_ files that are provided by the software distribution that the SPDX documents reflect: the `content/` directory does not contain libdl.so.2 or libc.so.6.
 Because they are not part of the software distribution that the SPDX document is primarily describing, there is _not_ a `DESCRIBES` relationship between the document and these shared libraries.
 

software/example6/README.md

@@ -15,9 +15,9 @@ The content is identical to [example5](../example5).
 Nothing has changed -- in fact, the comments still refer to "Example 5" -- for illustration purposes, so that the file hashes are identical to those in Example 5.
 
 The differences are in the SPDX documents.
-The [sources SPDX document](spdx/example6-src.spdx) is substantively identical to its Example 5 counterpart.
-However, we've introduced [a new (third) SPDX document](spdx/example6-lib.spdx), this one describing the Go distribution used to build the Hello World program, along with Packages describing a small portion of its contents.
-The [binary SPDX document](spdx/example6-bin.spdx) then includes Relationships describing how some portions of the Go distribution relate to the build results -- e.g., referencing the compiler used to build it, and the standard libraries that are incorporated into / statically linked with the binary.
+The [sources SPDX document](spdx2.2/example6-src.spdx) is substantively identical to its Example 5 counterpart.
+However, we've introduced [a new (third) SPDX document](spdx2.2/example6-lib.spdx), this one describing the Go distribution used to build the Hello World program, along with Packages describing a small portion of its contents.
+The [binary SPDX document](spdx2.2/example6-bin.spdx) then includes Relationships describing how some portions of the Go distribution relate to the build results -- e.g., referencing the compiler used to build it, and the standard libraries that are incorporated into / statically linked with the binary.
 
 ## Comments
 
@@ -35,18 +35,20 @@ This would enable the distributor's SPDX document to become a "single source of
 ### Package details
 
 In this example, I've also gone into greater detail about the Go distribution I used, to demonstrate some of the optional fields.
-These fields are fully documented in the [SPDX spec](https://spdx.github.io/spdx-spec/3-package-information/), but here are a few comments:
-* I compiled this example using a distribution of Go installed via a Ubuntu snap package. Because of that, the "PackageSupplier" (Canonical) is the immediate / most recent step in the distribution chain, but the "PackageOriginator" (Google) is the primary upstream project organization.
-* Even though I have the particular snap file and checksum, from a cursory review I wasn't able to determine a download location for the snap file, so `PackageDownloadLocation` is `NOASSERTION`.
-* `FilesAnalyzed: false`: We are not listing out all of the files from the distribution.
-* Some of the fields, like `PackageSourceInfo` and `PackageSummary`, are optional free-text fields. There are several others describe in the Package Information section of the SPDX spec.
+These fields are fully documented in the [SPDX spec](https://spdx.github.io/spdx-spec/v2.2.2/package-information/), but here are a few comments:
+
+- I compiled this example using a distribution of Go installed via a Ubuntu snap package. Because of that, the "PackageSupplier" (Canonical) is the immediate / most recent step in the distribution chain, but the "PackageOriginator" (Google) is the primary upstream project organization.
+- Even though I have the particular snap file and checksum, from a cursory review I wasn't able to determine a download location for the snap file, so `PackageDownloadLocation` is `NOASSERTION`.
+- `FilesAnalyzed: false`: We are not listing out all of the files from the distribution.
+- Some of the fields, like `PackageSourceInfo` and `PackageSummary`, are optional free-text fields. There are several others describe in the Package Information section of the SPDX spec.
 
 ### Libraries
 
 After defining the Go distribution as a Package, we then define a few other Packages that correspond to subcomponents of the Go distribution:
-* `SPDXRef-Package-go-compiler` refers to the `go` command.
-* `SPDXRef-Package-go.fmt` refers to the `fmt` standard library package.
-* There are also Packages defined for the `reflect` and `strconv` libraries as well.
+
+- `SPDXRef-Package-go-compiler` refers to the `go` command.
+- `SPDXRef-Package-go.fmt` refers to the `fmt` standard library package.
+- There are also Packages defined for the `reflect` and `strconv` libraries as well.
 
 Each of these Packages is then declared as being contained in the Go distribution via a `CONTAINS` Relationship.
 
@@ -71,7 +73,7 @@ That enables us to then create Relationships referring to the Go distribution's
 
 Our [original source file](content/src/hello.go) imports the `"fmt"` library.
 Because of that, the binaries document includes a `RUNTIME_DEPENDENCY_OF` Relationship.
-There are a variety of `*_DEPENDENCY_OF` [Relationship types](https://spdx.github.io/spdx-spec/7-relationships-between-SPDX-elements/), and the SPDX document creator may use any or all of them depending on their particular use case.
+There are a variety of `*_DEPENDENCY_OF` [Relationship types](https://spdx.github.io/spdx-spec/v2.2.2/relationships-between-SPDX-elements/), and the SPDX document creator may use any or all of them depending on their particular use case.
 Keep in mind that SPDX is a language, and just like a regular spoken language, multiple words might be usable in place of one another depending on the desired context or connotation.
 
 This SPDX document also lists a `STATIC_LINK` Relationship between the binary and the `fmt` library.

software/example7/README.md

@@ -27,10 +27,11 @@ This would also enable the supplier's SPDX document to become a "single source o
 ### Package details
 
 This example reflects the workflow of a golang developer. As such, there are some differences with example6:
-* The Golang binary is downloaded from Golang.org as per the website's instructions. Therefore, I assume the originator is "Golang.org". In this case I know the exact URL where I had downloaded the golang distribution from.
-* The external modules downloaded from `rsc.io` is less certain because go supports vanity import paths which redirect the network call to a VCS. Therefore `rsc.io` is not the canonical download location. I have used [pURL](https://github.com/package-url/purl-spec) to describe the download location.
-* `FilesAnalyzed: false`: Developers think in terms of modules and the final binary distribution. File level knowledge is only restricted to their module. Here, I do not include `go.mod`, `go.sum`, and `hello.go` in my `Package` definition.
-* Some of the fields, like `PackageSourceInfo` and `PackageSummary`, are optional free-text fields. There are several others describe in the Package Information section of the SPDX spec.
+
+- The Golang binary is downloaded from Golang.org as per the website's instructions. Therefore, I assume the originator is "Golang.org". In this case I know the exact URL where I had downloaded the golang distribution from.
+- The external modules downloaded from `rsc.io` is less certain because go supports vanity import paths which redirect the network call to a VCS. Therefore `rsc.io` is not the canonical download location. I have used [pURL](https://github.com/package-url/purl-spec) to describe the download location.
+- `FilesAnalyzed: false`: Developers think in terms of modules and the final binary distribution. File level knowledge is only restricted to their module. Here, I do not include `go.mod`, `go.sum`, and `hello.go` in my `Package` definition.
+- Some of the fields, like `PackageSourceInfo` and `PackageSummary`, are optional free-text fields. There are several others describe in the Package Information section of the SPDX spec.
 
 ### hello module
 

software/example8/README.md

@@ -44,4 +44,3 @@ A simple "Hello world" generated by the Maven quickstart archetype.
 ### Third party libraries
 
 There is one direct runtime dependency, Apache Log4j SLF4J Binding, and one direct test dependency, JUNIT.
-

software/example9/README.md

@@ -7,5 +7,3 @@ This is a copy of the [App-BOM-ination SPDX example](https://github.com/yevster/
 This is a particulary challenging SPDX example in that it contains several unique relationships.
 
 Note: If you disagree with the SPDX document produced - be sure to add an issue to this repo!
-
-