Java 17 and NFTC Licensing: What CIOs and IT Leaders Must Know

Java 17 and NFTC Licensing: What CIOs and IT Leaders Must Know

In 2021, Oracle surprised the industry by releasing Java 17 under a new No-Fee Terms and Conditions (NFTC) license – essentially making Oracle’s JDK free again for a time​.

This was a big shift after Oracle’s 2019 move to charge for Java under the older OTN license. However, the “free” period for Java 17 comes with strict conditions and an expiration date. CIOs, CFOs, and IT asset managers must understand what NFTC allows, when the free ride ends, and how to avoid costly licensing traps.

Below is a direct, no-nonsense guide to Java 17’s NFTC licensing and what to do next.

NFTC vs. OTN – Oracle’s Java Licensing Explained

Oracle’s OTN License (Pre-2021): Before NFTC, Oracle’s Java was offered under the Oracle Technology Network (OTN) license for Java SE. The OTN terms allowed free use only in very limited scenarios – primarily for development, testing, prototyping, demonstrations, and personal use.

Any commercial or internal production use under OTN requires a paid Java SE subscription. In other words, running Oracle Java on a business server or client without a subscription was not permitted. This 2019 licensing change effectively ended “free” Java for enterprises and prompted many to seek alternatives​.

Oracle’s NFTC License (Introduced with Java 17): In September 2021, Oracle introduced the NFTC license for Java 17, responding to backlash and demand for a free Oracle JDK. Under NFTC, Oracle JDK 17 could be used at no cost for all purposes, including internal business applications and production​.

There was no catch in terms of usage: internal, commercial, and production deployments were allowed royalty-free, unlike the OTN terms. However, NFTC came with a time limit. Oracle promised to provide free updates for Java 17 only until one year after the next Long-Term Support (LTS) Java release​.

In practice, this meant Java 17 was free to use and update for about three years (the two-year LTS cycle plus one extra year). After that, Oracle would revert Java 17 to the restrictive OTN license for any further updates.

To clarify the difference, here’s a quick comparison of NFTC vs. OTN for Java:

As shown above, NFTC temporarily opened the door for free production use of Oracle Java, whereas OTN keeps that door shut without payment. Notably, Oracle also distributes builds of OpenJDK (GPL license), but these come with no support and only brief update windows. The focus here is on the Oracle JDK distributed under NFTC/OTN terms.

When Does Java 17’s Free NFTC Coverage End?

Oracle’s NFTC for Java 17 doesn’t last forever. The “no-fee” period officially ends one year after the next Long-Term Support (LTS) release. Java 21, the successor to Java 17 LTS, was released in September 2023.

One year later, in September 2024, Java 17 fell out of NFTC coverage. Oracle clearly states that updates of JDK 17 released after September 2024 are provided under the Java SE OTN License (no longer NFTC)​. In practical terms, any new patch or update for Java 17 released after that date will not be free for production use.

Example – Java 21 and a Java 17 Patch: Java 21’s release (Sept 2023) started the clock. Oracle continued issuing Java 17 updates during the following year under NFTC. For instance, an update like the January 2024 CPU patch for Java 17 (JDK 17.0.10) was still covered by NFTC and free to apply.

But once Java 21 had been out for a year, the very next Java 17 update (e.g., the October 2024 release of JDK 17.0.13) switched to the old OTN terms​. Oracle’s release notes confirm that JDK 17.0.13 is the first Java 17 update under the OTN license, which is “substantially different” from NFTC – meaning that uses that were free under NFTC (such as running in production) “may no longer be available” without a subscription.

In short, applying a Java 17 patch released after the NFTC window (after Sept 2024) will put you out of NFTC compliance. The environment that was once free now suddenly falls under Oracle’s paid licensing requirements.

If you continue to use Oracle JDK 17 beyond the free update period, you are essentially accepting the OTN license for those updates, which prohibits commercial use without a license. CIOs need to identify when their Java installations cross this line to avoid running unlicensed software unintentionally.

Consequences of Crossing into OTN Territory

Crossing from NFTC into OTN licensing for Java 17 exposes your organization to compliance and financial risks. Here’s what can happen if you go past the free terms:

