Overview Oracle Java Licensing Changes

Oracle Java Licensing Changes

• Employee-Based Licensing: Covers all employees if Java is used.
• Old Licenses Replaced: Named User Plus and Processor licenses removed.
• 2023 Changes: New pricing based on total employee count.
• Audit Risks: Oracle audits for non-compliance can lead to penalties.

Oracle Java Licensing Changes

Oracle has significantly changed its Java licensing model over the past few years. These changes – notably in 2019, 2021, 2023, and 2024 – have affected how businesses can use Java and what costs they incur​.

This report will break down each major change, explain how Java licensing works, and discuss what these changes mean for organizations.

We’ll also cover common questions (like whether Java is still free), outline licensing options, and provide expert insights and practical advice for decision-makers.

Did Oracle change the Java license?

Yes – Oracle has significantly changed its Java licensing model multiple times. In the past, Oracle’s Java was freely usable with few restrictions, but this evolved. Major shifts occurred in 2019, 2021, 2023, and 2024, each impacting usage rights, costs, and compliance requirements​.

For example, Oracle ended free public updates for Java SE 8 in 2019, introduced a new no-cost license for Java 17 in 2021, switched to a per-employee subscription model in 2023, and in 2024 began charging for Java 17 security updates​.

These changes mean that organizations must stay informed and possibly adjust how they obtain and use Java to remain compliant and cost-effective.

2019 Java Licensing Changes

2019 Oracle changed how Java SE (Standard Edition) is licensed and supported. The free updates businesses enjoyed for Java 8 ended unless they paid for a subscription​.

Key changes included:

• Java SE Subscription Required for Updates – With Java SE 8 Update 211 (released in April 2019), Oracle required a paid Java SE Subscription to receive further updates or security patches​. This effectively ended free patch support for commercial users of Java 8.
• New OTN License Introduced – Oracle replaced the old Binary Code License with a new Oracle Technology Network (OTN) License for Java SE. Under the OTN agreement, using Oracle’s Java for commercial purposes without a subscription became prohibited​. The OTN license allowed personal use, development, and testing at no cost, but production use now demanded a paid license.
• Timeline and Impact – Although announced in 2019, these changes took full effect by April 2020​. Businesses had only a short window to respond. Many companies suddenly faced a choice: purchase Java SE subscriptions to stay compliant or migrate to alternative Java distributions (like OpenJDK) to avoid new licensing costs​. This 2019 shift began Oracle’s more restrictive and revenue-focused approach to Java licensing, surprising many organizations.

The 2019 change had significant real-world implications. Organizations with Java 8 running in production could no longer legally apply critical updates from Oracle without paying. Some firms budgeted for the new subscriptions, while others looked to open-source Java alternatives to keep their Java applications secure without incurring fees.

Oracle’s enforcement also increased. Before 2019, many companies used Oracle Java without proper licenses, but Oracle signaled it would be less lenient​after the change. In short, 2019 was the year Java stopped being “free” for commercial use of older versions, introducing a paid subscription model.

2021 Java Licensing Changes

In 2021, Oracle adjusted its Java licensing approach again, allowing businesses to use newer Java versions without charge – albeit with conditions.

The most important development was the introduction of the Oracle No-Fee Terms and Conditions (NFTC) license alongside Java 17:

• No-Fee Terms and Conditions (NFTC) for Java 17 – With Java SE 17 (released September 2021), Oracle made its Oracle JDK builds available under a No-Fee Terms and Conditions license. This meant Java 17 and later could be used free of charge, even in production, for all users​. It was a major shift designed to encourage the adoption of the latest Java. Under NFTC, businesses could deploy Java 17 without purchasing a subscription, starkly contrasting to Java 8 and 11, which required paid support for updates.
• Older Versions Remained Commercial—It’s important to note that the NFTC did not apply retroactively to older Java versions. Java 8 and Java 11 (and anything earlier) still fell under the previous agreements (like OTN or the old licenses), meaning no new free-use rights were granted to those versions​. Companies sticking with Java 8 or 11 continued to need a paid subscription for updates or risk running those systems without security patches.
• Security Patch Deadline – Oracle’s NFTC license for Java 17 came with a built-in time limit on free updates. Oracle committed to providing Java 17 updates under NFTC until September 2024, one year after the next LTS (long-term support) release​. After that date, any new Java 17 security patches would require a paid license (via the Java SE Subscription) to install​. In essence, Java 17 was free for a three-year window. If a company didn’t upgrade beyond Java 17 by late 2024, it would have to start paying to keep Java 17 secure.

The impact of the 2021 changes was twofold. On the one hand, organizations willing to stay on the latest Java LTS (17 at the time) were rewarded with significant cost savings – they could run Java 17 in production without any Oracle license fees​.

On the other hand, companies that needed to remain on Java 8 or 11 were unchanged in their obligations for compatibility or stability reasons and still faced license requirements for updates.

This dynamic pushed some businesses to accelerate Java upgrades to newer versions to take advantage of free use. Others, unable to easily upgrade legacy systems, had to budget for ongoing Java SE subscriptions to remain compliant and secure.

Oracle’s message was clear: stay up-to-date with Java, and you won’t pay license fees (at least for a while), but clinging to older versions will cost you.

2023 Java Licensing Changes

January 2023 brought one of the most significant (and costly) licensing changes: Oracle completely overhauled its Java SE subscription pricing model.

Instead of counting processors or named users as in the past, Oracle moved to an employee-based subscription model called the Java SE Universal Subscription​.

This had major implications for cost and compliance:

• Employee-Based Subscription Model—Oracle eliminated the old “Named User Plus” and “Processor” license metrics for Java and introduced the “Employee for Java SE Universal Subscription” metric​. A company’s Java SE subscription cost is based on its total number of employees, not on how many people use Java or how many servers run Java. Even if only 50 out of 5,000 employees actively use Java, all 5,000 count toward the license.
• All Employees Counted – The definition of “employee” is broad. It includes full-time and part-time staff, temporary workers, contractors, agents, and outsourcers who support internal operations​. Oracle counts everyone in the organization (at least everyone on payroll or equivalent) as needing to be licensed for Java, regardless of actual Java usage. The employee count is determined when ordering the subscription and isn’t reduced if not all employees use Java​.
• Legacy Licenses Phased Out – With this change, Oracle stopped selling the legacy Java SE Desktop and Processor subscriptions to new customers as of January 23, 2023​. Existing Java subscription customers were technically allowed to renew under the old model “to the extent permitted” in their contract, but only if their usage hadn’t grown​. In practice, Oracle is pushing everyone toward the new model​. The usage terms of Java itself (what you can do with it) didn’t fundamentally change in 2023 – it was primarily a pricing restructure​. However, this pricing change had major cost implications for many.

Impact on businesses: The move to an employee-based license model led to significant cost increases for many organizations, especially large enterprises. If a company previously paid for 100 Java users or a handful of server processors, they might have to license thousands of employees under the new scheme.

Gartner analysts estimated the new model would be “two to five times more expensive” for most companies than the old licensing​. For example, one hypothetical large organization with ~50k employees would have seen costs jump 90% (from ~$1.64M under the old model to ~$3.12M under the new model)​.

Budgeting became challenging – suddenly, even minimal Java usage could incur a hefty fee because it scales with headcount. Compliance management also changed: companies can no longer just count specific Java installations; they must accurately track total employees.

Under this model, there is no way to limit Java license costs by reducing usage—short of reducing employees​. This 2023 Java licensing change forced many businesses to rethink their Java strategy. Some accepted the higher cost of Oracle’s support; others started seriously evaluating third-party Java distributions or support providers to cut ties with Oracle’s licensing.

2024 Java Licensing Changes

In 2024, Oracle imposed new restrictions affecting Java 17 users, signaling the end of the “free ride” for those who adopted Java 17 under the no-fee license.

The crux of the 2024 Oracle java licensing change is about security updates for Java 17 (and later) in the future:

• End of Free Updates for Java 17 – Oracle announced that any Java 17 security patch released after September 2024 would require a paid subscription ​. Until that cutoff, Java 17 users could download and apply updates at no cost under the NFTC terms. After the cutoff, however, organizations must have an active Java SE subscription to get critical fixes​. In other words, Java 17 remains free, but keeping it secure beyond late 2024 is no longer free.
• Choice for Businesses: Pay or Don’t Patch – Companies running Java 17 now face a dilemma​. They have two main options:
  1. Stay on Java 17 without updates (Free): Continue using Java 17 for free, but forego any security patches released after September 2024. This saves money but could expose the organization to security vulnerabilities over time.
  2. Subscribe for Updates (Paid)—Purchase an Oracle Java SE subscription to download and apply new Java 17 patches and updates. This ensures security and compliance but comes with an ongoing cost​.
• Push to Newer Versions – The 2024 policy effectively nudges organizations to upgrade to newer Java versions (like Java 21) to stay on a free-supported path​. Oracle’s model is to offer the latest LTS release under NFTC (Java 21 is free until at least Sept 2026), so when Java 17’s free period ended, Java 21 arrived as the new free option. Companies unwilling to pay for Java 17 updates can migrate to Java 21 to receive free updates for a few more years​. The cycle will likely repeat for Java 21 when Java 25 comes out in 2025.

For businesses, the 2024 change served as a wake-up call. It marked the end of fully free use of Java 17 and reinforced Oracle’s strategy: if you want to stick with an older LTS release beyond a certain point, you must pay​.

