Types of software licenses: a guide for enterprise IT teams

TL;DR

• Proprietary licenses (perpetual, subscription, per-seat) still make up most enterprise software spend and carry the biggest shelfware risk. 

• Open-source licenses fall into two camps: permissive (MIT, Apache 2.0, BSD) with minimal obligations, and copyleft (GPL, AGPL, LGPL) with strict sharing requirements. 

• Source-available licenses (SSPL, BSL, Elastic License) look like open source but restrict commercial use. Several major vendors have switched to them in the past two years. 

• Freeware and freemium models bypass procurement, creating shadow IT and compliance blind spots. 

• Every license type creates specific cost, compliance, and audit obligations. Without visibility across all of them, you’re managing risk with incomplete data. 

What is a software license? 

A software license is a legal agreement that defines how you can use, distribute, and modify software. It’s the contract between the vendor and your organization.

Every piece of software in your estate carries a license. Commercial applications. Open-source libraries embedded in internal tools. The freemium SaaS app someone in marketing signed up for last quarter. Each one comes with terms, and most enterprise IT teams haven’t read them all.

The license type determines what you can do with the software, what you owe the licensor, and what happens when you get it wrong. For some licenses, the penalty is an invoice. For others, it’s a legal obligation to release your own source code.

The challenge for software asset management teams is that license types vary dramatically. Not just between vendors, but within a single vendor’s product portfolio. Managing them requires knowing what you have, what terms apply, and whether those terms have changed since you first deployed the software.

Proprietary and commercial licenses

Proprietary licenses are the most familiar category for enterprise IT. You pay a vendor for the right to use their software under specific terms. The vendor retains ownership of the code, and your rights are limited to what the agreement allows. 

This is the model that drives most enterprise software spend. It’s also where the most visible waste occurs. 

Perpetual licenses 

A perpetual license is a one-time purchase. You pay upfront and can use the software indefinitely. But “indefinitely” comes with caveats. 

Most perpetual licenses require separate maintenance and support fees to receive updates, patches, and vendor support. Let those lapse and you’re running unsupported software with no security patches and no access to the vendor’s help desk. Perpetual licensing is still common for on-premises deployments: Microsoft Volume Licensing, Oracle database licenses, SAP. 

The primary risk here is shelfware. Licenses purchased years ago, deployed once for a project that ended, and never reclaimed. Without usage data tied to each license, you won’t catch this until the next renewal cycle or, worse, during a vendor audit when the cost of reconciliation is much higher. 

Subscription licenses 

Subscription licensing has become the default for cloud and SaaS software. You pay recurring fees for continued access. Stop paying, lose access. 

The model bundles updates and support into the subscription fee, which simplifies vendor management. But it introduces a different risk: cost creep. Subscriptions auto-renew. Teams add seats. Nobody removes the ones that go unused. 

Over three to five years, subscription costs can exceed what a perpetual license would have cost, especially when utilization is low. And because SaaS subscriptions are often purchased by individual departments on corporate credit cards, IT may not even have a complete picture of what’s been bought. The renewal date passes, the charge hits, and another year of underused licenses begins. 

Other commercial models 

Beyond perpetual and subscription, vendors use a range of licensing structures: 

• Per-seat/per-user: Each license is tied to an individual user. Common in productivity and collaboration tools. 

• Per-device: The license is tied to specific hardware. Still used in manufacturing and embedded systems. 

• Concurrent/floating: A fixed number of licenses shared across a user pool. Only a set number of people can use the software simultaneously. 

• Site licenses: Unlimited use within an organization or physical location. Simple to manage, but expensive if usage doesn’t justify the flat fee. 

• Usage-based: You pay based on consumption: API calls, compute hours, data volume. Increasingly common in cloud infrastructure and AI services. 

Each model creates different tracking requirements. Per-seat licenses need user-level assignment data. Concurrent licenses need real-time usage monitoring. Usage-based models need consumption analytics. 

Without visibility into how licenses are actually used, you can’t manage cost or compliance for any of them. And most enterprises run a mix of all these models simultaneously across hundreds of vendors. For any IT asset management team preparing for a renewal or responding to an audit, that complexity is the daily reality. 

Open-source licenses

Open-source software can be freely used, modified, and shared, but that doesn’t mean it’s free of obligations. 98% of commercial codebases contain open source components¹, according to Black Duck’s 2026 OSSRA report. The specific license attached to each component determines what you can and can’t do with it.

Permissive licenses

Permissive licenses impose minimal restrictions. You can use, modify, and redistribute the software, including in proprietary products, as long as you preserve the original copyright notice.

• MIT License: The most widely adopted open-source license, found in roughly 32% of open source projects². Allows commercial use, modification, and distribution with one main requirement: include the original copyright notice. No patent protections.

