How to run a Java licensing review before Oracle starts asking questions.

A Java licensing review should end in a signed file, with a coverage statement, two registers and an employee workpaper, that shows what you would owe Oracle and what you could prove if a claim arrived tomorrow.

There is no Oracle deadline today, no audit letter and no sales call pending. That makes now the cheapest time to establish your Java position and change it on your own schedule. A good review ends in a signed file: a charter, a method note, a coverage statement, two registers, a headcount workpaper and a conclusion.

Before you rely on any summary, including this one, read the five documents that settle most review questions. They are the OpenJDK project for what is not Oracle at all, Oracle's no fee terms, its Technology Network license, its Java SE licensing questions page and its Universal Subscription page for the metric and the rates.

When should you run a Java licensing review?

Run it at a time you pick. Three windows give you enough time and freedom to act on the findings. A fourth, the formal audit notice, arrives too late for a voluntary review, because from that point the work happens under audit rules.

What goes in the review charter?

Write a one page charter before anyone opens a discovery tool. Without it, the review turns into an inventory exercise and stalls there. The charter fixes six things.

• The question. One sentence, written in the language of the person who will read the answer. "How much Java do we have" is the wrong question; "what would we owe Oracle, and what could we prove, as of 30 June" is closer.
• The sponsor. A named executive who will sign the conclusion. Knowing a signature is coming keeps everyone honest about what the evidence supports.
• Scope in and out. Legal entities, geographies, and the populations you will and will not reach. Naming the exclusions is what makes the rest credible.
• The as of date. One date the whole review speaks to. Mixed dates are the quickest way to lose an argument about a number.
• The privilege position. If the answer might be unwelcome, run the work under counsel from day one. Protection cannot be added to a document that has already circulated.
• The circulation list. Who sees drafts. A draft with a wrong number in it has a long and unhelpful life once it reaches a wide audience.

Who should do the work?

You need three functions, and one of them is usually missing. Asset management reaches the machines, procurement holds the ordering documents, and legal reads the terms. A review run by asset management alone produces a count with no position behind it.

What have we seen in voluntary Java reviews?

Fredrik Filipsson ran roughly 35 to 45 voluntary Java reviews across 2024 and 2025. Some later held up when Oracle pushed on them and some fell apart. The ones that held up differed in four ways.

• They stated their reach. Each one said how much of each population it had actually reached, and named the assets it had not.
• They recorded who built every runtime. When Oracle later questioned the total, the discussion stayed on the total and never became a dispute about the method.
• They searched entitlements as hard as deployments. Roughly a third turned up rights the organization had forgotten it held.
• They ended in a range. The conclusion gave a low and a high figure with the assumptions that move it, instead of one number an executive could quote out of context.

What counts as Oracle Java in a review?

Oracle Java, for licensing purposes, means builds produced by Oracle, obtained under terms that require a subscription, and used in a way those terms do not permit for free. Everything else is noise, and most organizations carry far more noise than signal. Sort every runtime into one of five categories, in this order.

Categories one to four are cheap to prove, and each one you close shrinks the fifth. The fifth category is where every commercial conversation with Oracle eventually ends up, so you want it as small and as well documented as possible.

Why does the build number matter more than the version?

Oracle changed its Java terms several times between 2019 and 2023, and the terms attached to a runtime are the ones that applied when it was obtained. A build number is evidence. A version family is not, because one family can span two licenses.

Record the full build string for every Oracle runtime and the date it arrived. A review that records only major versions has thrown away the field that decides which license applies.

The chronology behind these changes is set out in our guide to the 2023 Java licensing changes. The current Java 21 cutoff is covered in our note on Java 21 updates ending in 2026.

How do you tell an Oracle build from an OpenJDK build?

Read the evidence off the runtime itself, and capture it with a date. Four checks cover most machines.