Organizations that had upgraded to Java 17, thinking they would avoid Java fees indefinitely, discovered they eventually had to either accept new costs or plan frequent upgrades. Companies prioritizing security now have to budget for Java subscriptions or ensure they upgrade to Java 21 (and, later, Java 25) promptly.

Those who choose not to pay face increasing security and compliance risks over time​. In summary, 2024’s changes closed the free-updates window for Java 17 and cemented Oracle’s “free for a while, then pay or upgrade” approach to Java licensing.

How does Java Licensing Work?

Java licensing can be complex, but it essentially boils down to which version and distribution of Java you use and for what purpose.

Here’s a high-level overview of how Java licensing works, especially in the Oracle context:

Oracle’s Dual Offerings (OpenJDK vs. Oracle JDK): Oracle provides Java in two forms: Oracle OpenJDK and Oracle JDK. Oracle OpenJDK is an open-source reference implementation available under the GNU General Public License (GPL) with Classpath Exception, free for anyone.

Oracle JDK is Oracle’s commercially branded binary of Java. Historically, it was offered under a proprietary license and was free for general use, but with certain restrictions and optional support contracts.

After 2019, Oracle JDK for newer versions became governed by the OTN or NFTC licenses (described below), which impose conditions on commercial use.

The important point is that using open-source Java (like OpenJDK from Oracle or other providers) is free, while using Oracle’s JDK in production may require agreeing to Oracle’s license terms or paying for a subscription, depending on the version.

License Agreements and Versions: Oracle’s Java licensing framework is anchored by a few key license agreements, which apply to different versions of Java:

• Binary Code License (BCL) – Applied to Oracle Java versions released before April 16, 2019 (Java 8 and earlier)​. The BCL allowed free use of Java for general-purpose computing (so running typical applications was free) but restricted embedding Java in devices or specialized uses​. Oracle no longer uses the BCL for new Java releases​.
• Oracle Technology Network (OTN) License – Introduced in 2019 for Java SE 8 updates (post-8u202) and used for Java 11 (and later for certain releases)​. The OTN license permits no-cost use only for personal, development, and testing purposes. Any commercial or production use under OTN requires a paid subscription​. If you’re running Java 8u211+ or Java 11 in production, you fall under OTN and need Oracle Java subscriptions (unless you never update, which is risky).
• No-Fee Terms and Conditions (NFTC) – Introduced in 2021 with Java 17​. The NFTC allows free use of Oracle JDK for all purposes, including commercial – but only for specific versions and timeframes. Oracle JDK 17 and later are offered under NFTC for their initial support period​. The catch is that after a certain date (e.g., after Sept 2024 for Java 17, after Sept 2026 for Java 21), Oracle stops offering free updates and reverts to the OTN (paid) model for that version​. So, NFTC is essentially a free-use license with an expiration date for updates.

How Java licensing works for you depends on your production version. If you use an older Java (Java 8 or 11) and need updates, you must purchase a subscription or be out of compliance​. If you use Java 17 or 21 within their NFTC window, you can run them free for now. If you exclusively use non-Oracle distributions of Java (such as Amazon Corretto, Eclipse Temurin, etc.), Oracle’s licensing doesn’t apply – those are typically free under open-source terms.

Java SE Subscription (commercial support): Oracle’s main licensing product is the Java SE Subscription, which provides the right to use Oracle JDK in production and access to patches/support. As of 2023, this is sold per employee (earlier, it was per user or processor).

Purchasing a subscription essentially grants a company a license to use Oracle Java commercially and receive updates from Oracle continuously​. Without a subscription (or other contractual license like an enterprise agreement), a company cannot use Oracle’s Java updates in production once the free terms (if any) expire.

To sum up, Java licensing is a mix of open-source availability and commercial terms. The Java platform is free and open-source, but Oracle’s branded builds and support are commercial. Many organizations mix these: using free OpenJDK builds where possible and only paying Oracle if they need Oracle-specific features or prolonged support for a version.

Decision-makers must determine which Java deployments require an Oracle license (to stay secure and compliant) and which can be switched to free alternatives. The following sections will explore whether you need an Oracle Java license, which versions require one, and how the costs break down.

Do you need an Oracle Java License?

Do you need to pay Oracle for Java? The answer depends on how you use it. Many uses of Java remain free, but certain scenarios require a license (subscription).

Here are the key considerations:

• Using Oracle’s Java in Production: If your organization uses the Oracle-branded JDK (Oracle’s download) for Java 8 or Java 11 in a production or commercial environment, you need a license for any updates beyond the free public versions. Oracle’s Java 8 after update 202 and Java 11 are covered by the OTN license, which prohibits commercial use without a subscription​. In practical terms, if you’ve installed Oracle JDK 8 and applied patches released after January 2019 or run Oracle JDK 11 in production, you should have an active Java SE subscription from Oracle.
• Java 17 and newer: Oracle JDK 17 and later can be used in production for free under the NFTC license as long as you are within the supported update period (for Java 17, this was until Sept 2024)​. During that period, you do not need to pay Oracle. However, applying new security updates requires a subscription once the free period ends. So, if you plan to stick with Java 17 beyond its free-update window (or similarly with future versions), you will eventually need a license.
• Open-Source Java implementations: If you use a non-Oracle Java distribution, such as OpenJDK builds from Eclipse Temurin, Red Hat, Amazon Corretto, Azul, etc., then no Oracle license is required. Those are free under open-source licenses. Many organizations have transitioned to these to avoid Oracle fees.
• Development and Personal Use: Oracle’s licensing allows developers to use Oracle JDK at no cost for development or testing, and individuals can use it for personal use (e.g., running Java applications on a home PC) without a paid license​. The license requirement kicks in when software is deployed for internal business operations or commercial purposes.
• Bundled Java with other Software: If you obtained Java as part of another software product that you licensed (for example, an Oracle product that includes Java; see a later section), you might already have a right to use that Java for that specific application without a separate Java SE subscription.

In summary, you need an Oracle Java license (subscription) if you are running Oracle’s Java in production and the version/usage isn’t covered by Oracle’s free-use policies. Many companies realized they fell into this category when Oracle changed the rules in 2019.

For instance, having Java 8 on employee laptops for business applications after 2019 technically required a subscription if those Java installations were updated past the public free version. On the other hand, if you have entirely switched to open-source Java or upgraded promptly to the latest LTS releases (staying within the NFTC free window), you might not need to purchase an Oracle license.

It’s crucial to evaluate each Java deployment in your organization – what version it is and how it was obtained – to determine if it triggers a licensing requirement​. Neglecting this could mean either unnecessary spending or a compliance gap.

Is Java still free?

This question causes a lot of confusion. The answer is yes, Java (the technology) is free – but Oracle’s specific distribution and support for Java may not be free.

Let’s clarify:

• The Java language and OpenJDK: Java as a programming language and the reference implementation (OpenJDK) are open source and free. Anyone can download and use OpenJDK at no cost. In fact, since Java 9, Oracle has released OpenJDK builds under a GPL license for each Java version​. So, in the broader sense, Java is free and open-source. Multiple free Java runtime providers exist; you do not have to pay royalties to use Java in your applications.
• Oracle’s JDK binaries: What changed is that Oracle’s official JDK binaries are no longer universally free for commercial use as they were many years ago. Up to Java 8 (202 updates), Oracle JDK was free to use under the old license for general computing. After the license changes, Oracle JDK 8 and 11 require a subscription for commercial use (with only dev/test or personal use free)​. Oracle JDK 17 and newer are free for a period under NFTC, but not perpetually (security updates eventually cost money)​.
• Free for current versions: In a sense, Oracle did “make Java free again” for the latest versions. Oracle JDK 17, 18, 19, 20, 21… all current releases are available under the NFTC license, which permits free use in production​. As of today, you can use Java 21 (latest LTS) or Java 20/22 (latest non-LTS) without paying Oracle. However, this free usage is conditional – it lasts until those versions fall out of Oracle’s free update window. So Java is free now, but it may not remain free forever unless you keep upgrading or switching to an open-source build.
• What about older versions? Older Java versions (Java 8, 11) are not free for businesses if you need updates. Oracle continues to offer Java 8 for free for individual users (and developers) indefinitely​, but organizations cannot use Oracle’s Java 8 updates in production without a license. So if “Java” in your context means an older installed runtime, then no – that Java isn’t as free as it once was unless you’re okay with no updates (which is risky).

In summary, Java is free to download, learn, and even use in production—via OpenJDK or Oracle’s no-fee licensed versions—but it’s not guaranteed free forever for all use cases. Oracle’s strategy is to provide a free option for the latest release and push users to keep up or pay for support on older releases​.

Businesses that want stability (staying on one Java version long-term) will likely have to pay at some point. Businesses that are agile or use community-supported JDKs can effectively use Java without ever paying Oracle.

So, Java is still free for those who manage it proactively, but one must be careful to stay within the bounds of what’s free and what’s not.

Is Oracle Java 17 Free?

Oracle Java 17 was made free to use – with some caveats. When Java 17 was released, Oracle announced it under the NFTC (No-Fee Terms and Conditions) license, meaning all users (including companies) could use Oracle JDK 17 at no cost, even in production​.

However, this free usage comes with an important time limitation:

