Open Source licenses play the crucial role of enabling collaboration, innovation, and transparency in the world of software development. As the software supply chains are becoming more complex by the day, it becomes increasingly essential to start building visibility into the components and licenses of the software being used. This is where the Software Bill of Materials (SBOM) comes in. SBOMs enable organizations to identify vulnerabilities, track open-source usage, and ensure compliance with numerous licensing obligations.
Open Source licenses define the terms and conditions under which software can be used, modified, and distributed. When considering Open Source components for software, understanding and inventorying licenses associated with those components must play a key part in the selection criteria. Different licenses have varying requirements and restrictions. Permissive licenses like MIT and BSD allow for more flexibility, while copyleft licenses like GPL impose stricter obligations, such as sharing modifications under the same license.
Including Open Source licenses in SBOM helps organizations accurately track the licenses associated with their software components. This creates a more open, manageable, and scalable path for managing license risks and obligations.
1. Ensuring compliance with Open Source licenses: By including licenses in SBOM, organizations can easily keep an inventory of the licenses of the components used in their software projects. This helps ensure compliance with the licenses' terms and conditions, avoiding any legal ramifications or delays in the sales and M&A.
2. Mitigating legal risks: Failure to comply with Open Source licenses can result in legal disputes and potential loss of intellectual property rights. Including licenses in SBOM allows organizations to proactively address any licensing issues and mitigate legal risks associated with Open Source usage.
3. Promoting transparency and trust: Open Source licenses in SBOM foster transparency and trust within software supply chains. By openly declaring the licenses, organizations demonstrate their commitment to complying with licensing obligations and build trust with users, customers, and the broader Open Source community.
CycloneDX and SPDX — two of the three most commonly used and NTIA-recommended SBOM specifications — provide precise and easy-to-implement license details in an SBOM.
The SPDX License List is a list of the most commonly used licenses in open-source software and components, extensions of these licenses, and exceptions to them. As of version 3.20, the list includes 506 licenses and derivatives. The SPDX License list is a crucial part of the SPDX SBOM Specification. The list can be used to form larger license-expression by following these rules:
The license-expression forms the backbone of declaring licenses, such as declaring licenses for Packages by the authors of the package. (e.g.
PackageLicenseDeclared: (LGPL-2.0-only AND LicenseRef-3)and governing licenses as concluded by the authors (e.g.
PackageLicenseConcluded: (LGPL-2.0-only OR LicenseRef-3)in addition to providing any comment or analysis as the background information. (e.g.
PackageLicenseComments: <text>The license for this project changed withthe release of version 1.4. The version of the project included herepost-dates the license change.</text>CycloneDX SBOM Specification also uses the SPDX License list and SPDX license-expression and also provides fields to populate links to license text. (e.g.
While specifications have described license declaration in a methodical way, implementation in SBOM generators has lacked the same rigor. This has led to some challenges:
1. Absent Licenses: The absence of license fields from the SBOM is the most common challenge. While it is accurate that CycloneDX and SPDX have kept License fields optional (for broader use cases), NTIA Minimum Elements for a SBOM has recommended the inclusion of licenses to make them useful.
2. Invalid Default: SDPX has provided two defaults : NONE for when no license applies and NOASSERTION for when license discovery was not attempted, or the license is intentionally not included in the document. However, a number of invalid defaults — EMPTY, NULL, NOLICENSE, UNKNOWN can be found in SBOM generated by various tools. This challenges the SBOM consumption tools.
3. Invalid License-References: An SPDX simple license-expression can include a user-defined license reference. However, to make this useful for the SBOM consumption tool, this indirection requires: (a) a valid license-reference id and (b) an accurate description of the license reference itself. At Interlynk, we see various errors in such license expressions, including (a) Invalid characters in license references, (b) dangling license references, (c) non-terminating license references, (d) License-reference for external documents without providing the external documents themselves.
4. Invalid License Expressions: Including licenses in the ABNF referenced above is the only sure way of ensuring automated processes can parse SBOM accurately and extract the licensing information. However, we have noticed very little adherence to sticking to the ABNF and instead relying on various short-hands that make licenses easy to read by humans (and therefore getting presumption of accuracy) while causing errors for consumption tools. Examples of invalid license expressions include:
PackageDeclaredLicense: MIT, LGPLv2, BSDPackageConcludedLicense: [MIT, LGPLv2, BSD]PackageConcludedLicense: [MIT, LGPLv2, BSD]LicenseID: MIT/LGPLv2To overcome these challenges, it is crucial to pre-process SBOM with quality (e.g., sbomqs) or data extract tools (e.g., sbomgr) to understand the accuracy and completeness of the underlying SBOM and the maturity of the SBOM generator.
1. Establish a clear policy for managing Open Source licenses within your organization. This includes defining acceptable licenses, conducting regular license reviews, and educating developers about license obligations.
2. Conduct regular license audits and scans: Regularly audit your software projects to ensure compliance with Open Source licenses. Utilize scanning tools that can automatically identify and report the licenses associated with your software components.
3. Utilize tools and automation: Leverage software composition analysis (SCA) tools that can automatically generate SBOMs and provide insights into license compliance. These tools can help streamline the process and ensure accuracy in managing Open Source licenses.
4. Engage legal expertise: In complex licensing scenarios, consider involving legal expertise to navigate any potential legal challenges. Legal professionals can provide guidance on license compatibility and obligations and help resolve any licensing issues that may arise.
As Open Source and SBOM practices continue to evolve, staying informed about future trends and developments is essential. Efforts are underway to standardize SBOM formats, enabling easier sharing and interoperability across different software ecosystems. Regulatory requirements related to software supply chain transparency are also emerging, emphasizing the need for comprehensive SBOMs and Open Source license management.
Open Source licenses in Software Bill of Materials (SBOM) ensure compliance, mitigate legal risks, and promote transparency in software supply chains. By including Open Source licenses in SBOM, organizations can effectively manage their software components, address licensing obligations, and build trust with stakeholders. Stay vigilant, adopt best practices, and embrace the evolving landscape of Open Source licensing to successfully navigate the complexities of software development.
