The main types of software licensing fall into three families: permissive open source, copyleft open source, and proprietary, and the software licensing type attached to each dependency decides what you are allowed to do with it and what obligations come attached. Getting the licensing types wrong rarely causes an outage, but it causes something worse at the wrong moment: a copyleft obligation discovered during acquisition due diligence, or a proprietary term breached in a customer deployment.
For a modern codebase built from hundreds of dependencies, knowing these licensing types is not academic. It is the difference between a clean audit and a scramble.
Permissive open source licenses
Permissive licenses grant broad freedom with minimal obligation. You can use, modify, and redistribute the code, including in closed-source commercial products, and the main requirement is preserving the copyright and license notice. The common ones:
- MIT is the simplest and most popular. Do almost anything; keep the notice.
- BSD (2-clause and 3-clause) is similar, with the 3-clause variant adding a non-endorsement term.
- Apache 2.0 is permissive but adds an explicit patent grant, which is why enterprises often prefer it: contributors grant you a license to any patents their contribution needs, reducing patent-troll risk.
Permissive licenses are the low-friction default for most commercial development. The obligations are light enough that they rarely block anything, though you still need to reproduce notices, which trips up teams that never assembled a proper attribution file.
Copyleft open source licenses
Copyleft grants the same freedoms but adds a reciprocity requirement: derivative works must be released under the same license, with source available. This is where obligations get real, and copyleft splits into strong and weak variants.
Strong copyleft (GPLv2, GPLv3) applies to the whole combined work. If you distribute software that incorporates GPL code, you generally must release the entire work under the GPL, including your own additions. Our guide to the GPL covers exactly when that obligation triggers, which turns on distribution rather than mere use.
Weak copyleft (LGPL, MPL, EPL) limits the reciprocity to the licensed component itself. The LGPL lets you link a library into a proprietary application without the copyleft spreading to your whole program. The MPL applies copyleft at the file level, so files you add stay under your chosen license while modified MPL files stay MPL.
Network copyleft (AGPL) is the strongest and the one SaaS teams must watch. The AGPL treats providing software over a network as distribution, so running a modified AGPL service typically obligates you to offer users the source, even though you never shipped a binary. An AGPL dependency in a hosted product is a genuine compliance question, not a formality.
Proprietary and commercial licenses
Proprietary licenses are closed by default. You get whatever specific rights the license text grants and nothing more, and the terms vary enormously:
- Per-seat or per-core commercial licenses tie usage to a count you must not exceed.
- Subscription (SaaS) terms govern acceptable use, data handling, and often prohibit reverse engineering or competitive benchmarking.
- Freemium and dual licenses offer an open-source version alongside a paid commercial one. Many databases and libraries ship GPL or AGPL for free and sell a commercial license precisely so companies can avoid the copyleft obligation. MongoDB's SSPL and similar "source-available" licenses sit here too: the source is visible but the terms restrict commercial hosting, which is not the same as open source.
The trap with proprietary licenses is assuming that because you paid, you can do anything. Read the actual grant. Usage caps, deployment restrictions, and audit clauses are common and enforceable.
Why licensing types are a security team's problem
License compliance ends up on the security or platform team's plate because it is a supply chain problem, and the supply chain is what they already scan. Three failure modes recur:
- Transitive copyleft. A permissively licensed package pulls in a GPL or AGPL component several levels deep. Your "MIT-safe" application now carries a copyleft obligation nobody chose.
- License changes across versions. Projects relicense. A dependency that was Apache 2.0 at the version you adopted might be under a restrictive source-available license in a later release you upgrade into without reading the fine print.
- Missing attribution. Even permissive licenses require you to reproduce notices. Shipping without them is a technical violation that surfaces in audits.
All three are invisible unless you inventory licenses continuously. This is where a software bill of materials earns its keep: an SBOM records every component and its license, giving you the map. An SCA tool such as Safeguard generates that inventory across your dependency tree, flags copyleft and source-available licenses wherever they appear, and lets you set a policy that fails a build when a forbidden license shows up. That turns license compliance from a pre-audit fire drill into a gate that runs on every pull request.
A workable policy
Most organizations converge on a tiered allowlist, enforced automatically:
- Allow: MIT, BSD, Apache 2.0 and other permissive licenses.
- Review: LGPL, MPL and other weak copyleft, checked for how the component is linked and used.
- Restrict: GPL, AGPL, and source-available licenses like SSPL in anything you distribute or host, unless explicitly approved.
Encode it in your scanner, document the exceptions, and keep the SBOM current. That is the whole discipline: know what you have, know its terms, and catch changes before they ship.
FAQ
What are the three main types of software licensing?
Permissive open source (MIT, BSD, Apache 2.0), copyleft open source (GPL, LGPL, MPL, AGPL), and proprietary or commercial licenses. Permissive imposes minimal obligations, copyleft requires sharing derivative source, and proprietary grants only the specific rights its terms allow.
Which licensing types are safest for commercial products?
Permissive licenses like MIT, BSD, and Apache 2.0 are the lowest-friction for closed-source commercial use, requiring mainly that you preserve notices. Strong copyleft (GPL, AGPL) can obligate you to release your own source, so many teams restrict it in distributed products.
What makes the AGPL different from the GPL?
The AGPL extends copyleft to network use. Running a modified AGPL service typically requires offering users the source, even though you never distributed a binary. This matters specifically for SaaS and hosted products.
How do I track licensing types across all my dependencies?
Generate a software bill of materials and scan it with software composition analysis. That inventories every component and its license, including transitive ones, so restricted or changed licenses become visible and can be blocked by policy on each build.