Many IT teams think the Oracle Java 17 deadline is still ahead of them. It isn't. The licensing window quietly closed on October 15, 2024, and the consequences have been accumulating ever since. If your organization is still running Java 17 under the assumption it's free, you may already be operating under terms you never agreed to and never noticed change.
The bill, when it arrives, won't reflect how many servers run Java. It will reflect how many people are on payroll. Oracle has already changed the licensing model, and the gap between what IT teams assume and what Oracle's current terms actually require is wide enough to generate material financial and audit risk.
What Actually Changed in October 2024
Java 17 was released in September 2021 as a Long-Term Support version. Oracle introduced it alongside the No-Fee Terms and Conditions license, commonly called the NFTC, which allowed organizations to use Java 17 in production without a paid subscription. For many IT leaders, this looked like a continuation of how Java had worked for years: effectively free.
That interpretation was correct, but only temporarily. On October 15, 2024, Oracle moved update releases of Java 17 from the NFTC to the Oracle Technology Network (OTN) license, the same license that already governed Java 8 and Java 11. The OTN license is free for personal, development, and testing use only. Any production use after that date requires a paid Oracle Java SE Universal Subscription.
The shift didn't generate an invoice. It didn't trigger an audit notice. There was no system alert.
Most IT teams continued patching, deploying, and updating Java 17 the same way they had been doing for three years, unaware that the licensing terms underneath those operations had quietly inverted.
Premier Support for Java 17 continues until September 2029, with Extended Support running through September 2032, so security patches keep coming. But that coverage only applies to organizations with an active subscription. Everyone else is using updates that are no longer permissively licensed, and the Premier Support path is now a paid path. The question for IT leaders isn't when the deadline arrives. It's whether they're already past it.
How Oracle Rewrote the Licensing Rules
The more consequential change isn't the support timeline. It's the underlying licensing model itself. When Oracle introduced the Java SE Universal Subscription on January 23, 2023, it didn't simply adjust prices. It changed the fundamental unit of measurement by which Java is licensed.
Under the previous Java SE Subscription, organizations paid based on the number of processors or named users running Java. That model was complicated, but it at least tethered the licensing cost to something approximating actual usage. The Universal Subscription replaced that approach with something far more expansive. Organizations are now required to license Java based on total employee count, including full-time employees, part-time staff, contractors, and consultants supporting internal business operations.
An organization running Java on fifty servers does not negotiate a fifty-server deal. It negotiates a deal based on how many people work there, regardless of how many of those people ever interact with a Java application or are even aware Java exists in the environment. For a mid-market organization with 2,000 employees at the list price of roughly $15 per employee per month, that's about $360,000 per year, whether five employees use Java or all of them do.
Oracle has described the Universal Subscription as a simplification. In narrow terms, that's accurate. It consolidates the line items. But simplification here means the scope of what's being licensed expanded considerably, not that the cost went down. IT leaders who haven't re-evaluated their Java licensing posture since 2022 may be working from assumptions about cost and scope that are no longer valid.
The Visibility Problem Underneath the Licensing Problem
If the licensing changes were the only challenge, they'd be manageable through a targeted review of known Java deployments. The deeper problem is that most organizations don't have reliable visibility into where Java actually lives across their environment.
Java isn't just an application runtime IT teams install intentionally and track carefully. It's embedded in enterprise applications, middleware platforms, development toolchains, container images, and legacy systems. A commercial application may ship with its own bundled Java runtime that the vendor manages separately and that doesn't appear in standard software inventory. A containerized workload may inherit a Java version from a base image built years ago. A developer's workstation may have multiple Java versions installed in parallel, some current and some not. The environment doesn't announce these installations. They accumulate silently as dependencies of other things.
This means the answer to a basic question, how many Java installations does your organization have, is genuinely difficult to produce. Endpoint management platforms may capture installations on managed devices but have no visibility into server environments or container workloads. CMDB records reflect Java as it was deployed at a point in time, not how it has evolved through application updates and infrastructure changes. The exposure stays invisible until something external forces it into view. That forcing mechanism is usually a vendor audit or a renewal conversation. Neither arrives at a convenient time.
How Licensing Exposure Gets Discovered
Oracle has a well-documented history of conducting software licensing audits, and the Universal Subscription has given those audits a wider surface area. When an audit request arrives, it typically requires organizations to provide an accurate count of eligible employees and evidence of all Java installations across the environment. For organizations without centralized software intelligence, producing that documentation becomes an emergency project rather than a routine compliance exercise.
The audit dynamic is structurally disadvantageous for organizations that discover exposure after the fact. Negotiating a subscription when an audit has already identified potential non-compliance is different from negotiating proactively. Oracle's audit rights are broad, and the employee-based model means the difference between a compliant and non-compliant posture can represent a substantial financial gap.
Renewal conversations create related pressure. Organizations migrating from Oracle JDK to OpenJDK distributions, a common strategy to reduce licensing dependence, often find the transition is more complicated than anticipated. Not all Java applications are runtime-agnostic. Some require Oracle's specific JDK implementation, and identifying which workloads have that dependency requires the same kind of deep inventory capability most IT teams haven't built. Both scenarios share a common characteristic: the organization is responding to external pressure rather than acting on internal intelligence.
Don't Wait for an Audit Letter to Find Out Where Java Is Running
Block 64 scans your environment and surfaces every Java installation across servers, endpoints, containers, and bundled applications, so you can model your exposure before the conversation with Oracle starts.
Try it free or ask about our Advisory Services.
A Broader Pattern Across Enterprise Software
Oracle's Java licensing evolution is not an isolated event. It reflects a broader pattern of enterprise software licensing changes that has been accelerating across the industry. VMware's transition to subscription-based licensing following the Broadcom acquisition created similar disruption for organizations that had built infrastructure plans around perpetual license assumptions. Microsoft's adjustments to its Enterprise Agreement program have pushed mid-market organizations toward arrangements with different scopes and cost structures. Vendors across the stack have been tightening audit rights, narrowing free tier access, and restructuring pricing in ways that expand what organizations are required to pay for.
The common thread is that these transitions reward organizations with clear, current visibility into their software environments. When a vendor changes its licensing model, an organization that knows precisely what it has deployed, on how many systems, and under what existing terms can assess the impact and model its options. An organization that lacks that visibility is forced to discover its exposure at the same moment it needs to act on it.
For IT leaders, the Java 17 situation is a concrete illustration of a risk that exists across the entire software portfolio. The specific mechanics, NFTC, OTN, the Universal Subscription, the October 2024 transition, are Java-specific. The underlying dynamic, a licensing change that creates exposure invisible until it isn't, is common to dozens of software relationships mid-market IT organizations maintain.
What Visibility Actually Requires
Addressing Java licensing exposure means moving toward a more complete picture of the software environment than most organizations currently maintain. That requires discovery that extends beyond managed endpoints to include servers, virtual machines, containers, and cloud workloads. It means correlating installation data against license entitlements to identify where gaps exist. And it means maintaining that picture continuously rather than producing it as a snapshot in response to an audit or renewal.
This is why mid-market IT teams are turning to unified software visibility platforms that continuously map applications, runtimes, and infrastructure dependencies. These tools give IT teams the intelligence they need before a vendor conversation forces the issue, rather than after.
For Java specifically, the immediate priority is understanding the actual footprint: how many installations exist, which Java distribution they're using, and what applications depend on them. That inventory becomes the foundation for modeling what the Universal Subscription would actually cost, evaluating whether OpenJDK migration is feasible for specific workloads, and entering any vendor conversation with an informed position rather than an improvised one.
The October 2024 licensing shift already happened. For organizations that have done the work, inventoried their Java footprint, understood their posture, and made deliberate decisions about subscriptions or migration, it represents a managed transition. For organizations that haven't started, the experience will be different: they'll discover the exposure when an external party forces them to, and the window for acting on their own terms will already have closed.
Find Out If You're Already Out of Compliance
A software visibility assessment identifies Java deployments, licensing exposure, and migration opportunities before a vendor audit forces the conversation. Learn how Block 64 helps mid-market IT teams map their software environment and identify hidden licensing risks. Or check out our hands-on Advisory Services, which include a free subscription to the platform.