• The release file. Most JDK and JRE home folders hold a plain text file called release. In recent builds its IMPLEMENTOR line names the builder, for example Eclipse Adoptium or Amazon.com Inc.
• The version banner. Running java -version on an Oracle JDK prints "Java(TM) SE Runtime Environment" with the build string. An OpenJDK build prints "OpenJDK Runtime Environment".
• The system properties. Running java -XshowSettings:properties -version lists java.vendor and java.vm.vendor, which is useful where you can run a command but cannot browse the file system.
• The installer record. On Windows, Oracle's installers register entries such as "Java 8 Update 202" in the installed programs list, which gives you the update number without touching the runtime.

One trap catches many teams. Oracle also publishes free OpenJDK builds under GPLv2 with the Classpath Exception at jdk.java.net, and those builds, like some older Linux distribution OpenJDK packages, can report Oracle Corporation as the vendor. Pair the vendor field with the version banner before you place anything in category 5.

What should the coverage statement say?

It states what proportion of each population you actually reached, and how you know. Few teams write it, yet this one paragraph separates a review from an anecdote. Forty seven findings across an environment you reached 60 percent of are a sample, and Oracle will treat them as one.

• Report by population. Reaching 90 percent of servers and 40 percent of endpoints is a very different result from 78 percent overall.
• Name the unreachable. Air gapped systems, plant equipment, machines belonging to people on long leave, and anything a supplier controls.
• Say how you know. A coverage figure taken from the same tool that did the discovery is circular. Reconcile against a second source, usually the asset register or the payroll device list.

How do you build an employee count Oracle cannot pick apart?

Build it as a workpaper with a source, a test and a note for every line. A payroll extract is only the starting point. The finished count is a reasoned position that has to survive someone challenging each line on its own.

Who does Oracle's employee definition include?

Oracle's employee definition for the Universal Subscription is broad, and it is the single term that decides your bill. Read the current wording on Oracle's own price list rather than relying on any summary, including ours.

In substance it covers two groups of people:

• Your own staff. Full time, part time and temporary.
• Staff of your suppliers. The full time, part time and temporary staff of your agents, contractors, outsourcers and consultants who support your internal business operations.

The definition is not limited to people who use Java, and outsourced staff are not automatically outside it. Our guide to counting contractors and consultants works through the borderline cases.

What do the published tier rates do to that count?

Oracle publishes seven employee tiers. The rate for your tier applies to your entire count, including the employees below the threshold, and support is included in the price rather than added on top.

Why is 999 employees the worst count to have?

Because the rate applies to the whole count, the annual bill drops every time you cross a tier boundary upward. At 999 employees you pay the top rate on every head, and a thousandth employee takes you to $12.00 and cuts the bill by roughly a fifth. Each row below can be checked against the published rates.

Two practical consequences follow. If your count lands just under a boundary, test whether a broader reading that you could support just as well costs less. And do not accept a supplier's claim that a growing headcount must mean a growing Java bill.

A worked example near a tier boundary

Say a hypothetical company has 2,640 permanent staff and 190 part time and temporary staff on payroll at the as of date. It also has 120 agency contractors working inside its own operations.

A systems integrator also has 90 people delivering a project for the company from the integrator's own offices and systems. That line can be argued either way.

The broader reading is 90 people larger and $41,760 a year cheaper. You must be able to support whichever reading you choose, so test both and record why the integrator line is in or out. A line you include this year is hard to remove at the next renewal, so weigh the saving against that precedent.

How do you rate and rank what the review finds?

Put every asset into one of five evidence classes, then drive one of those classes to zero. Ranking findings by dollar value first is the common mistake, because it hides the class that decides your position.

At sign off, the unknown class is the one that counts, and the target for it is 0. A review that closes with 300 confirmed findings and zero unknowns is a strong position. One that closes with 30 confirmed findings and 2,000 unknowns is no position at all, because Oracle will fill every unknown with its own assumption.

How do you turn the classes into a range?

Report a low case and a high case, and name the two or three decisions that separate them. A single figure gets forwarded without its caveats, while a range carries its assumptions with it.

