The "Approved List" Policy
You cannot expect every developer to be a lawyer. Companies implement structured policies and automated tooling to make license compliance a guardrail, not a manual review process.
1. The Green List (Pre-Approved):
MIT, Apache 2.0, BSD-2-Clause, BSD-3-Clause, ISC, Unlicense.
Developers can use these without asking anyone. The build pipeline allows them through automatically.
2. The Yellow List (Requires Review):
LGPL, MPL (Mozilla Public License), CDDL.
These have conditions that may or may not apply depending on how the library is used. A legal or architecture review is required before use.
3. The Red List (Banned):
AGPL, GPL (for shipped products), SSPL, BUSL (Business Source License), WTFPL (too legally ambiguous).
Developers need VP-level or legal approval to use these. In practice, the answer is almost always "no" for any code that ships to customers.
2. Automated Scanning — Software Composition Analysis (SCA):
Manual review of licenses doesn't scale. A modern Node.js project can have 800+ transitive dependencies. You need automation.
SCA tools (Snyk, FOSSA, Black Duck, Trivy) scan your dependency tree — not just your direct dependencies, but every package those packages depend on — and report the license of each one. Configured as a CI pipeline gate, scoped to flag Red List licenses like AGPL and GPL as high-severity findings and set to fail the build outright, the scanner checks every manifest file across the dependency tree, identifies the license of every package, and blocks the merge if a banned license shows up anywhere in it. This turns license compliance from a quarterly audit into a continuous, automated check.
3. The "Dual License" and "License Change" Trap:
Be careful of projects that change their license after you've adopted them. This has happened repeatedly:
- MongoDB switched from AGPL to SSPL (Server Side Public License) in 2018. SSPL is even more restrictive than AGPL — it requires you to open-source not just your application but your entire service infrastructure if you offer the software as a service.
- Redis added the Commons Clause to its license, then later switched to a dual RSALv2/SSPLv1 license, preventing cloud providers from selling Redis as a managed service.
- Elasticsearch moved from Apache 2.0 to SSPL/Elastic License in 2021.
- HashiCorp (Terraform, Vault) switched from MPL 2.0 to BUSL (Business Source License) in 2023, which prohibits competing commercial use.
SSPL and BUSL are not OSI-approved open-source licenses. They are "source available" licenses — you can read the code, but your usage rights are restricted in ways that traditional open-source licenses do not permit. When a project you depend on changes its license, you must re-evaluate whether your use case is still permitted.
Interviewers at companies with large open-source footprints sometimes ask: "How would you handle a situation where a critical dependency changes its license to something incompatible with your business?" Strong answer: "First, assess whether our current use case is actually affected — sometimes the new license only restricts competing SaaS offerings. If we are affected, we have three options: negotiate a commercial license with the vendor, fork the project at the last permissive version and maintain it internally, or find and migrate to an alternative. The HashiCorp/Terraform situation is a real example — OpenTofu was created as a community fork of Terraform at the last MPL 2.0 version specifically because of this scenario."