Oracle Java 17 stopped being free in October 2024. If you are still running it,
the question is not whether the rule changed but whether anyone in your
organisation has taken an update since — because that single action is what
moves you from a no-fee licence to a chargeable one.
How the No-Fee Terms and Conditions actually work
Products released under Oracle’s No-Fee Terms and Conditions (NFTC) are
available at no charge to “support internal business operations” for a defined
period. The catch is in how Oracle defines that period. NFTC coverage applies
only while the release is the current Long-Term Release, plus twelve months
after the following Long-Term Release arrives.
The intent is straightforward: Oracle wants organisations on the newest LTR, and
does not want to maintain free updates for older ones indefinitely.
For Java 17 that meant it was free under the NFTC only while:
- it was the current Long-Term Release;
- you were within twelve months of the next LTR, Java 21, reaching general
availability; and
- you stayed on Update 12 or lower.
Java 21 reached general availability in September 2023. Twelve months later the
free window for Java 17 closed, and the first quarterly update to fall outside
it was 17.0.13, released on 15 October 2024.
What changed at Update 13
The NFTC covers Java 17 Updates 1 through 12 only. Install Update 13 or higher
and that installation is licensed under the Oracle Technology Network (OTN)
Licence Agreement instead. OTN permits development, testing and demonstration
use at no charge. It does not permit production use — and Oracle reads
“production” broadly, taking in disaster recovery environments and end-user
compute devices as well as production servers.
Running Java 17 Update 13 or above outside a development context means you need
an Oracle Java SE Universal Subscription. Since January 2023 that subscription
has been sold on an employee metric: you licence your entire workforce, not the
machines or the people that use Java. Oracle’s definition of “employee” is wide,
covering full-time and part-time staff along with contractors, consultants and
outsourcers who support internal operations.
That is the part organisations find hardest to accept. One machine running one
OTN-licensed Java installation makes the whole workforce the licensable unit.
What’s the risk?
The risk is that this happens without a decision being taken.
Organisations running older Java releases frequently do not know what they have.
Java arrives bundled inside other products, gets installed by developers, and
persists on desktops years after whatever needed it was decommissioned. Where
Java 17 is present, it is often present at several different update levels
across different machines.
Then someone accepts an update prompt. Updates are served from Oracle’s own
infrastructure, and Oracle keeps records of what was downloaded and by whom —
those records have been a routine feature of Oracle’s Java compliance
correspondence. A single accepted prompt on a single production machine is
enough to change your licence position.
At that point the organisation is using OTN-licensed software in production
without a subscription. That is a non-compliance finding waiting to be made, and
Java has been one of Oracle’s most active audit areas since the metric changed.
Because the metric is per employee, the exposure bears no relation to how much
Java you actually run, which is what makes the resulting numbers so
disproportionate.
What to do about it
The remedy is unglamorous and entirely about evidence. You need four things, and
you need them continuously rather than once.
Every Java installation, on every machine. Not just servers. JDKs, JREs and
the runtimes bundled inside third-party applications, across Windows, macOS,
Linux and the Unix platforms most tools quietly skip. CerteroX SAM recognises
installed software against the Software Recognition Database — 3.5 million-plus
normalised titles — so a Java installation is identified as Java regardless of
how it was packaged or what the folder is called.
The exact version and update level. “Java 17” is not an answer. 17.0.12 and
17.0.13 sit on different licence agreements. Version and update-level
recognition is what turns an inventory into a licence position.
Whether anything actually uses it. AppsMonitor meters file-based usage with
first-used and last-used tracking and a rolling 90-day utilisation figure. Java
installations that nothing has invoked in three months are removal candidates,
and removal is the cheapest form of compliance available to you.
A record you can defend. Certero is a verified third-party tool vendor with
Oracle License Management Services. In Certero’s own 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 under
time pressure.
The organisations that came through the Java change well were the ones that
already knew where their runtimes were. They pinned the machines that had to
stay on 17.0.12, migrated the rest to a non-Oracle distribution or a supported
release, and removed what nothing used. None of that is difficult. It is only
impossible without an inventory.
If you do not currently know how many Java installations you have, or at which
update levels, book a demo and see what the discovery returns
across a fully populated environment.