• Free use until September 2024: Oracle committed to providing Java 17 updates for free for about three years. Specifically, Oracle JDK 17 updates through September 2024 were released under the NFTC license and did not require payment​. During this time, Java 17 was effectively free and supported—you could download and use the latest security patches without an Oracle contract.
• Post-2024 updates require a subscription: After that free period, Oracle transitioned Java 17 updates to the OTN license (the same restrictive license used for Java 8 and 11)​. In practical terms, any Java 17 update released after Sept 2024 is not free for commercial use. A company must purchase a Java SE Subscription (the paid support)​to apply those later updates. For example, Java 17 update 17.0.8 (released in July 2023) was free, but a hypothetical update 17.0.13, released in late 2024, would fall outside the NFTC window and thus require a license.
• Using Java 17 without updates: It’s worth noting that Oracle doesn’t revoke the right to use Java 17 itself after 2024 – Java 17 core is still “free” to use under NFTC. The restriction is on updates/patches. If an organization chose to keep running the last free version of Java 17 indefinitely without applying new fixes, they wouldn’t have to pay Oracle (though this would mean missing future security fixes)​.

So, to answer the question directly, Yes, Oracle Java 17 is free to download and use in both development and production through the end of its NFTC period. Oracle JDK 17 (up to update 17.0.12) can be used without any license fee​. However, that “free” status ended for ongoing maintenance after September 2024.

Organizations that want to keep Java 17 systems patched after that point must transition to a paid subscription or migrate to a newer Java version (like Java 21), which Oracle currently offers for free under NFTC​.

For many companies, the approach was to adopt Java 17 when it came out (free use) and plan an upgrade to Java 21 (the next free LTS) by late 2024 rather than start paying for Java 17 support.

This way, they can continue leveraging Oracle’s free license strategy. Others who cannot upgrade so quickly face either the decision to purchase a Java 17 subscription or risk running an outdated Java 17. But in summary, Oracle Java 17 was free and remains free to use – only its updates beyond a certain date are behind a paywall.

The Oracle Java Licensing Agreements to Review

When reviewing your Oracle Java licensing, it’s crucial to understand the three main Oracle Java license agreements and which apply to your situation​.

Each agreement has different terms and implications:

• Oracle Binary Code License Agreement (BCL): This was the traditional license for Java SE used for older versions (generally Java 8 and earlier)​. Under the BCL, Java was free for “General Purpose” computing. That means you could use Java runtime on PCs, servers, etc., without paying, as long as it was for general application use. However, the BCL forbade certain uses – notably, embedding Java in an integrated hardware/software product for resale (embedded use) or using certain advanced features required separate licensing​. For most standard business applications, Java under BCL was free. Oracle stopped using the BCL for new Java versions after 2019​, so it’s mainly relevant if you run older Java versions. Example: If you have a legacy system using Java 6 or 7, the BCL applies – you likely don’t owe Oracle anything for running it (since public updates are no longer available anyway), unless you were using Java in an embedded device.
• Oracle Technology Network License (OTN) for Java SE: This license came into effect starting with Java SE 8 updates after 8u202 and for Java 11 (and later in certain cases)​. The OTN license is much more restrictive: it permits using Oracle Java only for personal use, development, testing, and demonstration. Any production or commercial use requires a subscription. In other words, OTN is a free license only for non-production scenarios; when you use the software to run business operations, you’re supposed to have a paid license. This license covers Oracle JDK 8 (updates 211 and above), Oracle JDK 11, and even Oracle JDK 17 once its no-fee period lapses​. Example: If you downloaded Oracle JDK 11 from Oracle’s website, you had to click through the OTN License agreement – using that JDK to run an internal application or a customer-facing app would violate the license unless you purchased Oracle’s Java SE Subscription.
• Oracle No-Fee Terms and Conditions (NFTC): Introduced with Java 17 in 2021, the NFTC is Oracle’s attempt to keep Java adoption high by allowing free use of newer versions​. Under NFTC, anyone can use Oracle JDK for free, including in production, but only for the versions Oracle designates and only for a certain time. Oracle JDK 17 and JDK 21 are under NFTC for their initial support life​. The critical condition with NFTC is the update limit – as discussed, security patches after a certain cutoff (e.g., after Sept 2024 for JDK 17) fall under the OTN (which requires a subscription)​. Example: A company uses Java 17 on their servers from 2022 through 2024 and applies all updates. All of that is free under NFTC. In October 2024, Oracle released a new critical patch update for Java 17; if the company wants to apply it, NFTC no longer covers that update, so they would need to start a subscription.

Understanding which of these agreements your Java installations fall under is essential because it determines whether you owe Oracle money​.

For instance:

• If you’re under the BCL (older Java), you likely don’t need to pay (assuming general use).
• You need a commercial subscription if you’re under OTN (Java 8 update 211+, Java 11, or expired Java 17).
• If you’re under NFTC (Java 17/21 current), you can use it now, but you need a plan for when the free period ends​.

It’s often helpful for a company to inventory its Java deployments and tag each with the applicable license agreement. This will highlight compliance gaps. Many organizations have a mix—for example, Java 8 in some apps (OTN license, needs subscription), Java 17 in newer apps (NFTC, currently free), etc. Only by reviewing these agreements in light of your deployments can you avoid surprises and ensure you’re not violating terms or overpaying unnecessarily.

Which versions of Java with Oracle require a license?

This is a critical question for planning. In simple terms, any Oracle Java version not covered by a current free license and used for commercial purposes requires a license (subscription).

Let’s break it down by version:

• Java SE 7 and earlier: Oracle’s Java 7 (and 6, etc.) reached the end of public updates years ago. These older versions were under the Binary Code License (BCL). If you still run Java 7 or 6 in production, Oracle no longer provides updates unless you have a support contract. Technically, general use of those old versions was free under BCL, but the main issue is usually security since they are out of support. If you need a patch, you’d have to pay Oracle for extended support (so effectively, a license is needed if you require fixes). Otherwise, running Java 7 without updates doesn’t violate Oracle’s old license, but it’s risky. In practice, few companies run such old Java unless necessary.
• Java SE 8: This is a special case. Java 8 was free under BCL for many years. Oracle ended free public updates for Java 8 in January 2019 (Update 202 was the last free one). Java 8 update 211 and later require an Oracle Java SE subscription for commercial use​. Oracle’s license (OTN) for those later updates does not allow you to use them in production without paying. So, if your servers or applications have Java 8 and you’ve kept them updated beyond early 2019, you need a license. If you freeze at Java 8u202 (the last free update), you technically don’t owe Oracle for using that build, but you haven’t received any security patches since then, which is problematic. Most businesses using Java 8 in 2023+ have subscriptions to get updates through at least 2022 (when Oracle’s Premier support for Java 8 ended)​. Summary: Java 8 in production requires a license if you’re using any updates released post-Jan 2019.
• Java SE 11: Oracle JDK 11 was released under the OTN license. So, any commercial use of Oracle Java 11 requires a subscription (unless it’s strictly for development/testing)​. Oracle had no free production use period for 11. (Oracle did, however, allow free use of OpenJDK 11 — which is the route many took, using OpenJDK builds to avoid this license.) Suppose a company standardizes on Oracle JDK 11 for an internal application. In that case, they should subscribe to remain compliant and get updates (which run until at least 2023 for Premier and beyond for Extended support)​.
• Java SE 17: Oracle JDK 17 was initially free (NFTC license) until September 2024​. During that time, no license was needed. Starting with updates released after that date falls under the OTN license – meaning a license (subscription) is required to apply those updates​. So, if after Sept 2024, you plan to keep using Java 17 and want the latest patches, you need to purchase a Java SE subscription. You could avoid paying if you don’t care about updates or switch to a different JDK distribution after 2024.
• Java SE 21 (and future versions): Java 21, released in 2023, is also under NFTC and free for all use for a defined period (Oracle has said at least until Sept 2026)​. So, currently, Java 21 does not require a license. If history repeats, after its free period, updates will require a subscription (likely after the release of Java 25). The pattern seems to be that the latest two LTS versions (currently 17 and 21) are in free-support mode; once a new LTS comes, the oldest falls out of free support.
• Non-LTS versions (Java 9, 10, 12, 13, …): Oracle’s non-LTS releases are short-lived and under NFTC for their active six-month life​. They don’t require a license during that time; after that, they don’t get updates (so no subscription concept applies). In practice, few companies deploy non-LTS versions to production.

Java 8 (post-2019 updates) and Java 11 always require commercial use licenses. Java 17 and 21 are free for now; they only require a license if you continue to use them with updates beyond their free update period​. Any older Java you need patches for would require an Oracle support contract.

Suppose you’re unsure about a particular installation. In that case, one guideline is to check what license you accepted if you’ve downloaded Java from Oracle’s website and clicked “Accept License” and that Java is running a business application.

For Java 8/11, it’s OTN (no free prod use); for Java 17/21, it’s NFTC (free until cutoff). That will tell you if you need a subscription.

Oracle Java License Cost (Pre-2023)

Before Oracle switched to the employee-based model in 2023, Java SE licenses were sold under two primary metrics: per Processor (for servers) and per Named User Plus (for desktops or users).

Oracle called these the Java SE Subscription (for servers) and Java SE Desktop Subscription products. Below is a summary of the legacy pricing structure (which was in effect from 2019 up until Jan 2023):

Oracle’s pre-2023 Java SE Subscription price list shows monthly costs per Processor and Named User Plus (Desktop). Higher volumes enjoyed tiered discounts​.

