Oracle Java Licensing Change in 2024: From NFTC to OTN for Java 17

Oracle Java Licensing Change in 2024: From NFTC to OTN for Java 17

Oracle significantly changed its Java 17 licensing in late 2024, ending the free “No-Fee Terms and Conditions” (NFTC) period and transitioning to a more restrictive Oracle Technology Network (OTN) license.

This means that enterprises that previously used Oracle Java 17 for free now must pay for a Java subscription (or find alternatives) to continue receiving updates and remain compliant.

CIOs and IT leaders must understand this change, assess their Java usage, and take action to prevent unexpected costs or legal risks.

Background: Java 17’s NFTC Free License (2021–2024)

When Java 17 was released in September 2021, Oracle introduced the No-Fee Terms and Conditions (NFTC) license. This was a unique, temporary license model intended to encourage rapid adoption of Java 17.

Under NFTC, organizations could:

• Use Java 17 in Production for Free: Companies were allowed to deploy Oracle JDK 17 in commercial and production environments without paying licensing fees.
• Obtain Free Security Updates: Oracle provided regular quarterly security patches (Critical Patch Updates) for Java 17 at no cost, keeping it secure through 2024.
• Plan for a Limited Free Window: Oracle made it clear that NFTC was time-limited. The free period was set to expire one year after the next Java Long-Term Support (LTS) release. With Java 21 (the next Long-Term Support, or LTS) release scheduled for September 2023, the NFTC free-use window for Java 17 was set to end in September 2024.

Oracle’s strategy with NFTC was to get organizations onto the latest Java version by removing cost barriers.

For three years, many businesses benefited from free Java 17, thereby avoiding the subscription fees that older versions, such as Java 8 or 11, required.

However, this “free ride” was always meant to be temporary, setting the stage for a paid model once the free term elapsed.

The 2024 Licensing Change: NFTC to OTN for Java 17

In late 2024, Oracle ended the NFTC license for Java 17 and transitioned Java 17 updates to the Oracle Technology Network (OTN) License.

This change took effect around the October 2024 quarterly update. The last free NFTC-covered update was JDK 17.0.12. Starting with JDK 17.0.13 (released October 2024), Oracle JDK 17 is only available under the OTN terms for most users.

This licensing shift has several major implications:

• Paid Subscription Required for Production: Under the new model, any organization that wants to apply Java 17 updates (17.0.13 and beyond) in a commercial production environment must purchase an Oracle Java SE subscription. The free NFTC coverage is no longer in effect; therefore, continuing to use the updated Oracle Java 17 without a paid license violates Oracle’s terms.
• Free Use Now Limited to Non-Production: Oracle’s OTN license allows Java 17 to remain free only for specific, non-commercial purposes such as personal use, development, testing, prototyping, or demonstrations. In other words, developers can still download and use Oracle JDK 17 at no cost on their local machines for coding and testing purposes. However, deploying those updates in live business applications now triggers licensing requirements.
• Security Patches Behind Paywall: Crucial security fixes for Java 17 released after late 2024 are available exclusively to paying customers. Organizations that do not pay for a subscription will no longer receive critical patch updates for Java 17, leaving them vulnerable to security vulnerabilities if they remain on older patch levels.
• Compliance Risk Spike: The moment Java 17 fell under OTN terms, companies that unknowingly continue updating Oracle Java or using it in production without a subscription become out of compliance. Oracle’s license audits could identify these unlicensed uses, potentially leading to hefty backdated fees or penalties for the organization.

Illustration: Oracle’s shift from the free NFTC license to the restrictive OTN license for Java 17 in 2024 means businesses must now pay for updates or seek alternatives. The free ride is over, and CIOs must adjust their Java strategy.

The table below summarizes how the licensing terms changed for Java 17, comparing the NFTC era (before October 2024) to the OTN era (after the change):

In short, Java 17 is no longer free for businesses after this change. The OTN license is essentially a “paywall” for production use.

