Open Source License Governance

Why License Governance Matters

Using open source without tracking licenses is like using cloud services without tracking costs. It works fine until it does not. A single AGPL dependency in your SaaS product could legally require you to release your entire source code. An unlicensed dependency means you technically have no right to use it. Companies have received cease-and-desist letters, faced lawsuits, and had acquisitions complicated by license compliance failures. The risk is real and the fix is straightforward: know what you ship.

License Categories

Permissive licenses (MIT, BSD-2-Clause, BSD-3-Clause, Apache 2.0, ISC) let you do almost anything. Include the license text when you distribute the software. Apache 2.0 adds an explicit patent grant, which is why many enterprises prefer it.

Weak copyleft (LGPL, MPL 2.0, EPL) requires changes to the licensed component itself to be shared under the same license, but code that merely links to or uses the component is not affected. This is manageable for most projects.

Strong copyleft (GPL, AGPL) requires any derivative work to be distributed under the same license. GPL triggers on distribution. AGPL triggers when users interact with the software over a network. For SaaS companies, AGPL is essentially a ban unless you want to open-source your product.

Source-available (BSL, SSPL, Elastic License 2.0) looks like open source but restricts commercial or competitive use. These are not OSI-approved open source licenses. Treat them as proprietary for governance purposes.

Tooling and Automation

Software Composition Analysis (SCA) tools scan your dependency tree and flag license issues:

• FOSSA and Snyk Open Source integrate with CI pipelines and provide license policy enforcement
• Mend (formerly WhiteSource) offers detailed license compatibility analysis
• Scancode-toolkit is a free, open-source option for license detection
• Syft and Trivy generate SBOMs in CycloneDX and SPDX formats

Set up a license allow-list in your CI pipeline. Block builds that introduce dependencies with licenses your legal team has not approved. Common allow-lists include MIT, Apache 2.0, BSD variants, ISC, and MPL 2.0. Common block-lists include AGPL, GPL (for proprietary products), SSPL, and unlicensed packages.

SBOM Requirements

Executive Order 14028 (May 2021) requires software vendors selling to the US federal government to provide SBOMs. NTIA minimum elements define what an SBOM must contain: supplier name, component name, version, dependency relationship, and timestamp. Generate SBOMs automatically during your build process using CycloneDX or SPDX format. Attach them to release artifacts. This is headed toward becoming a standard customer requirement, not just a federal one.

Contribution Policies

If your engineers contribute to open source projects, you need a contribution policy. It should cover CLA (Contributor License Agreement) requirements, which projects are approved for contribution, and IP review for substantial contributions. Many companies use a lightweight approval process: contributions to permissively-licensed projects under a certain size are auto-approved, while larger contributions or contributions to copyleft projects require legal review.