Intro
In September 2021, Forrester published Software Composition Analysis, Q3 2021 providing a Software Composition Analysis (“SCA”) overview, particularly open source software (“OSS”) vulnerability and licensing analysis, and occasionally referring to Software Bills of Materials (“SBOMs”). Although some overlap between SBOMs and OSS license compliance exists, the two are not the same. The remainder of this post differentiates the two.

OSS License Compliance
As explained in Top OSS Licensing Issues: Part 1, OSS components are copyrighted works with usage terms defined in their licenses. In our Open Source Compliance & SBOM overview, OSS compliance presents “external” and “internal” factors, the former generally referring to license term adherence and the latter organizational policy (e.g., license type restrictions and copyright owner identification). Regardless, both categories are within the purview of legal, compliance, and risk considerations.

SBOMs
Succinctly, an SBOM enumerates the composition of an application, normally including certain licensing attributes, but is distinct from license compliance. For example, SPDX (Software Package Data Exchange; ISO/IEC 5962:2021) provides an SBOM standard, including licensing attributes, but ultimately covers software composition and not software licensing compliance, OSS or otherwise .

SBOMs Don’t Satisfy OSS License Compliance (and vice-versa)
Since an SBOM is an inventorying exercise and OSS compliance is a legal and policy exercise, even a comprehensive SPDX enumeration will not represent the state of the app’s license compliance and thus why potential conflation should be avoided.

The SPDX standard is fairly lengthy, but suffice to say its rationale is to “create a set of data exchange standards that enable companies and organizations to share human-readable and machine-processable software package metadata to facilitate software supply chain processes.”. More directly, SPDX scopes-out “[l]egal interpretation of the licenses or any compliance actions that have been or may need to be taken.” [emphasis added].

Lastly, SBOM format alternatives to SPDX are available, as are numerous tools to produce an SBOM. However, while SBOMs are quite valuable (and, in some cases, required), they neither identify, nor recommend potential remediation for, problematic licensing; this is a distinct effort covering quite different subject matter.

Final Thoughts
Software supply chain protection, accountability, and normalization requirements have increased markedly in 2021. Factors include cyber attacks, EO 14028’s SBOM requirements in the U.S., and organizations simply not knowing their software compliance risk level.

Sector 7G’s extensive OSS legal and technical experience uniquely suits its clients to understand the license compliance and SBOM landscapes for determining license risk and remediation and asset composition. We know that code vulnerability assessment is fundamentally different than OSS license compliance review and that SBOMs and license compliance similarly are not the same. But we’re fluent in all three.

DISCLAIMER
Sector 7G Consulting LLC (“Sector 7G”) does not provide, nor should anything from Sector 7G be construed as, legal advice nor the establishment of legal representation or attorney-client privilege. Additionally, Sector 7G strongly encourages review of all licensing with legal counsel.