A license type is the category of legal terms attached to a piece of software that dictates how you may use, modify, and distribute it. Every dependency your application pulls in carries one, and the type of license it uses can quietly create legal obligations — or outright legal risk — for the product you ship. Most engineers treat licenses as boilerplate they scroll past, which is exactly how companies end up with copyleft code in a proprietary product they cannot legally distribute. This post explains the main software license type categories and why keeping track of them is part of doing security and compliance properly.
Why the license type matters at all
When you install an open-source package, you are not buying it and you do not own it. You are being granted permission to use it under specific conditions set by the copyright holder. Ignore those conditions and you are, technically, infringing copyright. The consequences range from being forced to open-source your own code, to legal disputes, to failed acquisition due diligence — buyers scrutinize a target's license obligations closely, and a tangle of incompatible licenses can sink or reprice a deal.
So the license type is not a legal footnote. It is a constraint on what you are allowed to build and ship, and it deserves the same attention you give to security vulnerabilities.
The main categories of software license type
Broadly, every license falls into one of a few buckets, and knowing which bucket a dependency sits in tells you most of what you need to know.
Permissive licenses. These impose minimal restrictions. You can use, modify, and redistribute the code, including inside proprietary products, as long as you preserve the copyright notice and license text. MIT, BSD (in its 2- and 3-clause forms), and Apache 2.0 are the common examples. Apache 2.0 adds an explicit patent grant, which is one reason many companies prefer it. This is the friendliest type of license for commercial software, which is why the most popular libraries tend to use one.
Copyleft licenses. These require that derivative works be distributed under the same license. The GNU GPL is the archetype: if you distribute software that incorporates GPL code, you generally must make your combined work's source available under the GPL too. "Strong" copyleft like GPLv3 reaches broadly; "weak" copyleft like the LGPL and the Mozilla Public License (MPL) is more limited, typically applying the obligation only to the licensed component itself, so you can link to it from proprietary code with fewer strings attached.
Network copyleft. The AGPL extends copyleft to cover software provided over a network, not just software you distribute as a binary. This closes the "SaaS loophole" — if you run modified AGPL code as a hosted service, you may be obligated to offer its source to your users. Many companies ban AGPL dependencies outright for this reason.
Proprietary and commercial licenses. These are closed by default. The vendor grants you specific, limited rights in exchange for payment or agreement to terms, and you usually cannot see, modify, or redistribute the source. Commercial software license type terms vary enormously, so they must be read individually.
Public domain and near-equivalents. Dedications like CC0 or the Unlicense place code effectively outside copyright, letting anyone do anything. These are the least restrictive of all, though some jurisdictions complicate outright public-domain dedication.
Copyleft is where teams get burned
The single most important distinction to internalize is permissive versus copyleft. A permissive dependency almost never creates a problem for a commercial product. A strong-copyleft or network-copyleft dependency can force obligations you did not intend — up to publishing source you meant to keep private.
The trap is that these dependencies arrive indirectly. You add one small, permissively licensed package, and three layers down its own dependency tree includes something GPL or AGPL. Nobody chose it deliberately; it just came along for the ride. Because transitive dependencies dominate modern applications, the license risk is usually hidden below the surface where a manual review of your direct package.json or pom.xml will never find it.
Tracking license type at scale
You cannot manage what you cannot see, and manually auditing licenses across hundreds of transitive dependencies is not feasible. This is where software composition analysis earns its place beyond vulnerability scanning: the same tool that inventories your components and flags known CVEs can also record each component's license and flag types that conflict with your policy.
A practical policy defines an allowlist (permissive licenses are usually fine), a denylist (often AGPL, sometimes GPL for products you distribute), and a review queue for anything ambiguous. An SCA tool evaluates every dependency against that policy on each build, so a newly introduced copyleft transitive dependency fails the check before it merges rather than surfacing during an acquisition audit two years later. A platform such as Safeguard tracks both the license and the vulnerability status of each component in one inventory, which keeps the two compliance concerns from being managed in separate spreadsheets.
The output you want from all this is a software bill of materials that lists every component, its version, and its license. That document is increasingly requested by customers and required in regulated procurement, and it is the artifact that makes license compliance provable rather than hopeful.
A workable license policy
Keep it simple enough that developers will follow it. Permit the well-understood permissive licenses without ceremony. Require explicit approval for any copyleft dependency, with the network-copyleft ones held to the highest bar. Automate the check in CI so the policy enforces itself rather than depending on someone remembering to look. And generate an SBOM on every release so you always know your current exposure. The Safeguard Academy covers building this kind of policy gate into a pipeline in more detail.
FAQ
What are the main types of software license?
The main categories are permissive (MIT, BSD, Apache 2.0), copyleft (GPL and the weaker LGPL and MPL), network copyleft (AGPL), and proprietary or commercial licenses. Public-domain dedications like CC0 sit outside copyright entirely. The type of license determines what you may do with the code.
What is the difference between permissive and copyleft licenses?
Permissive licenses let you use and redistribute code, including in closed-source products, with minimal conditions such as keeping the copyright notice. Copyleft licenses require derivative works to be released under the same license, which can obligate you to open-source code that incorporates them.
Why is the AGPL treated as risky for companies?
The AGPL extends copyleft obligations to software offered over a network, not just distributed binaries. If you run modified AGPL code as a hosted service, you may be required to provide its source to users. Many organizations ban AGPL dependencies to avoid that obligation.
How do I know which license type my dependencies use?
Use software composition analysis to inventory every direct and transitive dependency and record each one's license. Manual review misses the transitive dependencies where risky licenses usually hide, so automated scanning against a defined license policy is the reliable approach.