Types of Software Licenses: A Guide to Choosing the Right One

Every piece of software you build, ship, or buy runs under a license. That license is a legal agreement that says who can use the software, how, and under what conditions. Get it wrong, and the consequences can be expensive to unwind.

This guide covers the four core types of software licenses, explains the key terms you need to know, and ends with a practical framework to help you make the right call.

Key Takeaways

• Every software license is either proprietary (closed source) or open source.
• Open source licenses split into four main types: public domain, permissive, copyleft, and proprietary/commercial.
• Copyleft licenses (most famously the GPL) can require you to open-source your own code if you distribute software that includes them.
• Commercial licenses come in several forms, including perpetual, subscription, per-seat, floating, OEM, and freemium, each with different cost structures and use-case fits.
• Avoid dependency traps, including transitive, license shifting, unmaintained software, and pinning by taking proactive steps to manage your risk.

Understanding Software Licensing: The Core Framework

Before diving into specific licenses, it helps to understand how software licensing in general works. Every type of software license falls into one of two categories: proprietary or open source.

Proprietary software is closed. You get the software, but not the code behind it. The vendor owns all rights and sets the rules through a legal agreement called an End User License Agreement (EULA). Modifying, redistributing, or reverse-engineering the software is off-limits unless the vendor explicitly says otherwise. Microsoft Windows, Adobe Photoshop, and most commercial business software fall into this category.

Open source software makes its code publicly available. The key thing to understand here is that "open source" doesn't mean "no strings attached." Some open source licenses let you do almost anything with the code. Others come with conditions. One of the most common conditions is a requirement to share your changes if you distribute the software.

Here is what different licenses mean for open source software:

• Permissive licenses give you broad freedom: use it, modify it, ship it in a commercial product. You don't have to share your own code in return.
• Copyleft licenses ensure software remains open-source by mandating that any derivative work be distributed under the same terms as the original. But copyleft licenses also come with a condition: if you distribute software that includes copyleft code, you must release that software under the same license. This is sometimes called the "viral clause" because the obligation can spread through a codebase.

A few other terms come up regularly when evaluating software licenses:

• EULA: The contract between a software vendor and the end user. It defines what you're allowed to do with the software, what's restricted, and who's liable if something goes wrong.
• Royalties: Fees paid to a licensor for ongoing use of their software. This model is common in OEM and embedded software deals.
• SaaS vs. on-premise: SaaS software runs on the vendor's servers and is accessed over the internet. On-premise software is installed and runs locally. This matters for copyleft compliance: most copyleft licenses are triggered by distributing software, not by running it as a service, so a SaaS deployment may not trigger the same obligations as shipping a product to customers.
  
   

Real-world examples help to illustrate what each type of software license means. For example, Windows is proprietary in that Microsoft controls how it's distributed and used. Linux runs under the GPL (GNU General Public License), a copyleft license that gives anyone the right to study, modify, and redistribute the code, but requires that any derivative work be released under the same terms, keeping it open for everyone. Photoshop is proprietary under a subscription EULA, which means you're paying for access to the software, not permanent ownership of it. VS Code is MIT-licensed—Microsoft publishes the code and places almost no restrictions on how others use or build on it.

What Are the 4 Types of Software Licenses?

Each type of software license can fit into one of four categories:

1. Public Domain Licenses

A public domain license, or more accurately, a public domain dedication, removes copyright protection entirely. The author gives up all rights, and the work becomes free for anyone to use, modify, or distribute for any purpose, including commercial use, with no attribution required and no conditions attached. The most common examples are the Unlicense and Creative Commons CC0. These exist because copyright is automatic in most countries, so you need a formal legal instrument to actually waive it.

Public domain dedications make sense when maximum freedom is the goal, such as for reference implementations, sample code, or data released for public benefit. The trade-off is simple: no conditions, but also no warranty. If something breaks, most of the time you have to fix it yourself.

2. Permissive Open Source Licenses

Permissive licenses are the most commercially friendly of the open source license types. They let you use, modify, and redistribute code with very few conditions, typically just keeping the original copyright notice and license text intact.

The most common permissive software licenses are:

• MIT License: The most widely used permissive license. One requirement of it is that attribution is kept. There are almost no other restrictions. Used by React, Rails, and jQuery, among thousands of others.
• Apache 2.0: Similar to MIT but with one important addition, an explicit patent grant. Contributors license any relevant patents to anyone who uses the code downstream. Used by Kubernetes and Android (AOSP). If patent exposure is a concern, Apache 2.0 is the stronger choice.
• BSD (2-clause and 3-clause): Functionally close to MIT. The 3-clause version adds a non-endorsement clause, which means you can't use the project's name to promote your own product without permission.

The practical difference between MIT and Apache 2.0 ultimately comes down to patents. MIT says nothing about them, leaving patent risk undefined. Apache 2.0 explicitly grants a patent license, which gives companies building commercial products a cleaner legal position.

Permissive licenses are generally the right choice for libraries, developer tools, and any project designed to encourage broad commercial adoption.

Permissive Licensing Summary

3. Copyleft (Share-Alike) Open Source Licenses