• Unbudgeted License Liability: The moment you deploy an Oracle JDK 17 update that’s under OTN (post-Sept 2024 versions), you legally need a Java SE subscription for any production use. If you haven’t purchased one, you are out of compliance. Oracle’s current Java SE subscription isn’t cheap – it now uses an employee-based pricing model, meaning you must license every employee in your organization, regardless of how many use Java. This can lead to significant, unexpected costs for large firms (even if only a subset of servers runs Java). CFOs should note that Oracle’s per-employee Java licensing can quickly run into seven figures for a large enterprise, as it is charged per headcount, not per server.
• Audit and Penalty Risk: Oracle is known to enforce its Java licensing. Running Oracle Java in production without a valid subscription is a violation of the Oracle Technology Network (OTN) terms. Oracle’s License Management Services have been actively auditing companies for Java usage since these rules changed. If an audit finds you used Oracle JDK 17 updates past the NFTC period without paying, you could be forced into a costly retroactive license purchase or face penalties. Compliance issues, surprise fees, or legal action are real possibilities​. One advisory notes that any organization updating Java 17 beyond version 17.0.12 “will need to pay” for a subscription, and failing to do so may result in compliance issues or audit penalties​.
• Security Trade-offs: Some organizations may try to avoid OTN fees by sticking with the last free version (17.0.12) and not applying further patches. While this avoids immediate licensing costs, it introduces a security risk. Oracle’s post-NFTC patches include critical security fixes. If you forego these, your Java 17 installations will grow increasingly vulnerable over time. Running an outdated Java runtime in production could expose your business to cyber threats and stability issues. Thus, avoiding updates to save money is a risky strategy in terms of security compliance and operational risk.
• Operational Constraints: Even aside from audits, being stuck on an old update (to stay “free”) can hurt your IT strategy. You may not be able to apply bug fixes or performance improvements without a subscription. Moreover, Oracle’s licensing change is part of a broader strategy: new LTS releases every two years and phasing out free use of older versions. It signals that relying on “free” Oracle JDK indefinitely is not viable. You’ll either need to regularly upgrade your Java version or face eventual licensing costs. Both paths require planning.

In summary, once you cross into OTN territory with Java 17, you’re looking at either paying Oracle’s price or accepting significant risk. Non-compliance can lead to painful audits and bills, while failing to update can lead to security incidents.

Neither is a good outcome for a CIO or CFO to justify. The next section outlines your options for navigating this situation.

Your Options Once the NFTC Term Ends

When Java 17’s no-fee term expires, organizations essentially have four paths forward. Each comes with pros and cons in terms of cost, risk, and effort:

• Stay on Java 17.0.12 (No Further Updates): One option is to freeze your Oracle Java 17 at the last NFTC-covered release (17.0.12 or earlier) and do not apply any new Oracle updates. This lets you continue running Java 17 under the NFTC terms, since those older builds remain licensed for free use. The benefit is that you avoid immediate subscription costs. However, this option means no more security patches – your Java runtime will become outdated and potentially vulnerable over time. This is a short-term stopgap at best. You’ll need additional mitigations, such as network security and monitoring, to manage the growing risk, and a plan to eventually upgrade or replace these Java instances.
• Upgrade to Java 21 (Next LTS): Oracle’s latest Long-Term Support (LTS) release, Java 21, was released in 2023 and is also available under NFTC terms for now. Upgrading to Java 21 resets the clock: you get free production use and security updates for that version until one year after the next Long-Term Support (LTS) release (Java 25, expected in 2025). The advantage is that you remain compliant and continue to receive updates without paying Oracle (until 2026, in this case). The drawback is the effort of migration and testing – you must ensure your applications are compatible with Java 21. Additionally, this only postpones the licensing issue: when Java 21’s NFTC period expires, you’ll face a similar decision again. This approach suits organizations that can keep pace with Java’s two-year long-term support (LTS) upgrade cycle as a way to avoid fees.
• Purchase an Oracle Java Subscription: If you cannot upgrade easily and need to keep using Java 17 with ongoing updates, you can bite the bullet and buy Oracle’s Java SE Universal Subscription for your environment. This will license your Java 17 use past the NFTC period under Oracle’s support. The upside is full access to updates (and support) for Java 17 and other versions. The downside is cost. Oracle’s subscription model is now based on your total employee count, not the number of Java installations. That means even a moderate Java usage could require licensing hundreds or thousands of employees, which can be extremely expensive for large firms. Smaller organizations will also feel this if they have to license the entire company. Before choosing this route, get a clear cost estimate from Oracle and weigh it against the other options. (For some, the cost will be justified for stability; for others, it will be prohibitive.)
• Switch to OpenJDK or Third-Party JDK Distributions: Another route is to move away from Oracle’s JDK altogether and adopt an OpenJDK-based distribution from a third party. Open-source builds, such as Eclipse Temurin, Amazon Corretto, Azul Zulu, or Red Hat’s build of OpenJDK, are Java 17 implementations that can be used for free in production. Many of these vendors provide longer-term security updates for Java 17, independent of Oracle’s timeline, and some offer paid support at a fraction of Oracle’s cost if needed. The benefit here is avoiding Oracle’s licensing fees entirely​. Java is Java – switching to another vendor’s JDK typically requires no code changes, just deployment and testing for any subtle differences. Organizations pursuing this option should validate that the alternative JDK is a drop-in replacement and ensure their teams can manage updates from the new source. This path gives you more control and independence, but remember to stay up to date with updates from the chosen vendor.

