The Universal Subscription is priced per employee, not per install. For a fifteen thousand person firm that is the whole argument.
How to Negotiate the Oracle Java Employee Agreement: Honest Leverage in a Captive Deal
Priced per employee, every employee, from $15 down to $5.25. At renewal your leverage is thin and OpenJDK threats rarely land. The one year runway, trading through the wider Oracle relationship, and containing what you sign.
A UK professional services firm of roughly fifteen thousand people received an Oracle Java audit approach. The number attached to it bore no relationship to how much Java the firm actually ran, and that was not a mistake on Oracle's part.
Since Oracle moved Java SE to the Universal Subscription, the licence is priced per employee. Not per installation, not per server, not per developer. Every employee, whether or not Java exists anywhere near their work.
The audit resolved at a material saving. It did so on inventory and evidence rather than on argument about the metric, because the metric is what it is and disputing it goes nowhere.
See the Oracle services practice, the Oracle knowledge hub, the Oracle Java audit defense, and the Java audit defense playbook.
Roughly fifteen thousand employees, operating across the United Kingdom, with a technology estate typical of a professional services business: a large managed desktop population, a smaller server estate, and a long tail of departmental applications.
Java sat underneath a number of those applications, as it does almost everywhere. Some of it was Oracle's distribution, some of it was OpenJDK, and a good deal of it had arrived bundled inside third party software nobody thought of as a Java deployment.
That last category is the one that makes these audits difficult. An application vendor ships a runtime, and the customer inherits a licensing question without ever making a decision.
Oracle's opening approach priced the Universal Subscription across the full employee population, with audit exposure calculated on the same basis.
Under the employee metric that is internally consistent. If you require the subscription at all, you require it for everyone, so the size of your Java estate does not reduce the number in the way buyers expect it to.
| What Oracle counts | What buyers assume | Why the gap matters |
|---|---|---|
| Every employee, including part time and contractors | Users who actually run Java | Headcount drives the price, so reducing installs alone changes little |
| Whether Oracle branded Java is present at all | How many copies are installed | Presence triggers the requirement; volume does not scale it |
| Downloads recorded against your organization | Current live deployment | Historic downloads are evidence unless you can show removal |
| Oracle distributions specifically | All Java everywhere | OpenJDK builds carry no Oracle subscription requirement |
If the metric cannot be argued, the question becomes whether the requirement is triggered at all, and across what. That reduces to two pieces of work, both of them evidential.
First, a complete inventory that distinguishes Oracle's own Java distributions from OpenJDK builds. Adoptium Temurin, Amazon Corretto, Azul Zulu, the Microsoft build and the Red Hat build all run Java and none of them carries an Oracle subscription requirement.
Second, documented evidence of removal wherever Oracle Java had been taken out. Uninstalling is not the same as being able to prove you uninstalled, and only the second one is useful in an audit.
We ran both across the desktop estate, the server estate and the third party applications that ship their own runtime, which is where most of the surprises were.
These are the moves we ran. The first three carried the outcome.
The common advice is to reduce your Java footprint, on the reasonable sounding logic that fewer installations mean a smaller bill. We disagree, because it misreads the metric. The Universal Subscription is priced per employee, so removing nine tenths of your Java installations does not reduce the subscription by anything at all, as long as any Oracle Java requirement remains. What changes the number is whether the requirement is triggered, and that is a question about distributions rather than volume. Replacing Oracle builds with OpenJDK across the estate, and being able to evidence it, moves you out of the metric entirely. Trimming installs while leaving Oracle binaries in place is effort spent on the one variable the pricing model ignores.
The audit closed at a material commercial saving against Oracle's opening position, on a three year contracted term.
More usefully, the firm came out of it with an inventory that distinguishes distributions, a documented removal trail, and download controls that stop the position quietly rebuilding.
That second outcome is the one that matters at the next renewal. The saving is banked once; the evidence base pays every time Oracle comes back.
If Oracle has approached you about Java, or you think it might, start here.
The eleven moves, the employee metric explained, how to separate Oracle builds from OpenJDK, evidencing removal, and the buyer side position at every step of a Java audit.
Used across more than five hundred enterprise clients. Independent. Buyer side.
Source: Redress Compliance advisory engagement file.
Oracle priced the subscription against our entire headcount, which had almost nothing to do with where Java was actually running. Once we separated Oracle's own builds from the OpenJDK ones and evidenced what we had removed, the claim resolved at a material saving.
We work for the buyer. Always. There is no other side of our table.
Oracle Java audit signals, Oracle Java SE Universal Subscription signals, Oracle Java OpenJDK alternative signals, and the broader Oracle Java licensing leverage signals across the practice.
Per employee, not per installation. The metric counts your whole workforce, including part time staff and in many cases contractors, whether or not those people ever run Java. This is why reducing install counts alone rarely reduces the number.
No. OpenJDK builds from Adoptium Temurin, Amazon Corretto, Azul Zulu, Microsoft and Red Hat run Java without carrying an Oracle subscription requirement. The licensing question is which distribution is installed, not whether Java is present.
Most commonly, download records. Oracle can see what has been downloaded from its own site against your organization, and historic downloads are treated as evidence of deployment unless you can show the software was removed.
Usually yes, and for most standard workloads the migration is straightforward because the underlying code is the same. The effort sits in finding every Oracle distribution, including runtimes bundled inside third party applications, and in documenting the change.
An inventory that distinguishes Oracle builds from OpenJDK builds, dated records of every removal you have performed, and a reconciliation against Oracle's download records. Uninstalling without documenting it counts for nothing once an audit opens.