• Apache License 2.0: Covers roughly 16% of projects, according to Fossa. Similar freedoms to MIT, but adds an explicit patent grant and requires stating changes made to the code. Used by major projects like Kubernetes and Android.

• BSD licenses: A family of licenses (2-clause, 3-clause) similar to MIT. The 3-clause variant adds a restriction preventing use of the project’s name for endorsement.

Permissive licenses carry the lowest compliance overhead. But “low overhead” still means tracking which components use which licenses and ensuring attribution requirements are met across your estate.

Copyleft licenses

Copyleft licenses require that derivative works be distributed under the same license terms. This is where enterprise compliance gets significantly harder to manage.

• GPL (v2, v3): The strongest copyleft family, used by roughly 21% of open source projects, according to Fossa. If you modify and distribute GPL-licensed code, you must release your modifications under the GPL with full source code. GPLv3 adds patent protections and anti-Tivoization clauses.

• AGPL (v3): Extends the GPL to network use. If you run modified AGPL software as a service, you must provide source code to your users. This is the license that catches SaaS teams off guard, especially those running platforms that incorporate open-source components without realizing the AGPL reaches through to hosted deployments.

• LGPL: A weaker copyleft variant. You can link to an LGPL library from proprietary code without copyleft obligations on your larger application. But modifications to the library itself must be shared.

• MPL 2.0: File-level copyleft. Modified files must stay under the MPL, but they can be combined with proprietary code in the same project.

The risk with copyleft is often the license you didn’t know was there. A GPL component buried three layers deep in a dependency chain can create disclosure obligations for the entire work. Without visibility into your full dependency tree, you won’t know that obligation exists until an audit surfaces it.

Source-available licenses

Source-available licenses are a newer category that has created real confusion in enterprise IT. The source code is visible and you can read it, sometimes modify it. But the license restricts commercial use in ways that disqualify it from the OSI’s open-source definition.

The distinction matters because your teams may be treating source-available software as if it were open source. If someone evaluated a tool when it carried an Apache 2.0 license and the vendor has since switched to a source-available license, the terms governing your use have changed even though the code looks the same.

The most common source-available licenses:

• SSPL (Server Side Public License): Created by MongoDB. If you offer the software as a service, you must release the entire service stack’s source code. Not OSI-approved.

• BSL (Business Source License): Used by HashiCorp and MariaDB. Restricts certain commercial uses for a set period (typically four years), then automatically converts to a permissive open source license.

• Elastic License 2.0: Prohibits offering the software as a managed service. Not OSI-approved.

What makes source-available licenses an enterprise concern is the relicensing trend. Between 2018 and 2024, several major infrastructure vendors changed their licenses away from open source³:

• HashiCorp moved Terraform, Vault, and Consul from MPL 2.0 to BSL 1.1 in 2023

• Elastic moved Elasticsearch and Kibana from Apache 2.0 to SSPL in 2021 (then returned to AGPLv3 in 2024)

• MongoDB moved from AGPLv3 to SSPL in 2018 

• Redis moved from BSD 3-Clause to SSPL in 2024 (then returned to AGPLv3 in 2025)

Software you deployed under one license may now operate under different terms. If you deployed Terraform under the MPL and haven’t tracked the change, you could be running it under the BSL without knowing. Without monitoring license changes across your portfolio, compliance gaps accumulate.

Freeware, shareware, and freemium

This category receives less scrutiny than commercial or open-source licenses, but it carries its own compliance and cost risks.

• Freeware: Free to use, but proprietary. No source code access, no modification rights. Think Adobe Acrobat Reader or certain security utilities. The vendor controls everything, you just don’t pay for it.

• Shareware/trialware: Free for a trial period, then requires payment. The license terms change when the trial expires. If nobody tracks expiration dates, your organization may be using software it’s no longer licensed for.

• Freemium: A basic tier is free; premium features require a paid subscription. This model dominates SaaS. The risk is that teams sign up for free tiers without involving procurement, then upgrade to paid plans on corporate credit cards. That creates spend nobody in IT knows about.

These models share a common trait: they tend to bypass procurement workflows entirely. Someone downloads a free tool. It works. It spreads across the team through convenience, not malice. By the time IT discovers it, there are dozens of installations with no license tracking, no usage data, and no compliance review.

This is how shadow IT grows. And the compliance exposure is real: freeware often includes terms that restrict commercial use or limit liability in ways that conflict with enterprise security policies. A “free” PDF tool might bundle telemetry. A freemium SaaS product might store data in jurisdictions that violate your data residency requirements. The cost is zero, but the compliance exposure is real.

Why license type matters for enterprise IT

License obligations vary across every category covered above. A MIT-licensed library requires a copyright notice. A GPL-licensed component can require full source code disclosure. A proprietary subscription that auto-renewed last month might be costing you thousands for software nobody uses. A source-available tool you adopted two years ago might now carry restrictions that didn’t exist when you deployed it.