Each organization’s choice may differ. Some may do a mix – e.g., upgrade critical systems to Java 21, but use a third-party JDK for legacy apps that can’t be upgraded quickly.

The key is to decide proactively rather than slide unknowingly into an Oracle license violation.

Recommendations for CIOs and IT Leaders

Given the above, here are blunt recommendations to stay on top of Java 17 licensing and avoid unpleasant surprises:

• Inventory Your Java Installations: Immediately audit where Oracle Java 17 is running in your environment. Identify the versions in use (are they 17.0.8, 17.0.12, 17.0.13?) and whether those systems are production-critical. This will tell you if you’re already past the free-use cutoff or when you will be.
• Lock Down Updates: If you plan to stick with Oracle JDK 17 without a subscription, do not apply updates past 17.0.12. Disable or closely control any automated update mechanisms. One unintentional patch (for example, an admin installing the latest Java update out of habit) could switch your deployment into a paid license model overnight.
• Evaluate Upgrade vs. Subscription: For each Java-dependent system, decide whether to upgrade it to Java 21 or purchase a Java 17 subscription. Upgrading requires testing but avoids fees for a few more years. A subscription provides stability, but at a high cost – get quotes for Oracle’s per-employee pricing to inform your decision. Factor in your organization’s appetite for frequent upgrades versus the budget for licensing.
• Consider OpenJDK Alternatives: Strongly consider moving workloads to an OpenJDK distribution to escape Oracle’s licensing trap altogether. Many enterprises have successfully switched to free alternatives. Plan a pilot migration for a non-critical system to validate compatibility. If successful, this path can save significant costs in the long run and reduce dependence on Oracle’s release cycle.
• Plan for Regular LTS Transitions: If you choose to remain on Oracle’s free track (using NFTC licenses), incorporate the Java LTS release cycle into your IT roadmap. Oracle is releasing new LTS versions every two years, with a one-year grace period. This means a major Java upgrade at least every three years to stay on a free version. Ensure your development and QA teams are prepared for this cadence, or you will eventually fall behind and face the licensing issue again.
• Educate and Communicate: Make sure your IT staff and asset management teams understand these Java licensing constraints. A simple oversight, like an engineer downloading a later JDK 17 security patch, could put you out of compliance. Establish clear internal guidelines for using Oracle JDK, applying patches, and migrating to new versions or vendors. It’s cheaper to prevent a licensing mistake than to fix one.
• Engage License Management if Needed: If your Java usage is extensive or complex, involve your software asset management and legal teams. They can help interpret Oracle’s terms and ensure you have documentation for whatever path you choose (e.g., proof that you stayed on 17.0.12, or records of moving to OpenJDK). In high-stakes cases, consulting a third-party Oracle licensing expert might be wise to double-check compliance.

By taking these actions, CIOs and IT leaders can navigate the end of Java 17’s NFTC free period with minimal disruption. The overarching goal is to stay secure and compliant without paying more than necessary.

Java remains vital to many enterprise applications, but Oracle’s licensing shift means it needs to be managed carefully. Whether you upgrade, subscribe, or switch to a different JDK, do it on your terms and timeline, not as a reaction to an audit or a critical zero-day vulnerability.

Bottom Line: Java 17 under NFTC gave the enterprise world a reprieve on licensing costs. That reprieve is now expiring. Smart organizations will take a proactive stance – know your Java usage, avoid accidental license exposure once the free period ends, and choose a path (upgrade, alternative JDK, or subscription) that best balances risk and cost. In all cases, the worst move is to do nothing.

Now is the time to ensure your Java strategy is aligned with your organization’s budgetary and security priorities.