Oracle Java 17 Licensing
Oracle’s licensing for Java 17 has undergone significant changes that can have a major impact on enterprise IT budgets and compliance.
In recent years, Oracle has transitioned from offering free Java updates to a subscription model and, more recently, to a new per-employee licensing scheme.
This advisory explains the new Java 17 licensing rules, the associated costs, and how organizations can adapt to remain compliant while controlling costs.
Background: From Free Java to Subscription
For decades, Java was free for businesses to use under Sun Microsystems and early Oracle stewardship. This changed in 2019 when Oracle introduced new license terms that ended free commercial use of Oracle Java.
Oracle’s Java 8 and later updates fell under the Oracle Technology Network (OTN) license, which allowed free use only for development, testing, or personal purposes, not for production.
Commercial users now needed a paid Java SE subscription to stay compliant. This shift effectively ended the “free Java” era for enterprises, leading many organizations to either purchase Oracle Java licenses or migrate to open-source Java alternatives.
Oracle also ramped up compliance enforcement. Starting in 2019–2020, Oracle initiated audits and license reviews focused on Java usage.
Companies running Oracle’s Java in production without a subscription faced potential back-charges or the urgent need to buy licenses.
This aggressive stance on monetizing Java marked a new chapter in enterprise software management, making Java licensing a significant concern for CIOs and IT asset managers.
Oracle Java 17’s No-Fee License (NFTC)
With the release of Java 17 (LTS) in September 2021, Oracle introduced a No-Fee Terms and Conditions (NFTC) license. This move temporarily reinstated free use of Oracle JDK for Java 17 and later versions – including in production – but with important limitations.
Under NFTC, organizations could deploy Oracle Java 17 without paying license fees during an initial support period. Oracle provided Java 17 updates for free up until one year after the next Long-Term Support release (Java 21). In practice, this meant Java 17 was free for all users from 2021 until September 2024.
However, NFTC was a “free, but temporary” arrangement. After the free update period expired, any further Java 17 security patches or updates from Oracle required a paid subscription (or the business would need to upgrade to a newer Java version to stay in a free support window).
It’s crucial to note that NFTC does not include Oracle Support services or any right to redistribute Oracle’s Java binaries.
Oracle essentially treated Java 17 like an open-source release for a limited time, providing no-cost access to encourage uptake, but no long-term commitment. Companies that took advantage of the free Oracle Java 17 must now either upgrade to Java 21 (the current LTS, free under NFTC until its window closes) or purchase a Java SE subscription to continue receiving updates for Java 17.
In summary, Oracle JDK 17 was free to use for a while, but that freedom has an expiration date, after which normal licensing rules (and costs) kick in.
New Employee-Based Java SE Universal Subscription
In January 2023, Oracle overhauled its Java licensing model by introducing the Java SE Universal Subscription—a new plan that utilizes an employee-based metric.
This model replaced the legacy Java SE Subscription (which had been licensed per processor or named user). Now, instead of counting servers or specific named users, organizations must license Java for all their employees under a single subscription.
Oracle’s definition of “employee” is very broad, encompassing full-time and part-time staff, temporary workers, contractors, consultants, and anyone working for the company (or its affiliates) who benefits from the Java software.
In other words, if your organization uses Oracle Java in any capacity, you are expected to count every person in the organization for licensing purposes, regardless of whether a particular employee uses Java.
The Java SE Universal Subscription grants rights to use Oracle Java on an unlimited number of devices (desktops, servers, VMs, cloud instances) across the organization.
It consolidates what used to be separate licenses (for desktop Java and server Java) into one enterprise-wide license.
This simplification relieves the need to track individual installations or CPUs from a compliance standpoint – if you’ve licensed all employees, any amount of Java deployment is covered. Oracle also offers additional benefits for subscribers, including 24/7 support, security updates, and assistance with Java-related third-party libraries.
However, the cost structure of this model can be a shock for many. Under the old system, a company could choose to license only the specific servers or users that needed Java (for example, 100 users or a handful of servers).
The new model requires a license fee based on the total employee count, effectively serving as an “unlimited use” license but priced according to organizational size.
For companies with a large workforce and only a few Java applications, this approach often results in dramatically increased costs. (Oracle did allow some existing customers to renew their old metric subscriptions if contractually permitted, but in practice, it has been steering everyone toward the universal model.)
Enterprises now need to budget for Java as an organization-wide entitlement, making Java licensing a significant line item in IT costs if they continue to use Oracle’s JDK.
Pricing and Cost Impact for Java 17
A tiered per-employee pricing schedule is offered for Oracle’s Java SE Universal Subscription. The list price starts at $15 per employee per month for smaller organizations and decreases for larger employee counts.
Below is a breakdown of Oracle’s standard pricing tiers:
| Number of Employees | Cost per Employee / Month (USD) |
|---|---|
| 1 – 999 | $15.00 |
| 1,000 – 2,999 | $12.00 |
| 3,000 – 9,999 | $10.50 |
| 10,000 – 19,999 | $8.25 |
| 20,000 – 29,999 | $6.75 |
| 30,000 – 39,999 | $5.70 |
| 40,000 – 49,999 | $5.25 |
| 50,000+ | Contact Oracle (negotiable) |
This pricing is per month (multiply by 12 for annual costs). Even with volume discounts at large scales, the expenses are substantial. For example, a company of 2,500 employees would fall into the $12 tier, equating to $30,000 per month (roughly $360,000 per year) in Java subscription fees.
A larger enterprise with 10,000 employees would pay about $990,000 per year at list pricing. These figures illustrate how Java, once a free utility, has become a significant budget item under Oracle’s licensing.
Many organizations will experience higher costs than before. Industry analysts estimate the new employee-based model can result in spending 2× to 5× more on Java licensing compared to the previous per-user or per-processor model (depending on how concentrated or widespread the company’s Java usage is).
Essentially, Oracle’s one-size-fits-all licensing means even if only 10% of your staff uses Java, you’re paying as if everyone does. This “Java tax” on every employee has led some IT leaders to re-evaluate their Java strategy to manage costs.
On a positive note, the universal subscription simplifies compliance management — once you’re licensed enterprise-wide, you don’t have to track every install.
But that simplicity comes at a steep price, so it’s critical to assess the impact on your IT budget. Oracle does offer custom negotiations for very large organizations (those with over 50,000 employees or as part of broader Oracle deals), so there may be room to secure better rates or terms in specific cases. Nonetheless, every enterprise using Oracle Java 17 or later should treat licensing as a significant financial consideration going forward.
Compliance Risks and Audit Concerns
Non-compliance with Oracle’s Java licensing can pose significant risks to enterprises. Oracle has made it clear through audits and communications that it expects organizations to pay for Java if they use Oracle’s distributions beyond the allowed free use cases.
Here are the key risk factors and concerns:
- Audit Exposure: Oracle’s License Management Services have been actively auditing companies for Java usage. Suppose an audit finds that you’re running Oracle Java (for example, Java 8 after public updates ended, or Java 17 after its free period) without a subscription. In that case, Oracle will likely require you to purchase subscriptions retroactively. This could result in an unexpected true-up bill running into hundreds of thousands of dollars (or more), depending on the duration and extent of your unlicensed use. In worst cases, Oracle can charge back-support fees for the period of unlicensed use, creating a significant financial penalty.
- End of Free Updates: Java 17’s free update window under NFTC is now closed (as of late 2024). Continuing to run Oracle JDK 17 in production without either upgrading or buying a subscription means you will no longer receive security patches. Not only is this a compliance issue, it’s a security risk – known vulnerabilities will remain unpatched unless you have access to Oracle’s updates. Running mission-critical applications on an outdated Java version to avoid licensing fees is a risky strategy that can lead to security breaches or stability issues. Oracle’s licensing terms essentially force a choice: keep upgrading to the latest Java version (to stay in a free support cycle) or pay for a subscription to get patches on older versions.
- Legacy Contracts Ending: Oracle has been phasing out its legacy Java licensing agreements. If you previously had a Java SE subscription under the old metrics, you might not be allowed to renew it on the same terms. Oracle’s sales teams are informing customers that to continue receiving updates, they must transition to the employee-based model at renewal. This means that even organizations that have carefully limited their Java license scope in the past are being transitioned to the all-encompassing subscription. Ignoring the issue isn’t a long-term option – Oracle is effectively making the legacy deals disappear.
- Unbudgeted Costs: Without proactive management, Java licensing can become an unplanned expense. Many firms have discovered Java installations in their environment (on servers, build systems, appliances, etc.) that were forgotten or assumed to be free. An audit or license review can turn these into immediate costs. Additionally, Oracle’s habit of sending out notices or “free compliance reviews” for Java means you might be approached even if you aren’t formally audited. The safest course is to assume Oracle is monitoring enterprise Java usage closely in this period.
In summary, running Oracle Java in production “under the radar” is high risk. The combination of Oracle’s tightened policies and active enforcement means enterprises should treat Java like any other licensed software, with proper entitlements in place.
Beyond financial penalties, being caught off guard can also lead to rushed remediation projects (such as emergency migrations to alternative Java platforms or sudden budget requests to cover license fees).
It’s far better to get ahead of this issue than to react after Oracle comes knocking.
Managing Oracle Java Licensing in the Enterprise
Faced with these changes, enterprise IT leaders should take a strategic approach to manage Java 17 (and future Java) usage.
Below are key strategies to navigate Oracle Java licensing effectively:
- Inventory All Java Usage: Start by discovering where Oracle’s Java is used in your organization. This includes obvious places, such as application servers and client applications, as well as developer workstations, build pipelines, and test environments, and is often bundled within third-party software. A thorough inventory will reveal your true exposure. In large organizations, it’s wise to use software asset management tools to track Java installations. Knowing the scope of use is essential for deciding how to proceed (and it’s information Oracle will ask for during any audit or negotiation).
- Evaluate Your Needs (Subscription vs. Alternative): Determine if you truly need Oracle’s Java binaries and support. Some organizations have mission-critical systems that rely on Oracle’s long-term support and rigorous testing – these might justify the subscription cost. However, many others can run their Java applications on OpenJDK or other free or lower-cost Java distributions. Oracle’s own OpenJDK builds are functionally equivalent to Oracle JDK for a given version, except for the lack of support and a longer update timeline. If you have the in-house capability to keep Java updated (or use third-party support vendors), moving away from Oracle’s paid model could save considerable money. This evaluation should weigh the cost of subscriptions against the effort required to manage Java updates yourself or through alternative providers.
- Consider Upgrading Regularly: Oracle’s NFTC license essentially rewards those who stay on the latest version of Java. Suppose your development processes can handle frequent Java upgrades (LTS releases typically occur every two years). In that case, you might consider adopting a policy of always moving to the newest LTS within a year of its release. By doing so, you remain within Oracle’s free usage window and avoid subscription costs. This approach isn’t feasible for every organization – some have applications that require stability on a given Java version for many years – but it’s a valid strategy for others. It requires proactive planning: ensure your applications are tested and compatible with the new Java versions, and maintain a regular upgrade cycle (e.g., plan migration from Java 17 to 21, then to Java 25, and so on).
- Negotiate Smartly with Oracle: If you determine that Oracle’s Java subscription is necessary, approach the deal with a negotiation mindset. Oracle’s list prices can often be negotiated down, especially if you’re a large customer or bundling Java with other Oracle agreements. Some negotiation tips include: seek multi-year commitments for better discounts (e.g., a three-year deal might reduce the per-employee rate), right-size the employee count if possible (for example, very small businesses have sometimes negotiated to exclude a portion of employees who demonstrably never use a computer or Java – though Oracle’s official stance is all employees, there may be case-by-case flexibility), and leverage competition. Oracle knows that if you don’t buy their Java subscription, you have other options (open-source or third-party supported Java). Make it clear that you have evaluated those options – this puts pressure on Oracle to make a more attractive offer rather than lose the account. It’s also wise to review any Oracle contracts you have for clauses that might include Java usage or any guarantees you can use in negotiations.
- Leverage Existing Entitlements: Check if you are already entitled to Java usage through other products. Oracle has historically bundled Java SE rights within certain products – for example, some Oracle middleware and enterprise applications include a restricted-use Java license for running that product. If you use Oracle WebLogic Server, Oracle E-Business Suite, or other Oracle software, verify the license documentation for these products. You may find that the Java runtime for those specific applications is covered under that product’s license (meaning you wouldn’t need a separate Java SE subscription for that usage). Note: these entitlements typically **only cover Java use within the scope of the particular product (e.g., running WebLogic). They wouldn’t allow general-purpose Java use outside that context. Still, understanding this can prevent you from double-paying. Always document and confirm with Oracle your existing rights.
- Implement Java Governance: Treat Oracle Java as any other licensed asset – establish governance. This means establishing internal policies that, for instance, prohibit the installation of Oracle JDK on new systems without prior approval. You might standardize on using OpenJDK (or another free distribution) for all non-production environments, or even for production if support is not an issue. If developers need Oracle JDK for some reason, funnel those requests through a managed process. Also, maintain records of all Oracle Java downloads and usage; if Oracle inquires, you want to be able to show a controlled process. Proactively uninstall or replace Oracle JDK in areas where it isn’t strictly needed. The goal is to minimize your reliance on Oracle’s Java to only what you intend to license and support.
By taking these steps, enterprises can regain control of the situation. Oracle Java 17 and beyond can be managed cost-effectively, but it requires awareness and proactive planning.
Whether you decide to pay Oracle for subscriptions, shift to an open-source strategy, or a mix of both, the key is to have a deliberate plan rather than reacting under duress. This will ensure you remain compliant, secure, and within budget.
Recommendations
- Audit Your Java Footprint: Perform a comprehensive audit of all Oracle Java installations in your environment. Knowing where and how Java is used (and which versions) is the first step to managing it effectively.
- Assess License Requirements: Determine if you need Oracle’s Java SE subscription. If your applications can run on OpenJDK or another vendor’s Java without impacting operations, consider that route to avoid fees.
- Plan for Java Upgrades: If you choose to stick with Oracle JDK under NFTC, create a roadmap to upgrade to new Java LTS versions promptly. Don’t get caught running an older Java (like 17) without updates – plan the move to Java 21 or later proactively.
- Engage Oracle Early: If you anticipate needing a Java SE Universal Subscription, engage Oracle (or an Oracle licensing expert) to discuss your options. Early engagement can sometimes yield better pricing or clarify if any legacy terms can still apply.
- Negotiate the Subscription: Treat the Java subscription like any major software deal – negotiate volume discounts, multi-year terms, and clarify the definition of “employees” in your context. Push for exclusions if, for example, a portion of your workforce truly never uses any IT systems.
- Leverage Alternative Options: Use the existence of third-party Java support or alternative distributions as leverage in negotiations. Oracle may be more willing to offer concessions if they know you have a viable plan to switch away rather than pay an exorbitant fee.
- Include Security in Decisions: Weigh the security implications of any strategy. If you forego Oracle support, ensure you have another source for security patches (community or vendor). If you stay with Oracle, budget and schedule those patches as part of regular maintenance.
- Train and Inform Teams: Educate your development, operations, and procurement teams about the changes to Java licensing. Ensure everyone knows that using Oracle JDK has licensing consequences – this helps avoid unintentional non-compliance (like a developer downloading Oracle Java out of habit).
- Monitor Oracle’s Policy Updates: Keep an eye on Oracle’s announcements regarding Java. Licensing terms and support roadmaps can evolve (for example, new LTS release schedules or changes to NFTC terms). Staying informed will help you adjust your strategy in advance.
Checklist: 5 Actions to Take
- Inventory Your Java Installations: Create a checklist of all servers, applications, and endpoints running Oracle Java. Document the version and usage (e.g., production, test) for each to understand your exposure.
- Classify and Prioritize: Mark which Java installations are business-critical and require Oracle’s support/updates versus those that could be migrated to an open-source JDK without impact. Prioritize compliance for critical systems first.
- Upgrade or Subscribe Decision: For each Java deployment, decide whether to upgrade to the latest version (to stay within a free support window) or subscribe for support on the current version. For example, if an application can’t easily move off Java 17, you may opt to purchase a subscription for it.
- Engage Stakeholders: Pull in procurement, security, and application owners to review the plan. If a subscription purchase is required, obtain budget approval and initiate Oracle discussions. If migrating to OpenJDK, ensure testing and validation in those environments.
- Implement Controls: Establish policies to prevent unapproved Oracle Java usage. For instance, mandate that new projects use approved Java distributions and require a business justification (and license check) before deploying the Oracle JDK anywhere in the company.
FAQ
Q: Is Oracle Java 17 free to use or not?
A: Oracle Java 17 was initially free under Oracle’s no-fee license, but that was temporary. As of late 2024, Oracle no longer provides free updates for Java 17. If you continue to use Oracle JDK 17 in production now, you will need a paid subscription (or you should upgrade to Java 21, which Oracle currently offers for free under its free terms until the free period ends).
Q: What does “per employee” licensing include – who counts as an employee?
A: Oracle’s per-employee licensing counts all workers in your organization. This includes full-time employees, part-time staff, contractors, and even external consultants or agents who work on your internal operations. Essentially, if they’re on your payroll or doing work for your company, Oracle expects them to be counted. There is no distinction based on who uses Java – it’s an enterprise-wide count.
Q: We still run Java 8/11 in production; do we need to pay for those older versions?
A: Yes, if you use Oracle’s Java 8 or Java 11 in production and want updates/support, you need a subscription. Oracle’s free public updates for Java 8 ended in 2019 (and for Java 11 in 2022). Under Oracle’s licenses, older Java versions used commercially require a paid Java SE Subscription. The alternative is to switch to an open-source Java build (e.g., OpenJDK from another provider) for those applications, which many companies have done to avoid fees on Java 8/11.
Q: Can we renew our old Java SE licenses instead of switching to the new employee-based model?
A: In general, Oracle has discontinued selling the old Named User Plus or Processor-based Java SE licenses to new customers. For existing customers, Oracle allowed legacy subscription renewals only if the contract included this provision and the usage hadn’t exceeded the licensed amount. In practice, Oracle is strongly encouraging (and in some cases requiring) customers to move to the new model at renewal. It’s worth discussing with Oracle – if you have a prior agreement, ask if an exception is possible – but be prepared to ultimately adopt the employee-based subscription.
Q: How can we reduce the cost of Oracle Java licensing?
A: To reduce costs, first consider whether you need Oracle’s distribution at all. Many enterprises are migrating to OpenJDK or other Java distributions, which have no licensing fee (some use third-party support for those to get patches and assistance at a lower cost than Oracle). If you do need Oracle Java, try to minimize the scope – use Oracle JDK only where absolutely necessary, and use free alternatives elsewhere. Negotiating with Oracle is also key: leverage any available volume discounts and make it clear that you have alternatives. Finally, keeping your Java version updated (so you can utilize Oracle’s free LTS periods) can save money; for example, plan an upgrade to each new LTS release within its first year to avoid paying for extended support.
Read about our Java Advisory Services.
