Named User Plus Java Licenses Explained

Named User Plus priced Java by named people and devices, with per processor minimums. In 2026 a documented Named User Plus entitlement can still cover a defined population at a fraction of the employee metric.

What Named User Plus actually measured

Named User Plus, often shortened to NUP, is a per person metric. It counts the individuals authorized to use the licensed program and the non human operated devices that access it. The word Plus refers to that inclusion of devices alongside people. Under this model you did not pay for your whole workforce. You paid for the named users of the specific Java deployment, which for many enterprises was a defined group rather than the entire payroll.

That distinction is the heart of why NUP matters in 2026. The Universal Subscription counts every full time and part time employee, every contractor, and every temporary worker, regardless of who uses Java. Named User Plus counted only the authorized users of the program. For a deployment used by a few hundred people inside a company of tens of thousands, the difference is enormous.

The minimums that came with it

Named User Plus was never a pure headcount metric. Oracle attached minimums tied to the hardware. For many programs the rule was a set number of named users per processor, with the processor count itself adjusted by the core factor table that also governs per processor Java licensing. If your server had a high core count, the per processor minimum could require more named user licenses than you had actual users. Buyers who ignored that minimum at purchase time often found a gap at audit time.

So reading a Named User Plus entitlement correctly means checking two numbers. The count of actual named users, and the minimum the processors required. Your licensed quantity had to satisfy the larger of the two.

How Oracle counts a named user

A named user is an individual authorized to use the program, whether or not they are actively using it at any moment. That includes people who access Java indirectly through an application, which is where many counts grew. It also includes devices that run the program automatically. The careful buyer documented exactly who and what was authorized, because a vague authorization scope invites Oracle to count broadly.

An indicative comparison

The figures below are indicative and meant to show the shape of the difference, not to predict your terms.

Indicative annual cost, Named User Plus versus the employee metric

Basis	Counted unit	Indicative count for one deployment
Named User Plus	Authorized users and devices	400 named users
Per processor minimum	Cores times core factor	Check against user count
Universal Subscription	Entire counted population	20,000 employees

Four hundred named users against twenty thousand counted employees is the gap a documented NUP entitlement can defend. The employee metric does not care that only four hundred people touch the application. Your old license did.

Using a Named User Plus license in 2026

If you hold perpetual Named User Plus licenses for Java SE, the first task is to prove the quantity and the versions covered, then to confirm whether your support is current. Support and the license to use are separate. You may keep the right to run a version you licensed even after support lapses, though you lose access to new updates. Map your live users against your licensed quantity and the per processor minimum, and you will see whether you are covered, short, or holding spare capacity.

Where you are short, the buyer side answer is rarely to buy the employee metric for the whole company. It is to migrate the uncovered installations to a free OpenJDK distribution and license only the residual that truly needs Oracle Java. For how legacy positions hold up under the 2026 audit pressure, see why legacy Java licensing is still in play in 2026.

Named User Plus and virtualization

Virtualization complicates a Named User Plus position because the per processor minimum is tied to the hardware where the program can run. If Java sits on a virtual machine that can move across a large cluster, Oracle has historically argued that the minimum should reflect every processor in that cluster, not just the cores actually executing Java. The careful buyer constrains where the program can run and documents that constraint, so the minimum reflects a bounded set of processors rather than the entire farm. Without that boundary, a small named user population can attract a large per processor minimum, and the legacy license that looked generous can suddenly look short.

This is why a Named User Plus position is only as strong as the architecture around it. The metric counts people and devices, but the minimum counts hardware, and virtualization sits exactly at that seam. If you hold legacy Named User Plus licenses, mapping where the program can execute is as important as counting who is authorized to use it.

Common counting disputes

Two disputes recur in Named User Plus audits. The first is indirect access. When users reach Java through an application rather than directly, Oracle may count every one of those downstream users as a named user of Java. The buyer side response is to define the authorized population precisely and to show that the licensed quantity matches the people genuinely authorized, not every person who ever touched a connected system. The second dispute is dormant or departed users. A named user license covers an authorized individual whether or not they are active, so stale authorizations inflate the count. Keeping the authorized list current is both good hygiene and a defense.

In both disputes the pattern is the same. Oracle counts broadly by default, and the buyer narrows the count with documentation. A precise authorization scope, maintained over time, is worth more in an audit than any argument made on the day.

What documentation Oracle expects

To honor a Named User Plus position, Oracle will look for the original ordering document, the quantity of named user licenses, the programs and versions covered, and evidence that you have not exceeded the count or the per processor minimum. It will also look at your deployment to test whether the program runs only where the license allows. Assemble that record before the audit, not during it. A Named User Plus entitlement you can evidence cleanly is a defined population you already paid for. One you cannot evidence is a number Oracle will replace with its own.

When a Named User Plus position is not enough

A Named User Plus entitlement is powerful for a bounded group, but growth can outrun it. If the authorized population expands well beyond the licensed quantity, or the deployment spreads onto hardware that lifts the per processor minimum, the old license may no longer cover the estate. The buyer side response is not to default to the employee metric for the whole company. It is to measure the overage precisely, then decide whether to extend the named user count, contain the deployment, or migrate the excess to a free OpenJDK distribution.

The discipline is to keep treating the question as a deployment question rather than a headcount question. The employee metric wants you to price your whole workforce. A Named User Plus position, even one you have outgrown, anchors the conversation on the people and devices that actually use Java, which is almost always a far smaller and far cheaper number to defend.

The bottom line

Named User Plus is a per person and per device metric with a per processor floor. In 2026 it remains one of the cleanest ways to cap Java cost for a defined group of users, provided you can evidence the licenses and read the minimums correctly. For the wider context on how the metric and the audit interact, read our Oracle Java licensing guide for 2026.