• Java SE Subscription (Processor) – This covered Java installed on servers (or any device where licensing by CPU core was needed). The list price started at $25 per month per processor for up to 99 processors​. Volume discounts would reduce the per-processor cost at higher tiers (e.g., down to $12.50 per processor/month for large quantities)【13†】. Oracle defined “processor” similarly to how it licenses databases – it typically counted physical cores with certain multipliers for different CPU types (Java followed Oracle’s standard Processor definition).
• Java SE Desktop Subscription (Named User Plus) – This was meant for end-user machines or generally licensing per user. It started at $2.50 per user per month (for 1–999 users)​. The price per user dropped with larger purchases (down to around $1.25 per user/month at very high counts)【13†】. “Named User Plus” in Oracle means each unique person is authorized to use the software (even if they don’t). There was typically a 10-user minimum per organization for this license.

These subscriptions included the right to use Oracle Java in production and the support (patches, updates). The pricing was “all-in.” To illustrate, a company with 1000 desktop Java users would pay roughly 1000 * $2.50 = $2,500 per month ($30k/year) under this model (less if they negotiated discounts for volume). A company with 10 Java server instances on 8-core CPUs (assuming 10 processors in Oracle terms) would pay 10 * $25 = $250 per month for server licenses (again, list price).

It’s worth noting Oracle also had (and still has, in a sense) higher-tier Java offerings like Java SE Advanced or Java SE Suite, which included management tools and commercial features such as Flight Recorder and Mission Control. Those were more expensive and often licensed on a per-processor basis for mission-critical JDK features​. However, for most organizations, the focus was on the standard Java SE Subscription described above.

The legacy pricing model was more flexible because a company could only license specific servers or users that needed Java. If you had 100 users that needed Java, you paid for 100 users, not your whole company.

The employee-based model was replaced in 2023, which removed the option to license selectively. Some existing customers on the old model have been allowed to renew, but Oracle generally is steering new sales to the per-employee (universal) subscription​.

For historical context, these prices were introduced in 2019 when Oracle first rolled out Java SE subscriptions​. Before that, Java updates were free, and Oracle only sold support for Java (or the advanced features) in large enterprise deals.

So, in 2019, Java got a price tag, and the tags were as follows: Many companies locked in these rates via 2-3-year contracts. Those contracts faced huge changes as they came up for renewal around 2023 when Oracle pivoted to the new pricing model.

Oracle Java Licensing on VMware

Running Oracle Java on VMware or other virtualized environments introduces some additional considerations. Oracle’s official stance on Java SE licensing in VMware is similar to its stance on other Oracle software: they look at the entire physical infrastructure, not just individual VMs.

Specifically, Oracle has indicated that if you deploy Oracle Java on a VMware ESXi server (version 6.0 or higher), you must license every physical host in all connected vCenters where that VM could run​. This is sometimes called the “traveled once, license everywhere” rule.

In practical terms, if your VMware cluster has 10 hosts and you install Oracle JDK on a VM that is part of that cluster, Oracle’s policy would require you to have Java licensed for all 10 hosts (even if the VM usually runs on just one host) if there is vMotion or the possibility of moving that VM around.

Moreover, they may assert an even broader scope if that vCenter is linked to others (or, in Oracle’s view, if the environment could allow moving VMs beyond one cluster). This expansive view means Oracle can demand licenses for far more infrastructure than Java’s actual footprint, which can dramatically increase costs.

This policy is not spelled out in a Java license document but comes from Oracle’s partitioning policies and has been communicated via audits and Oracle reps. It’s analogous to how Oracle licenses databases on VMware – Oracle doesn’t recognize soft partitioning to limit licensing, so they default to requiring all potential hosts to be licensed.

However, with the new Employee-based Java SE Subscription (post-2023), these VM-specific concerns are somewhat moot for those licensees. The employee metric covers unlimited use across the environment, so if a company has switched to the per-employee model, they don’t have to count processors or worry about where Java is installed – every employee is already licensed, which implicitly covers any number of VMs. One of Oracle’s selling points for the Universal Subscription is to “simplify” licensing by not having to track installation.

Of course, that simplification comes at the cost of potentially licensing many unused installations, but it avoids the VMware issue by design.

For companies still on the older model (processor-based licenses), caution is needed. Oracle’s audits will look at your virtual environment configuration. If you run Oracle Java on VMware without isolating it to a dedicated, bounded set of hosts, you could be exposed to a claim that you need many more licenses.

Oracle’s contractual docs don’t explicitly mention VMware, but their audit teams apply policies that effectively treat VMware like a big shared pool. To be safe, some organizations either:

• Physically restrict Oracle Java deployments to specific hosts and get Oracle’s approval to count only those.
• Or move to containerization or other forms of deployment where it’s easier to pin down where Java runs.

In summary, Oracle’s view is that Java on VMware can require licensing of the entire environment​. This is a known point of contention. Companies planning to use Oracle Java on VMs should be aware of this stance and factor it in. Alternatively, using an open-source Java distribution on those VMs would entirely avoid this Oracle-specific issue.

Oracle Software with Included Java SE Licenses

One good news in the Oracle Java licensing landscape is that some Oracle products include a Java SE license for free as part of their licensing. Oracle calls these “restricted use” Java SE licenses. Essentially, suppose you have certain Oracle software deployed. In that case, you can use Oracle Java to run that software without purchasing a separate Java SE subscription, as long as it’s only used for that purpose​.

Oracle has published lists of products that come with an embedded Java license. There are two schedules (often referred to in Oracle docs as Schedule A and Schedule B) that enumerate these products​:

• Schedule A Products: These are typically client or small utility products. For example, Oracle SQL Developer is known to include a Java SE license (because it’s a tool that runs on a desktop and requires Java). If you use SQL Developer, you can use the Java that comes with it for that application without extra cost. (Another Schedule A example is Oracle’s Jinitiator and some older applet technologies).
• Schedule B Products: This list is more extensive and includes many Oracle enterprise products. For instance, Oracle WebLogic Server (all editions) includes a license to Java SE for running the WebLogic server application​. Oracle Forms, Oracle E-Business Suite, PeopleSoft, JD Edwards, and other major Oracle applications similarly include Java. Oracle Database historically included a Java runtime for stored procedures – and the database license covered that usage. The list (around 100 products) covers a range of middleware and enterprise apps​. Some examples from Oracle’s list:
  • Oracle WebLogic Server (Standard, Enterprise, Suite)​
  • Oracle GlassFish Server
  • Oracle Coherence
  • Oracle WebCenter products
  • Oracle Business Intelligence Enterprise Edition
  • Oracle Data Integrator and other Fusion Middleware tools​.

What this means for customers is that if you are only using Java as part of one of these Oracle products, you might not need a separate Java SE subscription. Java usage is considered licensed under the umbrella of the product’s license. For example, if you have an Oracle E-Business Suite ERP system that requires Java on the server and clients, Oracle allows that usage as part of your EBS license. You wouldn’t need to additionally pay for Java SE to support EBS – as long as Java is only used for that product.

However, caution: The Java license in these cases is restricted. It usually says you can only use Java to run the specific product. You cannot use that same Java installation to run other non-covered applications. If you do, you’d step outside the included license and need a Java SE subscription. For instance, just because WebLogic includes Java, you can’t use the WebLogic-supplied JDK to also run some separate custom application on the side and claim it’s covered.

From a compliance perspective, it’s wise to document which Oracle products include Java and how Java is used for them. If Oracle ever questions unlicensed Java usage, being able to show “this Java is bundled with WebLogic, which we are licensed for,” will clarify that portion​. Oracle’s documentation (in their Java SE Licensing FAQ or support notes) has the definitive list of products that include Java SE licenses​. Checking that list can save you money – you might realize you’re already entitled to Java for certain systems.

In summary, many Oracle enterprise products include Java SE usage rights. This benefits customers by reducing the need for duplicate licensing. Always verify the specific terms for your product, but leveraging these included rights can help avoid unnecessary Java SE subscription purchases for those environments.

Oracle Java Negotiation

If your organization needs to purchase Oracle Java licenses (or faces a renewal or audit), it’s important to approach it as a negotiation rather than a routine purchase. Oracle is known for being open to negotiation, especially if you’re a significant customer, but it requires preparation and strategy.

Here are key steps and tips for negotiating Oracle Java licensing:

1. Identify and Document All Java Deployments: Audit your Java usage internally before talking to Oracle. Identify where Oracle’s Java is installed: on servers, desktops, embedded in third-party apps, etc. Determine the versions in use and how they’re being used (production, development, etc.)​. This gives you a clear picture of your license requirements. Oracle will expect you to license everything, but you should know what “everything” actually is.
2. Measure Your License Needs Under Oracle’s Rules: Once you know your deployments, calculate what Oracle would ask for. If you’re negotiating under the new employee-based model, determine your total employee count that qualifies (full-time, part-time, contractors supporting operations, etc.). If under the older model (for renewal, perhaps), calculate the number of processors and named users. It can help to simulate the cost scenario: “By Oracle’s metric, we would need X employees licensed, which at list price is $Y per year.” This preparation not only prevents you from over-buying but also signals to Oracle that you understand your environment – which can prevent them from over-claiming licenses you don’t need​.
3. Formulate a Negotiation Strategy: Determine your objectives. Are you trying to minimize cost, get a multi-year deal, bundle Java with other Oracle purchases, or even negotiate time to migrate off Oracle Java? Perhaps you have leverage (e.g., other Oracle contracts up for renewal or considering third-party support). Also, decide what you can concede and what you cannot. For example, you might agree to a three-year subscription if Oracle gives a discount, or you might insist on being able to true-down (reduce count) if your employee numbers drop – something not offered by default.
4. Engage Oracle (or Reseller) with a Clear Ask: When you enter discussions, present data-based arguments. “We have X Java installations supporting these business apps. By your model, that’s N employees. However, we believe only M of them use Java actively.” While Oracle won’t change the metric for you, showing that you have data might encourage them to offer a concession (like a discounted tier) because you could otherwise optimize or reduce usage. If you’re renewing under an older metric, you might need to show deployment reports to justify not increasing counts. Provide Oracle with a deployment report only when needed and ensure accuracy​. The more credible your numbers, the better you can negotiate.
5. Negotiate Price and Terms: Oracle’s Java subscription model has published tiered prices, but there is room for negotiation. Large enterprises have reported getting significant discounts off list prices, especially if they have a good relationship with Oracle or buy other products. Don’t assume the list price is final. Negotiate for a lower price per employee or ask for incentives (like an extra year of support or the inclusion of some Oracle Advanced features). If you have a lot of Oracle products, sometimes you can negotiate Java as part of a broader deal (though Oracle has compartmentalized Java, it’s still worth trying). Remember, Oracle’s new model locks you into a high count; if you have any compelling reason (say, a portion of your workforce truly never uses computers/Java), you might argue for excluding them – Oracle might not agree. Still, it sets the stage for a possible compromise like a discount.
6. Consider Term and Flexibility: The standard Java SE Subscription term is one year​. You might negotiate a multi-year term for price protection or discounts. Conversely, if you expect to reduce Java usage in a year or two (maybe by migrating to OpenJDK), you might want a shorter term or the ability not to auto-renew. Clarity on renewal terms is crucial – will the price stay the same, or can it increase? Oracle’s contracts often allow yearly price hikes unless locked in.
7. Leverage Expert Help if Needed: Consider using a software licensing expert or a third-party advisory service if your Java spending is significant. They can help you benchmark a fair discount and navigate Oracle’s tactics​. Oracle’s negotiators do this daily, and having experienced negotiators on your side can save you a lot of money.
8. Negotiation Etiquette: Always maintain clear documentation of what is discussed and promised. Oracle sales teams might make verbal assurances – ensure those get into writing in the contract or ordering document​. Also, be transparent (but not gratuitously so) – providing credible data about your deployments can build trust, but don’t volunteer information that isn’t asked for or that could hurt your position (like admitting you were out of compliance – frame it instead as “we are here to resolve licensing for our current usage”).

A special scenario: If you previously had a Java Unlimited License Agreement (ULA) (Oracle occasionally offered Java ULAs that allowed unlimited use for a period), Oracle is now moving ULA customers to the employee model at renewal. This can cause a big cost jump​. In such cases, negotiation is critical – you’ll want to push for favorable terms since Oracle is effectively ending the unlimited use benefit you had.

Finally, note Oracle’s posture: in 2023, Java will be their hot focus. They might be less flexible on metric but more flexible on price if pressured. Also, suppose you have alternatives (like migrating to OpenJDK), and you make it clear that Oracle knows they risk losing you entirely. That can sometimes make them more willing to negotiate a lower price to retain you as a customer.

Preparation and knowledge are your best tools in Oracle Java negotiations. Know your usage, know Oracle’s rules, and approach the discussion like a major software contract negotiation because that’s what it is. Some companies have avoided paying for unnecessary licenses and secured more reasonable deals than off-the-shelf pricing.

Oracle Java Audits

Oracle has increasingly turned its attention to auditing customers for Java usage. In the past, Oracle primarily audited its database and middleware customers, but with Java now a paid subscription for many use cases, Java audits have become a reality. Business decision-makers should know how these audits work and the stakes involved.

Audit Likelihood: According to industry analysts, many organizations can expect a Java license audit in the coming years. Gartner predicted that by 2026, Oracle will audit at least 1 in 5 organizations using Java​.

Oracle has also launched “soft audit” campaigns (mass emails and calls) targeting companies to discuss Java licensing compliance. Organizations that have never purchased Oracle Java but downloaded Java or updates are being contacted.

Audit Triggers: Oracle can identify potential non-compliance through various means:

• Download Records: Oracle keeps download logs from its website. If your company’s domain or Oracle account has been used to download Java patches or installers (especially those under OTN license) since 2019, Oracle knows and may flag your organization​. For example, if someone in IT downloaded Java 8u221 from Oracle’s site, Oracle sees that as an indicator you might be using Java without a subscription.
• Support Contract Changes: If you had any Oracle support that implied Java use (or had an expired Java ULA), Oracle might follow up.
• Broad Industry Sweeps: Given Java’s ubiquity, Oracle appears to proactively contact many companies, even without specific evidence.

Soft Audits vs. Formal Audits: Oracle’s initial approach for Java has been through soft audits—the friendly outreach by Oracle’s LMS (License Management Services) or sales asking to “discuss Java.” They might send an email offering to help assess your Java usage​. Oracle will ask for data about all Java installations if a company engages.

If you ignore them or refuse, Oracle can escalate. Eventually, Oracle can initiate a formal contract audit (if you have any Oracle agreement that includes audit clauses – Java SE subscription agreements include audit clauses, and if you use Java under OTN without a contract, Oracle might leverage any relationship to enforce an audit or take legal action).

What Happens in an Audit: In a formal audit, Oracle typically asks you to run scripts or fill spreadsheets to inventory Java installations on all servers and PCs. They will want to know:

• Version and patch level of each Java installation.
• Where it’s installed (which machine, perhaps how it’s used).
• They may check if those installations correspond to any included-with-Oracle-product scenarios.
• They’ll compare the data to what you’ve licensed (e.g., if you have some Java licenses, they check if your usage exceeds them).

Oracle may also look for evidence of commercial features usage (e.g. if Java Flight Recorder was used in Java 8 without the proper license, as that used to require Java SE Advanced licensing).

Audit Outcomes: If Oracle finds unlicensed use, they will issue a compliance report detailing what’s required. Often, they will demand:

• Purchase Java SE subscriptions for the observed usage (often with back-dating or some penalty).
• In some cases, retroactive fees for unlicensed period usage can be requested – Oracle has been known to seek payment for up to several years of past use of Java if you used it without a license​. This can be a massive, unexpected cost.
• Oracle’s stance is that if any Java usage is found, the company should buy a subscription for the entire employee count (the current model) in the future​. This can feel like using the audit to force companies onto the new licensing scheme.

Risks and Preparation: The risk of a Java audit is not just theoretical. Many firms have reported receiving those Oracle emails in early 2023. The cost exposure can be high – a non-compliant Java deployment can lead to a compliance bill in the millions of dollars for large organizations if Oracle calculates back support and future licensing​. To prepare:

• Proactively perform an internal audit as mentioned. Know your status before Oracle comes.
• If you receive a soft-audit email, do not rush to respond with data without preparation​. Treat it seriously. You may want to consult a legal or licensing specialist.
• During an audit, ensure you only provide the requested information and that it’s accurate. Over-disclosure can lead to Oracle identifying usage that might not require a license.
• Check if your usage is covered by the included licenses (from other Oracle products) to push back on findings.
• Negotiate resolution: Oracle will typically prefer to have you buy subscriptions moving forward (and sometimes forgive some past usage if you commit to a contract). You might negotiate a settlement where you agree to subscribe for X years rather than pay heavy back fees.

In short, Oracle Java audits are now possible and can be aggressive. Oracle sees Java as an installed base with compliance gaps and is pursuing it. Being prepared and proactive is key to avoiding a bad outcome.

Many organizations find that after self-review, they either true-up (purchase the needed licenses in a controlled way) or migrate off Oracle Java to eliminate the risk.

Did You Receive an E-mail from Oracle Regarding Java?

If you received an unexpected email from Oracle asking to discuss your Java usage or licensing, you’re likely part of Oracle’s recent “Java licensing outreach” campaign. These emails are often phrased as a courtesy or an offer to help assess your Java deployment, but they are effectively the first step of a soft audit​.

Here’s how to handle it:

1. Don’t Ignore It, But Don’t Panic: The email indicates Oracle’s interest in your organization’s Java usage. It might be tempting to ignore it, but Oracle often follows up persistently (multiple emails or calls over weeks)​. Eventually, they could escalate to a formal audit notice. So, take it seriously, but you have time to respond thoughtfully – there’s usually no immediate legal threat in the first email.

2. Do NOT Provide Data Immediately: Oracle’s email may ask you to fill out a survey or have a call to go through your Java installations. Do not directly share any information about your Java deployments before internally assessing your situation​. Responding impulsively could expose you to compliance liability. Even confirming “we use Java 8 on X machines” without context could lead Oracle to pursue licensing for those deployments.

3. Consult with Experts or Legal Counsel: If you have a vendor management or IT asset management team, loop them in. Consider contacting a software licensing consultant or legal advisor experienced in Oracle audits​. They can guide you on what to do (or not do) next. Many consulting firms offer a brief initial consultation on what such an email means and can help strategize a response.

