What Maintainers need to know about Open Source Licensing, SBOMs and Security

Key Concepts

• SBOM (Software Bill of Materials): An inventory of all software components, versions, and licenses within a project.
• License Compliance: The legal obligation to adhere to the terms of open-source licenses (attribution, copyleft, etc.).
• Transitive Dependencies: Dependencies of your dependencies; often hidden but legally and security-wise your responsibility.
• Copyleft vs. Attribution: Attribution licenses (MIT, Apache) require credit; Copyleft (GPL, AGPL) may require sharing your source code.
• VEX (Vulnerability Exploitability eXchange): A document used to explain why a specific vulnerability (CVE) does not affect your project.
• SPDX & CycloneDX: The two primary industry-standard formats for generating SBOMs.

---

1. The Importance of SBOMs and Legal Context

As global legislation (e.g., the EU Cyber Resiliency Act) increases, organizations are under pressure to know exactly what is inside their software. While maintainers may not be legally required to provide an SBOM, their users—often large companies—are. Providing an SBOM proactively helps maintainers avoid "panic emails" from users and improves the overall security of the software supply chain.

• The "Food Label" Metaphor: An SBOM is essentially a nutrition label for software, listing components, versions, and licenses.
• Legal Pillar: Copyright law dictates that you must have permission to use code. Open-source licenses act as a pre-granted permission slip, provided you follow the obligations (e.g., attribution).

2. License Types and Policies

Maintainers should categorize dependencies into a "License Policy" to determine what is acceptable for their project.

• Attribution (MIT, BSD, Apache): The most common (80-90%). Requires giving credit and passing along license text.
• Copyleft (GPL, LGPL, MPL): Requires sharing source code if you distribute the software.
• Network Copyleft (AGPL): Specifically targets Software-as-a-Service (SaaS) models, requiring source disclosure even if the software isn't "distributed" in the traditional sense.
• Source Available/Proprietary: Often contain usage restrictions (e.g., no commercial use). These should be avoided in open-source projects unless explicitly intended.

3. Step-by-Step: Managing Dependencies and Compliance

• Selection Time: Review licenses and security status before adding a dependency. Check for "dead" projects (no updates in years).
• Review Time: Periodically scan the entire dependency tree (including transitive dependencies) to ensure no incompatible licenses or vulnerabilities have crept in.
• Remediation Strategies:
  1. Replace: Swap the problematic dependency for a compliant one.
  2. Remove: Delete the functionality that relies on the problematic code.
  3. Re-license: If possible, change your project's license to match the dependency (rarely recommended).
  4. Isolate: Use separate processes or linking strategies to prevent "viral" license contamination (requires legal expertise).

4. Technical Best Practices

• Automation: Use CI/CD pipelines to generate SBOMs and license notices automatically for every release.
• License Notices: An SBOM is not a substitute for a license notice. You must still provide the full license text and copyright statements (e.g., in an "About" box or a third-party-notices.txt file).
• Handling Transitive Dependencies: If a transitive dependency has a restrictive license (e.g., GPL 3.0), you are responsible for it. Use multiple scanners to uncover these hidden components.
• Inbound = Outbound: Ensure your CONTRIBUTING.md clarifies that contributions are licensed under the same terms as your project to avoid future legal hurdles.

5. Notable Quotes

• "If you don't know who wrote it, if you don't know what the permissions are for you to use it, it shouldn't be ending up in your repository."
• "Another name for transitive dependency is just dependency. You depend on it... you have to respect the license obligations that come along with the use of that library."

6. Data and Tools

• GitHub Insights: Use the "Dependency Graph" tab to export an SBOM (SPDX 2.3).
• ClearlyDefined (clearlydefined.io): A resource to help fix or clarify incorrect license metadata.
• Vulnerability Scoring: Be aware of CVEs (Common Vulnerabilities and Exposures), CVSS (severity score), and EPSS (exploit prediction score).

7. Synthesis/Conclusion

The shift toward transparency in software is inevitable. Maintainers should treat license compliance and security as core development tasks rather than afterthoughts. By establishing a clear license policy, automating SBOM generation, and performing regular dependency audits, maintainers protect both their users and their own projects from legal and security risks. The goal is to create a "clean" dependency tree that is easy for downstream users to adopt and trust.