Domain Concepts

OCSA is a decision-support instrument for a human reviewer, not an automated compliance authority. Every output is framed as triage that a qualified engineer — and ultimately legal counsel — confirms. Understanding these eight concepts is enough to read any result.

Concept	Definition	Why it matters
Component	A package in the SBOM with a resolved effective license	The unit of assessment
Effective license	licenseConcluded → licenseDeclared → licenseInfoFromFiles → NOASSERTION	Suppliers populate these inconsistently; the fallback chain is what makes real SBOMs usable
Distributed unit	The shipped artefact (executable, ECU image); an SBOM root	Copyleft attaches to the shipped work, not to a repository
Linkage	static / dynamic / unknown / dev / optional	The single biggest determinant of a copyleft outcome
Taint	Ancestor-of-copyleft marker	Shows reachability, which is what makes a risk real or theoretical
Obligation	A concrete action: disclose source, provide relinking, include notice	The actual deliverable of compliance work
Finding	Rule + severity + evidence + obligation + action	The audit artefact
Identity	purl minus version, else lowercased name	Without it, a version bump looks like a removal plus an addition

The mental model

The graph view exists to make this picture instantly legible: red nodes are strong copyleft, red edges are static links, and a red ring means this is reachable from copyleft.

Effective license resolution

Suppliers populate license fields inconsistently. Some fill only licenseDeclared, some only licenseInfoFromFiles, and a depressing number fill NOASSERTION everywhere. A tool that demanded licenseConcluded would reject most real input; a tool that ignored the distinction would lose the information about how confident the verdict is.

Recording which field was used (licenseSource) is what makes the result auditable. A finding derived from licenseInfoFromFiles is weaker evidence than one derived from licenseConcluded, and the detail panel shows which.

The final guard encodes ADR-009: a LicenseRef- whose text was supplied in hasExtractedLicensingInfos is resolved for copyleft purposes. It stays UNKNOWN tier, because a human should look at it, but it does not raise the LIC-003 blocker — otherwise every proprietary component in the BOM would produce a HIGH finding and bury the real ones.

Linkage classification

Each dependency edge is classified from the SPDX relationship type:

SPDX relationship	Linkage	Dev	Optional
STATIC_LINK	static	no	no
DYNAMIC_LINK	dynamic	no	no
DEPENDS_ON, CONTAINS, HAS_PREREQUISITE	unknown	no	no
DEV_DEPENDENCY_OF, BUILD_DEPENDENCY_OF, TEST_DEPENDENCY_OF	unknown	yes	no
OPTIONAL_DEPENDENCY_OF, PROVIDED_DEPENDENCY_OF	unknown	no	yes

Duplicate edges between the same pair collapse, preferring an explicit STATIC_LINK or DYNAMIC_LINK over a bare DEPENDS_ON.

:::caution The conservative default DEPENDS_ON carries no linkage information, and OCSA treats it as static. In automotive firmware, linking is overwhelmingly static; assuming dynamic would systematically under-report the most common real-world violation. Every finding raised on this path states "linkage not declared", so the supplier can correct it and the finding disappears. Over-reporting with a visible, correctable reason is the right trade for a compliance gate. :::

Identity

identityKey(c) is the purl with the version stripped — pkg:generic/qt@6.5.3 becomes pkg:generic/qt — falling back to name:<lowercased name>.

This single detail prevents a version bump from appearing as a removal plus an addition, and it is what makes the license-change comparison possible at all. Findings are matched on rule | component | title rather than ID, because IDs embed SPDXIDs that suppliers regenerate between releases.

Next

• License tiers — how an expression becomes a tier.
• Finding rules — the eight rules and what triggers them.
• Risk scoring — how the 0–100 number is computed.