OSS licenses are the legal terms that grant you the right to use, modify, and distribute open-source software, and understanding them is a compliance requirement rather than a formality, because using a dependency in violation of its license exposes your organization to legal action, forced code disclosure, and blocked acquisitions. Because a modern application pulls in hundreds of open-source packages, each with its own license, tracking OSS licenses is a scale problem you cannot solve by reading terms one at a time. This guide covers the license families, the obligations that matter, and how to automate compliance.
The core misconception worth clearing up first: open source does not mean "no rules." Every open-source component carries a license, and that license is a contract. "It's on GitHub" grants you nothing by itself. Absent a license, default copyright applies and you have no right to use the code at all.
The two big families: permissive and copyleft
OSS licenses split into two broad camps, and the distinction drives almost every compliance decision.
Permissive licenses let you do nearly anything, including using the code in closed-source, commercial products, as long as you preserve the copyright notice and license text. The common ones are MIT, BSD (2-clause and 3-clause), and Apache 2.0. Apache 2.0 adds an explicit patent grant, which is why many organizations prefer it over MIT for anything patent-sensitive. Permissive licenses are the low-friction default for most commercial software.
Copyleft licenses require that derivative works be released under the same license. The strong form, the GPL (GPLv2, GPLv3), says that if you distribute software that incorporates GPL code, you must make your combined work's source available under the GPL too. That is the "viral" property people worry about: link a GPL library into your proprietary product and distribute it, and you may be obligated to open-source your own code.
Between the extremes sit weak-copyleft licenses like the LGPL and MPL 2.0. These apply the copyleft obligation at the file or library boundary rather than the whole program, so you can typically use an LGPL library in a proprietary app as long as you keep that library replaceable and share modifications to the library itself.
The AGPL deserves special mention because it closes the "network use" gap in the GPL: if you run modified AGPL code as a network service, you must offer users the source, even though you never "distributed" a binary. Many companies ban AGPL dependencies outright for this reason.
Obligations that trip teams up
Even permissive licenses carry obligations, and they are easy to overlook:
- Attribution. MIT, BSD, and Apache all require you to include the copyright notice and license text in your distribution. A common failure is shipping a compiled app or container without the accumulated notices of everything inside it.
- Notice of changes. Apache 2.0 asks you to state that you modified files if you did.
- Copyleft source disclosure. GPL and AGPL can require you to provide complete corresponding source, on request or to users.
- Patent and trademark terms. Some licenses grant patent rights and revoke them if you sue; trademarks are usually not licensed at all.
The obligations attach at distribution. Using open source purely internally triggers fewer of them than shipping a product to customers, and shipping a network service sits in between. Map your actual use before deciding a license is a problem.
License compatibility
A subtler risk than any single license is combining incompatible ones. You cannot always mix licenses freely in one distributed work. The classic conflict is GPLv2-only code combined with Apache 2.0 code, which the Free Software Foundation considers incompatible. Combine them in a distributed binary and there is no license under which you can legally ship the result.
Compatibility flows in a direction: permissive code can generally be pulled into a copyleft project, but copyleft code cannot be pulled into a permissive-licensed distribution without the whole thing inheriting the copyleft terms. Getting this wrong is how organizations discover during due diligence that a product cannot be shipped or sold as-is.
Automating OSS license compliance
You cannot manage hundreds of licenses by hand, and they change: a dependency can relicense between versions, as several high-profile projects have done. The practical approach is to generate a software bill of materials (SBOM) that records every component and its license, then enforce a policy against it.
# Generate an SBOM with license data (CycloneDX example)
npx @cyclonedx/cyclonedx-npm --output-file sbom.json
With an inventory in hand, define a policy: which licenses are allowed automatically, which need legal review, and which are banned (AGPL and unlicensed code are common blocks). Then enforce it in CI so a pull request that introduces a GPL dependency into a proprietary product fails before merge rather than surfacing during an acquisition.
An SCA tool typically does both jobs: it inventories your dependencies and reports each one's license alongside its vulnerabilities, since the same dependency graph feeds both concerns. A tool such as Safeguard can flag a newly introduced copyleft or unknown-license dependency in a pull request, which is exactly the point where fixing it is cheap. For the compliance fundamentals behind SBOMs and license policy, the Safeguard Academy has structured material.
One honest caveat: automated license detection is very good but not infallible. Dual-licensed projects, custom license texts, and files with inconsistent headers can be misclassified. Treat the tool's output as a strong first pass and route anything ambiguous or high-stakes to counsel. This article is not legal advice.
FAQ
What is the difference between permissive and copyleft licenses?
Permissive licenses (MIT, BSD, Apache 2.0) let you use the code in closed-source commercial products as long as you keep the attribution. Copyleft licenses (GPL, AGPL) require derivative works you distribute to be released under the same license, which can obligate you to open-source your own code.
Can I use GPL software in a commercial product?
You can use it internally and you can sell GPL software, but if you distribute a product that incorporates GPL code, you generally must make the combined work's source available under the GPL. The AGPL extends this to network services. Many companies restrict GPL and ban AGPL for proprietary products.
How do I track OSS licenses across many dependencies?
Generate a software bill of materials that records each component's license, then enforce a policy in CI that allows, flags for review, or blocks specific licenses. An SCA tool automates both the inventory and the policy check.
Is automated license detection reliable?
It is a strong first pass but not perfect. Dual-licensed projects, custom terms, and inconsistent file headers can be misclassified, so route ambiguous or high-stakes cases to legal counsel rather than relying on the scanner alone.