An effective license position (ELP) is a reconciliation that compares, for each software product, edition and license metric, the quantity of license entitlements an organization holds with the quantity it requires under the vendor’s counting rules for what it has deployed or used. The result is expressed per metric as a surplus (more entitlements than required), a balance, or a shortfall (fewer entitlements than required). An ELP is a point-in-time statement: it is valid for the deployment data, contract documents and vendor rules in force on the date it is computed.
The term is practitioner usage in software asset management (SAM) rather than a term defined in the published abstracts of the ISO/IEC 19770 standards. Those standards nevertheless supply the building blocks an ELP relies on: an asset management system (Part 1), software identification tags (Part 2), an entitlement schema (Part 3), resource utilization measurement (Part 4) and a shared vocabulary (Part 5).[1][2][3][4][5]
History
Reconciling purchased licenses against installed software is as old as volume licensing, but the vocabulary for doing it consistently is more recent. ISO/IEC 19770-5, first published in 2013 and revised in 2015, sets out consistent terms for the whole 19770 family.[2] ISO/IEC 19770-3 (2016) added a transport format for entitlements “including associated metrics”, with the stated aims of easier proof of ownership, cost optimization and license compliance management.[3] ISO/IEC 19770-4 (2017) added an information structure for resource utilization measurement, which covers the usage side of the comparison.[4]
Public-sector audits have also shaped the practice. In January 2024 the U.S. Government Accountability Office reported that none of nine agencies it examined had fully determined whether their five most widely used software licenses were over- or under-purchased, and recommended that agencies compare license inventories with purchases on a regular basis, which is the core ELP operation.[11]
Scope and definitions
An ELP combines three distinct kinds of data. Confusing them is the most common source of error.
| Input | What it records | Typical source |
|---|---|---|
| Entitlements | What the organization has the right to use: product, edition, metric, quantity, term, and any program overlay | Ordering documents, license statements, enrollment records; see Software entitlement |
| Deployments | Where the software is installed or running, on what hardware or virtual environment | Discovery and inventory tools, SWID tags, configuration databases |
| Usage | Who or what accesses the software, and how much | Access logs, user directories, vendor measurement tools, resource utilization records |
Which of the last two matters depends on the metric. A capacity metric counts the environment the software is installed and/or running on; a user metric counts people or devices authorized to use it; a consumption metric counts measured activity. Oracle’s Processor metric, for example, is defined over all processors where the programs are installed and/or running, while its Named User Plus metric counts every individual authorized to use the programs whether or not they are actively using them at any given time, plus non-human operated devices that can access them.[6] Cisco’s Enterprise Agreement terms define consumption to include software that is installed, activated or merely available, even if not actively used.[13] In both cases, measured activity alone would understate the requirement.
A license requirement is the number of licenses the vendor’s rules demand for the observed deployment or usage, after applying multipliers, floors, rounding and use rights. The ELP for a metric is entitlement minus requirement.
How it works
The calculation is done per vendor, product and metric, never as a single cross-vendor total. A typical sequence:
- Fix the scope and date. Name the legal entities, sites and environments covered, and the date the position represents.
- Normalize entitlements. List every entitlement by product, edition, metric and quantity. Remove expired term licenses and subscriptions, and note which licenses carry active support, because some use rights depend on it (see Software maintenance and support).
- Collect deployment and usage data. Match discovered installations to licensable products and editions, including options and add-ons that are licensed separately.
- Select the governing rule set. Identify the definitions and rules the contract incorporates, with their effective dates. For Oracle, the ordering document incorporates the License Definitions and Rules; for Microsoft, the Product Terms entry for the product and program.[6][8]
- Compute the raw count for each metric: cores, sockets, users, devices or transactions.
- Apply multipliers and rounding, such as a core factor.
- Apply floors and minimums, such as users per processor or cores per processor.
- Apply use rights and exceptions: virtualization and partitioning policy, disaster-recovery or failover rights, cloud mapping, and any program overlay.
- Compare the requirement with the entitlement and record a surplus or shortfall for each line.
- Document the evidence for each line: the data extract, the rule and the document that states it.
Worked example
The example below uses rows from this wiki’s catalog. It is illustrative arithmetic, not a statement about any real estate.
Oracle Database Enterprise Edition on one physical server. The server has two Intel Xeon processors of a family listed on the Oracle Processor Core Factor Table at 0.5, with 16 cores each.[7]
- Processor requirement: Oracle aggregates all cores, multiplies by the core factor and rounds fractions up (Processor Core Factor rule). 32 cores × 0.5 = 16 Processor licenses.[6]
- Named User Plus alternative: Enterprise Edition carries a minimum of 25 Named Users Plus per Processor (Named User Plus minimum), and all actual users must also be licensed. With 120 authorized users, the requirement is the greater of 120 and 25 × 16 = 400, so 400 NUP.[6]
SQL Server Enterprise under the Per Core model. A physical host with two 6-core processors is licensed by physical core; a separate virtual machine with 2 virtual cores is licensed by individual virtual OSE, which the Product Terms make available only for subscription licenses or licenses with active Software Assurance.[8]
- Per Core, physical: licenses equal physical cores, subject to a minimum of four per physical processor (SQL Server Per Core floor). 12 cores, and 6 ≥ 4 per processor, so 12 core licenses.
- Per Core, virtual OSE: licenses equal virtual cores, subject to a minimum of four per virtual OSE. 2 virtual cores, so 4 core licenses.
Assembled into a position:
| Product / edition | Metric | Entitlement | Requirement | Position |
|---|---|---|---|---|
| Oracle Database EE | Named User Plus | 300 | 400 (floor 25 × 16 Processors) | Shortfall 100 |
| SQL Server Enterprise | Per Core (physical) | 12 | 12 | Balanced |
| SQL Server Enterprise | Per Core (virtual OSE) | 2 | 4 (floor 4 per VM) | Shortfall 2 |
In the first line the organization has fewer users than NUP licenses, yet is short because the floor, not the headcount, sets the requirement. In the last line, a two-core VM needs four licenses. Neither shortfall would appear if the ELP counted only raw usage.
Common errors
Errors in an ELP usually come from applying the wrong rule rather than from arithmetic.
- Mixing metrics. Entitlements under one metric cannot be netted against requirements under another unless the contract says so. Processor and NUP positions are computed separately.
- Ignoring floors and rounding. Per-processor user minimums, per-processor or per-VM core minimums, and round-up rules often dominate the result, as the worked example shows.[6][8]
- Assuming sub-capacity counting. Several vendors count full physical capacity unless a stated exception applies. IBM’s Client Relationship Agreement requires capacity-based programs to be licensed to the full capacity of the server unless sub-capacity usage is available and its requirements are met.[10] Oracle’s partitioning policy states that soft partitioning, which it illustrates with technologies including VMware and Oracle VM, is not permitted as a means to limit the licenses required, unless the document says otherwise.[9]
- Counting only current usage. Some programs count anything used or installed during a period. Microsoft’s Enterprise Agreement true-up guidance, for example, asks customers to account for products used or installed at any time since the last true-up, even if no longer in active use.[12]
- Using the wrong edition or rule version. Standard Edition 2 is counted by occupied socket, not by core factor; a rule’s effective date matters when documents change.[6]
- Losing use rights with support. Rights such as licensing by virtual OSE for SQL Server depend on active Software Assurance or a subscription.[8]
- Inconsistent data. GAO found that agency license data were inconsistent and incomplete, which prevented agencies from identifying their most widely used and most costly products.[11]
Standards and frameworks
ISO/IEC 19770-1 specifies requirements for an IT asset management system and states that it can be used by internal and external parties to assess an organization’s ability to meet its own IT asset management requirements; an ELP is one of the outputs such a system typically produces.[1] The other parts map onto the three inputs:
| ELP input | ISO/IEC 19770 part |
|---|---|
| Entitlements | Part 3, entitlement schema (Ent), which notes that the original licensing documents remain definitive and take precedence over the encapsulation[3] |
| Deployments | Part 2, software identification (SWID) tags[5] |
| Usage | Part 4, resource utilization measurement (RUM)[4] |
| Vocabulary | Part 5, overview and vocabulary[2] |
Vendors also publish their own measurement procedures, which define the usage data they accept. SAP’s Software Use Rights, for example, provide for system measurement with unaltered SAP tools and self-declaration forms.[14]
Relationship to other disciplines
An ELP is the quantitative core of license compliance work and of preparation for a software license audit. It feeds true-up orders under enterprise agreements, renewal and support decisions, and optimization, where surplus entitlements are reharvested or support on them is reconsidered. Within software asset management and IT asset management, it connects the procurement record to the technical inventory.
Criticism and challenges
An ELP is only as reliable as its inputs and its rule interpretation. Vendor rules can be revised, published as educational documents that are not incorporated into contracts, or superseded by negotiated terms; Oracle’s partitioning policy, for instance, states that it is educational and may not be incorporated into any contract.[9] Two parties can therefore compute different positions from the same data. For that reason, each line of an ELP should cite the rule and document it relies on.
Out of scope
This article does not cover hardware asset positions, security vulnerability data, or the pricing of shortfalls. Vendor-specific counting is covered in the vendor articles, such as Oracle Database licensing and SQL Server licensing.