It seems that currently only the tag / value format is supported as an output format. Could we get native (i.e. without the need to rely on external conversion tools) support for the arguabley more readable YAML / JSON representation of SPDX?

It is admittedly a bit hard to follow in the spec, but my reading is the external document references must use SHA1.

This is based on section 2.6 subsection 2.6.4:

[Checksum] is a checksum of the external document following the checksum

format defined in section 4.4.

In section 4.4 subsection 4.4.3:

4.4.3 Cardinality: Mandatory, one SHA1, others may be optionally provided.

Currently, cmake-spdx can determine:

• a source code file's license (if it has an SPDX-License-Identifier: tag); and
• which source code file(s) are built into a binary file (to the extent that the CMake file API response contains that info).

It would be interesting to explore whether this can be used to auto-conclude the binary file's license -- in other words, to fill in LicenseConcluded with some value other than NOASSERTION.

The most obvious approach would be to simply AND together the licenses of all the source files and/or libraries that are used as inputs. So, for instance, if a binary has four source file inputs, three of which contain Apache-2.0 licenses and the other containing ISC, then cmake-spdx could follow the relationships to determine that those are the four files used to create the binary, and then conclude the binary's license as Apache-2.0 AND ISC.

After #1 is merged, and before sharing the links back with the Zephyr Slack channel, update the README and add a better writeup explaining:

• process for building with CMake file API / running cmake-spdx
• outputs created (also add sample sources.spdx and build.spdx to examples directory)
• what is included now
• what still needs to be improved
• consider also adding graphviz sample image to examples directory
• interesting results (e.g. invalid SPDX doc b/c module identifiers, with links to incorrect ones)

Currently, cmake-spdx makes some incorrect assumptions about how the source files will be structured:

• it assumes that all relevant source files are contained within one top-level directory
• it requires that the user specify what that top-level directory is
• it assumes that relative paths within the CMake file API responses will be relative to that top-level directory

The CMake file API response does contain an initial "source" directory response in the codemodel object, see for example:

The problem is that this points to the sources of the specific application being built, not to the main zephyr directory itself. So this can't be used as the top-level directory for treating all the relevant sources as a single Package in SPDX terminology.

Most likely, the more correct way to do this will be something like the following:

• use the CMake codemodel's directories, projects and targets data to represent the sources more correctly as a collection of multiple Packages, rather than as a single Package
• when walking through the source files, appropriately include them in the Package (or even multiple Packages) that contain them, taking into account the potential for different relative paths in the CMake file API responses depending on the context

This will lead to a more flexible process and more correct SPDX document, which will also require less user guidance (as it should be driven entirely from the CMake file API responses). However, it will likely add significant complexity to the process of scanning the sources and creating the sources SPDX document, so I haven't started on an approach to this for the initial proof of concept.

In SPDX 2.2 documents, the field FileType can optionally be filled in with one (or more) entries indicating the file's type, using a small number of broad categories: see https://spdx.github.io/spdx-spec/4-file-information/#43-file-type

cmake-spdx should ideally fill in this value where it can be determined. For many files it may be determinable based on file extension.