4. Assess Your Java Usage Internally: Use this time to perform an internal review (if not already done). Identify how widespread Java is and under what licenses (see previous sections). Check if you have any Oracle-included licenses via other products. Essentially, you want to know if Oracle’s likely claims have merit or if you have a defensible position. For instance, if you find “we only use OpenJDK except one instance of Oracle JDK 8 that we forgot about,” that’s useful to know. Or if you discover a broad usage of Oracle Java without subscriptions, you can quantify the risk.

5. Respond Strategically: A polite, non-committal acknowledgment is often the best initial response. For example, “We received your inquiry. We are reviewing our Java usage internally and will reply.” This buys time. Oracle’s team might press for a meeting. When you do engage, you might consider having a consultant or knowledgeable licensing manager lead the discussion. The goal in initial calls is usually to understand what Oracle is looking for and the scope of their inquiry. Try to get them to clarify: are they reaching out to all customers? (They have been reaching out widely.)

6. Avoid Self-Incrimination: On any calls or emails, avoid statements like “We had no idea Java needed a license” or “We’ve been using it freely for years.” Those can be used against you in negotiations. Instead, ask Oracle to clarify the licensing rules (even if you know them) to frame the discussion and say you want to ensure compliance moving forward. You can share that you are evaluating options (maybe considering the Java Universal Subscription vs alternatives).

7. Consider Your Options: If your internal review shows significant unlicensed use and Oracle likely knows (like if you downloaded a lot from Oracle), one path is to negotiate a subscription deal proactively (perhaps with a discount) for Oracle to close the matter without penalties. Another path, if your usage is minimal or you plan to eliminate Oracle Java quickly, might be to inform Oracle that you are transitioning off Oracle Java and, therefore, do not intend to purchase at this time – this can be delicate and should be done with advice, as Oracle may then decide to audit to verify.

8. Soft Audit Process: Oracle’s “soft audit” typically has stages—initial email, follow-ups, and possibly escalating to Oracle’s formal audit team if you don’t engage. How you respond at each stage can satisfy or encourage them to push harder. Some firms, with guidance, have navigated the soft audit by providing just enough info or plan (like agreeing to a modest subscription) to make Oracle back off full audit.

Key point: Treat the Oracle Java email seriously and respond with a plan, not spontaneously. If you ignore repeated inquiries, Oracle might escalate to a more forceful formal audit letter. If you respond unprepared, you might overshare and give Oracle easy evidence of non-compliance. The middle ground—cautious engagement with preparation—is usually best​.

In summary, the Oracle Java email is Oracle knocking on your door about licensing. Open the door carefully, ideally with an expert, and know your situation before you talk. With a measured response, many organizations have managed to satisfy Oracle’s request without severe consequences or have bought themselves time to remediate their Java usage.

Java Retro-Active Licensing Claims

One of the more daunting aspects of Oracle’s Java compliance enforcement is the possibility of retroactive licensing claims. This refers to Oracle demanding payment for Java usage in past years when you didn’t have a proper license.

Essentially, Oracle can say: “You’ve been using Java without a subscription for X years; you now owe us for those past years of unlicensed use.”

Oracle often pursues such fees as part of Java audits and compliance discussions​. For example, suppose Oracle finds you have been running Java 8 in production since 2020 without a subscription. In that case, they may calculate what you would have owed from 2020 to the present and ask for that in arrears (in addition to requiring subscriptions moving forward). These back charges can be substantial – sometimes amounting to hundreds or even millions of dollars for large organizations.

However, there are a few important considerations:

• No explicit contract, no back license? Java SE subscriptions are typically sold on annual terms. If you never had a Java contract with Oracle, you might argue there was no agreement to pay for past usage (you can only be asked to stop using or pay going forward). But Oracle’s counter is that you violated the license terms (OTN) by using without subscription, so you owe damages or need to buy retroactive support. They might frame it as resolving non-compliance by buying back support.
• Negotiation strategy: In many cases, Oracle uses the threat of retroactive fees to motivate a purchase. They might say, “You should pay for the last 3 years, plus penalties,” but then offer, for instance, to waive those if you commit to a 3-year subscription deal now. This is a common tactic—forgiving the past in exchange for future business. An Oracle partner document indicated that Oracle could ask for three years’ worth of back licensing during negotiations​.
• Defense strategies: Organizations can push back on retroactive claims. Those facts matter if you didn’t use certain updates or OpenJDK part of the time. Also, the lack of a direct contract for Java could be a point (though Oracle can claim a breach of copyright/license). Some companies have successfully negotiated down the retroactive portion or eliminated it, especially if they agree to fix the issue in the future​. Oracle is primarily interested in selling subscriptions now.
• Legal aspect: If it ever becomes legal, Oracle must show that you installed/used Oracle JDK under OTN terms and violated them. Often, companies avoid legal fights and settle commercially by purchasing licenses.

From a business perspective, retroactive claims are punitive costs with no value gained (paying for past use doesn’t get you anything new). So, your aim in any settlement is to minimize or eliminate that component. Spending money on a subscription that covers current/future use (which provides actual support and updates) is more palatable than cutting a check purely for past usage. Oracle knows this and will often try to funnel you into the latter.

Best practice to avoid retroactive fees: Act before an audit. If you identify unlicensed use, it might be better to approach Oracle to buy subscriptions starting now (Oracle might then not press for past fees, seeing you as a new customer going forward). Once you’re in an audit situation, your leverage is lower. Also, maintaining good records can help. If Oracle’s claim is based on an assumption (like “we think you used Java on 100 servers for 3 years”), you can reduce that if you have records to show maybe it was only 50 servers or only 1 year on some of them.

In conclusion, Oracle may attempt retroactive licensing claims for Java, which are often negotiable. They serve as a stick to drive compliance. An organization’s goal should be to avoid getting into that situation by staying compliant or switching to free Java or, if caught, negotiating to focus spending on future compliance rather than past penalties. Many have avoided paying for past usage by agreeing to correct the licensing moving forward​.

Oracle Logs of Security Downloads

Oracle has mentioned a few times that it keeps logs of Java downloads – this is a critical point in how Oracle identifies usage. Specifically, Oracle likely has records of downloads from its Oracle Technology Network (OTN) site and Oracle’s Java download pages, especially for updates that require login or acceptance of terms. These logs can include information such as the Oracle Single Sign-On (SSO) account used, email domains, IP addresses, etc.

Why are these logs important? If Oracle contacts you about Java, they might already have evidence that someone from your organization downloaded Java installers or patches. For example, if an IT staff used their corporate email to register an Oracle account and download JDK 8u251, Oracle’s system recorded that. Oracle sales or audit teams can mine this data to create a list of organizations that have likely used Java beyond the free allowances​.

Oracle has reportedly referenced these download logs during audits or soft inquiries to substantiate its claims. For example, it might say, “We have information that you downloaded Java updates on these dates,” indicating that it knows you have those Java versions in use. This often catches companies off guard; many assume Oracle wouldn’t know about internal Java usage, but downloading a patch from Oracle is a telltale sign.

It’s worth clarifying: downloading Oracle software (like Java) and accepting the license typically creates an agreement that you will abide by that license. If you downloaded an OTN-licensed Java update, you agreed it’s for non-production use unless you have a subscription. Oracle uses the logs as indirect evidence that you used the software and might be non-compliant if no subscription exists.

For companies, what can be done?

• Awareness: Oracle likely has this information. If you’ve downloaded Java from Oracle’s site, assume Oracle knows. Some companies instructed their teams to stop downloading Oracle JDKs once the licensing changed to avoid leaving this trail (instead of using open-source builds).
• Audit preparation: If facing an inquiry, Oracle might pull out a list: “User X from your company downloaded Java 8 update 241 on this date.” I have an explanation: Was it just for a test environment? Or was that system decommissioned? Lying is not advised, but context can matter (if it truly was for a non-prod use, that could be defensible).
• Countering claims: Oracle might infer much from a download (e.g., one download could mean many installations). You can counter by showing actual deployment data. Also, Oracle’s logs won’t show usage of OpenJDK or other distributions, so if you primarily used other sources, that can be a rebuttal: “Yes, we downloaded that, but ultimately, we chose to deploy OpenJDK on our servers, not Oracle JDK.”

From a licensing standpoint, accepting Oracle’s Java download terms and then using the software in production without a subscription is a breach of license. Oracle’s logs provide evidence of acceptance/download. Therefore, controlling who in your org can download Oracle software and tracking what they do with it is now a part of compliance governance.

In summary, Oracle’s logs of Java downloads and security updates are tools to enforce licensing. They have been actively using it by sending emails to organizations with downloads on record​. Companies should not assume their Java use is under the radar. A prudent step is to minimize unnecessary downloads from Oracle (use alternative sources if possible) and keep records of what any downloaded Oracle JDK was used for. Internally, this transparency can prevent unpleasant surprises if Oracle comes knocking.

The Employee for Java SE Universal Subscription

The “Employee for Java SE Universal Subscription” is the cornerstone of Oracle’s current Java licensing model (as of 2023). Understanding this metric is critical for any business considering Oracle’s Java subscription:

• Who counts as an “Employee”? Oracle defines it very broadly. It includes all your full-time employees, part-time employees, temporary staff, contractors, agents, and consultants who support your internal business operations​. Essentially, if a person is working for your company in any capacity that isn’t an external end-user, they are counted. Even employees who never use a computer or never directly use Java are counted because they could benefit indirectly from Java running somewhere in the company.
• One Employee = One License (covering any use): With this model, you pay a set price per employee, and that covers any amount of Java usage within the company—on servers, desktops, etc. It’s an “all-you-can-eat” model, but you pay for everyone regardless of consumption​. This simplifies tracking but means many companies are now licensing many “non-Java users,” which is where much of the cost increase comes from​.
• Counting Employees: Oracle uses the number of employees at the time of the subscription order to determine the tier and pricing​. If your company has 5,000 employees at purchase, you must license 5,000 – even if only 500 use Java. If the employee count goes up later, you’re usually expected to true up at renewal (if you renew, you will renew at the higher number). If it goes down… Oracle has not offered refunds or reductions mid-term; you generally commit to the term with that number.
• Excluded Personnel: Oracle’s definition might exclude third parties that do not support your operations (like your customers or contractors of a different nature). But typically, anyone working for you is included. Some companies asked Oracle if they could exclude warehouse workers who don’t use computers, and the answer has been that they still count if they are employees because Java could be part of internal systems that indirectly support their work. The only ones not counted are those wholly unrelated to your operations (like software users, etc., those are not your employees).
• Capped at 50,000, then custom: Oracle’s price list has tiers up to 40k-49,999 employees at $5.25 per employee/month, and beyond 50k, it says “contact Oracle.”​ Large enterprises might negotiate a custom rate once they exceed 50k employees.
• Implication – No Partial Licensing: You cannot choose to license just a subset of employees. It’s all or nothing. Even if only one team uses Java, Oracle expects a subscription for the entire organization’s headcount​. This is a departure from the older model, which allows you to license certain servers or users.

For companies, this metric forces some considerations:

• Cost-Benefit: If Java is mission-critical across many systems, licensing all employees might be acceptable as a cost of doing business, and it covers growth. However, if Java usage is minor, this model feels very expensive (paying for thousands of people who never use Java).
• Auditing Simplicity: The upside is that you don’t have to track where Java is installed. If properly licensed by an employee, you’re covered everywhere, even new deployments. Oracle also doesn’t need to audit installations; they just need to verify your employee count (which they could compare to public information or ask for HR records).
• Employee Count Verification: In an audit, Oracle could ask for proof of the number of employees. Companies should be consistent—the count should include part-time workers, etc. The subscription agreement likely allows Oracle to audit headcount. Make sure you have an agreed-upon definition. For example, do contractors count? (Yes, if they use internal systems typically.) If in doubt, clarifying edge cases in the contract would be wise.

The “Employee for Java SE Universal Subscription” metric can be seen as Oracle monetizing Java based on company size rather than usage. It’s “simple” but not very fair for low-Java-use scenarios. Many organizations responded by exploring alternatives due to this model.

One additional point: If you have a subsidiary or division that uses Java, Oracle will count the entire legal entity that is party to the contract. Companies have asked if they can just license a subset of the company (like one business unit). Typically, Oracle wants the agreement to cover the whole corporation (all majority-owned entities). Splitting out is complicated and usually not allowed unless you do separate contracts under different names.

The Employee metric means you license Java like a company-wide site license—priced per capita. Getting the count right is important, and it is important to understand that this is now the only way Oracle sells Java SE subscriptions to new customers. Decision-makers should carefully evaluate whether this model is cost-effective or if switching to free Java alternatives yields savings, especially if only a small fraction of employees need Java.

Java Pricing

Let’s consider the current Java SE Universal Subscription pricing. Oracle’s published prices (as of early 2023) for the employee-based model are tiered by the total number of employees you need to license​.

Here’s the breakdown:

Employee Count	Price per Employee per 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 and above	Contact Oracle for pricing

How to interpret this: Suppose you have 2,500 employees in your company. That falls in the 1,000–2,999 tier, so the list price is $12 per monthly employee. Oracle would price your Java subscription at 2,500 * $12 = $30,000 per month, which is $360,000 annually. If you had 500 employees, it’d be 500 * $15 = $7,500 per month ($90k/year).

The tiered structure means the per-unit price decreases at larger scales, which is typical for enterprise pricing. If you’re over a tier boundary (say 3,100 employees – just over 2,999), your cost jumps into the next tier at $10.50 each. Oracle doesn’t automatically exclude the first 2,999 at $12 and then the rest at $10.50 – rather, once you cross the threshold, usually the lower price applies to all units. (The table is a bit simplified; Oracle’s actual price list might be cumulative, but effectively, these are average per-user prices in those ranges.)

Note on currency and agreements: These prices are generally USD for US-based customers. Oracle price lists globally may vary in local currency but follow a similar structure. Oracle usually sells these as annual subscriptions so that you might pay, for example, $360k upfront for a year for 2,500 employees.

Comparison to Pre-2023: It’s useful for decision-makers to know how this compares to the legacy model. Under the old model, you might have paid far less if you only had Java on a few servers or a subset of users. For instance, if only 50 users needed Java, it was 50 * $2.50 = $125/month ($1,500/year). If you have 1,000 employees company-wide, you pay $144k/year minimum, even if those 50 users are the only ones running Java. This is why many organizations see big cost increases.

Oracle justifies that this model simplifies licensing and better covers cloud environments, etc.. Still, from a pure cost perspective, most scenarios except “Java everywhere in huge deployment” resulted in higher fees. Gartner and others have noted that many customers will pay significantly more (2-5x) under the new scheme​.

Large enterprise deals: If you have over 50k employees or you’re negotiating, Oracle might offer a custom flat rate. For example, a company with 60k employees might negotiate a $4 per employee rate or some capped amount. Every negotiation is different, but the table above gives the baseline.

Other costs: The subscription includes support, so there’s no separate support fee. It’s a subscription, not a perpetual license, meaning if you stop paying, you lose the right to updates (technically, the right to use Oracle Java in production going forward). So, it’s an ongoing operational expense. Oracle typically offers 1-year terms, but possibly 3-year terms at a set price if you negotiate.

One should also factor in that Oracle Java is not the only cost—if you decide not to pay, you might invest in migrating to another solution, which has its costs (engineering effort, testing, etc.). So, the pricing should be weighed against those potential costs as well.

In conclusion, Java pricing under Oracle’s current model is straightforward but can be substantial. It’s effectively a site license charged by employee count. The larger your organization, the cheaper the per-unit cost, but the overall spend can be high.

Given these price points, decision-makers need to consider how much business value they get from Oracle’s Java (e.g., support and timely updates) versus using an alternative. For some, $100k—$1M per year for Java might be justifiable; for others, especially if Java isn’t heavily used, those funds might be better spent elsewhere by switching to free Java distributions.

Read more about Java pricing.

Expert Advice on Licensing Changes in 2023

The 2023 changes to Java licensing (the employee-based model) sparked much discussion among IT asset management and licensing experts.

Here are some key pieces of advice and insights from industry experts and analysts for businesses navigating these changes:

• Prepare for Higher Costs: Analysts like Gartner quickly pointed out that most organizations will pay significantly more under the new model​. If you stick with Oracle’s Java, adjust your IT budgets. Don’t assume it’s a negligible line item anymore. Some experts estimated 2x to 5x cost increases, so companies should run the numbers and avoid sticker shock​.
• Reevaluate Java Usage: Experts recommend thoroughly reviewing where you need Oracle’s Java. Many organizations have broadly installed Java, but not all is truly required. Eliminate or replace Java where it’s not needed to reduce your footprint. For example, if an application can run on OpenJDK or you can uninstall Java from endpoints that don’t require it, do so. The smaller your real usage, the more negotiating power or the easier to migrate off Oracle.
• Consider Third-Party Java Distributions: A major piece of advice is to evaluate alternatives like OpenJDK distributions from other vendors (Azul, Amazon, IBM, Eclipse Temurin, etc.). Given the cost increase, many experts suggest that paying Oracle is no longer the default choice – there are mature, free, or cheaper support options. Indeed, Gartner predicted that by 2026, over 80% of Java applications might be running on third-party (non-Oracle) Java runtimes, up from 65% in 2023​. This shift is expected as companies seek to avoid Oracle fees.
• Negotiate and Don’t Accept the First Quote: Licensing consultants emphasize that Oracle’s list price can often be negotiated down. Especially if your employee count is huge or you’re an important Oracle customer, push back on price. Oracle sales reps have targets and may have some flexibility to close a deal. Use any leverage – for instance, if you spend millions on an Oracle database or cloud, mention that in negotiations for a better Java price.
• Check Existing Contracts: Some experts advise checking if you have any existing contracts that might cover Java. For example, a global Oracle ULA (Unlimited License Agreement) or a special Oracle agreement sometimes had Java clauses. If you have a Java ULA that is expiring, know your rights. Oracle is likely not renewing those and pushing to the new model​, but maybe you can time your transition or negotiate continuity benefits.
• Stay Compliant, Avoid Audits: Expert licensing firms warn that Oracle is actively auditing Java. The advice is to get ahead of any audits by performing self-assessments. If you find it non-compliant, remediate it by installing alternative JDKs or purchasing the necessary Oracle subscriptions. It’s usually cheaper to address it proactively than to deal with an audit finding and potentially pay back fees. Gartner also warned that an estimated 30% of organizations using Java might be out of compliance by 2026, so don’t assume you’re fine – verify it.
• Security vs Cost – Don’t Skip Updates: Some organizations considered not patching Java to avoid needing a subscription (especially with the Java 17 free period ending). Security experts advise this is a dangerous strategy. Experts recommend not letting licensing costs prevent you from applying security updates. If you choose not to pay Oracle, plan to upgrade to a newer free version or switch to another JDK source that provides patches. Leaving your Java unpatched to save money could lead to security breaches that cost far more.
• Get Internal Alignment: Advice also comes for communication – ensure your procurement, IT, and security teams are on the same page. Sometimes, security wants to patch (implying a license need), while procurement may not realize the license is needed. Experts suggest raising this issue to management: “We need a strategy for Java – either we pay Oracle, or we invest in migration – but doing nothing is not an option.” This proactiveness can prevent last-minute expensive true-ups.
• Use Experts if needed: If the stakes are high (large environment, potentially large fees), many companies engage Oracle licensing specialists or firms specializing in compliance (like Palisade Compliance, Miro, SoftwareONE, etc.). These experts have dealt with Oracle Java cases and can guide on negotiation or audit defense. For example, if Oracle claims huge retroactive fees, an expert who has successfully fought those claims can save you a lot. They often know Oracle’s playbook and where there is wiggle room​.

