Oracle's NFTC-then-OTN pattern gives every Java LTS release roughly 36 months of free updates, so staying free means a forced major upgrade every two years forever
Oracle introduced the No-Fee Terms and Conditions with JDK 17 in September 2021, moved JDK 17 to the OTN license in October 2024, and moves JDK 21 to OTN with the October 2026 Critical Patch Update. JDK 25 is already scheduled to expire in September 2028. The pattern is now a confirmed three-cliff precedent, not a forecast, and it means "free Java" is a standing commitment to a two-year upgrade cadence, not a one-time decision.
Prepared by Redress Compliance · August 27, 2026 · Oracle Java advisory. NFTC transitions 2021 to 2028, employee-metric negotiations 2024 to 2026.
Executive summary
The free window per LTS release is approximately 36 months, and it is a structural output of Oracle's own published cadence: LTS every 24 months plus 12 months of license overlap.
JDK 17 shipped September 2021 and left NFTC at update 17.0.13 in October 2024; JDK 21 shipped September 2023 and leaves NFTC at the October 2026 CPU; JDK 25 shipped September 2025 and is scheduled to leave in September or October 2028.
Three cliffs in, the pattern has zero exceptions, which removes any basis for a "maybe Oracle will extend it" assumption in your 2027 and 2028 budget.
Every Java release since September 2021 has shipped under NFTC and every superseded LTS has moved to OTN one year after its successor, and Oracle published the JDK 25 expiry date before the JDK 21 cliff had even landed.
The cost of stepping off the treadmill is priced on headcount, not deployment, so a 5,000-employee company running Oracle Java on 40 servers pays $630,000 per year at list, or $15,750 per server.
The Java SE Universal Subscription runs from $15.00 per employee per month at 1 to 999 employees down to $5.25 at 40,000 to 49,999, and "employee" includes part-timers, temporary workers, and contractors who support internal operations regardless of whether they ever touch Java.
The treadmill's real danger is that you fall off it silently: patch automation pulls the first post-cliff update and converts a free estate into a licensable one without a purchase order, a contract, or a conversation.
The dominant Oracle targeting signal in 2026 is download history tied to an authenticated Oracle account, which means one unmanaged CI runner or one admin signing in to grab a patch can put an entire employee count in scope.
How the NFTC-to-OTN clock actually runs
The mechanic is simple enough to model on one page, and Oracle has now run it three times, so treat it as contract behavior rather than roadmap intent. Oracle introduced the No-Fee Terms and Conditions (NFTC) with JDK 17 in September 2021. Each new LTS ships under NFTC.
When the next LTS arrives, the older LTS gets exactly one year of dual-permissive overlap, after which its updates revert to the Java SE OTN license, the same license that governs Java 8 and 11.
JDK 17 hit that wall first: updates issued after September 2024 moved to OTN, with the transition landing at 17.0.13 in the October 2024 Critical Patch Update. JDK 21 is the second pass.
JDK 25 GA in September 2025 started the 12-month clock, Oracle distributed the last free NFTC update to JDK 21 in July 2026, Java.com builds remain free through September 16, 2026, and from the October 2026 CPU all further JDK 21 updates arrive under OTN.
JDK 25 is already scheduled to follow: NFTC until September/October 2028, one year after Java 29 lands in September 2027. Non-LTS releases get no overlap at all.
JDK 22, 23, 24 and 26 sit under NFTC for their full six-month life, then stop, which is why the 2026 event sweeps up 21 through 24 in a single date. JavaFX 21 and GraalVM for JDK 21 ride the same October 2026 clock, a detail most estates miss until a patch fails a license check.
What OTN permits is narrow and unchanged: personal use, development, testing, prototyping, demonstration. What it forbids is the thing you actually do with Java. Production is not permitted under OTN without a paid subscription.
See our 2026 Java version support cliff guide for the estate-level inventory work this implies.
| Release | NFTC start | Moves to OTN | Free window |
|---|---|---|---|
| JDK 17 (LTS) | September 2021 | October 2024 CPU, at 17.0.13 | ~37 months |
| JDK 21 (LTS) | September 2023 | October 2026 CPU (last free update July 2026, free use to Sept 16, 2026) | ~36 months |
| JDK 25 (LTS) | September 2025 | September/October 2028, one year after Java 29 | ~36 months |
| JDK 22, 23, 24, 26 (non-LTS) | At GA | End of six-month support life, no overlap | ~6 months |
The second reading of the table is the non-LTS row. Teams that adopted JDK 22, 23 or 24 to pick up a language feature did not buy themselves runway, they bought a six-month grant that expires on the same September 2026 date as JDK 21.
Any estate discovery that reports "not on 21, so not exposed" is wrong.
The arithmetic of a two-year cadence: why 36 months is the ceiling
Stop treating the free window as an Oracle policy that might soften. It is an output of two published parameters: LTS releases every 24 months, plus 12 months of dual-permissive overlap.
Twenty-four plus twelve equals roughly 36 months of NFTC coverage per LTS, and the three observed cliffs land at 37, 36 and 36 months. There is no discretion in that number for Oracle to exercise in your favor, and none for you to negotiate.
The only variable is how much of the 36 months you spend on the release rather than getting onto it.
That subtraction is where the real number lives.
In our engagement experience, a full enterprise JDK major upgrade across a mixed estate (vendor application certification, internal build pipelines, container base images, regression cycles, change windows) runs 6 to 12 months from decision to last host cut over.
Subtract that from 36 and the genuinely usable steady-state window is 24 to 30 months, and that assumes you start the day the new LTS goes GA rather than the day the deprecation notice lands.
Start late, as most estates do, and the usable window compresses toward 18 months, at which point the upgrade project is effectively continuous.
Model JDK 25 on that basis now. Java 29 arrives September 2027, which fixes two things in one stroke: the JDK 25 OTN cliff at September/October 2028, and the opening of the JDK 29 free window.
That means the JDK 25 qualification work you have not yet scoped is due to complete by roughly Q3 2026 if you want a full 24 months of stable running, and the JDK 29 project starts before the JDK 25 one is cold.
Anyone weighing this against a permanent exit should read our upgrade to Java 25 or migrate to OpenJDK decision guide before committing engineering capacity to a cycle that repeats forever.
The honest framing for your steering committee: staying free is not a cost of zero, it is a recurring engineering program with a two-year beat and a hard external deadline you do not control.
Price that program in engineer-months and compare it against subscription list, because that, not the license fee alone, is the actual decision.
Defend an Oracle Java audit without overpaying
Oracle now audits Java SE on employee count, not installs, which can multiply the bill several times over. How to defend the notice and exit to OpenJDK.
Get the white paper →The treadmill is a hedge Oracle wrote, not a gift it gave
Read the NFTC as a commercial instrument, not a concession. Before September 2021, Oracle charged for Java 8 patches under OTN and got exactly what any licensor should expect from that posture: mass migration.
Estates rebuilt on Adoptium, Amazon Corretto, Azul, Red Hat builds, and Microsoft's OpenJDK, and Oracle lost the default download position it had held for two decades. The NFTC bought that position back.
Make the latest LTS free again and Oracle JDK returns to being the thing a developer grabs without a procurement conversation, which means it returns to being the thing that shows up in your estate discovery three years later. Nothing in that sequence is generosity.
It is distribution strategy funded by the small percentage of estates that later fail to move in time.
The one-year overlap is the calibrated part, and it is worth staring at. Oracle could have given six months, which would have looked punitive and pushed architects to non-Oracle builds at design time. It could have given three years, which would have removed the pressure entirely.
One year is precisely long enough to defend in a blog post and precisely short enough that a typical regulated enterprise, with a change freeze from mid-November through early January, a quarterly release train.
And two or three vendor-certified appliances that will not bless the new JDK until their own next major, cannot comfortably finish.
That gap between what looks reasonable and what actually completes is where the conversion revenue sits. Our negotiation experience across Java renewals is that the accounts Oracle converts are rarely the ones that decided to buy. They are the ones that ran out of calendar.
The employee metric is what makes a low conversion rate profitable. Oracle does not need most estates to fall off. It needs a fraction, because each conversion prices whole headcount rather than the four servers that missed the upgrade.
A 12,000-person firm that fails on one payments gateway does not owe for one gateway; it owes $1,188,000 a year at list. That asymmetry means Oracle can afford to let ninety percent of the market ride the treadmill successfully and still grow the book.
The free tier is not a loss leader in the retail sense. It is a wide net with a very expensive mesh.
So treat the treadmill as what it functionally is: a recurring discipline test with a seven-figure failure penalty. Oracle is not betting on your architects.
It is betting on your change-freeze calendar, your ISV certification matrices, your embedded appliances shipping a bundled JRE you do not control, and the Java 8 workload nobody will sponsor.
Those four things have beaten every heroic upgrade plan I have watched over twenty-five years, and they will keep beating them, because they are organizational rather than technical.
The strategic consequence is the part buyers consistently miss. Staying free on Oracle is not a decision you made in 2025. It is a renegotiation you conduct with yourself every twenty-four months, forever, and each round you must win outright across the whole estate.
Migrating to a non-Oracle distribution is a single cost, incurred once, that terminates the cycle.
The runtime side of that migration is largely settled; as covered in the upgrade to Java 25 or migrate to OpenJDK decision, the binaries are built from the same OpenJDK sources, and the friction is contractual and organizational rather than technical.
Frame the comparison honestly over six years. Oracle-free-forever is not zero.
It is three mandatory major-version programs (JDK 21, JDK 25, JDK 29), each with regression testing, ISV recertification, and appliance coordination, plus a standing residual risk that one of the three slips and prices your entire headcount.
One migration is a single program of comparable size that removes all three future programs and the residual risk with them. In practice, on the estates we model, the migration pays for itself inside the first avoided upgrade cycle, and everything after month thirty is pure avoided cost.
What falling off costs: the employee metric and the band boundaries
| Employee band | List rate per employee per month | Annual list at band floor |
|---|---|---|
| 1 to 999 | $15.00 | $179,820 at 999 |
| 1,000 to 2,999 | $12.00 | $144,000 at 1,000 |
| 3,000 to 9,999 | $10.50 | $378,000 at 3,000 |
| 10,000 to 19,999 | $8.25 | $990,000 at 10,000 |
| 20,000 to 29,999 | $6.75 | $1,620,000 at 20,000 |
| 30,000 to 39,999 | $5.70 | $2,052,000 at 30,000 |
| 40,000 to 49,999 | $5.25 | $2,520,000 at 40,000 |
| Above 50,000 | Not published | Negotiated |
Two readings matter. First, deployment count is not an input. A 12,000-employee enterprise pays $1,188,000 a year at list whether it runs four Oracle JDK installs or four thousand, and a 5,000-employee firm needing Java on 40 servers pays $630,000, which is $15,750 per server.
Oracle's own published example prices 28,000 employees and agents at $2,268,000 annually. Falling off the treadmill on one forgotten appliance costs the same as falling off across the entire estate, which is why estate hygiene, not estate size, drives the bill.
Second, the band boundaries create arbitrage that runs in the buyer's favor. At 9,999 employees the annual list is $1,259,874; at 10,000 it is $990,000. One additional counted employee removes $269,874.
Above roughly 7,857 defended employees, the rational order quantity is 10,000, and the same logic repeats at every boundary. Model the tier above yours before you accept a quote at your headcount.
Three corrections to budgets we routinely see. There is no separate 22 percent support line on the Universal Subscription, so any model that adds a support percentage on top of the per-employee rate is double counting by roughly a fifth.
There is no credit for legacy perpetual Java SE Advanced holdings; those entitlements remain useful as audit cover and migration runway, but they buy nothing against the subscription price.
And advisory sources report an 8 percent annual escalation clause, which compounds every year the estate stays on Oracle, turning a $990,000 year one into roughly $1,455,000 by year six if unchecked. Cap escalation at CPI or zero in the negotiation, not at renewal.
Advisory benchmarking also puts the average increase from pre-2023 processor licensing to the employee metric at 340 percent, which is why the sticker shock on first conversion is genuine and why the subscribe, migrate, or hybrid comparison almost always favors migration at scale.
How estates fall off the treadmill without deciding to
Nobody in a licensing committee ever votes to move from NFTC to OTN. The estate crosses that line in a Tuesday patch window.
A Puppet or Ansible role says "install latest 21," an apt or yum repository refreshes, a base container image rebuilds from a tag that tracks the newest build, or a third-party vendor bundles its own Oracle JDK inside an application installer that your platform team never inspected.
The first post-cliff update lands, the version string moves from 21.0.x to the October 2026 CPU build, and every production host running that binary is now under a license that permits development, testing and demonstration but not production.
The consequence is unusually broad this cycle: the October 2026 CPU sweeps JDK 21, 22, 23 and 24 at once, and pulls JavaFX 21 and GraalVM for JDK 21 through the same gate.
Estates that spent 2024 congratulating themselves on standardizing off 17 often standardized onto four versions that all expire on the same date, as covered in our 2026 Java version support cliff guide.
The reason this matters more than in prior cycles is the detection path. In our engagement experience, Oracle's dominant 2026 targeting signal is download history tied to an authenticated Oracle account, not an installed-base scan.
Someone in your organization signed in to fetch a build, and that record does not expire when the employee does. The bill that follows is sized from headcount, not from those downloads, and Oracle's estimate of headcount is built from LinkedIn, annual reports and your own careers page.
We routinely see that method overstate the contractual employee count by roughly 18 to 28 percent, because it sweeps in contractors, former staff, subsidiaries outside the contracting entity and open requisitions.
Four controls carry almost all of the weight. Pin versions explicitly in build manifests and container tags rather than tracking "latest." Stand up an internal artifact mirror so no pipeline reaches oracle.com at build time.
Block oracle.com JDK download endpoints at egress, which converts a silent conversion into a failed build somebody has to explain. And name one owner for the Java version register, with a per-host record of vendor, version and license basis, refreshed monthly.
The asymmetry to internalize: Oracle needs one authenticated download record to open a conversation, while you need a complete, current version register across every host to close it.
Most estates have the first and not the second, which is why the opening letter lands before internal fact-finding has even started.
Treat the egress block as the highest-leverage single control. It is reversible, costs nothing, and it is the only measure that stops the conversion at the moment it would otherwise happen rather than reporting it after the fact.
The evidence base: five years, three cliffs, one pattern
The record here is Oracle's own. The JDK License General FAQs and the Java SE Support Roadmap (August 2026) set out the two-year LTS cadence with a one-year permissive overlap. The Spring 2024 Roadmap Update pre-announced the JDK 17 move to OTN.
The August 2026 Java blog post confirmed the JDK 21 end of permissive license and the GraalVM for JDK 21 transition, and the JDK 21.0.12 release notes carried the parallel change for JavaFX 21.
Third parties corroborate rather than contradict: Azul fixes the last free patch date at September 16, 2026, Certero confirms the sweep covers versions 21 through 24, and BellSoft states plainly that OTN excludes production use.
JDK 17 (October 2024), JDK 21 (October 2026) and JDK 25 (September 2028) follow identical NFTC-to-OTN mechanics.
Advisory-sourced from our engagements: public-source headcount modelling sweeps in contractors, alumni and out-of-scope subsidiaries.
Four buyer-side patterns recur across engagements. First, estates that read NFTC as a permanent grant and documented it that way in architecture decision records, then discovered the grant was always time-boxed.
Second, estates with no mixed-version register, where nobody could state on request how many hosts ran which JDK from which vendor, which is fatal because the defense is inventory.
Third, first contact arriving not as an audit letter but as a soft license review referencing download logs, which buys Oracle a conversation without triggering your audit clause protections.
Fourth, where subscription genuinely could not be avoided, advisor-assisted negotiation landing 20 to 40 percent below list through multi-year terms and headcount definition carve-outs.
The pattern across all four is that the losses were operational, and the recoveries were contractual, which is why the upgrade-versus-migrate decision should be made before the letter, not after.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Build the version register this quarter, owned by infrastructure with a hard date. Tag every host by JDK version, vendor and build string before the October 2026 Critical Patch Update, because that single event sweeps up JDK 21, 22, 23, 24, JavaFX 21 and GraalVM for JDK 21 at once, and an estate that cannot name its versions cannot price its exposure (see the 2026 Java version support cliff guide for what falls off and when).
- Force the treadmill decision to board level, not architecture level. With LTS releases every two years and a one-year permissive overlap, the free window per release is roughly 36 months, so the choice is either a standing 24-month upgrade program with funded engineering capacity in every budget cycle forever, or one funded migration off Oracle distributions; drifting between the two is how estates end up paying.
- Cut the download vector before the audit letter, owned by security. Block Oracle JDK downloads at egress, mirror approved binaries internally, and pull the list of accounts that have ever authenticated to Oracle's download portal, because Oracle's download telemetry is the most common opening exhibit in a Java review.
- If subscription is unavoidable, defend the employee number before you discuss price. Strip temps and non-supporting contractors from the count (we routinely see 18 to 28 percent overcounts in first-pass figures), then buy at the band boundary, since at 9,999 employees list is $1,259,874 against $990,000 at 10,000, and cap escalation well below the 8 percent advisory sources report as Oracle's standing ask.
- Pre-book the next two cliffs in the capital plan today. JDK 25 leaves NFTC in September 2028, twelve months after Java 29 ships in September 2027, so put those dates in the plan now and settle the upgrade versus migrate decision while you still have eighteen months of runway rather than eighteen days.
Frequently asked questions
How long is Oracle Java free under the NFTC?
About 36 months per LTS release. Oracle ships each new LTS under the No-Fee Terms and Conditions, keeps the previous LTS on permissive terms for one more year of overlap, then moves it to the OTN license.
With LTS releases arriving every 24 months, that yields roughly a three-year free update window, and less than that in practice once you subtract the time needed to qualify and deploy the release.
When exactly do free Java 21 updates stop?
Oracle distributed the last NFTC-licensed Oracle JDK 21 update in July 2026, and Java 21 builds from Java.com remain free to use until September 16, 2026.
Beginning with the October 2026 Critical Patch Update, further JDK 21 updates are planned under the Java SE OTN license, which does not permit production use at no cost. The same October 2026 change applies to JavaFX 21 and to GraalVM for JDK 21.
Does the OTN license really block all free use?
No, it blocks production. OTN permits personal use, development, testing, prototyping, and demonstration at no cost.
What it removes is the right to run Oracle JDK in production without a Java SE Universal Subscription, which is why the October 2026 transition converts a free operational estate into a licensable one without any change to your code.
Is Java 25 free, and until when?
Yes, under NFTC, and Oracle has already published the end date. Oracle JDK 25 updates are planned under the NFTC until September 2028, which is one year after the next planned LTS release, Java 29 in September 2027.
Oracle's own blog frames the switch as October 2028, so treat late 2028 as the cliff and budget the JDK 25 to 29 upgrade project in 2027, not 2028.
What does it cost if we stop upgrading and just subscribe?
The Java SE Universal Subscription is priced per employee, not per deployment. List runs from $15.00 per employee per month at 1 to 999 employees down to $5.25 at 40,000 to 49,999, with nothing published above 50,000.
A 5,000-employee firm pays about $630,000 per year even if Oracle Java runs on 40 servers, and Oracle's own published example puts a 28,000-employee organization at $2,268,000 per year.
Who counts as an employee under the Universal Subscription metric?
Everyone. The definition reaches full-time and part-time employees, temporary workers, and the contractors, agents, and consultants who support your internal business operations, regardless of whether any of them ever touch Java.
Advisory work routinely finds an 18 to 28 percent overcount from temps and non-supporting contractors, so the employee number is the first thing to defend, before price.
Can we avoid the treadmill entirely by moving to another OpenJDK build?
Yes, and that is the only move that ends the cycle rather than deferring it. Non-Oracle OpenJDK distributions decouple your patch supply from Oracle's licence calendar, so you upgrade on your own schedule instead of Oracle's 24-month one.
The honest comparison is not free Oracle versus paid Oracle, it is one migration project against a recurring upgrade program every two years plus the residual risk of a silent conversion in between.
