The types of software license agreements fall into five practical buckets: proprietary licenses, permissive open source, copyleft open source, source-available licenses, and service agreements that govern SaaS. Everything else you will meet in a due diligence review is a variation on one of those five. The legal texts differ wildly, but the questions they answer are always the same: can you use the software commercially, can you modify it, can you redistribute it, and what do you owe in return.
This post is the map I wish someone had handed me before my first license audit. It is written for engineers and engineering managers, not lawyers, so the framing is operational: what each category lets you do, and what it quietly obligates you to do.
Proprietary Licenses and EULAs
The classic commercial model. You get a right to run the software under specific conditions, you get no source code, and the agreement usually restricts reverse engineering, benchmarking disclosure, and transfer. Within this bucket there are sub-flavors worth recognizing:
- Perpetual licenses grant indefinite use of a specific version, often with a separate maintenance contract for updates.
- Subscription licenses grant use only while you keep paying. Most desktop and enterprise software has moved here.
- Per-seat, per-core, and per-instance metrics define how usage is counted. This is where audits bite; database and virtualization vendors are famous for core-count disputes.
- OEM and redistribution licenses let you embed a vendor's component inside your product, with their terms flowing down to your customers.
The operational risk with proprietary agreements is rarely the license text itself. It is drift: engineering spins up more instances than procurement bought, or a component licensed for internal use ends up inside a customer-facing product.
Permissive Open Source Licenses
MIT, Apache 2.0, BSD 2-Clause and 3-Clause, and ISC dominate this category. They allow commercial use, modification, and redistribution with minimal conditions, usually just preserving the copyright notice and license text.
The differences between them matter more than people assume. Apache 2.0 includes an explicit patent grant and a NOTICE-file requirement; MIT and BSD are silent on patents. BSD 3-Clause adds a non-endorsement clause. If your product ships a bundled NOTICE file or an open source attributions screen, permissive licenses are why it exists.
Permissive licensing is the default for most of the modern dependency graph, which is exactly why teams stop paying attention to it. The obligations are light but they are not zero, and a missing attribution file is the most common finding in acquisition due diligence. We compared the mainstream options in detail in our comparison of the most popular open source licenses.
Copyleft Licenses: Strong and Weak
Copyleft licenses grant the same freedoms as permissive ones but attach a reciprocity condition: if you distribute the software or derivatives of it, you must make source available under the same license.
- Strong copyleft (GPL-2.0, GPL-3.0) extends that condition to the whole combined work. Linking GPL code into your proprietary application and distributing the result generally obligates you to release your application's source under the GPL.
- Network copyleft (AGPL-3.0) closes the SaaS loophole. Merely offering the software to users over a network counts as the trigger, which is why many companies maintain a blanket AGPL prohibition list.
- Weak copyleft (LGPL, MPL-2.0, EPL) scopes the reciprocity to the licensed component itself. You can link an LGPL library from proprietary code if you keep the library replaceable; MPL-2.0 scopes obligations to individual files.
The single most important word in all of this is distribution. Internal tools that never leave your infrastructure generally do not trigger GPL obligations. The moment code ships to customers, in a binary, a container image, or an embedded device, the analysis changes.
Source-Available and Dual Licensing
A fast-growing category that is frequently mislabeled as open source. Licenses like the Business Source License (BSL), the Server Side Public License (SSPL), and various "fair source" texts make source code readable but restrict specific uses, typically offering the software as a competing managed service. Elastic, MongoDB, HashiCorp, and Redis all moved flagship projects into this bucket between 2018 and 2024, each triggering community forks (OpenSearch, Valkey, OpenTofu).
Dual licensing is the commercial sibling: the vendor offers the same codebase under a copyleft license for open use and a paid commercial license for teams that cannot accept copyleft terms. Qt and MySQL are the long-running examples. The practical trap is that an engineer pulls the GPL edition from a package registry while the company believes it bought the commercial edition.
SaaS Terms of Service and API Agreements
When you consume software as a service, there is no software license in the classic sense; there is a service agreement. That shifts the risk questions from redistribution to data: where is your data processed, what happens on termination, what are the availability commitments, and what rights does the provider claim over content you submit.
API terms deserve special attention because they often include rate limits, field-of-use restrictions, and revocation clauses that can kill a product feature overnight. Treat critical third-party APIs as supply chain dependencies with contract risk, not just uptime risk.
Why This Belongs in Your Security Program
License obligations attach to your dependency graph, and your dependency graph is enormous. A typical service pulls in hundreds of transitive packages, each carrying its own license, and nobody reads them by hand. This is where license compliance converges with supply chain security tooling: the same SBOM that powers vulnerability response can carry per-component license data, and SCA tools can flag a copyleft or source-available license entering the tree the same way they flag a vulnerable version.
A workable policy usually looks like three lists: allowed by default (MIT, Apache 2.0, BSD, ISC), review required (LGPL, MPL, EPL), and prohibited without legal sign-off (GPL in distributed products, AGPL, SSPL, BSL for competing uses). Enforce it in CI, not in a wiki page nobody opens.
FAQ
What are the main types of software license agreements?
Five categories cover nearly everything: proprietary licenses (including EULAs and subscriptions), permissive open source (MIT, Apache 2.0, BSD), copyleft open source (GPL, AGPL, LGPL, MPL), source-available licenses (BSL, SSPL), and SaaS or API service agreements.
Is open source software free to use commercially?
Usually yes, but with conditions. Permissive licenses require little beyond attribution, while copyleft licenses require sharing source code when you distribute derivatives. See our guide on using Apache 2.0 and MIT code commercially for the two most common cases.
What is the difference between a license and a service agreement?
A license grants rights to copy, run, and modify software you possess. A service agreement governs access to software the provider runs; you receive no copy, so classic license concepts like redistribution rarely apply, and data handling terms matter far more.
How do I track licenses across thousands of dependencies?
Generate an SBOM as part of your build and evaluate license policy automatically in CI. Manual review does not scale past a handful of direct dependencies, and the risky licenses usually arrive transitively.