68% of audited codebases contain license conflicts⁴, the largest year-over-year increase in 11 years, according to Black Duck’s 2026 OSSRA report. AI-generated code introducing open-source snippets without clear license attribution partly drives the surge.

The risks fall into three categories:

• Compliance risk: Software audits increasingly cover open source, not just proprietary license counts. GPL enforcement actions have established legal precedent. In Artifex v. Hancom (2017), a U.S. court ruled that open-source licenses are enforceable contracts⁵. In SFC v. Vizio (2022, ongoing), the Software Freedom Conservancy established that end users, not just licensors, can bring enforcement claims. German courts have consistently upheld GPL enforcement in European jurisdictions.

• Cost risk: Shelfware from unused perpetual licenses. Subscription creep from unmanaged renewals. Duplicate tools across departments. The U.S. Government Accountability Office found that federal agencies could save hundreds of millions by better managing software licenses. At the enterprise level, the same patterns play out: teams buy overlapping tools, nobody decommissions the old ones, and renewal cycles lock in waste for another year.

• M&A and due diligence risk: Acquirers now audit open-source license composition as part of technology due diligence. License conflicts, especially copyleft contamination, can reduce valuations or stall deals entirely. An unresolved GPL obligation in a codebase creates liability that buyers price into their offers or walk away from.

The common thread across all three risk categories is visibility. You can’t manage what you can’t see. Most organizations have a clear picture of their commercial license counts but almost no visibility into the open-source components, source-available tools, and shadow IT applications running across their estate.

How to manage software licenses at scale

Managing software licenses across an enterprise isn’t a one-time project. License terms change. Vendors relicense. Teams add new tools. People leave and their seats go unused. What you need is continuous visibility across all license types, not just the ones that generate invoices.

The typical approach, a spreadsheet maintained by IT procurement, breaks down quickly. It can’t track transitive open-source dependencies, won’t alert you when a vendor changes license terms, and goes stale the moment someone installs a new tool without logging it.

Effective software license management at enterprise scale requires:

• Automated discovery across SaaS, on-premises, and cloud environments that identifies all software, including open-source components embedded in applications and SaaS tools adopted outside procurement

• Centralized license tracking that brings commercial, open source, and source-available licenses into a single view instead of scattered spreadsheets maintained by different teams

• Usage monitoring over time that catches changes: new deployments, version upgrades, license term shifts. It flags unused licenses before renewal so you can reclaim or cancel them.

• Audit-ready reporting that gives you a defensible record of what’s deployed, what’s in use, and what license terms apply, so when an audit request arrives you have reliable evidence rather than guesswork.

The goal is control, with compliance as the baseline. When you can see every license across your estate, you can right-size renewals, eliminate waste, and respond to audits with confidence instead of scrambling to build an inventory after the fact.

Xensam provides this visibility across your entire software estate. Automated discovery identifies software across SaaS, on-prem, and cloud with no heavy implementation. Customers start identifying waste and compliance gaps within days, not months.

Ready to see what’s running across your software estate? Xensam gives you complete visibility over every software license, SaaS, on-prem, and cloud, so you can control costs, stay compliant, and make confident decisions at renewal time. 

FAQ

What are the main types of software licenses? 

The main categories are proprietary/commercial (perpetual, subscription, per-seat), open source (permissive and copyleft), source-available (visible source code with commercial restrictions), and freeware/freemium (free to use with varying terms). Each type creates different obligations for use, distribution, and compliance. 

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

Permissive licenses (MIT, Apache 2.0, BSD) allow nearly unrestricted use with minimal requirements, usually just attribution. Copyleft licenses (GPL, AGPL, LGPL) require that derivative works be shared under the same license terms. In the case of AGPL, this extends to software offered as a network service. 

Can you use open-source software commercially? 

Yes. Both permissive and copyleft licenses allow commercial use. The difference is in the obligations. Permissive licenses have few restrictions. Copyleft licenses may require you to release your modifications or, in some cases, your entire derived work under the same terms. 

What happens if you violate a software license? 

For proprietary licenses, violations typically result in audit penalties and back-payment obligations. For open-source licenses, enforcement can include lawsuits. Courts have ruled that open-source licenses are enforceable contracts. Penalties can include injunctions, damages, and mandatory source code disclosure. 

What’s the difference between open source and source available? 

Open-source licenses (as defined by OSI) allow unrestricted use, modification, and redistribution. Source-available licenses let you view and sometimes modify the code, but restrict commercial use, typically blocking you from offering the software as a competing managed service. Source-available licenses are not OSI-approved. 

How do you track software licenses across an organization? 

Manual tracking breaks down at enterprise scale. Effective license management requires automated discovery tools that identify software across all environments (SaaS, on-prem, cloud), centralized tracking that covers all license types, and continuous usage monitoring to catch changes in deployment and license terms.