Open source software licenses are the legal contracts that grant you the right to use, modify, and distribute a dependency, and ignoring them exposes you to compliance risk that can be as damaging as an unpatched vulnerability. A single copyleft library slipped into a proprietary product can, in principle, obligate you to release your own source code, which is why license posture belongs in the same audit as security posture.
This guide explains the main types of software license models, the permissive-versus-copyleft split that drives most decisions, and how to run an open source software audit that keeps you compliant.
Why Licenses Sit Next to Security
When teams think about open source software vulnerabilities, they picture CVEs. Licenses are the other half of dependency risk. A vulnerability can get you breached; a license violation can get you sued or force you to open-source proprietary code. Both risks enter through the same door, the package manager, and both are invisible unless you look.
The reason this catches people off guard is transitivity. You might choose a permissively licensed direct dependency, but it can pull in something copyleft three levels down. The obligation attaches to what you actually ship, not to what you consciously selected, so the only reliable view is the full dependency tree.
Types of Software License Models
The types of software license agreement in open source cluster into a few families, ordered roughly from most permissive to most restrictive.
Permissive licenses let you do almost anything, including using the code in closed-source commercial products, as long as you preserve the copyright notice. The common ones are MIT, BSD (2-clause and 3-clause), and Apache 2.0. Apache 2.0 adds an explicit patent grant, which makes it the friendlier choice for enterprises worried about patent claims.
Weak copyleft licenses require you to share modifications to the licensed code itself but do not reach into the rest of your application. The Mozilla Public License (MPL 2.0) and the GNU Lesser General Public License (LGPL) fall here. LGPL is often used for libraries you link against without wanting to encumber your whole program.
Strong copyleft licenses require that any work that incorporates the code be released under the same license, which for a proprietary product is usually a dealbreaker. The GNU General Public License (GPL 2.0 and 3.0) is the archetype.
Network copyleft closes the "software as a service" gap. The GNU Affero General Public License (AGPL) extends copyleft obligations to code you run as a network service, not just code you distribute. If you offer an AGPL-covered component over a network, users may be entitled to its source. This is the one that surprises SaaS companies most.
There are also source-available licenses like BSL and SSPL that are not open source by the OSI definition but appear in the same catalogs; treat them separately because they carry commercial-use restrictions.
The Practical Decision: Permissive vs Copyleft
For most commercial software, the working rule is straightforward. Permissive licenses (MIT, BSD, Apache 2.0) are safe to use in proprietary products with minimal obligations. Strong copyleft (GPL) and network copyleft (AGPL) require legal review before they go anywhere near a product you do not intend to open-source. Weak copyleft sits in between and usually depends on how you link to it.
This is a legal judgment, not a purely technical one, so the engineer's job is not to make the call alone but to surface every license in the tree so counsel can. The failure mode is not "we chose GPL knowingly"; it is "we had no idea it was in there."
Running an Open Source Software Audit
An open source audit answers two questions for every component: what is it, and what license does it carry. The mechanism that ties them together is a software bill of materials (SBOM), a complete inventory of your dependencies with their versions and licenses.
The workflow looks like this:
- Generate an SBOM for each build, in a standard format like SPDX or CycloneDX, covering direct and transitive dependencies.
- Resolve every license, including the awkward cases: dual-licensed packages, packages with no declared license (a risk in itself), and packages whose declared license disagrees with the text in the repository.
- Evaluate against a policy that classifies licenses as allowed, review-required, or forbidden for your distribution model.
- Gate the build so a forbidden or unknown license fails CI rather than shipping silently.
Doing this by hand does not scale past a trivial project. Open source audit software automates the SBOM generation and policy evaluation, and because the same tools already resolve the dependency tree for vulnerability scanning, license and security checks naturally run together. An SCA platform such as Safeguard produces the SBOM, resolves licenses across the transitive tree, and enforces a license policy in the same gate that catches vulnerabilities. Our compliance and pricing overview shows how that fits a continuous pipeline.
Common Pitfalls
A few recurring mistakes account for most license incidents. Assuming a package's license from its ecosystem rather than reading it; npm is not uniformly MIT. Missing a license change between versions, since projects do relicense (several high-profile libraries have moved to BSL or AGPL). Ignoring "no license" packages, which by default grant you no rights at all. And auditing only direct dependencies while the risky obligation hides transitively.
Treat license data as living inventory, regenerated on every build, rather than a one-time spreadsheet. Combined with vulnerability scanning, it gives you a complete picture of dependency risk instead of half of one.
FAQ
What are the main types of open source software licenses?
They fall into permissive (MIT, BSD, Apache 2.0), weak copyleft (LGPL, MPL), strong copyleft (GPL), and network copyleft (AGPL). Permissive licenses impose the fewest obligations, while copyleft licenses can require you to share source code.
Can I use GPL software in a proprietary product?
Distributing a proprietary product that incorporates GPL code generally triggers an obligation to release your combined work under the GPL. Because the rules depend on how the code is used and linked, get legal review before including strong copyleft in closed-source software.
What is the difference between an SBOM and an open source audit?
An SBOM is the inventory: a list of every component, its version, and its license. An open source audit is the process of generating that inventory and evaluating it against your security and license policies.
Why do transitive dependencies matter for license compliance?
License obligations attach to everything you ship, not just the packages you chose directly. A permissive direct dependency can pull in a copyleft package deep in the tree, so you must audit the full transitive graph, not only your top-level dependencies.