The 2019 change that ended free public updates for commercial use of Java SE 8, what happened in the years that followed, and how to build a Java deployment record that survives contact with an auditor.
From January 2019, public updates for Java SE 8 stopped being available for business, commercial or production use without an appropriate commercial licence. Before anyone rushes out to buy licences, it is worth understanding what is actually being licensed — because a large part of what most organisations run may not need one.
If you are a personal user, you can still use Java for ordinary tasks on personal desktops, notebooks, smartphones and tablets. That allowance does not extend to commercial or production environments.
Java SE is made up of many features and components. Most are covered by Oracle’s Binary Code License Agreement and were available free of charge. The complication is that Oracle developed a set of commercial features available with Java SE, and using any of those in a business, commercial or production environment requires a licence.
The MSI Enterprise JRE Installer is the standard example. It was the normal way to distribute the Java Runtime to desktops and laptops, and using it for business operations required a licence. Using the same commercial features for design, development or testing did not.
The other complication runs in your favour. You may already be covered. Your existing Oracle entitlements cover a suite of features and components, some of which include Java. You may also be covered for Oracle Java inside your entitlements for IBM or SAP products. Neither of those is obvious from an installation record, and both are worth establishing before a purchase order is raised.
The change also altered support.
Java 8 no longer receives public updates for business, commercial or production use. Oracle provides security patches and updates for it only under a support contract. Personal-use updates continued on a separate track and Oracle has extended that window more than once since — but personal-use terms are not available to a commercial deployment, so they are not a strategy.
From Java 9 onwards, Oracle moved to a six-month feature release cadence, with only selected releases designated for Long Term Support. Releases not designated LTS receive updates for six months and then stop. At the time this was written, LTS was expected every three years — Java 11 in September 2018, and Java 17 after it.
The practical implication is that you need to review the support available for each Java version you actually run, and decide whether it meets your requirements. That decision is impossible without knowing which versions you run and where.
Oracle’s own recommendation was to review the Java SE roadmap to determine ongoing support requirements and assess the impact on business and commercial models, and to prepare migration plans to move from older versions to a later release where LTS is needed.
The six-month schedule is designed to make each upgrade smaller and therefore less onerous than the large, infrequent jumps that preceded it.
There was also good news at the time, and it has held: Oracle committed to releasing Oracle JDK and OpenJDK together, with essentially the same content from Java 11 onwards. OpenJDK is genuinely capable of meeting the same requirements as Oracle JDK for most workloads. Security patches are released for both, though for OpenJDK they are not described as “public updates”.
That leaves a set of options, each with a consequence:
Three things, and each one changed the shape of the problem.
September 2021 — the No-Fee Terms and Conditions licence. Oracle released JDK 17 under a new NFTC licence permitting free use, including in production and commercial settings, for a defined window: until one year after the following LTS release. This was a genuine reversal of direction, and it is why some organisations run current Oracle JDK builds today at no cost. The window is finite, and it closes on a schedule rather than on notice.
September 2023 — the LTS cadence shortened. Oracle moved from three years between LTS releases to two. JDK 21 shipped in September 2023 and JDK 25 in September 2025. The NFTC free-use period for JDK 21 through 24 accordingly closes in September 2026. If you adopted JDK 21 under NFTC and have not planned the move to 25, that is the date to have in the diary.
January 2023 — the metric changed completely. Oracle withdrew the per-user and per-processor Java SE subscriptions and replaced them with the Java SE Universal Subscription, sold on an employee metric. “Employee” is defined broadly: full-time, part-time, temporary and seasonal staff, plus contractors, consultants and outsourcers supporting internal operations — regardless of whether any of them ever touch Java.
That last change inverts the exercise. Under the old metric, counting your deployments told you how much to buy. Under the employee metric, counting your deployments tells you something more valuable: whether you need a commercial subscription at all. Every host you can move to a non-Oracle build, retire, or show is covered by an existing entitlement is a host that no longer pulls you into the commercial metric.
As for the audit question in the title — Oracle’s interest in customers’ Java deployments has been sustained rather than sporadic since, and the pattern is consistent: before Oracle will process an order for additional subscriptions, it wants a list of where Java is deployed. If you are being asked for that list, produce it from evidence rather than from memory.
The advice from 2018 stands, and the employee metric has made it more urgent rather than less. Discover and inventory every application that runs Java SE.
Identify and document:
Then assess:
Once that is gathered, you can make a licensing decision on evidence, and defend it later.
Java is unusually hard to count, which is why so few organisations can answer this question quickly.
It has been around long enough to be everywhere. Developers use it, so it turns up inside in-house and third-party applications. It arrives bundled with licensable products from IBM and SAP, and sometimes with other Oracle products. It sits in build images, so it is redeployed with every machine refresh. And “Java” means Oracle JDK, OpenJDK, the IBM and SAP redistributions, Amazon Corretto, Eclipse Temurin and more — all identical to the person who installed them, and only some of them creating an Oracle liability.
CerteroX ITAM discovers and inventories the hosts; CerteroX SAM recognises what is on them and computes the position.
There is one further advantage worth knowing about. Certero is a verified third-party tool vendor with Oracle License Management Services. In Certero’s published wording: being a verified third-party toolset means that Oracle’s audit team can accept data from Certero during an official audit, as an alternative to installing Oracle License Management measurement tools. That is a conditional rather than a guarantee — but it is a materially better starting position than a spreadsheet assembled by hand.
Get the inventory right and the rest follows: you can see your licensing position, work out how to improve it, and ring-fence the legacy and non-Oracle installations rather than paying for them. The organisations that come out of a Java review well are the ones that knew where their Java was before anyone asked.
Other posts covering the same ground.
Locking an application down at user level does not make you compliant with a per-device licence. In a Citrix or RDS environment, one user with access can cost you a licence for every device in the organisation.
A third-party summary of a vendor can be wrong, and it stays wrong for as long as people read it. The case for checking a vendor's facts at source — and the current, sourced record for Certero.
An audit is won or lost on the quality of your inventory long before the letter arrives. Six ways data goes wrong, and what it takes to have the answer already in hand.
Everything argued above is checkable. Name the publisher, the billing account or the platform you would argue with, and the session is built around it — the reasoning attached, not a summary slide.
No gated download at the end of it.