The most restrictive open source license in common use is the GNU Affero General Public License (AGPL), because its strong copyleft obligations extend even to software offered over a network, not just software you distribute. When people ask which is the most restrictive open source license, they are really asking which one imposes the heaviest obligations on how you can combine, modify, and deploy the code. This post explains what "restrictive" means in licensing terms, why the AGPL tops the list, and how the opposite end (the most permissive open source license) compares.
"Restrictive" means strong copyleft, not closed
A restrictive open source license is still open source; the restriction is not on your freedom to see and use the code, but on your freedom to keep your changes and combinations proprietary. That obligation is called copyleft. Copyleft licenses require that if you distribute the software (or a derivative), you also make your corresponding source available under the same license.
The strength of copyleft varies:
- Permissive licenses (MIT, BSD, Apache 2.0) impose almost no reciprocal obligation. Use the code however you like, including in closed-source products, as long as you preserve the copyright notice.
- Weak copyleft licenses (LGPL, MPL) require you to share changes to the licensed files themselves but let you link them into proprietary software.
- Strong copyleft licenses (GPL, AGPL) extend the obligation to the whole derivative work.
The more the license reaches into your own code, the more "restrictive" it is in the practical sense that matters to a business.
Why the AGPL is the most restrictive
The GPL already requires that distributing a derivative work means releasing your source under the GPL. The AGPL closes what is often called the "SaaS loophole." Under the plain GPL, if you modify GPL software but never distribute the binary (you only run it on your own servers and let users interact with it over a network), the source-sharing obligation is not triggered, because you never "conveyed" the software.
The AGPL adds a network clause: if users interact with your modified version over a network, you must offer them the corresponding source. That single addition makes the AGPL the most restrictive open source license for the modern world of hosted services, because it captures exactly the deployment model (SaaS) that the GPL leaves untouched.
For a company building a proprietary hosted product, this is the license that most often triggers a hard "do not include this dependency" rule, because merely running modified AGPL code behind an API can obligate you to publish your changes.
The permissive end of the spectrum
At the opposite pole, the most permissive open source license is usually said to be one of the public-domain-equivalent or minimal-attribution licenses. MIT and BSD are the classic minimal-obligation choices: keep the copyright notice, and you are free to relicense, embed in closed products, and modify without sharing. Some consider the Unlicense or a public-domain dedication even more permissive, since they waive attribution too.
Apache 2.0 sits with the permissive group but adds an explicit patent grant, which is why many companies prefer it: it gives permissive freedom plus protection against patent claims from contributors.
The practical implication: permissive licenses are low-friction for commercial use, while strongly copyleft licenses like the AGPL require deliberate legal review before you take a dependency.
Why this matters for your dependency tree
Here is the trap. You rarely add an AGPL dependency on purpose. You add a convenient library, and three levels down its dependency tree pulls in something AGPL-licensed. Now your entire hosted product may be subject to obligations you never evaluated, and you will not know unless you inventory licenses across the full transitive graph.
This is a compliance problem that scanning solves. A software bill of materials (SBOM) with license data per component tells you exactly which licenses are present. A software composition analysis tool that flags copyleft and network-copyleft licenses in your dependency tree is how most teams catch an AGPL component before it ships rather than after a customer's legal team asks about it.
Rough risk ordering for commercial closed-source products:
AGPL -> highest obligation (network copyleft)
GPL -> strong copyleft on distribution
LGPL/MPL -> weak copyleft, file-level
Apache 2.0-> permissive + patent grant
MIT/BSD -> permissive, minimal obligation
Building a license policy
Most organizations codify a policy rather than judging each dependency ad hoc. A common shape:
- Allow MIT, BSD, Apache 2.0 without review.
- Review LGPL and MPL, since linking boundaries matter.
- Block or escalate GPL and AGPL for proprietary products, allowing exceptions only with legal sign-off.
Encoding that policy into an automated gate in your pipeline is what makes it enforceable. A license that slips through in a rushed release is exactly the kind of finding that surfaces at the worst possible time, during due diligence for a funding round or an acquisition.
FAQ
What is the most restrictive open source license?
The AGPL (GNU Affero General Public License). Its strong copyleft extends to software offered over a network, so even running a modified version as a hosted service can obligate you to publish your source. That network reach makes it the most restrictive in practice.
What is the most permissive open source license?
MIT and BSD are the usual answers, requiring little more than preserving the copyright notice. Public-domain dedications like the Unlicense go further by waiving attribution. Apache 2.0 is permissive too and adds an explicit patent grant.
Is the AGPL safe to use in a commercial SaaS product?
Only with deliberate legal review. Because the AGPL's network clause can require you to publish source for your modifications when users interact with the software over a network, many companies block it for proprietary hosted products.
How do I find restrictive licenses in my dependencies?
Generate an SBOM with per-component license data and scan the full transitive dependency tree, not just your direct dependencies. Composition analysis tools flag copyleft and network-copyleft licenses so you catch them before release.