Organizations that have enjoyed three years of free Java 17 support must now decide whether to pay Oracle for continued support or pursue alternative options.

Understanding the OTN License and Its Impact

The Oracle Technology Network (OTN) License Agreement for Java SE is the same type of license Oracle has long used for older Java versions (Java 8 and Java 11). It is a free-to-download license with heavy restrictions on use.

Key points of the OTN license for Java 17 include:

• Allowed Uses (No Cost): You can use Oracle JDK 17 under OTN at no charge for individual, non-commercial purposes or certain internal development activities. This covers personal use (e.g., a developer’s project), development and testing in a non-production environment, prototyping, and demonstrations. These uses do not generate licensing fees.
• Disallowed Uses (Require Payment): Any “commercial use” or “use for internal business operations” of Java 17 under OTN requires an active Oracle Java SE subscription. In practical terms, if Java 17 is running any production application or any internal system that is part of your business processes, that usage is not free. Even staging or QA environments might be considered internal business use if they are not purely for non-revenue-generating test purposes. Essentially, OTN prohibits enterprises from using Oracle Java in production without purchasing a license.
• No More Free Support: Under OTN, Oracle will no longer provide free bug fixes or security updates to non-paying users. Only customers with a Java SE subscription (which gives access to Oracle’s Support portal) can download patches beyond 17.0.12.

This change forces businesses to consider the cost of Oracle Java versus alternatives. Oracle’s Java SE Universal Subscription is the commercial offering that covers Java 17 and other versions under OTN.

Notably, in 2023, Oracle switched to a per-employee pricing model for Java licenses, which can be expensive:

• Per-Employee Pricing: The Java SE Universal Subscription is priced based on the total number of employees, not per server or user. It starts at $15 per employee per month (for organizations with up to 999 employees) and the rate scales down for larger enterprises (as low as ~$5 per employee for very large companies). Importantly, this count includes all employees, not just developers or Java users – a point that has caused sticker shock.
• Significant New Costs: Many companies incur six-figure annual expenses to maintain their Oracle Java licenses. For example, a firm with 500 employees would pay about $90,000 per year at list pricing (500 × $15 × 12 months) to license Oracle Java across the company. Larger organizations with thousands of staff members could incur Java licensing costs of hundreds of thousands to millions of dollars annually. These costs are significantly higher than Oracle’s previous Java licensing model (which was based on either per server or per named user), and they essentially represent a new budget line item that didn’t exist during the NFTC free period.
• Real-World Example: Before this change, a mid-sized business might have paid nothing for Java 17 or only a few thousand dollars under older models. After the switch, the same business, with, say, 250 total employees, could see its Java licensing cost jump from near $0 to $45,000 per year under the per-employee model. This kind of increase (in this case, roughly 15× more than an older license metric) has been common, leading some IT executives to label Oracle’s new pricing an “overstep.”

The OTN license essentially puts organizations at a crossroads: either pay Oracle’s subscription fees or stop using Oracle’s Java updates in production.

Understandably, this has led many IT teams to evaluate alternatives and explore ways to mitigate the impact on cost and compliance.

Options for Enterprises After the Licensing Change

With Java 17’s free period over, CIOs and IT managers must decide how to proceed. Here are the primary options to navigate Oracle’s licensing change:

• Option 1: Purchase an Oracle Java Subscription. The straightforward (but costly) path is to budget for and acquire Oracle’s Java SE Universal Subscription. This ensures you can legally continue using Java 17 (and other versions) in production and receive all updates and support. It’s a convenient solution (Oracle provides patches and support tools), but it comes with a hefty recurring cost. Organizations should consider entering negotiations with Oracle to potentially optimize the price or bundle Java as part of broader Oracle agreements. This option essentially involves paying for assurance and staying within Oracle’s official support ecosystem.
• Option 2: Freeze on Java 17.0.12 (No Further Updates). Some companies may choose not to apply any Java 17 updates beyond the last free release (17.0.12). By staying on the final NFTC-covered version, they avoid immediate licensing fees. In the short term, this means no new costs. However, the downsides are significant: you will miss all future security patches and bug fixes, which over time leaves your Java 17 installations increasingly vulnerable to exploits and compliance issues (especially if regulatory standards demand up-to-date security).
  Additionally, if you eventually must update (e.g., to fix a critical vulnerability), you’ll face the subscription requirement at that point. This “do nothing” approach is generally a stopgap and carries a security risk. It may be worth considering if you plan to decommission those Java-dependent systems soon or migrate away from Oracle Java shortly.