Experts say that the Java licensing landscape has changed enough that businesses must actively respond. Ignoring it can lead to hefty bills or compliance issues. The silver lining is that with planning, you may avoid paying Oracle altogether by using alternatives or at least minimizing the cost through negotiation and smart management.

The 2023 change prompts companies to treat Java like any other licensable software asset—manage it actively. Those who do so can achieve a controlled outcome (be it a fair deal with Oracle or a migration plan), while those who don’t might face unwanted surprises from Oracle’s auditing machine.

Free Java Options

The good news for organizations feeling squeezed by Oracle’s Java licensing is that there are numerous free Java alternatives. Java is a highly portable platform, and many vendors provide Java Development Kit (JDK) builds that are 100% free to use, even in production.

Here are some key free Java options:

• OpenJDK Builds by Other Providers: The OpenJDK project is open source, and many reputable organizations release their builds of OpenJDK. These include Eclipse Temurin (Adoption), the continuation of the AdoptOpenJDK project now under the Eclipse Foundation. Temurin provides free binaries with Java 8, 11, 17, and newer updates. Many consider it a drop-in replacement for Oracle JDK.Amazon Corretto: Amazon provides Corretto as a free distribution of OpenJDK, with long-term support for LTS versions (Amazon has committed to supporting 8 and 11 for an extended period, for example). It’s used internally at Amazon and offered to the public. Azul Zulu: Azul Systems offers Zulu a free OpenJDK build. They also offer paid support, but the binary is free and often updated in lockstep with OpenJDK releases.IBM Semeru (OpenJ9): IBM’s OpenJ9 JVM is an alternative to HotSpot, but they also offer builds of OpenJDK with OpenJ9. These can be free and may have performance benefits in certain scenarios. Red Hat’s OpenJDK: Red Hat contributes heavily to OpenJDK and provides binaries (particularly as part of Red Hat Enterprise Linux, etc.). While Red Hat’s official support is for its customers, the OpenJDK updates (for example,
  Java 8 and 11) are pushed to the community and often picked up by others like Adoptium. These providers ensure Java remains free for use in production. There are no licensing fees for using these JDKs​. You can download them and run your applications as you would on Oracle JDK. In most cases, switching from Oracle JDK to one of these is as simple as installing it and running your application. The code is essentially the same (Oracle JDK and OpenJDK have “converged” since Java 11, aside from minor differences).
• Oracle OpenJDK builds: Oracle provides OpenJDK builds for each release under the GPL license. These are free. However, Oracle only provides updates for each version until the next version is out (for LTS, they provided two updates, and then the community took over). So you could use Oracle’s OpenJDK binary for, say, Java 17, but after Jan 2022, you’d have to get updates from another source. Many people find it easier to use one of the above providers that continues long-term updates.
• In the short term, Oracle’s own “free” Java (NFTC): As discussed, Oracle JDK 17 and 21 are free under NFTC for now. So technically, sticking with the latest Oracle JDK and upgrading every few years is also a free option (as long as you’re diligent). This essentially leverages Oracle’s offer without paying by always moving to the next LTS before the previous one’s free period ends​. Some might consider this a viable strategy if they can manage the upgrade cycle.
• Alternate JVM implementations: Some specialized Java implementations (like GraalVM Community Edition, which Oracle offers for free, or Liberica JDK from BellSoft) are more niche. For most, an OpenJDK build, as above, suffices.

Support for Free Options: The free options typically come with community support (forums, GitHub issues, etc.) but not commercial support by default. However, companies like Azul, IBM, and Red Hat offer paid JDK support. For example, you could use Azul Zulu for free or pay Azul for a support contract, which might still be cheaper than Oracle. Similarly, Red Hat supports OpenJDK for its customers (if you have Red Hat subscriptions). There are also third-party support firms, such as organizations, that specialize in supporting open-source solutions.

Compatibility: Modern Java is very standard. Switching from Oracle JDK to a free OpenJDK distribution usually causes no issues. It’s the same codebase. You just have to ensure that if you were using any Oracle-proprietary features (which are few now – e.g., Java Flight Recorder is now open source, Mission Control is open source, etc.), the new JDK supports them. Most do. Testing in a staging environment is recommended, but countless companies have switched without incident.

Example Real-world moves: After Oracle’s 2019 changes, many governments, banks, and enterprises moved to AdoptOpenJDK (now Temurin) or others. Similarly, the 2023 change has spurred even more to plan migration. We’ve seen estimates that Oracle’s share of the Java runtime market will shrink. The fact that Oracle themselves predict (and Gartner echoes) that most Java workloads will be on non-Oracle JDKs by mid-decade underscores this is a well-trodden path​.

In summary, robust free Java options allow you to continue using Java without Oracle’s licensing fees. Organizations should weigh the relatively low effort of switching to these against the high cost of Oracle’s licenses. The free route is very attractive for many, especially those without a deep need for Oracle’s direct support. The existence of these options is essentially the leverage customers have – Oracle can’t raise prices infinitely because moving to a free JDK is always on the table.

Why You Need to Review Your Oracle Java Licensing

With all the changes and information discussed, one clear takeaway is that every organization using Java should review its Oracle Java licensing situation. This isn’t something to put off because the landscape has shifted underfoot.

Here are the main reasons to conduct a review now:

1. Understand Your License Requirements: Many organizations are unsure which Java deployments require a license and which do not​. Some may assume everything is fine because “Java used to be free,” while others might overpay for licenses they don’t need. A review will map out each Java instance and clarify if it’s covered by BCL, OTN, NFTC, an included license with another product, or if it indeed needs a paid subscription. This prevents both compliance mistakes and unnecessary costs.
2. Ensure Security and Compliance Planning: If you discover you have Java versions that are not licensed (e.g., Oracle JDK 8 in production without a subscription), you need to address it – either by licensing or migrating – especially before Oracle possibly contacts you. If you have Java 17 but didn’t plan for the end of free updates, you can now plan an upgrade to Java 21 or budget a subscription. Reviewing allows you to proactively plan transitions (like moving away from Oracle Java to OpenJDK) so you don’t get caught off guard with unpaid licenses running in your data center​.
3. Prepare for Negotiation or Audit: If you suspect you will need to buy Oracle’s Java subscription, knowing exactly what you use (how many employees truly require Java) arms you with data to negotiate effectively​. If Oracle initiates an audit, reviewing and documenting your Java usage puts you in a stronger position to respond accurately and limit the scope. It’s far better to go into those conversations informed than scrambling.
4. Optimize Costs: Java might be a smaller line item than other enterprise software, but the 2023 changes made it potentially quite large. By reviewing your licensing, you might realize you can save a lot. For example, you might discover that a certain Oracle JDK department could switch to OpenJDK and save tens of thousands annually. Or you might confirm that you do need Oracle’s support for certain critical applications and that it’s worth the cost. Either way, the review leads to an informed decision, aligning spending with actual needs.
5. Avoid Future Pitfalls: Oracle’s licensing will likely continue to evolve (e.g., how will they treat Java 25, etc.). If you have a process to regularly review your Java usage, you can adapt to changes more easily. It’s similar to how organizations learned to track their Microsoft or Oracle database licenses – Java now demands a bit of the same rigor. In the future, an annual or semi-annual Java license review can be part of IT governance.
6. Internal Education: Reviewing licensing also educates your IT and procurement teams about Java. Many developers or system admins might not be aware that installing Oracle JDK could incur costs. Through review and subsequent communication, you ensure that teams know to either use approved free JDKs or go through proper channels to license Oracle JDK if needed. This reduces the risk of “shadow IT” deployments of Oracle Java that later become compliance issues.

In summary, reviewing your Oracle Java licensing is about due diligence. The environment changed—if you don’t adjust, you could either pay more than you need to or unknowingly run significant compliance and security risks. It’s a classic case of software asset management: know what you have, know what agreements govern it, and manage it actively.

You can answer the following questions by thoroughly reviewing: Which Java versions we use require a license? Do we have those licenses?

Are we using the most cost-effective option for our needs? And are we prepared for Oracle’s approaches?

If you can confidently answer those, you’ve significantly mitigated the potential negatives of Oracle’s Java licensing changes and positioned your organization to use Java optimally​.

Do you want to know more about our Oracle Java Advisory Services?