License compliance is the condition in which an organization’s installation, use and distribution of software stays within the terms of the licenses under which it obtained that software, together with the practices that keep it there. For commercial software the terms are mostly use rights: which products, editions and quantities may be used, under which metric, where and by whom. For open source software the terms are mostly conditions attached to copying, modification and distribution: preserving notices, supplying license texts and, for copyleft licenses, making source code available on the same terms.
Compliance is binary for a given license term at a given time, but organizations usually manage it as a continuous process, because deployments, users and license terms all change.
History
Commercial license compliance grew with volume licensing and with the audit clauses that accompany it (see Software license audit). Public-sector reviews in the United States illustrate how the subject moved from procurement to management. In 2014 the U.S. Government Accountability Office found that only 2 of 24 major agencies had comprehensive software license management policies.[4] A 2024 follow-up found that license data were inconsistent and incomplete and that none of nine agencies examined had fully determined whether their most widely used licenses were over- or under-purchased.[3]
Open source compliance developed in parallel. The GNU General Public License version 3 was published in 2007.[9] The Free Software Foundation states that it began copyleft enforcement in the 1980s and published community-oriented enforcement principles, first formulated in 2001, in their current form in 2015.[12] Machine-readable license data followed: the SPDX project traces its specification work to 2010, and SPDX 2.2.1 was published as ISO/IEC 5962 in 2021.[14][15] ISO/IEC 5230, the OpenChain Specification for open source license compliance programs, was published in 2020.[16]
Scope and definitions
Compliance and optimization
Compliance and optimization look at the same effective license position from opposite sides.
| Term | Meaning | Nature of the problem |
|---|---|---|
| Under-licensing | Deployment or use exceeds entitlements under the vendor’s rules | Non-compliance with the license terms; exposed in audits and self-reporting |
| Over-licensing | Entitlements (and often support fees) exceed what is deployed or used | Wasted spend; not a breach |
| Optimization | Reducing cost while staying compliant: reharvesting, reassigning, right-sizing editions and metrics, dropping support on unneeded licenses where the rules allow | Management decision |
GAO’s 2024 recommendations ask agencies to do both: track which licenses are in use and compare inventories with purchases to find over- and under-purchasing.[3]
Commercial license terms
Commercial licenses typically make the right to use software conditional on paying for the quantity used. IBM’s Client Relationship Agreement grants use up to the number of license entitlements acquired and requires the client to acquire additional entitlements before increasing use.[7] Oracle’s License Definitions and Rules state that where user minimums apply, all actual users must also be licensed.[17] The scope of a license can also turn on how “use” is defined; in SAP UK Ltd v Diageo Great Britain Ltd the court held that, under that agreement, indirect use or access by users of third-party systems required Named User licensing.[18]
Remedies for shortfalls are set in the agreement. Under the Microsoft Customer Agreement sample, a customer must order licenses covering the period of unlicensed use within 30 days of a verification that reveals it, and pays a 25% uplift and the verification costs if unlicensed use is 5% or more of total use.[6] IBM’s agreement adds subscription and support charges for the excess, for the lesser of its duration or two years.[7]
Open source license terms
The Open Source Initiative’s Open Source Definition sets ten criteria a license must meet to be open source, including free redistribution, availability of source code and permission for derived works.[8] Open source licenses grant these permissions subject to conditions, which fall broadly into two groups.
- Notice (permissive) conditions. The MIT License, for example, permits use, copying, modification and distribution on condition that its copyright notice and permission notice are included in all copies or substantial portions of the software.[10]
- Copyleft conditions. The GNU GPL version 3 requires that a modified work distributed in source form carry notices of modification, and that the entire work be licensed under the GPL to anyone who receives a copy. Object code may be conveyed only if the corresponding source is also made available by one of the methods the license lists.[9] The FSF describes copyleft as a framework that permits ongoing sharing of a work and defends users’ freedoms, in contrast with licenses that grant freedom but do not defend it.[12]
The GPL’s conditions attach to conveying and modifying the work, and the license states that acceptance is not required merely to receive or run a copy; the compliance questions therefore arise mainly when software is passed to others.[9] Non-compliance can terminate the license. GPL version 3 provides that rights terminate on violation, but are reinstated provisionally when the violation stops, permanently if the copyright holder does not give notice within 60 days, and permanently for a first-time violation cured within 30 days of notice.[9]
Practice
Organizations that manage compliance systematically typically operate these controls:
- Entitlement records. A complete, current record of what has been bought, under which metric and terms (see Software entitlement). ISO/IEC 19770-3 names easier license compliance management among the intended benefits of a standard entitlement format.[1]
- Inventory and usage data. Discovery of installations and measurement of use, matched to licensable products and editions.
- Periodic reconciliation. A regular effective license position per vendor, and before renewals, true-ups and hardware or cloud changes.
- Change control. License review before virtualization changes, cloud migrations, mergers and new integrations, because these change how metrics are counted. GAO has documented vendor licensing terms that impose repurchase or additional fees when software moves to other cloud providers.[5]
- Open source intake and release review. Recording the licenses of components used, and checking notice and source obligations before distribution. SPDX short identifiers, drawn from the SPDX License List, give a standard way to record which license applies to a file or package.[13]
- Roles and policy. Named ownership and written policy. GAO’s 2014 report treated comprehensive policies and centralized management as the baseline for agencies.[4]
When a problem is found, remediation options include buying licenses, removing or reconfiguring deployments, or, for open source, restoring notices and supplying source code. The FSF states that its enforcement aims at bringing violators back into compliance rather than at monetary damages.[11]
Standards and frameworks
| Standard | Relevance to compliance |
|---|---|
| ISO/IEC 19770-1 | Requirements for an IT asset management system; usable by internal and external parties for assessment[2] |
| ISO/IEC 19770-3 | Entitlement schema, intended to ease proof of ownership and license compliance management[1] |
| ISO/IEC 5230 (OpenChain) | Key requirements of a quality open source license compliance program[16] |
| ISO/IEC 5962 (SPDX 2.2.1) | Data format for software package component and license metadata[15] |
SPDX states that it makes no legal interpretations of licenses or license compliance; it records facts and assertions.[14]
Relationship to other disciplines
License compliance is a core objective of software asset management and a component of IT asset management. It overlaps with procurement (buying the right metric), with legal (contract interpretation), with software engineering and supply-chain security (open source component records), and with finance (spend on surplus licenses and support).
Criticism and challenges
Compliance depends on interpreting metric definitions and policies that differ by vendor and change over time, and on data that GAO found to be inconsistent and incomplete even in large organizations.[3] GAO also notes that several products may be bundled into one license without per-product usage data, which makes it hard to tell whether the quantity bought is right.[3] For open source, the volume of components and licenses makes manual review impractical, which is the problem SPDX and OpenChain address.[14][16]
Out of scope
This article does not cover export control, data protection or accessibility compliance, and it does not give legal opinions on particular license texts.