Different Types of Software Licenses: 5 Categories (2026)

Understanding the different types of software licenses is essential for any business that builds, acquires, or integrates software. The license attached to a piece of software dictates what you can legally do with it: how you may use it, whether you can modify it, and under what conditions you can distribute it. Choosing the wrong license, or failing to comply with the one you have, can expose your organization to copyright infringement claims, forced code disclosure, or contract termination.

This guide covers every major category of software license, explains the practical differences between them, and helps you determine which type fits your situation. This content is educational and does not constitute legal advice. Consult a qualified attorney for guidance specific to your circumstances.

What a Software License Is and Why It Matters

A software license is a legal instrument that grants specific rights from the software copyright holder to the user. Under the Berne Convention, adopted by 181 countries, software is automatically protected by copyright from the moment it is created. Without a license, no one other than the copyright holder has the legal right to use, copy, modify, or distribute the software.

The license is what creates permission. It defines the boundaries of what the user may do and what remains prohibited. Violating those boundaries constitutes copyright infringement, which under US law (17 U.S.C. Section 504) can result in statutory damages up to $150,000 per work for willful violations.

The different types of software licenses exist because software creators have different goals. Some want to maximize revenue and control. Others want to maximize adoption and community collaboration. The license type reflects these priorities and creates corresponding obligations for the user.

Proprietary Software Licenses

Proprietary licenses are the most restrictive category. The software vendor retains full ownership of the source code and grants the user only a limited right to use the compiled product. Modification, reverse engineering, and redistribution are prohibited unless the contract explicitly permits them.

Per-user and per-device licensing

Per-user (or per-seat) licensing ties each license to an individual person. Every employee who uses the software needs their own license. Microsoft 365, Adobe Creative Cloud, and Salesforce follow this model.

Per-device (or node-locked) licensing ties the license to a specific machine rather than a person. This model is common for:

• Industrial control systems and manufacturing equipment
• Point-of-sale terminals
• Embedded software in medical devices
• Specialized workstations running engineering or design tools

The key distinction: per-user licenses follow the person across devices, while per-device licenses stay with the machine regardless of who uses it.

Enterprise and volume licensing

Enterprise license agreements (ELAs) cover an entire organization under a single contract. They offer several advantages over per-user purchasing:

1. Simplified compliance through a single agreement covering all employees
2. Volume discounts that reduce per-unit cost significantly
3. Centralized management and deployment rights
4. Custom terms negotiated for the specific organization

Enterprise agreements are typically structured as multi-year commitments with annual true-up provisions, where the licensee reports actual usage and pays for any additional seats consumed above the baseline.

Subscription and SaaS licensing

Subscription licensing grants access to software for a recurring fee, usually monthly or annually. When the subscription ends, so does the right to use the software. SaaS (Software as a Service) takes this further by hosting the software in the vendor's cloud, eliminating the need for local installation.

Key characteristics of subscription and SaaS licensing:

• No perpetual rights: Access terminates when payments stop, unlike perpetual licenses that grant indefinite use.
• Automatic updates: The vendor manages upgrades, patches, and infrastructure.
• Usage-based pricing: Some SaaS products charge based on consumption (API calls, storage, active users) rather than flat per-seat fees.
• Data portability concerns: When the subscription ends, retrieving your data depends on the vendor's export capabilities and the contract's data return provisions.

OEM licensing

OEM (Original Equipment Manufacturer) licenses allow hardware manufacturers to bundle software with their products. The Windows operating system pre-installed on most PCs is the most familiar example. OEM licenses are typically non-transferable: the software cannot be moved to a different device.

Permissive Open-Source Licenses

Permissive open-source licenses grant broad freedoms with minimal conditions. Users may use, modify, and redistribute the software, including for commercial purposes, as long as they comply with a small set of requirements, usually limited to attribution.

MIT License

The MIT License is the most widely used open-source license on GitHub. Its full text is only about 170 words. The MIT License permits:

• Commercial use without restriction
• Modification of the source code
• Distribution of original or modified versions
• Private use

The sole requirement is that the copyright notice and license text must be included in all copies or substantial portions of the software. There is no obligation to share modifications or release source code.

Apache License 2.0

The Apache License 2.0 provides the same freedoms as MIT but adds two important provisions:

• Explicit patent grant: Contributors grant users a royalty-free license to any patents that cover their contributions. This protects users from patent infringement claims by contributors.
• Contribution documentation: Modified files must carry notices stating that changes were made, and a NOTICE file must be preserved if one exists.

The patent grant makes Apache 2.0 the preferred choice for projects where patent exposure is a concern, particularly in enterprise and infrastructure software.

BSD Licenses

The BSD license family comes in two main variants:

