How Oracle's employee-based Java metric works, and why a few installs can price your whole company

Most software licenses scale with usage: more servers, more cores or more users means a bigger bill. Oracle's current Java SE subscription doesn't work that way, and that surprises a lot of finance and procurement teams the first time they see a quote.

Since January 2023, Oracle has sold Java SE commercially as the Java SE Universal Subscription, priced on an employee metric. The count is based on the size of your organization, not on how much Java you run.

What counts as an "employee"

Oracle's definition is broad. Paraphrasing the published terms, the employee count includes:

• all full-time, part-time and temporary employees of your organization, and
• all full-time, part-time and temporary employees of your agents, contractors, outsourcers and consultants who support your internal business operations.

A few implications follow:

• It isn't limited to people who use Java. Payroll, warehouse staff, sales and executives all count, whether or not they ever touch a Java application.
• It isn't limited to where Java runs. One business unit running Oracle JDK doesn't limit the count to that business unit.
• Contractors and outsourcers can increase the number. An outsourced service desk or a large offshore development partner may add materially to the total.

The number of installations, servers or processors doesn't enter the calculation. This is the core point: deployment footprint has almost no bearing on the price. It mostly determines whether you need a subscription at all.

The published price bands

Oracle publishes list prices per employee per month, with volume bands. At the time of writing, the published list runs from $15 per employee per month in the smallest band down to $5.25 in the largest published band. Organizations above the top band negotiate directly.

The bands as commonly cited from Oracle's price list:

A worked example

Here's an illustrative organization, not a real client:

• 5,000 employees, including in-scope contractors
• Oracle JDK installed on 40 servers, running a handful of internal applications
• No other Oracle Java use

At the 3,000–9,999 band list price of $10.50 per employee per month:

5,000 employees × $10.50 × 12 months = $630,000 per year

That's roughly $15,750 per server per year for 40 servers, for a runtime that has free, drop-in-compatible alternatives.

Now suppose those 40 servers turn out to be 38 that can move to a free OpenJDK build and 2 running a vendor product certified only on Oracle JDK. The subscription price doesn't drop by 95%. It stays the same, because the metric is headcount. Removing Oracle JDK from 38 servers doesn't reduce the bill. Removing it from all 40 eliminates the bill.

This is why the employee metric makes licensing an all-or-nothing inventory problem.

Why inventory accuracy is the lever

Under per-processor licensing, a slightly incomplete inventory meant a slightly wrong number. Under the employee metric, one forgotten install can carry the full cost.

The Oracle JDKs that cause problems are rarely on the standard server build. They tend to be:

• Old Oracle JDK 8 installs on long-lived servers that nobody has rebuilt
• Oracle JDKs bundled into, or manually added to, vendor products and appliances
• Developer tooling and build agents that fetched "the Oracle JDK" years ago
• Base container images that were never updated
• Desktop installs for a single legacy client application

Finding them takes more than querying the package manager on your standard Linux build. We describe what a complete discovery looks like in finding every JVM in your estate, and the harder case of JVMs bundled inside vendor products.

Not every Oracle JDK is automatically in scope

Two nuances are worth checking before assuming exposure:

• Builds released under the No-Fee Terms and Conditions (NFTC) license. Oracle JDK 17 and later have been released under NFTC for a limited period per release. A binary released under NFTC isn't necessarily a licensing problem on its own; updates released after the free window are. See what the end of the JDK 21 free window means.
• Java included with another licensed product. Some Oracle and third-party products include a restricted Java SE license for use with that product only. That usually doesn't cover general-purpose use of the same JDK by other applications on the same host.

Both depend on specific versions, dates and contract wording. That's exactly why the inventory needs to record version, vendor, build and what each JVM is used for, not just "Java is installed here."

Making a deliberate decision

Once you know where every Oracle JDK is, the decision gets much clearer. For each install, choose one:

1. Migrate to a free OpenJDK build such as Eclipse Temurin, Amazon Corretto, Azul Zulu, Red Hat build of OpenJDK or Microsoft Build of OpenJDK. See our migration checklist.
2. Remove it if nothing actually uses it. This is more common than you'd expect.
3. Keep it, deliberately, because a vendor requires it or Oracle support is worth the cost to you. If the answer for even one install is "keep," price the subscription on your full employee count and decide knowingly.

What you want to avoid is the default outcome, where the subscription cost is set by an install nobody remembered.

A note on audits and renewals

Oracle doesn't publish audit statistics. Licensing advisors report a steady volume of Java-related compliance conversations since the metric change. Whether a conversation starts from an audit, a renewal or an inbound sales call, the party with the accurate inventory negotiates from a much stronger position.

What to do next

Start with the facts. Our JVM discovery and estate assessment quantifies your Oracle Java exposure against the employee metric, and our OpenJDK migration service removes the installs that don't need to be there.