Java 17 stopped being free at build 17.0.13 on 15 October 2024, and every patch since then licenses your entire employee headcount at up to $15 per employee per month
Oracle's one-year NFTC overlap for Java 17 closed in September 2024, so the last no-cost build was 17.0.12.0.2 (16 August 2024). Nothing broke on the cliff date: the compliance event is the next patch a team applies, which converts a technical decision into an Employee-metric subscription covering every employee and contractor. Your next move depends on whether that patch has already landed.
Prepared by Redress Compliance · August 26, 2026 · Oracle Java advisory. Java SE Universal Subscription negotiations and audit defense, 2024 to 2026.
Executive summary
The cliff is a build number, not a date: 17.0.12.0.2 (16 August 2024) is the last free Oracle JDK 17 binary, and 17.0.13 (15 October 2024) is the first that requires OTN or a paid subscription.
Every Java 17 update from 17.0.13 upward carries the same restriction, so a single unattended patch cycle in October 2024 can be the entire basis of an Oracle claim two years later.
Nothing enforces the change technically, which is exactly why exposure accumulates quietly: no build stops working, no license check fires, and the compliance event is the next patch applied.
That means the population at risk is not "teams running Java 17" but the narrower set of teams that kept pulling Oracle-branded builds after August 2024, and identifying which is which is the first billable hour of any defense.
The only remediation Oracle sells is the Java SE Universal Subscription at $15 per employee per month list, falling to $5.25 in the 40,000 to 49,999 band, and it counts headcount rather than installs.
Oracle's own worked example bills 28,000 counted employees (23,000 staff plus 5,000 contractors) at $6.75 for $2,268,000 per year, whether the estate runs 40 servers or 4,000.
Three of the four viable exits cost nothing in license fees, and the fourth is negotiable by 28 to 44 percent if you can show a credible OpenJDK plan.
Rolling back to 17.0.12, swapping to a supported OpenJDK distribution with runways to 2029 or later, or restricting Oracle builds to development under OTN all remove the trigger; only continued Oracle production patching requires the subscription.
What actually changed: the build numbers, the dates, and the license that attaches
Oracle did not change the Java 17 license. It let a clock run out. When JDK 21 went GA in September 2023, that release started the one-year No-Fee Terms and Conditions (NFTC) overlap for JDK 17, the transition window Oracle grants so estates can move to the next LTS.
That window closed in September 2024.
The practical marker is the build number: 17.0.12.0.2, released 16 August 2024, is the last no-cost Oracle JDK 17 binary, and 17.0.13, released 15 October 2024, is the first one that requires either the Oracle Technology Network (OTN) license or a paid Java SE Universal Subscription.
Every update from 17.0.13 upward carries the same restriction.
The point most estates miss is that NFTC attaches to the binary, not to the version line: 17.0.0 through 17.0.12 remain free under NFTC indefinitely, including in production, including commercially, and Oracle cannot retroactively re-license a binary you already hold.
That asymmetry is the whole basis of your defense, and it is also why the date you concede matters more than any other fact in the file. Our breakdown of which Java versions remain free maps the same logic across 8, 11, 21, and 25.
| Date claimed as the cutoff | Source pushing it | What it actually marks | Why it matters in an audit |
|---|---|---|---|
| 16 July 2024 | Azul FAQ | Last GA distribution of a free build per Azul's reading | Earliest date on the table, worst for you |
| 16 August 2024 | Oracle patch-set date | Release of 17.0.12.0.2, the last NFTC binary | The defensible line: last free build |
| 19 September 2024 | java.com | Consumer download channel stopped serving free 17 | Distribution channel change, not license change |
| 15 October 2024 | Oracle CPU | Release of 17.0.13, first OTN-restricted build | The real compliance trigger |
The table cannot show the exemption that removes a large share of most Java 17 estates from scope. OTN permits personal use, development, testing, prototyping and demonstration at no cost.
An Oracle JDK 17.0.13 install on a developer laptop, a build agent, or a throwaway test container is not automatically a liability, and Oracle's LMS teams routinely count those installs anyway. Your rebuttal is scope, not volume.
Two follow-ons deserve a place in the same runbook. GraalVM for JDK 17 flipped on the identical schedule, moving from GFTC to the GraalVM OTN license after September 2024, so any Graal-based build toolchain inherits the same question.
And JDK 21 has now run the same course: the July 2026 quarterly update was its last free build, with NFTC ending 16 September 2026 and the 20 October 2026 CPU as the first restricted release.
If you remediated 17 by moving to 21, read what happens when free Java 21 updates end before you assume the problem is solved.
The compliance trigger is a patch pipeline, not a calendar entry
Nothing happened on your estate on 15 October 2024. No build stopped working, no license check fired, no telemetry gate tripped, no functional failure surfaced. That is exactly the problem: the compliance event is silent, and it happens the moment a machine takes 17.0.13 or later.
So the exposure question is narrow and answerable. Which hosts received a restricted build, when, and who authorized it. Everything else in the argument is noise.
In our engagements, three transmission paths account for nearly all unintended uptake. First, automated OS or configuration-management patching, where an Ansible role, SCCM package, or yum repository pushes the latest Oracle JDK without anyone reviewing the license terms.
Second, container base image refreshes, where a Dockerfile pinned to a floating Oracle JDK tag pulls a restricted binary on the next rebuild, sometimes hundreds of times before anyone notices.
Third, developer or vendor-supplied installers, including third-party application bundles that quietly ship an Oracle JDK inside their own installer.
None of these routes involves a purchase order, an architecture review, or a licensing decision, which is precisely how a patch pipeline licenses your estate without anyone raising a purchase order.
Four evidence sources decide the argument, and you want them in your hands before Oracle asks. Download records tied to an Oracle SSO account are the strongest single artifact because Oracle already holds their copy and will lead with them.
Runtime java -version output across the estate establishes what is actually installed today. Artifact repository and package manager logs establish when a restricted build entered your supply chain and through which channel.
Container image manifests and layer digests establish whether a rebuild pulled a restricted tag or an inherited one. Reconstruct that timeline yourself first, because the alternative is accepting Oracle's version of it.
Stop overpaying for Oracle Database 23ai options
Oracle Database 23ai bundles options you may never deploy. The buyer side guide to edition right sizing, option pruning, and AI Vector Search licensing.
Get the white paper →What the subscription costs if you concede: the Employee metric arithmetic
Oracle sells exactly one Java SKU today: the Java SE Universal Subscription, priced on an Employee metric, list $15 per employee per month at the 1 to 999 band and stepping down through seven bands to $5.25 at 40,000 to 49,999.
There is no published rate above 50,000 employees, the standard term is one year, and the rate is all-in: no separate 22 percent support line exists, so any budget model that adds a support percentage on top is double counting by roughly a fifth.
The metric counts all full-time, part-time and temporary employees plus the employees of your agents, contractors, outsourcers and consultants who support your internal business operations, and Oracle's own price list is explicit that quantity is determined by headcount.
Not by the number of people who touch the Programs.
Oracle's worked example makes the contractor inclusion concrete: 28,000 counted bodies (23,000 staff plus 5,000 agents and contractors) at $6.75 equals $2,268,000 per year.
One buried constraint matters for infrastructure-heavy estates: the subscription permits installation on up to 50,000 Processors, and beyond that ceiling, excluding desktops and laptops, an additional license is required.
Deployment size is otherwise irrelevant, which is the point of the metric and the reason it detonates small estates. See which Java versions are free and which ones bill your whole headcount before you accept any quote built off an install count.
| Scenario | Employees | List rate/mo | Annual list | Effective unit cost |
|---|---|---|---|---|
| 5,000 staff, Oracle Java on 40 servers | 5,000 | $10.50 | $630,000 | $15,750 per server |
| 12,000 staff, 4 installs or 4,000 installs | 12,000 | $8.25 | $1,188,000 | Identical either way |
| Band inversion, just under threshold | 9,999 | $10.50 | $1,259,874 | Penalty for being small |
| Band inversion, at threshold | 10,000 | $8.25 | $990,000 | $269,874 cheaper |
| Oracle's published example | 28,000 | $6.75 | $2,268,000 | Includes 5,000 contractors |
Read the inversion carefully, because it is not a rounding artifact. At 9,999 employees you pay $1,259,874; at 10,000 you pay $990,000. One additional counted head removes $269,874 of annual cost.
If your true count sits between roughly 9,400 and 9,999, buying to 10,000 is cheaper than buying what you use, and the same distortion sits at every band edge.
In practice the more useful direction is downward: advisors typically find an 18 to 28 percent overcount when temps and non-supporting contractors are stripped from HR extracts, and at 12,000 employees a 22 percent correction is worth about $261,000 a year at list.
Why Oracle priced the cliff so that patching is the cheapest thing you can stop doing
Every cost-reduction reflex your organization has is useless against this metric. Consolidate servers, decommission the dev estate, containerize, virtualize, cut the JVM count from 400 to 40: the bill does not move by a dollar.
Oracle deliberately decoupled price from consumption when it retired the processor and NUP metrics in January 2023, and the consequence is that the normal remediation ladder (measure, reduce, right-size, renew smaller) has exactly one rung on it.
Either the estate contains Oracle-branded binaries in a patched path or it does not. There is no partial position, no efficient middle, no clever architecture that shaves 30 percent off.
That leaves two rational responses, and only two: remove Oracle binaries entirely from anything you intend to keep patching, or negotiate a rate on a headcount you have scrubbed and scoped. Oracle knows the first path is technically trivial for the overwhelming majority of Java 17 workloads.
Bytecode compatibility across OpenJDK builds of the same version is effectively total, because they are built from the same upstream source. Swapping Oracle JDK 17.0.12 for Temurin, Corretto, Zulu or Liberica 17.0.13 is a path change and a restart, not a migration.
The engineering effort is measured in hours per application, not sprints.
So if the exit is that easy, why does Oracle keep collecting? Because the pricing is not a bet on technical lock-in. It is a bet on organizational friction.
Oracle is monetizing change-freeze windows that run November through January, vendor certification matrices that name "Oracle JDK" in a support statement nobody has re-read since 2019, patch pipelines owned by three different teams.
And the plain fact that no single person in most enterprises owns the Java runtime as a line item.
The runtime is infrastructure plumbing. It has no budget holder, no product manager, and no one whose bonus depends on it. That vacuum is the product Oracle is selling into.
Recognize what that means for your negotiation posture. Oracle's leverage is not the license text; it is the assumption that you cannot move before the next Critical Patch Update lands. The moment that assumption is false, the entire conversation changes character.
The benchmark data supports this directly: across 80-plus contracts, 28 to 44 percent price reductions track organizations with a credible OpenJDK migration plan.
And the 78 percent reduction modeled from entity-scoping (licensing only the legal entities still running Oracle Java after a partial migration) is available only to buyers who have already migrated part of the estate.
Neither outcome correlates with spend volume. Both correlate with demonstrated ability to leave. Our breakdown of the six Java options, including the two requiring no migration at all, is the fastest way to build that evidence.
The strategic sequence follows from this. Do not open a commercial dialogue and then start remediation. Remediate first, at least to the point where you can name the applications still on Oracle binaries and the date each will be off them, then open the dialogue.
A buyer who arrives with a scrubbed headcount, a migration completion date, and three applications already running on Temurin in production is negotiating a residual. A buyer who arrives with a discovery scan and a hope is negotiating a headcount.
Finally, treat the one-time framing as false. Java 21 fell off the identical cliff in September 2026, with the first non-free build arriving in the October 2026 Critical Patch Update. Java 25's NFTC window is scheduled to close in October 2028.
Oracle has stated a two-year LTS cadence, with Java 29 planned for September 2027. This is a treadmill, not an event, and every two years your change process faces the same decision under the same time pressure.
Paying once does not buy peace; it teaches your own organization that the cliff is a procurement problem rather than an engineering hygiene problem, which guarantees you meet it again with the same lack of readiness. The 2026 version support cliff guide maps the full sequence.
Build the muscle now, on Java 17, while the stakes are one LTS wide.
Your four remediation paths, and what each one actually costs
Four exits exist, and only one of them ends with a purchase order. Path one is pinning: freeze the estate on 17.0.12.0.2 (16 August 2024) and accept that no further security updates will ever arrive.
License cost is zero, because the NFTC grant attaches to the binary you already downloaded, not to the 17 version line. That is defensible for an air-gapped build agent or a short-lived internal batch host.
It is indefensible for anything internet-facing or PCI-scoped, and we have watched security teams veto it in the same meeting that finance approved it. Path two is migration to a supported OpenJDK 17 distribution: Amazon Corretto 17 carries security support to June 2029 inside Amazon Linux 2023.
Red Hat's build runs to December 2027, and Azul Zulu commits to at least eight years of LTS support.
Cost is zero to modest, and the classpath is identical, which is why our comparison of the six Java options treats most of these as reconfiguration rather than migration. Path three is confinement: keep Oracle JDK 17 patched under OTN, but only for personal use, development, testing.
Prototyping and demonstration, which OTN permits at no cost.
The whole path lives or dies on provable segregation, meaning a named host inventory, no production traffic, and no shared artifact that a UAT deployment can promote. Path four is concession: buy the Universal Subscription. Note what that actually purchases.
Oracle Premier Support for JDK 17 ends September 2026, so the subscription buys a shrinking runway and then Extended Support, and the roadmap already waives the Extended Support fee for Java SE 17 from October 2026 through September 2029.
No extended-support uplift quote for 17 should ever be signed.
| Path | License cost | Security runway | Main risk carried |
|---|---|---|---|
| Pin at 17.0.12.0.2 | Zero | None after Aug 2024 | Unpatched CVEs, audit-clean but security-exposed |
| OpenJDK 17 (Corretto, Red Hat, Zulu) | Zero to modest support fee | June 2029 / Dec 2027 / 8+ years | Migration testing effort, vendor consolidation |
| Oracle JDK 17 under OTN, non-production only | Zero | Full, dev/test scope only | Segregation must be provable in an audit |
| Universal Subscription | $15 down to $5.25 per employee per month | Premier to Sept 2026, Extended to Sept 2029 | Whole-headcount metric, waived fee must be enforced |
The table hides the asymmetry that matters: three of the four paths cost roughly nothing and one costs your entire employee count times twelve. Oracle's commercial case for path four rests on the assumption that migration is hard.
For Java 17, where the bytecode target and the standard library are the same across distributions, it usually is not.
Sequence these rather than choosing one. Pin first to stop the bleeding, confine the Oracle binaries you genuinely need for development, migrate production to a supported OpenJDK build, and hold the subscription in reserve as the priced fallback that makes the other three credible in a negotiation.
Evidence base: the patterns we see across Java 17 remediation engagements
Temps and non-supporting contractors get swept into the Employee count that Oracle's own definition does not require.
Benchmarks across 80-plus contracts show reductions of this size when the buyer can show a dated migration schedule.
The rest of the pattern is consistent enough to plan around.
Negotiated rates land at $9.50 to $12.80 per employee per month for 1,000 to 10,000-employee organizations and $6.20 to $9.80 for large enterprises accepting a multi-year commit, against an average 340 percent increase versus pre-2023 processor licensing.
Entity-scoped licensing, where only the legal entities still running Oracle Java after a partial migration are licensed, has been modeled at 78 percent off a group baseline. Three evidence traps recur.
First, the dates conflict across sources: vendor FAQs variously cite a 16 July distribution, an August patch set, a 19 September license window close, and the 15 October 17.0.13 release, and no concession should be made before the GA date, the BPR date.
And the license window close are reconciled against the specific build hash in your estate.
Second, adjacent products flip on the same clock: GraalVM for JDK 17 moved to the GraalVM OTN license in September 2024, and JavaFX 21 follows after September 2026, so a Java-only inventory understates exposure.
Third, and most common in our engagements, the only Oracle-branded JDK on the estate arrived bundled inside a third-party appliance or ISV product, where the ISV's own distribution rights may already cover it.
Establish provenance before you count anything, using the approach in our guide to checking your Oracle license position.
- 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
- Inventory every JDK by vendor string and build number, this week. Have the platform owner run java -version plus a filesystem sweep across servers, desktops, container images, and CI runners, then flag anything reporting Oracle 17.0.13 or above as an active exposure rather than a housekeeping item, because the free build line stops at 17.0.12.0.2.
- Freeze Oracle-branded patch sources in configuration management and registries before the next quarterly update. Ansible roles, Dockerfile base images, and internal artifact mirrors pull Oracle binaries automatically, so the release engineering lead should block those sources within one sprint, ahead of the 20 October cycle that will also convert Java 21 estates.
- Reconcile the three competing cutoff dates and pull your own download-account records. Oracle's GA date (July), the patch-set date (16 August 2024), and the license window close (September 2024) do not agree, and Azul cites 16 July, so an audit team will assert the earliest one unless procurement holds timestamped evidence of what was downloaded and when.
- Rebuild the counted-employee number before any quote conversation. The metric captures full-time, part-time, temporary staff plus supporting contractors, and advisors typically measure an 18 to 28 percent overcount in the number Oracle proposes, so HR and legal should agree a defensible figure and test whether partial migration lets you license only the remaining legal entities.
- If a subscription is unavoidable, bank the waived Extended Support fee and price the later cliffs into the same term. Oracle waives the 17 Extended Support uplift from October 2026 through September 2029, so refuse any uplift quote, and use the Java 21 and Java 25 cliff dates as negotiating content rather than a repeat conversation in eighteen months.
Frequently asked questions
Is Java 17 still free to download?
Yes, and that is the confusion Oracle benefits from. Builds 17.0.0 through 17.0.12.0.2 remain available under the No-Fee Terms and Conditions license and stay free permanently, because the license attaches to the binary you downloaded rather than to the 17 version line.
Builds 17.0.13 and later are distributed under the Oracle Technology Network license, which does not permit commercial or internal business use without a paid subscription.
Which Java 17 build is the last free one?
17.0.12.0.2, released 16 August 2024. The first restricted build is 17.0.13, released 15 October 2024, and every subsequent 17 update carries the same OTN restriction.
Note that you will see 16 July 2024 quoted as the last free distribution date and 19 September 2024 quoted as the date java.com builds stopped being free; reconcile the GA date, the patch-set date and the license window close before conceding anything in an audit.
What triggers a licensing obligation for Java 17?
Applying a restricted build in a commercial or internal business context, not the passage of the cliff date. No build stops working, no license check fires, and nothing changes on your estate on the cutoff date.
Exposure begins at the next patch, which is why automated patching, container base image refreshes and vendor-supplied installers are the three paths that create most unplanned liability.
Can we keep using Oracle JDK 17 for development without paying?
Yes, within limits. The OTN License Agreement for Java SE permits personal use, development, testing, prototyping and demonstrating at no cost. Commercial or internal business use, including running an internal application that supports operations, requires the paid Java SE Universal Subscription.
The practical test in an audit is whether you can prove segregation between development machines and anything supporting business operations.
How much does a Java 17 subscription cost?
Oracle sells only the Java SE Universal Subscription on an Employee metric, starting at $15 per employee per month and declining to $5.25 in the 40,000 to 49,999 band, with no published rate above 50,000 employees.
The count includes full-time, part-time and temporary employees plus agents, contractors, outsourcers and consultants supporting internal business operations, regardless of who uses Java. Oracle's own example bills 28,000 counted employees at $6.75 for $2,268,000 per year.
The rate is all-in, so adding a 22 percent support line double counts.
What are the free alternatives with a longer support runway than Oracle's?
Oracle Premier Support for Java 17 ends September 2026, which is shorter than several no-cost distributions.
Amazon documents Corretto 17 security support until June 2029 in Amazon Linux 2023, Red Hat's OpenJDK 17 support runs to December 2027, and Azul supports its Zulu LTS releases for at least eight years.
Vendor support for OpenJDK 17 across the market runs anywhere from September 2026 to at least October 2029, so the runway is a procurement choice, not a fixed date.
Does the same thing happen to Java 21 and Java 25?
Yes, on a published schedule. JDK 21 updates were under NFTC through September 2026, with the July 2026 quarterly update the last free build and the October 2026 Critical Patch Update moving to OTN; Oracle's release notes advise not using 21.0.12.1 after 20 October 2026.
JDK 25 is planned to stay under NFTC until October 2028, one year after Java 29 arrives in September 2027. Plan for a recurring two-year cliff rather than a one-time event.