• 2-Clause BSD (Simplified): Allows redistribution in source and binary forms with attribution. Nearly identical in effect to the MIT License.
• 3-Clause BSD (New BSD): Adds a non-endorsement clause prohibiting the use of the project's name or contributors' names to promote derived products without written permission.

BSD licenses are popular in academic and research software, including the foundational networking code that powers most internet infrastructure.

Copyleft Open-Source Licenses

Copyleft licenses grant the same freedoms as permissive licenses: use, modification, and redistribution. The critical difference is the reciprocal obligation. If you distribute software that incorporates copyleft-licensed code, you must release your derivative work under the same license terms, including making the source code available.

GNU General Public License (GPL)

The GPL is the most well-known copyleft license and exists in three versions. GPL v3, released in 2007, is the current version and includes protections against patent retaliation and anti-circumvention claims.

GPL obligations when distributing software:

1. You must release the complete source code of the derivative work under GPL v3.
2. You must include the full license text.
3. You must preserve all copyright notices.
4. You cannot impose additional restrictions beyond those in the GPL.
5. You must provide installation instructions for the user to run their own modified version.

The GPL's requirements apply only when you distribute the software. Using GPL software internally within your organization, without distributing it to others, does not trigger the copyleft obligation.

GNU Lesser General Public License (LGPL)

The LGPL is a weaker form of copyleft designed specifically for software libraries. It allows proprietary software to link to (use) an LGPL-licensed library without triggering the copyleft requirement for the proprietary code. The LGPL obligation applies only to the library itself and any modifications made to it.

This makes the LGPL a practical choice for:

• Libraries intended for broad adoption across both open-source and proprietary projects
• Framework components where forcing copyleft on all users would limit adoption
• Infrastructure libraries (database connectors, logging frameworks, protocol implementations)

GNU Affero General Public License (AGPL)

The AGPL extends the GPL to close the "SaaS loophole." Under the standard GPL, running modified software on a server and providing it to users over a network does not count as distribution, so the source code disclosure obligation is not triggered. The AGPL adds a requirement that users who interact with the software over a network must be offered access to the source code.

The AGPL is particularly relevant for:

• Server-side software offered as a web service
• Database systems (MongoDB was AGPL-licensed before switching to SSPL)
• Any software where the primary use case is network-based rather than local installation

Many companies prohibit AGPL dependencies in their codebase entirely because the network interaction trigger is broader than traditional distribution-based copyleft.

Freemium and Dual Licensing

Some software products combine elements of different license types to serve both community and commercial goals. These hybrid models are among the most commercially successful licensing strategies in the software industry.

Freemium licensing

Freemium licensing provides a baseline version of the software at no cost, with premium features, capacity, or support available through paid licenses. The free tier serves as a customer acquisition channel while the paid tiers generate revenue.

Common freemium structures:

• Feature gating: Core functionality is free; advanced features require payment. Slack, Zoom, and Figma follow this model.
• Usage limits: The software is fully functional but limited by volume (storage, users, API calls). Exceeding the limits requires a paid upgrade.
• Time-limited trials: Full functionality is available for a trial period, after which a paid license is required.

Dual licensing

Dual licensing makes the same software available under two different licenses, typically one open-source and one commercial. Users choose whichever license fits their needs.

The typical pattern:

• Open-source license (usually GPL or AGPL): Free to use, but the copyleft obligations apply. If you distribute the software or make it available over a network, your derivative work must also be open source.
• Commercial license: Paid license that removes the copyleft obligation, allowing proprietary use and distribution without source code disclosure.

MySQL (now owned by Oracle), Qt, and Ghostscript all use dual licensing. This model works well for infrastructure software where many users are willing to comply with the open-source terms, but enterprise customers need proprietary flexibility.

Public Domain and Unlicensed Software

Public domain dedications represent the most permissive end of the licensing spectrum. The rights holder waives all copyright interest in the software, placing it in the public domain with no conditions whatsoever.

Creative Commons Zero (CC0)

CC0 is a legal tool that waives all copyright and related rights to the maximum extent permitted by law. In jurisdictions where full copyright waiver is not legally possible (such as some European countries where moral rights cannot be waived), CC0 includes a fallback permissive license to achieve the same practical effect.

The Unlicense

The Unlicense is a public domain dedication specifically designed for software. It explicitly waives copyright interest and includes a fallback permissive license for jurisdictions that do not recognize public domain dedication.

Risks of truly unlicensed software

Software published without any license is not in the public domain. It is fully copyrighted with no permissions granted. Under default copyright law, no one may use, copy, modify, or distribute it. Repositories on GitHub without a LICENSE file fall into this category. Despite being publicly visible, the code cannot legally be used.

Choosing Between the Different Types of Software Licenses

Selecting the right license requires balancing your commercial goals, your attitude toward community contribution, and the legal obligations you are willing to accept. Here is a decision framework.

Choose a proprietary license if:

• Revenue from software licensing is a primary business model
• You need full control over distribution and derivative works
• The software contains trade secrets or competitive advantages you want to protect
• Your customers expect dedicated support, SLAs, and enterprise features

Choose a permissive open-source license (MIT, Apache 2.0) if:

• You want maximum adoption and ecosystem growth
• You are building a developer tool, library, or framework where broad compatibility matters
• You want to attract contributions without deterring commercial users
• Patent protection is important (favor Apache 2.0 over MIT)

Choose a copyleft license (GPL, AGPL) if:

• You want to ensure all derivative works remain open source
• You plan to use dual licensing as a revenue model
• You want to prevent competitors from creating proprietary forks
• Community contribution and transparency are core values

Choose a public domain dedication (CC0, Unlicense) if:

• You want to maximize reuse with zero friction
• The software is a small utility, code sample, or educational resource
• You have no interest in controlling how the software is used

License Compatibility and Compliance

When building software that incorporates components under different licenses, compatibility is a critical concern. Not all licenses can be combined in a single product.

Key compatibility rules:

• Permissive licenses are broadly compatible: MIT, Apache 2.0, and BSD code can be included in GPL projects, proprietary projects, and each other.
• GPL is one-directional: GPL code can include permissive-licensed components, but permissive-licensed projects cannot include GPL code without the entire project becoming GPL.
• Apache 2.0 and GPL v3 are compatible: Code can flow between them. Apache 2.0 and GPL v2 are not compatible due to the patent clause.
• AGPL is the most restrictive: AGPL components trigger network-interaction copyleft for the entire combined work.

Maintaining license compliance is part of broader legal compliance for any software business. If your product collects user data, your privacy policy must accurately describe those practices. If users agree to terms when using your product, a well-drafted terms of service works alongside your license to define the complete legal relationship. Tools like TermsBox can help generate and maintain these compliance documents automatically.

Software composition analysis

For any non-trivial software project, manual license tracking is impractical. Software composition analysis (SCA) tools automate this process:

1. Scan your codebase and dependency tree to identify all third-party components
2. Map each component to its license
3. Flag license conflicts and compatibility issues
4. Generate compliance reports and notices

Popular SCA tools include FOSSA, Snyk, Black Duck, and WhiteSource. Running SCA as part of your CI/CD pipeline catches license issues before they reach production.

How License Terms Affect Data Privacy Obligations

The type of software license you use or grant can have downstream effects on your data privacy obligations. This is an often-overlooked intersection between licensing and compliance.

Proprietary SaaS products that process customer data must comply with data protection regulations regardless of the license model. Under Article 28 of the GDPR, any software vendor acting as a data processor must have a Data Processing Agreement in place. The CCPA (Cal. Civ. Code Section 1798.140) imposes similar requirements on service providers.

Open-source software creates a different dynamic. If you deploy an open-source application that collects user data, you are the data controller. The open-source license governs the code, but privacy law governs the data. You still need a compliant privacy policy and appropriate cookie policy for your deployment, even though the underlying software is freely licensed.

Whether you are licensing software from a vendor or publishing your own, aligning your license terms with your privacy obligations avoids gaps in your compliance posture.

Frequently Asked Questions

What are the main types of software licenses?

The main types of software licenses are proprietary licenses (per-user, per-device, enterprise, subscription), permissive open-source licenses (MIT, Apache 2.0, BSD), copyleft open-source licenses (GPL, LGPL, AGPL), freemium licenses, and public domain dedications (CC0, Unlicense). Proprietary licenses restrict usage to what the vendor explicitly grants. Open-source licenses allow use, modification, and redistribution under varying conditions.

What is the difference between permissive and copyleft open-source licenses?

Permissive licenses (MIT, Apache 2.0, BSD) allow you to use, modify, and redistribute the code with minimal obligations, usually just attribution. Copyleft licenses (GPL, LGPL, AGPL) grant the same freedoms but require that derivative works be distributed under the same license terms. This means if you modify GPL code and distribute it, you must release your modifications as open source under the GPL.

Can I use open-source licensed software in a commercial product?

Yes, but your obligations depend on the license type. Permissive licenses like MIT and Apache 2.0 allow commercial use with minimal requirements, typically just including the copyright notice. Copyleft licenses like the GPL also allow commercial use but require you to release the source code of derivative works under the same license. The LGPL offers a middle ground, allowing proprietary software to link to LGPL libraries without triggering copyleft obligations.

How do I choose the right software license for my project?

Consider your goals: if you want maximum adoption and community contribution, choose a permissive license like MIT or Apache 2.0. If you want to ensure all derivative works remain open source, choose a copyleft license like GPL v3. If you want full control and revenue from your software, choose a proprietary license. For commercial products that include open-source components, verify that all component licenses are compatible with your distribution model.