• Option 3: Migrate to an OpenJDK Distribution or Third-Party Java. Oracle is not the only provider of Java. The Java platform is also available via open-source builds and other vendors. A popular strategy to avoid Oracle’s fees is to switch to an OpenJDK-based distribution for Java 17 (or upgrade to a newer version from a non-Oracle source). OpenJDK is the open-source reference implementation of Java, functionally very close to Oracle’s JDK. There are several free or more affordable Java distributions maintained by other organizations (for example, Eclipse Temurin by the Adoptium project, Amazon Corretto, Azul Zulu, IBM Semeru, Red Hat OpenJDK, etc.). These distributions provide Java 17 updates and patches (often aligned with the same updates Oracle makes, since they all derive from OpenJDK). By migrating your applications from Oracle’s JDK to one of these alternatives, you can continue receiving Java 17 updates without paying Oracle. Many enterprises have found this to be a viable way to contain costs, though it’s crucial to properly test your applications on the new JDK to ensure compatibility. The technical differences are minimal in most cases, but support and update timelines may vary by vendor.
• Option 4: Upgrade to Java 21 (Next LTS) Under NFTC. Another alternative is to move up to Java 21, which is the latest Long-Term Support version (released in 2023). Oracle has Java 21 under the NFTC license (free for all use) until at least September 2026. By upgrading from Java 17 to Java 21, you essentially reset the clock on free updates, gaining a couple more years of free support from Oracle. This can be an attractive option if your applications can be certified on Java 21 in the near term. However, it’s not a permanent solution: when Java 21’s NFTC period ends in 2026, Oracle will likely impose the same OTN/subscription requirement for Java 21 updates. In effect, this approach buys you time, but you will face a similar licensing decision down the road. It’s wise to combine this with a longer-term plan (such as migrating to OpenJDK or adopting a strategy to always upgrade to the latest LTS before the free period expires).
• Option 5: Consider Third-Party Support for Java. In some cases, organizations rely on third-party support providers for legacy software. Some vendors offer Java support services (including backporting security fixes to older versions) outside of Oracle. If switching JDK distributions or upgrading versions is not feasible in the short term, a company might contract a third party for Java 17 support. This can sometimes be cheaper than Oracle’s subscription and avoids dealing with Oracle directly, though it introduces a new vendor and possibly varying quality of support. Ensure any third-party Java support covers security patching and is reputable.

Each of these options has pros and cons. The best choice depends on factors such as your budget, the complexity of your Java applications, your risk tolerance for security, and your strategic direction (e.g., standardizing on open-source solutions).

Many enterprises are combining tactics – for example, staying on 17.0.12 temporarily while fast-tracking a migration to OpenJDK or Java 21 – to minimize costs without exposing themselves to undue risk.

Recommendations

In light of Oracle’s Java 17 licensing change, here are key recommendations for enterprise IT leaders and architects:

• Audit Your Java Usage: Identify all systems, applications, and servers running Oracle Java 17 immediately. Determine the current update version installed (are you on 17.0.12 or an earlier/later update?). A clear inventory will reveal where you are at risk and help prioritize actions.
• Avoid Accidental Non-Compliance: Disable any automatic updates or unwitting downloads of Oracle Java on production machines. Ensure your teams do not unknowingly install Java 17.0.13+ in production without a license – this could occur through routine patch management if not properly controlled. Communicate the new restrictions to all developers and IT staff.
• Evaluate Your Need for Oracle JDK: Decide if you truly require Oracle’s JDK and support, or if an open-source Java distribution could meet your needs. In many cases, switching to OpenJDK builds can be done with minimal disruption and will eliminate licensing costs, provided you have the internal expertise to manage updates.
• Consider Upgrading Sooner Rather Than Later: If your applications can run on Java 21, plan an upgrade timeline to move to Java 21 (or even Java 20/latest non-LTS) to take advantage of Oracle’s free period. Staying current with Java versions can be part of your strategy to keep benefiting from NFTC terms (understanding these free periods are temporary).
• Budget for Java if Sticking with Oracle: If you choose to remain on Oracle’s JDK for Java 17 or future versions, incorporate the Java SE subscription into your IT budget projections. Engage with Oracle sales early to discuss terms – there may be room for negotiation, especially if you’re a large customer or bundling Java with other Oracle renewals.
• Assess Security Risk of Staying Put: If you plan not to update Java 17 (avoiding subscription costs), conduct a risk assessment. How critical are the forthcoming Java security patches to your environment? If you have internet-facing or security-sensitive applications running on Java 17, not applying patches is dangerous. In such cases, the cost of a breach or downtime may far exceed the subscription fees, making a strong case for either paying Oracle or migrating to a source of patches.
• Explore Third-Party Java Support: For legacy systems that cannot be easily upgraded or modified, look into third-party support vendors that can provide updates or help maintain older Java versions. This is a niche solution, but it could serve as a bridge strategy in specific cases.
• Plan for Future Oracle Java Changes: Recognize that Oracle is likely to continue the NFTC-to-OTN pattern for future Java LTS releases (e.g., Java 21, Java 25, etc.). Establish a long-term strategy for Java management – whether that’s constantly upgrading to stay in the free window, allocating a recurring budget for Oracle subscriptions, or completely transitioning to non-Oracle Java platforms. Proactive planning will prevent last-minute scrambles when the next change hits.
• Stay Informed and Train Your Teams: Keep your software asset management and development teams informed about Oracle’s licensing policies and best practices. Provide training or guidance on Java usage compliance. Ensure that everyone, from procurement to DevOps, understands that Oracle JDK now carries licensing obligations after the free period. This will help avoid mistakes and prepare staff to make informed decisions about Java in projects.

Checklist: 5 Actions to Take on Java 17 Licensing

1. Inventory All Java Installations: Compile a list of every Oracle Java 17 instance in your environment (servers, VMs, desktops, applications). Note the version (update level) and how it’s being used (prod, dev, etc.). This will pinpoint where you face licensing requirements.
2. Lock Down Updates & Downloads: Immediately prevent automatic updates of Java 17 on production systems. Adjust patch management policies to prevent Java updates from being applied without review. This avoids accidentally crossing into OTN territory without a license.
3. Decide on a Licensing Strategy: For each Java 17 use case, choose a path – either plan to purchase Oracle Java subscriptions for it or migrate the system to an alternative Java distribution (or a newer Java version). Prioritize critical systems for decision-making.
4. Engage Stakeholders and Budget Owners: Inform your procurement, finance, and executive stakeholders about the licensing change and potential cost impact. If subscriptions are needed, get approval for the expenditure or initiate negotiations with Oracle. If opting for open-source Java, allocate resources for testing and migration.
5. Implement the Plan and Monitor Compliance: Execute the chosen strategy – whether it’s deploying OpenJDK replacements, upgrading to Java 21, or signing an Oracle agreement and updating to the latest Java 17 patch. Ensure that, in the future, governance is in place for Java usage, including tracking licenses, monitoring new Java installations, and regularly auditing compliance to avoid any surprises during an Oracle audit.

FAQ

