The Oracle No-Fee Terms and Conditions licence — NFTC — is the licence that
covers Oracle JDK 17 and later releases. Subject to its conditions it permits
free use for all users, including commercial and production use, and it permits
redistribution provided you do not charge for it.
That is a considerably more generous grant than the OTN licence it succeeded, and
it is the reason moving to JDK 17 or later is the single most effective step most
organisations can take on Java cost. It is also conditional, time-limited and
easy to invalidate by accident.
Here are the terms.
Oracle grants to You, as a recipient of this Program, subject to the conditions
stated herein, a nonexclusive, non-transferable, limited license to:
internally use the unmodified Programs for the purposes of developing, testing,
prototyping and demonstrating your applications, and running the Program for
your own personal use or internal business operations; and
redistribute the unmodified Program and Program Documentation, under the terms
of this license, provided that you do not charge your licensees any fees
associated with such distribution or use of the Program, including, without
limitation, fees for products that include or are bundled with a copy of the
Program or for services that involve the use of the distributed Program.
Outside those terms you would need to pay for commercial licence use or a My
Oracle Support subscription.
The phrase carrying the weight is internal business operations. That is what
OTN does not grant, and it is why the same host can be chargeable on Java 11 and
free on Java 17.
When is an NFTC licence not free?
When the environment falls under a Binary Licence and Redistribution Agreement
An Oracle Binary Licence and Redistribution Agreement (BLRA) and an Oracle
Trademark Licence (TML) are required for commercial distribution rights where
your use of Oracle Java does not comply with the relevant Java licensing manuals.
Oracle’s licensing user manual sets out which rights are included in each version
of Oracle Java.
Keep local copies of your Oracle Java licence agreements. Oracle replaces the
published versions on its website periodically, and not always on terms more
favourable than the ones you accepted.
When commercial features are used
An NFTC licence is not valid where commercial features are in use — that requires
an additional fee. Hosts running commercial features remain chargeable, exactly
as they were under OTN, and the NFTC will not cover them.
Examples of commercial features include Java Mission Control (JMC), the Advanced
Management Console agent and Usage Tracker. Where any of those is enabled, a paid
licence is required for that specific host or environment.
Where commercial-feature usage predates the current subscription period, keep
evidence that licences were procured for each subscription period covering that
usage. You will be asked for it eventually, and reconstructing it after the fact
is not realistic.
The practical recommendation is to maintain an effective licence position that
reflects the annual subscription requirement, listing hosts and the licence
requirement attributed to each. Keep that evidence safe. It is what lets you
quantify — and contest — the difference between your position and whatever Oracle
proposes during an audit.
The nuance nobody plans for: NFTC licences expire
The NFTC exists partly to serve Oracle’s interest in moving customers onto newer
Java versions. An NFTC grant only applies while the installed version meets the
NFTC rules, and a given version stays valid only until one year after the next
Long-Term Support release ships.
LTS releases arrive every two years. So keeping a fleet inside the NFTC means
scheduling an upgrade of every host on that cadence — otherwise the deployment
falls out of the no-fee grant and into the subscription model. Non-LTS releases
revert a year after their own release date.
Each upgrade must complete within twelve months of the new LTS version shipping.
Oracle states the position plainly in its FAQs:
After the free use license period, Oracle intends to use the OTN Licence, the
same currently used for Java 8 and 11 LTS releases, for subsequent updates.
So the updates are not optional if you intend to stay free.
Where a v17 or higher installation is not upgraded to the newest LTS release
within twelve months of that release, the host requires licensing under the Java
SE Universal Subscription. That is the mechanism preventing organisations from
settling on an old version indefinitely and paying nothing.
Non-LTS versions of Oracle Java receive bug and security patches for only six
months after release. Unless there is a specific business requirement for a
particular non-LTS build, install LTS releases instead — otherwise you are
upgrading every six months just to stay patched, on top of the licensing clock.
If you are running a non-LTS version, you also have twelve months from its
release date to move to an LTS release for the NFTC grant to remain valid.
Where the cadence stands now
The original worked example described an upgrade window that has since opened and
closed, so it is worth restating with the dates that actually happened.
JDK 21 shipped in September 2023. Versions 17, 18, 19 and 20 therefore had to
move to v21 between September 2023 and September 2024 to stay inside the NFTC.
JDK 25 shipped in September 2025. Versions 21, 22, 23 and 24 remain free under
the NFTC until September 2026. Hosts still on those versions after that date
fall outside the no-fee grant.
Two cycles in, the pattern is confirmed rather than predicted. Treat Java
upgrades as a recurring licensing obligation with a date on it, owned by someone,
funded like any other compliance activity. The organisations that get caught are
not the ones that decided to pay — they are the ones that let a two-year clock run
without anyone watching it.
What this requires you to be able to prove
Everything above depends on the same underlying data: for every host, which Java
version and update level is installed, whether any commercial feature is enabled,
what the host does, and whether Java is actually being used on it.
CerteroX SAM addresses that directly. Installed software is resolved against the
Software Recognition Database — 3.5 million or more normalised publisher, product
and version titles — so Java is identified by version and update level rather
than logged as an unrecognised binary. The Software Recognition Service attaches
release, end-of-support and extended-support dates, which is how you find hosts
whose free-use window has closed or is about to.
Coverage is the other half of the problem. The native inventory agent runs on
Windows, macOS, Linux, IBM AIX, HP-UX and Oracle Solaris against one schema, with
agentless and command-line inventory for locked-down systems and standalone
inventory for air-gapped ones. Java is on all of them.
AppsMonitor meters usage at file level with first-used and last-used tracking and
a % Used figure over a rolling 90-day window, which separates hosts that run Java
from hosts that merely have it installed — the difference between a defensible
removal and an argument.
That feeds the effective licence position this post recommends keeping: purchased,
used, available, required, variance and exposure, computed continuously rather
than assembled under pressure. Governance Policies then hold the position,
flagging a chargeable version reappearing on a host you have already cleared.
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 conditional rather than guaranteed, but it materially changes
where an audit conversation starts.
Where the constraint is Oracle licensing expertise rather than tooling, Certero
runs a SAM managed service for Oracle Java. In-house Oracle licensing consultants
analyse the environment, identify the present risks, and work through the
mitigation options — upgrading to a version inside the NFTC, moving to OpenJDK or
another non-Oracle distribution, or making use of historic licence agreements you
may already hold.