In an SPDX SBOM, what is the difference between NOASSERTION and NONE in a license field?

## The problem SPDX is solving An SBOM is a claim made by one party and read by another. If a field is simply missing, the reader cannot tell whether the producer looked and found nothing, looked and could not decide, or never looked at all. Those three states have completely different consequences downstream, so SPDX refuses to let a blank stand in for any of them. Many SPDX fields are mandatory, and where the real answer is unavailable the producer must say so explicitly using one of two reserved values. ## The two values **`NONE`** is an assertion of absence. It says: I examined this, and the thing you are asking about does not exist here. In a license field, `NONE` means the producer determined that there is no licensing information present in the package. **`NOASSERTION`** is a refusal to assert. It says: I am not making a claim. It covers several real situations that the format deliberately does not distinguish between: the producer had no efficient way to determine the value, the analysis was inconclusive, the producer chose not to state it, or the value simply was not collected. The distinction is the difference between *nothing is there* and *I am not telling you what is there*, and conflating them is the classic first-week mistake with SPDX. ## Where the values show up Licensing is the field where people meet these values first, and SPDX splits licensing into two questions: - **`PackageLicenseDeclared`** — what the package itself declares, for example in its own metadata. - **`PackageLicenseConcluded`** — what the producer of the SBOM concludes after analysis, which may differ from the declaration. A generator that only reads package metadata typically emits a declared value and `NOASSERTION` for the concluded value, because concluding requires human or tool analysis it did not perform. That is honest behaviour, not a bug, and reading it as *unlicensed* is wrong. The same reserved values appear in supplier, originator, download-location and copyright-text fields, which is why they are best understood as a general grammar for uncertainty rather than a licensing quirk. There is also a related completeness signal: a package can be marked as having had its files analysed or not, and a package whose files were never analysed cannot honestly carry file-level conclusions. ## How CycloneDX handles the same situation CycloneDX takes the opposite approach: most fields are optional, so unknown values are usually expressed by omitting the field. That is more compact but genuinely more ambiguous, because absence collapses *unknown*, *not collected* and *not applicable* into one state. CycloneDX addresses completeness at the document level instead, with a compositions construct that lets a producer declare how complete an assembly or dependency listing is, including that it is incomplete or unknown. This asymmetry matters the moment documents move between the formats. Converting SPDX to CycloneDX naively turns `NOASSERTION` into a missing field, which reads as ordinary optional-field absence and loses the fact that the producer explicitly declined to assert. Converting CycloneDX to SPDX has the mirror problem: the converter must fill mandatory fields for values that were merely absent, and the only honest filler is `NOASSERTION` — which is correct, but means the SPDX document now looks emptier than the original felt. ## Reading a BOM in practice Treat `NOASSERTION` as a quality measurement of the document, not as a property of the software. Useful habits: - Count `NOASSERTION` occurrences per field and per package; a supplier BOM that is 90% placeholders has not been produced from real evidence. - Never let *no disallowed value found* be reported as *no risk found* when the underlying fields are unasserted. That converts document incompleteness into a green light. - Ask the supplier which fields they intend to assert, rather than which values they intend to send. Getting a supplier to move a field from `NOASSERTION` to a real value is a concrete, checkable ask. ## Why interviewers ask it The NTIA minimum elements for an SBOM name a small set of baseline data fields — supplier name, component name, component version, other unique identifiers, dependency relationship, author of the SBOM data, and a timestamp — and the whole point of a baseline is that the fields are *stated*. A candidate who knows that SPDX makes the unknown explicit, and that the explicit unknown is not a pass, is reading SBOMs as documents with provenance rather than as inventories that happen to be machine-readable.