An open source licence is a binding grant that tells you exactly what you may do with someone else's code — use it, modify it, redistribute it — and what you owe in return, and ignoring those terms exposes a project to both legal and operational risk. The licence open source projects attach to their code is not decoration; it is the contract that governs whether you can legally ship the dependency you just pulled into your build. Most teams pull hundreds of them without reading a single one.
That gap matters because obligations propagate. A single strongly-copyleft library buried three levels deep in your dependency graph can, in principle, impose source-disclosure requirements on the code you consider proprietary. You cannot manage what you have never inventoried.
The three families of open source licence
Nearly every open source licence falls into one of three buckets, and knowing which bucket a dependency sits in tells you most of what you need.
Permissive licences — MIT, BSD (2-clause and 3-clause), and Apache 2.0 — let you do almost anything as long as you preserve the copyright notice and licence text. You can use the code in closed-source commercial products without disclosing your own source. Apache 2.0 adds an explicit patent grant, which is why many companies prefer it over MIT for anything patent-sensitive. These are the licences you rarely have to think hard about, though "preserve the notice" is a real obligation that automated distribution pipelines frequently drop.
Strong copyleft licences — GPL-2.0 and GPL-3.0 — require that if you distribute software incorporating the licensed code, you distribute your corresponding source under the same terms. The reciprocity is the whole point: it keeps derivative works open. For a company shipping proprietary binaries, a GPL dependency in the distributed artifact is a serious question, not a shrug. GPL-3.0 also adds anti-tivoization and patent-retaliation clauses that GPL-2.0 lacks.
Weak copyleft licences — LGPL, MPL-2.0, and EPL — split the difference. They require you to share modifications to the licensed files themselves but let you link to the library from proprietary code without opening your whole application. MPL-2.0 operates at the file level, which is often the most business-friendly copyleft option: change their files, share those; your own files stay yours.
The AGPL and the network-use trap
The GNU Affero General Public License (AGPL-3.0) deserves its own mention because it closes what copyleft advocates call the "SaaS loophole." Ordinary GPL obligations trigger on distribution — shipping a binary to someone. If you run GPL software as a hosted service and never hand out the binary, distribution never happens, so source-disclosure never triggers.
AGPL changes that. If users interact with AGPL-licensed software over a network, you must offer them the corresponding source. For any company running a web service, an AGPL dependency in the serving path is a genuine decision point, not a formality. This is why some organizations maintain an outright deny-list for AGPL in production services. Whatever your policy, the point is to have one and enforce it before the code lands, not after legal discovers it during due diligence.
Why licence compliance is a security problem, not only a legal one
It is tempting to hand licence questions to legal and move on, but the mechanics overlap almost entirely with supply-chain security. Both depend on the same foundational artifact: an accurate, complete inventory of every component in your software, including transitive dependencies you never chose directly.
That inventory is a software bill of materials (SBOM). The same SBOM that lets you answer "am I affected by this new CVE?" also lets you answer "do I have a GPL dependency in a product I distribute?" You generate it once and query it for both purposes. Teams that already run software composition analysis for vulnerabilities usually get licence detection in the same pass, since the tool is already resolving and identifying every package.
The failure mode is identical too. A licence obligation you cannot see is one you cannot honor, exactly like a vulnerability you cannot see is one you cannot patch. An SCA tool such as Safeguard surfaces both the CVE and the declared licence for every resolved package, including the ones several layers deep that manual review always misses.
Practical policy that developers will actually follow
A licence policy nobody reads is worse than none, because it creates false confidence. Keep it short and enforceable.
Start with a tiered allow/review/deny structure. Permissive licences (MIT, BSD, Apache-2.0, ISC) go on the allow list — no review needed. Weak copyleft (LGPL, MPL-2.0) goes on the review list — allowed for most uses, flagged for a quick check on how it is linked. Strong copyleft and network copyleft (GPL, AGPL) go on the deny list for anything you distribute or host, with an exception process for the rare justified case.
Enforce it in CI, not in a wiki. A build step that reads the SBOM and fails when a new dependency introduces a deny-list licence catches the problem at the pull request, when changing it costs minutes, instead of at a security review before a funding round, when it costs weeks. Pair that gate with an automatically generated attribution file (the NOTICE or third-party licences document) so you satisfy the notice-preservation obligation that even permissive licences impose.
One more discipline: watch for licence changes. Projects relicense. A dependency that was Apache-2.0 when you adopted it can move to a source-available or copyleft licence in a later release, as several high-profile infrastructure projects did between 2021 and 2024. Your CI check should compare the licence of the resolved version, not the licence you recorded when you first added the package.
Dual licensing and "source-available" confusion
Two more cases trip teams up. Some projects offer dual licensing — GPL for open use and a paid commercial licence for proprietary use. If you rely on the open path, you inherit the copyleft obligations; if you want to avoid them, you buy the commercial licence. Both are legitimate; the mistake is using the code as if it were permissive.
The other is source-available licences such as the Business Source License (BSL) or the Server Side Public License (SSPL). These let you read and often modify the source but restrict commercial or competing use, and they are not OSI-approved open source. Treat them as their own category in your policy. Calling them "open source" in a customer contract when they are not can create representations you cannot back up.
FAQ
What is the safest open source licence to depend on?
For proprietary products, permissive licences — MIT, BSD, and Apache-2.0 — carry the fewest obligations; you preserve notices and can ship closed-source. Apache-2.0 additionally includes an explicit patent grant, which many organizations prefer for anything patent-sensitive.
Does using a GPL library force me to open source my whole application?
Only if you distribute software that incorporates it, and the scope depends on how the code is combined. Strong copyleft (GPL) reaches distributed derivative works; weak copyleft (LGPL, MPL) is narrower. If you only run the software as a hosted service, ordinary GPL usually does not trigger — but AGPL does.
How do I find every open source licence in my project?
Generate a software bill of materials with an SCA tool that resolves transitive dependencies. Manual inspection of top-level dependencies misses the licences buried deep in the graph, which is exactly where the risky ones tend to hide.
Are source-available licences like BSL and SSPL open source?
No. They restrict commercial or competing use and are not OSI-approved. Track them as a separate policy category and avoid describing them as open source in contracts or documentation.