Concurrent vs Named User vs Processor Licensing: The Enterprise Guide

Why Licensing Metrics Matter More Than List Prices

Enterprise software negotiations focus heavily on list price discounts. A 40 percent discount off Oracle Database Enterprise Edition list price looks impressive until you realise the organisation has licensed 200 processor cores on a server cluster where named user plus licensing would have cost a fraction of the processor licence bill. The metric determines the cost structure — the discount is applied on top of whatever metric the contract uses.

Metric selection is therefore the most consequential decision in any enterprise software procurement. Getting it right requires understanding how each model is defined, how vendors enforce each model during audits, and what the cross-over points are where one model becomes more cost-effective than another.

Named User Licensing: The Per-Seat Model

Named user licensing assigns a licence to a specific, identified individual or device. The licence is consumed regardless of whether that person or device is actively using the software. Access is permissioned at the identity level — only the named individual or device may use the software.

How Named User Works in Practice

In Oracle's implementation, the metric is called Named User Plus (NUP). A NUP licence must be purchased for every person or automated device that accesses the Oracle software, including service accounts, batch processes, and integration jobs. There is a minimum NUP count per processor: Oracle requires a minimum of 10 NUP licences per processor licence (adjusted by core factor) for most products.

IBM uses named user metrics for many of its software products, including Db2 and WebSphere, typically expressed as Authorised User licences. The IBM authorised user definition is similar to Oracle's: the licence must cover everyone who is authorised to access the software, not just concurrent users.

SAP uses the Named User metric through its User-Based Licensing model, which segments users into multiple categories (Professional Users, Limited Professional Users, Employee Users) based on what functionality they access. Each category has a different price per named user, creating an optimisation opportunity through user segmentation.

When Named User Is Cost-Optimal

Named user licensing is cost-optimal when the total number of users requiring access is relatively small compared to the server infrastructure. For a small team of 50 database developers accessing an Oracle Database installation on a 64-core server, NUP licensing (50 licences) will be dramatically cheaper than processor licensing (32 processor licences at the Oracle core factor for Intel, where 64 cores × 0.5 factor = 32 processor licences).

The break-even calculation between named user and processor licensing depends on both the number of users and the server configuration. For Oracle Database Enterprise Edition, the approximate break-even is: NUP count ÷ 10 = processor licence count. If your total authorised users divide by 10 to give a number smaller than your processor licence requirement, NUP is cheaper. If it gives a larger number, processor licensing is cheaper.

Concurrent User (Floating) Licensing: The Shared Pool Model

Concurrent user licensing, also called floating licensing, permits any number of identified users to be registered in the system, but limits the number who may use the software simultaneously. The licence count matches the peak number of simultaneous users, not the total user population. A floating licence pool of 100 can serve a registered population of 1,000 users, provided no more than 100 use the software at the same time.

How Concurrent User Licensing Works

Floating licensing is implemented through a licence server (often FlexLM, Reprise RLM, or a vendor-specific server) that issues tokens to users on demand and reclaims them when the user closes the application or the session times out. When all tokens in the pool are consumed, new connection attempts are queued or denied until a token is released.

IBM has historically used concurrent user licensing for many of its analytics and development tools, including SPSS Statistics. The IBM SPSS concurrent licence model allows a pool of tokens to be shared across an organisation's user base, with the pool sized to accommodate the peak simultaneous user count rather than the total population of potential users.

SAP BusinessObjects BI has offered a concurrent sessions metric as an alternative to named users for report consumers. A concurrent session licence allows a flexible pool of users to access reports and dashboards, with the licence count sized to the maximum simultaneous session load rather than the total registered user base.

When Concurrent Licensing Is Cost-Optimal

Concurrent licensing is cost-optimal when the total user population is large but the simultaneous usage rate is low. The mathematical threshold is the ratio of peak concurrent users to total users. If fewer than 20 to 30 percent of your total user population uses the software simultaneously at any given time, concurrent licensing typically delivers significant savings versus named user licensing, despite the per-token price premium of 3 to 5 times versus named user unit rates.

Typical use cases where concurrent licensing wins include analytics and reporting tools used intermittently throughout the day, development tools where developers work in sessions of defined duration, CAD and simulation software where projects are worked on sequentially rather than simultaneously, and shift-based operational environments where different cohorts use the software at different times.

Processor-Based Licensing: The Infrastructure Model

Processor-based licensing charges for the hardware capacity on which the software is installed, rather than the number of users. It grants unlimited users access in exchange for covering the underlying compute infrastructure. Processor licensing is the dominant metric for database and middleware products at major vendors.

Oracle Processor Licensing: Core Factors

Oracle's processor metric is expressed in Oracle Processor licences. The calculation requires multiplying the physical core count on each server where Oracle software is installed by the applicable core factor from Oracle's Processor Core Factor Table, then rounding up to the nearest whole number.

Core factors vary significantly by processor type. Intel Xeon and AMD EPYC processors carry a 0.5 core factor, meaning each physical core counts as half an Oracle processor licence. IBM POWER processors carry a 1.0 factor. Sun UltraSPARC T-series processors carry factors between 0.25 and 0.5. The core factor selection is based on processor family and model — using the wrong factor in a cost model is a common and expensive mistake.

