What Java compliance actually means
Java compliance is widely misunderstood as a question of whether you have bought enough subscriptions. In practice it is a question of knowledge: do you know which Oracle branded builds run in commercial production across your estate, under which licence, and whether each is covered. An organisation that runs no Oracle JDK at all is fully compliant with zero subscriptions, while an organisation that has bought subscriptions but cannot account for its builds is not in control even if it has overpaid. Compliance is a state of demonstrable knowledge, not a purchase.
This framing matters because Oracle's Java revenue strategy depends on the opposite assumption, that buyers will treat any Oracle download as a liability and resolve uncertainty by buying coverage. The disciplined buyer inverts that logic: it resolves uncertainty by inventorying the estate and controlling what enters it, then buys only what genuinely remains. This article sits beneath the Oracle Java licensing pillar and complements the defensive work in the audit defence service. When a review does arrive, the response sequence is set out in the Oracle Java audit defence guide.
Building a defensible inventory
The foundation of compliance is an inventory that records, for every Java installation in the estate, the host, the version, the patch level, and crucially the distribution vendor and licence. A list of version numbers is not enough, because Oracle JDK 17 and Eclipse Temurin 17 carry the same version string but entirely different licence consequences. The inventory must therefore read the binary's provenance, which modern software asset management tooling and Java specific discovery scripts can do by inspecting the JDK's vendor properties and signing.
A defensible inventory is also dated and repeatable. A one off scan answers today's question but says nothing about the estate next quarter, and Java sprawls quickly as developers install runtimes for new projects. The compliance discipline is therefore a recurring scan with results retained over time, so the organisation can show not only its current position but the controls that maintain it. Those same records are what let a buyer test Oracle's download evidence during a review, as set out in the audit triggers guide.
Governing downloads at the source
Inventory tells you what is already there; governance stops new exposure from arriving. The most common source of accidental Oracle Java liability is a developer downloading "the latest Java" directly from Oracle's site, taking an Oracle branded build under the OTN licence without anyone realising a fee may attach. Closing that path is the single highest leverage compliance control available.
| Control | What it prevents | Effort |
|---|---|---|
| Internal artifact repository | Ad hoc external downloads | Medium |
| Approved distribution list | Oracle builds entering by default | Low |
| Network egress rules | Direct pulls from Oracle site | Medium |
| Container base image policy | Oracle JDK in production images | Low |
The pattern that works is to provide developers with a sanctioned, free OpenJDK distribution through an internal repository and to make that the path of least resistance, so the right build is also the easy build. When the approved distribution is readily available, the incentive to pull an Oracle build from the public site disappears, and exposure stops accumulating.
Separating Oracle JDK from OpenJDK
At the heart of every Java compliance question is one distinction: is this binary an Oracle branded build that can carry a fee, or a free OpenJDK build that cannot. The two are functionally identical at runtime, which is precisely why they are so easily confused, but their licence consequences could not be more different. A compliance programme that cannot reliably tell them apart is not a compliance programme.
Every Java compliance failure traces back to the same blind spot: an estate that could not tell an Oracle build from a free one.
The distinction is detectable. Oracle branded builds identify themselves through vendor strings, and their provenance can be confirmed against the download source and signing. The conceptual difference, and why it is the whole game, is developed in the OpenJDK versus Oracle JDK comparison. Once the estate is cleanly separated, the licensable population is usually far smaller than the raw count of Java installations, and the path to compliance becomes clear.
How do I stay compliant with Oracle Java?
Staying compliant is a continuous loop rather than a one time project. Run a recurring estate scan that records vendor and licence, not just version. Govern downloads so new Oracle builds cannot enter the estate by accident. Standardise on a free OpenJDK distribution as the default, and confine Oracle branded builds to the narrow cases where they are genuinely required and covered. Where a subscription is held, maintain a reconciled employee count fixed to a defined date so the basis of the bill is documented.
The loop is what makes compliance durable. A single clean up followed by no governance simply re accumulates exposure, because Java installs continue and developers continue to need runtimes. The organisations that stay out of Oracle's compliance pipeline are the ones that have institutionalised the loop, so that the right build is the default and the inventory is always current. This operating discipline is exactly what a Java advisory engagement stands up.
Compliance posture and the employee metric
For organisations that do hold or need an Oracle Java subscription, compliance has a second dimension beyond the estate: the employee count that drives the price. Because the Universal Subscription is sized to total workforce rather than to deployment, the compliance record must include a defensible headcount that distinguishes the contracting entity from out of scope affiliates and that accounts correctly for contractors and outsourcers. An inaccurate count is a compliance exposure even when every build is properly licensed.
This is why estate control and metric control go together. Controlling the estate determines whether you need a subscription at all; controlling the count determines what a necessary subscription costs. The mechanics of the count, and the populations Oracle's definition sweeps in, are set out in the employee metric guide, and the option that removes the metric entirely is in the migration guide.
The buyer side view
The practical takeaway is that Java compliance is won by knowledge and governance, not by spending. The organisations that get blindsided are not the heavy Java users; they are the ones that never separated Oracle builds from free ones, never governed downloads, and never held a defensible count. Build a dated, repeatable inventory that reads vendor and licence, close the download path that lets Oracle builds in by default, and standardise on free OpenJDK so coverage is the exception rather than the rule.
Treat compliance as a continuous loop and the Oracle Java problem largely manages itself, because the estate never drifts into exposure and any enquiry can be answered from your own records. Start with the Java licensing pillar for the framework, the audit triggers guide for what Oracle watches, and the Java advisory service to stand up the controls.
Oracle Java compliance: frequently asked questions
How do I know if my company is compliant with Oracle Java?
You are compliant when every Oracle branded JDK build in production is covered by a current subscription, or when you run only free OpenJDK and Oracle builds within their free window. This requires a scan that identifies the vendor and licence of each binary, not just the version, as explained in the licensing pillar.
Does Oracle Java compliance require buying a subscription?
No. Many organisations are compliant without any Oracle subscription by standardising on free OpenJDK and removing Oracle builds from production. A subscription is only required where Oracle JDK runs commercially outside its free window.
What records should I keep for Java compliance?
Keep a dated inventory by host, version, patch level, and vendor; download governance records; and, where a subscription is held, a reconciled employee count fixed to a date. These let you answer an Oracle enquiry from your own evidence.