The different types of licenses in software sort into four practical families: permissive, weak (or file-level) copyleft, strong copyleft, and proprietary, and each imposes different obligations on how you use, modify, and redistribute the code. Understanding these families is not an academic exercise. Pull the wrong license into a product you ship, and you can trigger disclosure requirements you did not plan for, or violate terms in a way that becomes a legal and reputational problem. This guide maps the different types of software licenses and connects them to the supply chain decisions engineers actually make.
Why license type is a security and supply chain concern
License compliance often sits with legal, but the data lives in your dependency tree, which makes it an engineering problem too. Every package you install arrives with terms, and a modern application pulls in hundreds of them transitively. A single copyleft library buried three levels deep can change the obligations for your entire distribution. That is the same graph your vulnerability scanning walks, which is why license and vulnerability analysis usually happen together in a software bill of materials.
Treating license type as metadata you capture per dependency — ideally in an SBOM — turns a periodic legal fire drill into a routine gate. You want to know a package's license before it merges, not after a customer's legal team asks.
Permissive licenses
Permissive licenses let you do nearly anything — use, modify, redistribute, even 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.
The one meaningful distinction inside this family is patents. Apache 2.0 includes an express patent grant and a patent-retaliation clause, which is why many organizations prefer it for anything patent-sensitive. MIT and BSD are silent on patents. All three are safe to combine with proprietary code, which is why they dominate the JavaScript, Go, and Rust ecosystems. Your main obligation is attribution: ship the notices.
Weak (file-level) copyleft
Weak copyleft sits between permissive and strong copyleft. Licenses like the MPL 2.0 (Mozilla Public License) and the LGPL apply copyleft at the file or library boundary rather than to your whole application. If you modify an MPL-covered file, you must release those file changes under the MPL, but you can combine that code with proprietary code in the same project without opening your own source.
LGPL adds a linking nuance: dynamic linking generally keeps your proprietary code separate, while static linking can pull in additional obligations. For most SaaS backends this is manageable, but it requires you to actually track which files came from where — the obligation is scoped, not absent.
Strong copyleft
Strong copyleft is the family that most often surprises teams. The GPL (v2 and v3) and, more aggressively, the AGPL require that if you distribute software containing the code, you make the complete corresponding source available under the same license. AGPL extends this to network use: if users interact with your modified AGPL software over a network, that can count as distribution and trigger the source-disclosure obligation even though you never shipped a binary.
For a company building proprietary software, an AGPL dependency deep in the tree is the classic "how did this get here" moment. It is not automatically fatal — it depends on how the code is used and combined — but it is exactly the kind of finding you want surfaced early. This is where automated license detection across the dependency graph earns its keep; a tool such as Safeguard can flag a transitively introduced GPL or AGPL component before it reaches production.
Proprietary and source-available licenses
The fourth family is everything that is not open source in the OSI sense. This includes classic commercial EULAs and the newer "source-available" licenses like the BSL (Business Source License), SSPL, and Elastic License. Source-available code is readable and often free for some uses, but it typically restricts hosting it as a competing service or requires a commercial license past certain thresholds.
These licenses have grown common as infrastructure vendors defend against cloud providers repackaging their work. The practical trap is assuming that "the source is on GitHub" means "it is open source and I can do anything." Read the actual terms — several widely used databases and tools have relicensed to BSL or SSPL, and the change can quietly alter your compliance position on an upgrade.
Building a workable policy
A useful license policy is a short allowlist, a review list, and a denylist. Permissive licenses (MIT, BSD, Apache 2.0) usually go on the allowlist. Weak copyleft (MPL, LGPL) goes on a review list with usage conditions. Strong copyleft (GPL, AGPL) and unknown or missing licenses go to a block-or-review gate. Enforce it in CI against your SBOM so a new dependency with an unexpected license fails the build rather than being discovered in an audit. The Safeguard academy has deeper walkthroughs if you are formalizing this for the first time.
FAQ
What are the main types of software licenses?
Four families: permissive (MIT, BSD, Apache 2.0), weak/file-level copyleft (MPL, LGPL), strong copyleft (GPL, AGPL), and proprietary or source-available (commercial EULAs, BSL, SSPL). Each defines what you may do when you use, modify, or redistribute the code.
Which licenses are safe to use in commercial closed-source software?
Permissive licenses are the safest for closed-source products — you keep your source private as long as you preserve attribution. Weak copyleft is usually workable with care. Strong copyleft (especially AGPL) and many source-available licenses can force disclosure or restrict commercial hosting, so treat them as review-required.
Why is AGPL considered risky for companies?
AGPL treats network interaction as distribution. If users reach your modified AGPL software over a network, you may be obligated to publish the complete corresponding source under AGPL. That can conflict with a proprietary SaaS model, so many organizations block AGPL dependencies by policy.
How do I track licenses across all my dependencies?
Generate a software bill of materials that records each component's license, then enforce a license policy in CI. Automated software composition analysis detects licenses across the transitive graph and flags unexpected or missing ones before they ship.