Q1: Is Java 17 still free to use after Oracle’s 2024 licensing change?
A1: For enterprise production use, Java 17 is no longer free after the change. Oracle JDK 17 updates released from October 2024 onward require a paid license for commercial use. Java 17 remains free only for personal, development, and other non-commercial purposes. If you continue to run the older Java 17.0.12 or earlier in production, that specific version was obtained under the free NFTC license (so it’s technically free to use). Still, any new updates beyond that point are not free for business use. In essence, to stay current with Java 17 patches in a business, you must now pay Oracle or switch to a non-Oracle distribution.

Q2: What happens if we don’t update Java 17 past the free version?
A2: You can choose to stay on Java 17.0.12 (the last free NFTC release) without paying Oracle. Your existing installations won’t magically expire. However, you will stop receiving security updates and fixes, which over time can leave your applications vulnerable to exploits. This is a significant risk – critical vulnerabilities may emerge that you won’t patch unless you upgrade or subscribe to the latest version. Additionally, if you later decide to update to a newer Java 17 patch, you’ll need to address licensing at that time. Essentially, you’re deferring the cost (and accumulating security debt). If you never update, you avoid fees but must accept the security and support risks of running an outdated Java version indefinitely.

Q3: Does the licensing change affect non-production or internal development environments?
A3: For development and test environments, you can continue using Oracle Java 17 without cost as long as it’s strictly for development, QA, or personal experimentation. The OTN license explicitly permits these uses. The moment that code goes into a production deployment (or any use that is “for internal business operations”), you need a paid license if you’re using Oracle’s JDK. One caveat: even in non-production environments, be careful not to use Oracle Java in ways that serve third parties or commercial purposes (for example, embedding it in a product you distribute or using it in a service you provide to customers) without a valid license. Those scenarios might fall outside “development use” and could violate terms. In summary, the change primarily targets production usage – developers and testers can still work with Oracle JDK 17 freely. Still, they should avoid deploying Oracle JDK 17 updates to production without proper licensing.

Q4: What alternatives exist to avoid paying Oracle’s Java subscription fees?
A4: The main alternative is to use OpenJDK-based Java distributions from other sources. These are functionally equivalent to Oracle JDK for most purposes and are available under open-source licenses. Examples include Adoptium’s Temurin (the Eclipse Foundation’s build), Amazon Corretto, Azul Zulu, and others. By switching your Java runtime to one of these, you can get ongoing Java 17 updates and avoid Oracle’s fees. Another alternative is upgrading to Java 21, which Oracle still offers under the free NFTC license until 2026, providing you with a couple of years of breathing room (although after that, Java 21 will likely require payment as well). Some companies also consider third-party support providers who backport fixes, but most find moving to OpenJDK or a newer free version the more straightforward, cost-effective path. Always test compatibility when migrating to a different Java distribution or version. Still, since Java is standardized, most applications will run the same on OpenJDK builds as they do on Oracle JDK.

Q5: How can we prepare for Oracle audits and ensure compliance with Java licensing?
A5: Preparation is key. Maintain detailed records of where Oracle Java is installed and what versions are in use. If you have Oracle Java 17 in production, ensure that you either remain on an allowed free version or have documentation of your Oracle Java subscription that covers those installations. It’s wise to implement internal policies that no Oracle Java binaries be deployed to production without a licensing check. Consider using tools (or Oracle’s Java Management Service) to discover Java installations in your environment – shadow installations can be a compliance risk. If Oracle notifies you of an audit, you’ll need to provide evidence of licenses or prove you’ve only used Java in permitted ways. Working with a software asset management specialist or an Oracle licensing specialist can help you navigate audits effectively. Lastly, keep an eye on Oracle’s Java roadmap and future license announcements so you can proactively adapt rather than react under audit pressure.

Read how Oracle Java 6 is licensed.

Read about our Java Advisory Services.

Would you like to discuss our Java Advisory Services with us?

Please enable JavaScript in your browser to complete this form.

Name *

First

Last

Email *

Company

Message *

Submit