Copyleft licenses are built around one idea: freedom must be preserved downstream. If you distribute software that includes copyleft code—modified or not—you have to make the source code of your entire distribution available under the same license. That's the viral clause that we discussed earlier in action.

Copyleft isn't a single setting. It comes in different strengths:

• GPL v2 / GPL v3 (strong copyleft): The most widely used copyleft license. Any software that incorporates GPL code must itself be released under GPL upon distribution, meaning you can't wrap it in a proprietary product and ship it. Linux and WordPress both use GPL v2. GPL v3 adds patent retaliation protections and anti-tivoization clauses.
• LGPL (weak copyleft—library exception): Designed for shared libraries. You can link an LGPL library into a proprietary application without triggering copyleft, provided you don't modify the library itself.
• AGPL (network copyleft): GPL only activates on distribution. Running GPL code as a hosted service doesn't count as distribution, so the source-sharing obligation traditionally didn't apply. AGPL closes that gap: if users interact with the software over a network, source must still be provided. MongoDB adopted AGPL for exactly this reason.
• MPL 2.0 (file-level weak copyleft): Copyleft applies at the file level only. MPL-licensed files can coexist in a larger codebase without affecting surrounding code, as long as those files themselves remain open.

Copyleft obligations depend not just on which license applies, but on what triggers it. GPL activates upon distribution; AGPL activates upon network use. Know your deployment model before incorporating any copyleft dependency.

Copyleft Licensing Summary

4. Proprietary and Commercial Software Licenses

Proprietary licenses are the dominant model for commercial software. The source code stays private. Usage rights are defined entirely by the EULA. You can't modify, redistribute, or reverse-engineer the software without explicit permission.

Within this software license category, there are different sub types—each with a different pricing structure and use-case fit:

• Perpetual License: A one-time purchase that grants permanent rights to use that specific version. Updates and support are typically sold separately. Once the dominant model for desktop and professional software (older Adobe Creative Suite is a familiar example), it remains common in engineering and technical fields where long-term version stability matters.
• Subscription License: Recurring payment for ongoing access; when payment stops, access ends. Microsoft 365 and Adobe Creative Cloud are the standard examples. For vendors, subscriptions mean predictable revenue and a current user base. For buyers, the cost is continuous rather than upfront.
• Per-Seat / Per-User License: Priced by the number of named users. This is often the default model in enterprise SaaS. Salesforce, Slack, and most CRM and project management tools charge per seat. License audits verify that active user counts match purchased seats.
• Concurrent / Floating License: A fixed pool of license slots shared across a larger user population. Only simultaneous usage is capped, not total headcount. Common in engineering, CAD, and simulation tools like MATLAB and ANSYS, where usage is intermittent rather than continuous.
• OEM License: Software bundled with hardware at the point of manufacture, tied to that specific device and non-transferable. Windows pre-installed on a consumer PC is the most familiar example.
• Freemium / Free Tier: A free core product drives adoption; revenue comes from premium features, higher usage limits, or enterprise capabilities. Zoom, Dropbox, and GitHub all use this model. Freemium is a commercial license with usage restrictions, not open source.

Proprietary and Commercial Licensing Model Summary

How to Choose the Right Software License

 

Picking the right type of software license is a strategic decision. The wrong choice can create legal debt that compounds, like copyleft obligations that clash with your business model, commercial terms that don't scale, and dependency chains that expose you to unanticipated liability. 

Here are four important questions that you can ask yourself to help you choose the right type of software license for your product:

1. Is this open source or commercial? Open source is not automatically risk-free. If you're building a commercial product, audit the license of every dependency before it enters your codebase.
2. Do you want others to be able to commercialize your work? Use a permissive license (MIT or Apache 2.0) if yes. Use a copyleft license (GPL or AGPL) if you want contributions to stay open. Use a proprietary or source-available license if you want to monetize it yourself.
3. Do you need patent protection? MIT is silent on patents. Apache 2.0 includes an explicit patent grant. If patent exposure is a concern, Apache 2.0 is the safer default.
4. Will it be distributed or run as a service? GPL triggers on distribution; AGPL triggers on network use. If you're delivering software as SaaS, GPL is less constraining than AGPL. If you're shipping binaries, GPL obligations apply in full.

For most commercial software vendors, the practical path is: 

1. Publish open source components under Apache 2.0 or MIT
2. Audit all dependencies for copyleft licenses before distribution
3. Structure your commercial product under a proprietary EULA with a licensing model, either perpetual, subscription, floating, or per-seat, that fits both your customers' procurement preferences and your revenue structure.

Dependency Traps Every Developer and Business Needs to Know

 

Understanding license types gets you halfway there. The bigger risks are structural, buried in dependency chains that most teams never fully audit. When you’re choosing a software license, it’s important to be aware of these potential “traps” so you can be proactive in mitigating your overall risk.

The Transitive Dependency Trap