• The low case. Confirmed findings only, with covered and excluded assets fully proved and every probable resolved in your favor.
• The high case. Every probable resolved against you, every unknown assumed to be an uncovered Oracle build, and the broadest reading of the employee definition.
• The swing factors. Usually three: the outsourced staff line, the treatment of one large application supplier, and the assets you could not reach.

Why we advise against starting with a discovery scan and a count

The usual advice is to run a discovery tool across every machine and count the Java installations. We disagree, because a raw count never survives contact with Oracle. Oracle will press on the runtimes you cannot explain, and explaining one takes provenance, an entitlement search and a coverage statement a stranger could reproduce.

An early unqualified total also tends to leak, get quoted back to you, and become Oracle's opening figure in the negotiation. Produce the workpapers first and the number last.

What will Oracle say, and how should you answer?

Most Java conversations start with an informal message from an Oracle account or licensing contact. With a finished review in hand, you can answer each opening line calmly and in writing. These are the lines we hear most often, with replies that keep the discussion on your evidence.

If the first call has already happened, our note on what to say on the first Oracle call covers the next steps. Our guide to checking Oracle's headcount claim shows how to test the number Oracle puts forward.

What does a finished Java licensing review produce?

A finished review produces seven documents and one signed conclusion. If it ends with a slide instead of a file, it will not survive the first serious question, and that question always comes eventually.

1. The charter. The question, the sponsor, the scope, the as of date, the privilege position and the circulation list.
2. The method note. How each population was reached, in enough detail that a third party could repeat it and get the same answer.
3. The coverage statement. Proportion reached per population, the reconciliation source, and a named list of what was not reached.
4. The entitlement register. Every Oracle order touching Java, including grants hidden inside orders for other Oracle products.
5. The findings register. Every asset, its class, its provenance evidence and its owner.
6. The employee workpaper. Six lines, six sources, and a written note on each disputed line.
7. The conclusion. One page: a range, the assumptions that move it, and the three decisions the sponsor now has to make.

A review is finished when you could hand the whole file to someone hostile and still be comfortable.

How should you sign off and refresh the review?

• Sign it, with a date. An unsigned review stays a draft forever, and drafts get quoted without their caveats.
• Refresh it annually, and immediately after any corporate event that changes the entity list or the headcount materially.
• Keep the registers live. Asset management should maintain the entitlement and findings registers through the year, so next year starts from a current file instead of a rebuild.
• Store it where it outlives the tooling. Discovery platforms get replaced every few years. The file should not depend on any one of them.

What does the review feed into next?

The conclusion drives one of three decisions: remediate, buy, or do nothing and monitor. Each needs its own program, and the review tells you which one you are choosing. Size the buy case against your own numbers with the Oracle Java license calculator.

If the answer needs a negotiation, our Oracle advisory practice runs the commercial side without reselling anything. Whoever negotiates, the review should shape the contract terms you ask for.

• A stated count and date. Put the employee count and the as of date in the order, so the baseline cannot be reopened later.
• An agreed definition for disputed lines. Record in writing how the outsourced and contractor lines were treated, so the next renewal starts from the same reading.
• Named entities. List the legal entities covered, and say how acquisitions and divestments during the term are handled.
• Renewal price protection. Ask for a cap on the per employee rate at renewal. Without one, the tier rate is the only reference point.
• A release of prior use. If Oracle raised past use, ask for written confirmation that the new order settles it.

What to do next

1. This week: write the charter. One page, six fields, and a named sponsor who will sign the conclusion.
2. Fix the as of date first. Make every source, from payroll to discovery, speak to that same date.
3. Decide the privilege position before drafting starts. It costs nothing now and cannot be added later.
4. Search entitlements before machines. Every right you already hold reduces the work on the deployment side.
5. Capture provenance for every Oracle runtime. Record the builder and the full build number, since the major version alone does not decide the license.
6. Publish the coverage statement. Report it per population, with the reconciliation source named.
7. Drive the unknown class to zero before anyone starts debating the size of the number.
8. Close with a range and three decisions, then put the refresh date in the sponsor's calendar.

Frequently asked questions