For a server with two Intel Xeon 32-core processors (64 total physical cores), the Oracle processor licence requirement is 64 × 0.5 = 32 processor licences. For the same workload on an IBM POWER10 server with 20 cores, the requirement would be 20 × 1.0 = 20 processor licences. Server architecture decisions have direct Oracle licence cost implications.

IBM PVU and VPC Licensing

IBM uses two processor-based metrics: Processor Value Units (PVU) and Virtual Processor Cores (VPC). The PVU metric assigns a specific PVU value per core based on the processor type (ranging from 70 to 120 PVUs per core depending on the processor), and licence requirements are expressed as a total PVU count.

IBM transitioned many products from PVU to VPC licensing in recent years. VPC is simpler — it counts virtual processor cores directly, without the PVU weighting table. The PVU to VPC transition created compliance gaps for many organisations that had optimised their deployments around PVU sub-capacity licensing through the IBM Licence Metric Tool (ILMT). Organisations that moved to VPC without reconfiguring their ILMT deployment or recalculating their licence requirements against the VPC metric frequently found themselves either over- or under-licensed at the transition point.

This is why ILMT remains critical in IBM compliance. Sub-capacity licensing — where IBM allows organisations to licence only the VPC or PVU capacity actually allocated to the VM where IBM software runs, rather than the full physical host capacity — is only valid when ILMT is correctly installed and configured. An organisation without proper ILMT deployment must licence the full physical hardware capacity, which can increase licence requirements by a factor of 5 to 20 compared to sub-capacity.

When Processor Licensing Is Cost-Optimal

Processor licensing is cost-optimal when the user base is large relative to the server infrastructure. Once the user-to-processor ratio exceeds the vendor's minimum NUP-per-processor threshold, processor licensing becomes cheaper. For Oracle, once your authorised user count exceeds 10 times the processor licence count, processor licensing wins on cost.

Processor licensing is also preferable in scenarios where user counts fluctuate (adding users does not change the licence cost), where automated system-to-system access is required (which would require NUP licences under the named user model), and where the software is accessed by a very large number of users through a web front-end or service layer.

Virtualisation and Cloud: How Metrics Shift in Modern Infrastructure

The emergence of virtualisation and cloud infrastructure has complicated all three licensing metrics in ways that create significant compliance risk for organisations that apply on-premises licensing rules to virtualised or cloud environments.

Processor Licensing in Virtual Environments

Oracle does not recognise virtualisation as a limiting factor for processor licensing purposes (with a very narrow exception for Oracle's own OVM and Solaris Zones). Oracle software installed on a VM running on a physical server cluster requires processor licences for every physical core in the cluster — not just the cores allocated to the VM — unless a hard partition boundary that Oracle explicitly recognises is in place.

This rule creates the single largest source of Oracle licence compliance risk in enterprise environments. An organisation that runs Oracle Database on a three-node VMware cluster with 20 cores per node must licence 60 processor cores (at the applicable core factor), not just the cores in the VM where the database runs. Organisations that have only licenced the VM-allocated cores are consistently found to be under-licenced during Oracle audits.

IBM handles virtualisation differently through sub-capacity licensing. With a correctly deployed ILMT, IBM software deployed in a virtualised environment can be licensed based on the peak VPC or PVU allocation to the VM, not the full physical host. This sub-capacity entitlement is IBM's explicit policy and is a legitimate and significant cost optimisation tool — provided the ILMT deployment meets IBM's technical requirements.

Cloud Licensing Considerations

Cloud environments introduce additional complexity for all three metrics. Named user licences typically transfer to cloud deployments without metric change. Processor licences in the cloud depend entirely on the vendor's cloud policy: Oracle treats each cloud vCPU as equivalent to one physical core (with no 0.5 core factor), AWS and Azure bare metal instances are licenced by physical core count with the applicable core factor, and marketplace-deployed instances follow different terms than BYOL (bring your own licence) deployments.

Concurrent licensing in cloud environments is subject to the same token pool mechanics as on-premises but requires careful architecture to ensure the licence server is accessible from all cloud-deployed user sessions without introducing latency that degrades user experience.

Choosing the Right Metric: A Decision Framework

The decision between named user, concurrent, and processor licensing should be based on four variables: total authorised user count, peak simultaneous user count, server infrastructure characteristics (core count, processor type, virtualisation), and workload profile (continuous high usage versus intermittent sporadic usage).

• Use named user when: your total authorised user count is small relative to server infrastructure, users are identifiable individuals (not automated processes), and usage is continuous across all licenced users.
• Use concurrent when: your total user population is large but peak simultaneous usage is low (under 25 to 30 percent of total users), usage is shift-based or intermittent, and the vendor supports concurrent licensing as a metric for your required product.
• Use processor when: your authorised user count is large (exceeds the minimum NUP-per-processor threshold), access is provided to automated processes or large anonymous user populations, and you want to eliminate per-user tracking overhead.

The hybrid approach — using different metrics for different user segments — is often the optimal outcome. Technical power users on processor licences, occasional business users on concurrent licences, and read-only consumers on named user or a light-weight lower-cost licence tier is the architecture that typically delivers the lowest total licence cost across a complex enterprise deployment.