Most of an application's codebase isn't code you chose, it's the indirect dependencies your direct dependencies pulled in. These hidden layers often go unvetted, which is where license violations and security vulnerabilities originate. So for example, let’s say you’re integrating “Library A” codebase into your software. Including Library A means inheriting the licenses of everything Library A depends on, which could be Libraries B through F and beyond. Library A might be MIT-licensed, but a deep sub-dependency could be GPL. If a viral license appears anywhere in that chain, it may legally require you to open-source your entire proprietary codebase. Most developers never audit past the first level of dependencies. That's where compliance failures originate.

License Shifting

Open source maintainers, or the companies backing them, can change licenses between versions. For example, HashiCorp moved Terraform from MPL to Business Source License. Redis changed terms on several modules. A developer updating a dependency from v2.1 to v2.2 to patch a bug may not notice the license changed. The result: you're in violation of terms you never agreed to, or facing a commercial requirement you didn't budget for.

The Unmaintained Dead End

If a critical library is maintained by one person who stops maintaining it, you're stuck. When a CVE surfaces and there's no maintainer to patch it, you can't ship a secure product. You're forced to fork (create a separate copy of the coding database) and maintain the code yourself, or rewrite the affected component. Both are expensive options. In regulated industries, an unpatched CVE is also a compliance failure, not just an engineering problem.

The Pinning Problem

Different parts of your codebase may require conflicting versions of the same library. For example, Library X needs Helper A v1.0 while Library Y needs v2.0. When requirements conflict, you're forced onto an outdated, potentially insecure version. This becomes a licensing issue when the pinned version carries different terms than the current release.

Managing Your Risk

The risks described above are manageable with the right tooling. Software composition analysis (SCA) tools like FOSSA and OSS Review Toolkit scan your full dependency tree, flag license conflicts, and alert your team when a package update brings a license change. For businesses managing commercial software entitlements at scale, a purpose-built license management platform like LicenseSpring provides the audit trails, true-up tracking, and entitlement visibility that spreadsheets can't.
 

Frequently Asked Questions About Software License Types

What is the difference between open source and free software?

"Free software" is a term defined by the Free Software Foundation. It refers to software that gives users four specific freedoms: to run it, study it, modify it, and distribute it. In other words, the word "free" means freedom, not price. 

Open source software covers much of the same ground but comes from a different tradition—one focused on the practical benefits of transparent code rather than the ideological framing the FSF uses. In most cases, the two overlap almost completely. The difference is mainly in emphasis and community culture.

Can I use GPL software in a commercial product?

It depends on how you use it. If you're running GPL software internally, such as a development tool or internal service, without distributing it, GPL obligations generally don't apply. If you distribute software that incorporates GPL code to customers or the public, you must make the corresponding source code available under the GPL. That's incompatible with keeping your product closed source. Many companies structure their architecture specifically to avoid GPL code in distributed components, using LGPL or permissive alternatives instead.

What happens if I don't have a software license?

In most jurisdictions, copyright is automatic. Software is protected the moment it's created, even without registration. If code has no license attached, it's not public domain. Technically, no one has the right to use, modify, or distribute it except the author. Consuming unlicensed code from a public repository creates legal risk because the author can assert copyright claims at any point. This is why license awareness isn't optional for any organization that builds on third-party code.

What is the most permissive software license?

The Unlicense and CC0 are the most permissive options because they dedicate code to the public domain entirely, with no attribution required and no conditions at all. Among licenses that still technically function as licenses rather than dedications, MIT and BSD 2-Clause come closest: a single requirement to include the copyright notice and license text. Apache 2.0 adds a patent grant, which introduces a little more structure but remains highly permissive in practice.

What's the difference between a software license and a software subscription?

A software license defines your legal right to use software. A subscription is a payment and access model. A perpetual license grants the right to use a specific version of software indefinitely after a one-time purchase. A subscription bundles usage rights with an ongoing payment obligation—stop paying, and access ends. The two are related but distinct: you can have a perpetual license to software you paid for once, or a subscription that renews your license each year. For a detailed comparison, see LicenseSpring's guide to perpetual vs. subscription licensing.

Conclusion: Licensing is Infrastructure

A software license isn't a formality. It's a decision that shapes your obligations, your business model, and your risk exposure.

For developers, the practical rule is: audit your dependency tree before you ship, and again every time you update. A permissive top-level license doesn't guarantee a permissive supply chain. Tools like FOSSA and OSS Review Toolkit make this tractable.

For businesses evaluating commercial software, the licensing model matters as much as the feature set. Whether you choose perpetual, subscription, floating, per-seat, or a hybrid model, each carries a different cost structure and different constraints on how usage can grow.

For procurement and legal teams, licensing is ongoing work. True-up clauses, renewal terms, and entitlement limits require active tracking. High-profile license changes at HashiCorp and Redis are a reminder that the commercial open source landscape is still being renegotiated, and that any single vendor dependency carries more risk than it may appear.

Clear visibility into what you've licensed and what your obligations are is the foundation of sound software operations. 

LicenseSpring gives software vendors the infrastructure to design, enforce, and manage licensing with precision: from defining entitlements and enforcing usage limits to handling activations across air-gapped environments and complex deployment models. 

If you're structuring a licensing model for your own software, explore what LicenseSpring can do. Get started today.