The short version
Since January 2023, the Java SE Universal Subscription is priced per employee, every employee, whether or not they have ever touched Java. If 60 developers use Oracle Java and you employ 4,000 people, the subscription is priced against 4,000. The bill has almost nothing to do with your Java footprint. Your headcount sets it, which is exactly why shrinking what needs Oracle Java comes before licensing anything.
Oracle does not license Java by who uses it. That single design choice is why Java went from a rounding error to a boardroom line item, and why the most expensive misunderstanding in Java licensing is assuming the bill has anything to do with how much Java you run.
How does the employee metric actually work?
Before 2023, Oracle priced Java the way most software is priced: by the processor it ran on or the named user who ran it. The Java SE Universal Subscription replaced both with one metric: your total employee count.
And Oracle’s definition of “employee” is deliberately broader than your payroll. It covers all full-time, part-time, and temporary employees, plus the full-time, part-time, and temporary employees of your agents, contractors, outsourcers, and consultants who support your internal business operations. The people who staff your outsourced help desk can count. The consultants embedded in your projects can count.
The logic from Oracle’s side is simplicity: one number, no counting installations. The effect from the customer’s side is that the subscription prices your company, not your software.
What does it cost at list?
Oracle’s published tiers, per employee per month Employee countList price
1 to 999$15.00 1,000 to 2,999$12.00 3,000 to 9,999$10.50 10,000+Lower published tiers apply
Run the math on a mid-size organization: 2,000 employees at $12 is roughly $288,000 per year. For all of Java, whether 2,000 people use it or 20 do. A 10,000-person enterprise sits comfortably in seven figures before negotiation.
That is why a handful of unlicensed downloads can surface a demand far larger than the value of the software anyone actually runs, and why the first 48 hours after an Oracle Java review email matter so much: the number Oracle opens with is built on your headcount, and it only moves if you know your own position.
Why did Oracle design it this way?
Because it converts a niche technical product into an enterprise-wide commercial event. Under the old metrics, Java revenue was capped by how much Java you ran. Under the employee metric, Java revenue scales with the size of your company, and every organization that ever pulled an Oracle JDK download becomes a prospect for a headcount-sized subscription. Oracle has logged Java downloads since 2019, which is why the “usage review” emails arrive already knowing more than you expect.
None of that is illegal or even unusual as commercial strategy. But it means the metric, not your usage, is the negotiation, and treating the subscription quote as a fact rather than an opening position is how companies overpay by multiples.
How do you reduce what the metric costs you?
The lever is not negotiating the per-employee price first. It is shrinking what needs Oracle Java at all, because the subscription is only unavoidable where Oracle Java genuinely has to stay.
Inventory first. Every machine running Oracle Java, the exact version and build, and whether it came from Oracle or an alternative distribution. This is the fact base everything else depends on.
Remove and migrate. Uninstall Oracle Java where nothing needs it. Move what you can to free alternative distributions. What remains is your true licensable footprint, and it is almost always smaller than the first count.
Check the headcount itself. Oracle’s number is only as good as the employee figure it is built on. The definition is broad, but it is not infinite, and the figure is worth verifying against what you can document.
Then negotiate, if a subscription is genuinely needed, from a defensible position with license optimization done first. Buying the subscription to make a review go away, before remediation, locks in a headcount-based bill for years.
Where UMS fits
We spent years running audits for the software publishers. We know how a Java demand gets built, because we used to build them. When a review email lands, UMS Oracle audit defense rebuilds your real position, inventory, versions, licensable footprint, defensible headcount, before Oracle’s number gets to stand.
Frequently asked questions
What is the Oracle Java employee metric? Since January 2023, Oracle’s Java SE Universal Subscription is priced per employee across your entire organization, not per Java user or per processor. If any Oracle Java requires a license anywhere in your estate, the subscription is priced against your total headcount.
Who counts as an employee under Oracle’s definition? Oracle’s definition covers all of your full-time, part-time, and temporary employees, plus the employees of agents, contractors, outsourcers, and consultants who support your internal business operations. It is deliberately broader than your payroll.
How much does the Java SE Universal Subscription cost? Oracle’s published list pricing starts at $15 per employee per month for organizations up to 999 employees, stepping down through $12 and $10.50 at higher bands, with further tiers above 10,000. A 2,000-employee organization at the $12 tier is roughly $288,000 per year at list.
Do we really pay for people who never use Java? Under the metric, yes. If 60 developers run Oracle Java and you employ 4,000 people, the subscription is priced against 4,000. The size of your Java deployment barely moves the bill; your headcount sets it.
Can we stay on our older Java licenses instead? Oracle moved new Java subscription sales to the employee metric in 2023. If you hold legacy Java SE subscriptions or perpetual licenses, your renewal rights depend on your specific agreements, and they are worth reviewing carefully before any conversation with Oracle, because moving to the employee metric is rarely priced in your favor.
How do we reduce what the employee metric costs us? Shrink what needs Oracle Java before you license anything: remove Oracle Java where it is not needed, migrate what you can to free alternative distributions, verify which installs are genuinely licensable, and check the headcount figure itself. Licensing your whole company for software a small team uses should be the last resort, not the first response.