Overview of the Oracle Java Licensing
In January 2023, Oracle significantly changed its Java SE licensing model, creating substantial cost and compliance implications for organizations worldwide.
These updates shifted from traditional “Named User Plus” and “Processor” licensing models to a new employee-based metric called the Java SE Universal Subscription.
Here’s a detailed breakdown of these Oracle Java Licensing changes and their business impacts.
Key Oracle Java Licensing Changes (2019–2023)
Oracle’s Java licensing policies evolved significantly between 2019 and 2023:
- 2019 – Introduction of Java SE Subscription: Beginning in 2019, Oracle ended the era of “free” commercial Java updates. Oracle Java SE 8 reached the end of public updates for business use in January 2019, after which commercial users needed a paid Java SE subscription to receive updates. In effect, Oracle required paid subscriptions for businesses to continue using Oracle Java and obtaining patches beyond Java 8 update 202 (released in Jan 2019). This marked the end of free Java for commercial production use and introduced a Java SE Subscription model (with traditional Oracle metrics like per-user or per-processor pricing).
- 2021 – No-Fee Terms for Latest Java (NFTC): In September 2021, alongside Java 17 (a Long-Term Support release), Oracle announced a new “No-Fee Terms and Conditions” (NFTC) license. Under NFTC, Oracle JDK 17 and later could be used in production for free – but only for a limited time. The NFTC made the latest Java versions free of charge during their active support period, essentially as a grace period. Importantly, this free use is time-limited: Oracle provides updates for a new LTS release (like Java 17) for a few years, after which updates for that version stop or require a paid subscription. In other words, Java 17 was free from 2021 until one year after the next LTS (Java 21) release, i.e., free updates until September 2024. After that, continuing to use Java 17 (without upgrading) would require buying a subscription. This move temporarily made the newest Java version “free again” to use, but not indefinitely. Older versions (Java 8, 11) did not become free retroactively – they still required a subscription for commercial use.
- 2023 – Employee-Based Universal Subscription: In January 2023, Oracle introduced the Java SE Universal Subscription model, a major shift in licensing. Instead of licensing Java per server or named user, Oracle now charges per Employee. Companies must count all employees (and equivalent contractors) and subscribe based on that number, gaining rights to use Java across the organization. This “Employee for Java SE” metric replaced the legacy Named User Plus and Processor metrics for new subscriptions. The new model covers unlimited company-wide use of Java, but even users who don’t directly use Java must be counted in the license. We delve into this new model in detail below, as it has significant cost implications.
These changes greatly impact how organizations must approach Java licensing. If your company hasn’t adjusted its Java usage or procurement strategy since these changes, you could face non-compliance risks or surprise costs under the new rules.
Legacy Java Licensing Metrics: Processor vs. Named User Plus (NUP)
Under Oracle’s legacy Java SE licensing (approximately 2018–2022), Java was sold using the same metrics as Oracle database or middleware products.
The two primary license metrics were Processor and Named User Plus (NUP):
- Processor License (Per-Core Licensing): A Processor license entitles you to install and run Java on a server CPU (with any number of users). Oracle defines “processor” in terms of CPU cores, with a core factor applied based on the processor type. For example, Oracle’s core factor for Intel Xeon CPUs is 0.5, so one physical core counts as 0.5 “processors” for licensing. If you had Java running on a server with 8 Xeon cores, you would need 8 × 0.5 = 4 Processor licenses. Each processor license allowed unlimited Java usage on that core/processor. This metric was ideal for server-side deployments where many users or applications might share a Java runtime. You didn’t need to count individual users; you just licensed the hardware. Example: An application server on a 4-core (Xeon) VM would require two processor licenses (4 cores × 0.5 factor each) and could serve 10 or 1000 users with the same license count. Processor licensing provided simplicity for back-end systems.
- Named User Plus (NUP) License: A Named User Plus license is a per-user license. Each named individual (or non-human device) that uses the software counts as one NUP. In a Java context, NUP was often used for desktops, developer workstations, or environments where you could count the specific Java users. For example, if 50 employees run a Java-based client application or have Java installed on their PCs, you could license 50 NUPs (one per user) instead of licensing by processor. Oracle’s rules require a minimum of 25 NUP per processor if you choose user licensing on a server to prevent undercounting. (So, a server counts as at least 25 users per CPU, even if fewer users use it.) NUP licensing made sense for scenarios like developer desktops or small user populations, whereas it was less practical for high-density server use. Example: If you had a build server accessed by five developers, you could license 5 NUP for Java on that server (subject to the 25-per-processor minimum) instead of licensing the whole server by processors. On desktops, you’d simply count each user or device running Java.
Under this legacy model, Java licensing was granular and flexible—you paid for Java on the specific environments or users that needed it. An enterprise might mix metrics, for instance, licensing backend servers by Processor and developer machines by NUP. If Java usage decreased, you could potentially buy fewer licenses at renewal.
This model was similar to other on-prem software licensing, allowing partial deployment (not every user or system had to be licensed – only those running Oracle Java). It enabled cost optimization by targeting the license where it was needed.
Legacy Pricing: Oracle’s list prices for Java SE subscriptions under the legacy metrics were relatively modest per unit. In the 2019–2022 price list, Java SE Subscription was about $25 per month per processor (list price), and roughly $2.50 per user per month for NUP. That translates to about $300 per processor per year or $30 per user per year at list price (discounts could apply in volume deals).
For example, a company with Java on four servers (each with four cores) and 100 users might have ~ eight processor licenses for the servers and 100 NUP for user desktops. List pricing would cost roughly $2,400 per year for the processors (8 × $300) plus $3,000 per year for 100 users – about $5,400 annually (before any discounts). Many organizations had such subscriptions to remain compliant once Oracle stopped free updates for Java 8.
Java SE Universal Subscription – Employee-Based Metric (2023–Present)
Oracle’s Java SE Universal Subscription, introduced in 2023, replaced the above granular approach with an enterprise-wide licensing model. The key difference is the metric: instead of processors or named users, the unit is now “Employees.”
If an organization wants Oracle Java SE licenses, it must license all employees in the company (and certain contractors), regardless of how many use Java. This sweeping model has several important attributes:
- All Employees Count: Oracle’s definition of “Employee” is broad. It includes all full-time and part-time employees, temporary workers, and contractors who support the business. Essentially, anyone on the payroll or working for the organization is counted. One licensing expert joked it’s “basically everyone except your dog”. In practice, if your company has 5,000 employees worldwide (plus some contractors), that entire number is the count for licensing – even if only 100 of them are software developers using Java directly. No differentiation is made between those who use Java and those who don’t; the license is an enterprise-wide site license.
- Unlimited Java Use (One Size Fits All): The Universal Subscription permits unlimited use of Oracle Java on any number of devices across the organization once you’ve subscribed for all employees. You no longer have to track which specific servers or PCs have Java installed – in theory, any use of Oracle Java SE in the company is covered. Oracle even sets a high cap (e.g., up to 50,000 processor-equivalents), which is unlimited for most companies. This simplifies compliance because you either are fully licensed everywhere (if you subscribe) or use none of Oracle’s Java (if you choose not to subscribe and perhaps use alternatives).
- No Partial Coverage: Critically, Oracle does not allow partial licensing of Java under this model. You cannot choose to license only a subset of your users, departments, or devices. It’s an all-or-nothing approach – either you cover your entire employee count with a subscription or rely on permitted free uses (which are very limited) and avoid Oracle Java in production. This prevents the cost-minimizing approach of the past, where you might license certain servers or user groups. If you use Oracle Java anywhere in production (beyond the free allowances of NFTC for the latest version), Oracle expects you to have an enterprise subscription for everybody. This has surprised some organizations – for example, a company that only had a small team using Java now would still need to license all employees if they want Oracle’s support.
- Impact on Costs: The employee-based model often raises costs dramatically for organizations that previously only licensed a portion of their environments. You end up paying for many people who derive no direct benefit from Java. For example, a firm with 5,000 total employees but only a few Java applications must still pay for 5,000 Java licenses under this scheme. On the other hand, companies that truly run Java everywhere (on hundreds of servers and most desktops) might find the model cost-effective or at least more predictable, akin to a site-wide license. Oracle has built in volume discounts to the pricing to somewhat soften the blow for large enterprises. The per-employee price tiers down as the employee count increases. For instance, at list price, a small organization pays about $15 per employee per month.In contrast, a large enterprise (tens of thousands of employees) might pay around $5–6 per employee per month after discounts. (See the Licensing Costs section below for detailed numbers.) Even with these tiered prices, many organizations saw huge cost increases. Gartner analysts found the per-employee model typically 2× to 5× more expensive than the legacy model for the same usage. In one hypothetical example, a company with 49,500 employees and extensive Java usage would have paid about $1.64M/year under the old model versus $3.12M under the new model – a roughly 90% cost increase.
- Existing Contracts and Renewals: Oracle has stated it will honor existing Java SE subscription contracts (based on NUP/Processor) until they expire. If an organization signed a 3-year Java subscription in 2021 or 2022, they can continue using the old metrics until renewal. However, at renewal time, Oracle’s sales teams strongly encourage – some would say pressure – customers to switch to the new employee-based model. In many cases, Oracle will refuse to renew under the old terms or will quote an exorbitant price for legacy licenses to push you to the new scheme. By 2023, Oracle will have stopped offering new licenses under the old metrics for Java. If you want Java support going forward, you’ll opt into the Universal Subscription. Companies with legacy deals must be prepared for this transition and budget accordingly. Oracle’s aggressive stance has led some organizations to explore alternatives (such as OpenJDK builds from other vendors) rather than pay for an enterprise-wide subscription.
Read about the Oracle Java Licensing Changes 2019.
Oracle Java Licensing Agreements and Terms to Review
Oracle Java licensing isn’t just about metrics; it’s also about which license agreement applies to your Java usage.
Over time, Oracle has used different license agreements for Java SE, and customers should review these terms to understand their rights and restrictions. Key Java licensing agreements/terms include:
- Oracle Binary Code License (BCL) for Java: This was the traditional license that accompanied Oracle (and formerly Sun) JDK and JRE downloads up through Java 8 (before 2019). The BCL allowed the Java software to be used royalty-free in general, including commercial use, until Oracle ended public updates. However, any Java use in production under BCL still technically required compliance with the license, and after public updates ceased, Oracle expected users to either stop updating or move to a paid support model. Notably, starting with Java 8 update 211 (released April 2019), Oracle changed the download terms away from BCL. Under BCL, if you downloaded Java SE 8 before 2019, that installation was under the old terms (free to use). But if you downloaded a later Java 8 update in 2020, that download was under a different agreement (the OTN license, see below),, which is not free for production. In short, the BCL era ended in 2019 when Oracle stopped providing free commercial updates. What to review: If your organization still runs older Java versions, check which update level and license you have. Java SE 8 installations obtained pre-2019 might have been legally usable under BCL without a subscription, whereas newer builds require a subscription. Also, the BCL had clauses (like no unauthorized distribution, no reverse engineering) that are moot if you’ve moved on. However, be aware that other agreements might apply if you redistribute Java in any way.
- Oracle Technology Network (OTN) License for Java SE: Oracle introduced the OTN License for Java SE for Java 8 updates released after January 2019 and for Oracle JDK 11 (2018) downloads. This license explicitly forbids commercial use of Oracle JDK in production without a paid subscription. The OTN license allows the software to be used freely for development, testing, prototyping, and personal use, but using it “for internal business operations” (production use) is prohibited without a license/subscription. In effect, Oracle turned the free Java downloads into a trial – you could try Java 11 or late-update Java 8 for free, but if you deploy it in production for your business, you need to pay. What to review: If you have Oracle JDK 8 Update >211 or Oracle JDK 11 in use, did you accept the OTN License? If so, are you using it beyond the permitted scope? Unless you only use it for development or personal use, you likely need a commercial Java SE subscription. The OTN agreement does allow unlimited non-production use, which some companies leverage for dev/test environments while using OpenJDK or older versions in prod to avoid fees – but that carries risk if any production use slips through.
- No-Fee Terms and Conditions (NFTC): This is the license Oracle announced for Java 17 and later (starting in 2021). The NFTC license made Oracle JDK free for anyone, including commercial use, but only for a defined period. Under NFTC, you can use the current LTS release (e.g., Java 17 and, similarly, Java 21) in production without paying until its free support period ends. The catch is that once Oracle releases the next LTS + one year, the older LTS falls out of the no-fee terms. For example, Oracle JDK 17 was free from 2021 through September 2024; after that, no more free updates – continuing to run Java 17 would require buying a subscription or migrating to a newer version. NFTC also prohibits redistributing Oracle’s JDK to third parties (you can use it internally for free, but you can’t bundle Oracle JDK with your product and give it to customers without a separate agreement). What to review: If you are taking advantage of NFTC (using Java 17 or 21 for free), mark your calendar for the end of the free period. Ensure you plan to upgrade to the next version or budget for a subscription when the free window closes. Also, ensure you’re not violating NFTC by distributing Oracle JDK – for example, if you package an Oracle JRE with an internal application for client PCs, technically, that’s not allowed under NFTC or OTN without a distribution license.
- Oracle Java SE Subscription Agreement (Commercial License): This refers to your contract if you purchase Java SE licenses from Oracle. Typically, this is an ordering document under an Oracle Master Agreement or Oracle License and Services Agreement, plus the Java SE Subscription terms. If you purchased Java licenses pre-2023, your contract specifies the Named User Plus and/or Processor licenses and quantities and an annual support cost. If you subscribe after 2023, your contract is for the Java SE Universal Subscription, specifying your employee count and rate. What to review: Customers should review the quantities and terms in their Java order document, the definition of what’s covered, and any special clauses. For legacy subscriptions, note the end date – after which you must renew under the new model (Oracle won’t renew the old one). For new subscriptions, review how “Employee” is defined in your contract (it should match Oracle’s standard definition, including contractors). Also, check if your contract has an audit clause or verification process for employee counts. It’s wise to verify what happens if your employee count grows during the term – do you have to true-up immediately or only at renewal? These details can impact cost if your company is expanding or contracting.
- Java included with other Oracle products: Oracle allows certain uses of Java without a separate Java SE license when it is provided as part of another Oracle product. For example, Oracle Database and Oracle WebLogic Server (and many other Oracle products) include a Java Runtime Environment for their operation. Oracle’s policy is that if you are using Java solely to run an Oracle product you have licensed, you do not need a separate Java SE subscription. In other words, the right to use Java is included in the license for that Oracle product. However, this exception is narrow – it covers using Java only for that product if you use the same Java installation for any custom or third-party apps or install Java separately on a server that also runs Oracle software, that separate use is not covered. What to review: Inventory where Oracle JDK is installed and why. Suppose it’s installed solely because an Oracle application (like Oracle E-Business Suite, WebLogic, PeopleSoft, etc.) requires it, and it’s only used for that application. In that case, you might be okay with that. However, if administrators or other software on that machine use Java outside the Oracle app’s scope, that’s a gray area. It’s best to segregate those uses or get clarification from Oracle. Also, be cautious with third-party enterprise software that may have bundled Oracle’s Java – some vendors had redistribution rights for Oracle JRE for use with their products. Using that JRE for anything else or updating it beyond what the vendor supplies could be non-compliant.
- Java SE Advanced and other legacy Java offerings: Before subscriptions, Oracle offered perpetual licenses like Java SE Advanced, Java SE Advanced Desktop, and Java SE Suite, which provided access to commercial features (Flight Recorder, etc.) and support. A few organizations might still have these legacy licenses with active support contracts. What to review: If your company previously bought Java SE Advanced or similar, confirm what rights those licenses convey (they might cover certain versions or features without needing a subscription). Oracle has likely attempted to transition these to the subscription model as well. Ensure you understand if those licenses are still valid and if you’re entitled to upgrades or need to convert to a subscription.
In summary, identify which license terms govern each Java deployment in your organization. Many companies have a mix – e.g., some Java 8 installations that require a subscription, some Java 17 installations under NFTC, etc. It’s critical to reconcile these with Oracle’s policies.
For instance, Oracle JDK 8 downloaded in 2018 (under BCL) could be used legally back then, but if you kept using it into 2023 and applied security patches, you likely needed a subscription.
As one example illustrates, Oracle JDK 8 update 202 (Jan 2019) was the last free public update; Oracle JDK 8 update 261 (July 2020) was under the OTN license and not free for production. Similarly, Oracle JDK 17 in 2022 was under NFTC (free for the time being), but an update to Java 17 released after the free period (late 2024) would fall under a paid requirement (OTN or similar)
. Such nuances mean you should audit your Java installations and the terms under which they were obtained. Being clear will inform you whether you must purchase Oracle Java licenses or if some uses are still legitimately free or covered.
Lastly, Oracle also provides an open-source OpenJDK distribution for each Java version, under the GPL open-source license. These OpenJDK builds are functionally equivalent to Oracle JDK in most respects.
If you use OpenJDK (from Oracle or another provider) in production, you have no Oracle licensing obligation (it’s free, with no support from Oracle). Many organizations have transitioned to OpenJDK or vendor-supported builds (Amazon Corretto, Azul Zulu, etc.) to avoid Oracle’s fees.
However, ensure that your systems truly use those and do not accidentally download an Oracle JDK, which could create compliance issues. In any case, understanding the licensing agreement for each Java instance is a necessary step for compliance.
Oracle Java Audit Triggers, Process, and Risk Areas
Oracle has become very proactive in auditing organizations to ensure compliance with Java usage.
Knowing what triggers a Java audit, how the audit process works, and common risk areas can help you avoid or prepare for an audit. Below, we outline major audit triggers and risks:
1. Java Download and Update Activity: Oracle closely monitors Java downloads from its websites and update servers. It maintains detailed logs (reportedly up to seven years) of which companies (via IP ranges, Oracle login accounts, etc.) have downloaded Java installers or patches.
Why this matters: Downloading Oracle JDK updates—especially security patches for older versions—can signal that you are using Java in production, potentially without a license. For instance, if your IT staff continually downloaded Java 8 update patches from Oracle after 2019 without a subscription, Oracle’s records could flag this.
This is a common trigger for Oracle when sending an inquiry. If the download logs suggest you obtained patches or software that normally requires a support contract, Oracle may reach out to check your licensing. Risk mitigation: Centralize and track Java downloads in your organization. If you don’t have a Java subscription, avoid downloading Oracle JDK binaries (use open-source builds instead) to avoid leaving a trail.
Keep evidence if you only downloaded for evaluation or testing, not for production, in case you need to explain. Oracle’s audit letters often reference, “Our records show you downloaded X – please confirm your licensing.”
2. Legacy Java SE License Holders (Pre-2023 Contracts): Organizations that purchased Java SE subscriptions or perpetual licenses before 2023 are transitional. Oracle no longer renews the old Java SE licenses and wants these customers to use the new model.
Why this matters: Oracle often initiates a “soft audit” or license review as these legacy agreements are renewed. They will check if you comply with your existing license limits (e.g., did you deploy Java on more servers than you licensed?) and at the same time push you to migrate to the subscription model.
Essentially, Oracle leverages this moment to find any compliance gap and use it as pressure to upsell. Risk mitigation: If you have older Java licenses, perform an internal audit before Oracle does. Ensure you know where you might be over-deployed.
Also, be prepared that Oracle will likely not extend your old agreement – you’ll need to negotiate a new one (see negotiation section). By being proactive, you can avoid surprises. If Oracle reaches out, engage constructively and show them you have usage data; this can sometimes avoid escalation to a formal audit.
3. Refusal to Engage / Formal Audit Escalation: Oracle typically begins compliance checks with informal outreach (often an email from their License Management Services or a salesperson claiming “we’d like to discuss your Java usage”). Oracle may trigger a formal contract audit if a company ignores or refuses these inquiries. Under Oracle’s standard license agreements, they have the right to audit your use of their software. Why this matters: Oracle sees a lack of cooperation as a red flag.
Suppose you don’t respond to a Java licensing inquiry or decline to participate in a review. In that case, Oracle’s next step may be to send an official audit notice (under the audit clause in your Oracle Master Agreement).
A formal audit is much more invasive and time-consuming – it could involve Oracle or a third-party auditor collecting data from your systems, and it often uncovers more than the initial inquiry would. Risk mitigation: Generally, responding professionally to Oracle’s soft audits is advisable.
You can buy time or clarify your position without immediately admitting non-compliance. If you suspect an audit is likely, consult with licensing experts or legal counsel early. Make sure you have documentation of your Java usage and entitlements ready.
Being combative without preparation can backfire. You may not avoid an audit entirely, but showing Oracle that you take compliance seriously can sometimes keep the process in a “discussion” mode rather than an adversarial audit.
4. Minimal Oracle Footprint (Easy Targets): Oracle often targets organizations that are not large Oracle customers otherwise – for example, companies that don’t use Oracle databases or applications but do use Java. These firms may have less experience with Oracle licensing and fewer existing contracts.
Why this matters: Oracle perceives such organizations as potentially less informed about license compliance and, thus, more likely to be out of compliance with Java. They are also not risking a huge customer relationship by enforcing on Java, since the company isn’t buying much else from Oracle. This makes them “easy pickings” for a Java audit. Risk mitigation: Even if Java is your only Oracle product, treat it with the same compliance rigor as an Oracle database.
Do a software inventory to know where Oracle Java is used (indirectly via third-party apps).
Educate your IT teams about the basics of Oracle’s Java licensing rules. Sometimes, companies using mostly open-source software may accidentally have an Oracle JRE on some machines – find these before Oracle does. Proactively removing or replacing Oracle JDK in environments where it isn’t needed can reduce your exposure.
5. No Oracle Cloud Usage (Leverage for Cloud Sales): Oracle’s strategy heavily focuses on getting customers into Oracle Cloud Infrastructure (OCI) and Oracle Cloud apps. Oracle has been known to use license audits as a lever to drive cloud adoption. Why this matters: If your organization has no Oracle cloud services and runs everything on-prem or in other clouds, Oracle might see an audit as an opportunity to “encourage” cloud migration as part of any settlement or resolution.
In some cases, Oracle may waive certain Java licensing fees or penalties if the customer agrees to start using Oracle Cloud services. This isn’t a direct trigger like download logs, but it’s a factor in Oracle’s targeting – Oracle prioritizes audits where they see an upside in cloud or additional sales. Risk mitigation: Be aware of this tactic.
It might be worth evaluating Oracle’s cloud offerings on their technical and financial merits so you’re prepared if Oracle raises it. But don’t feel forced – you can negotiate Java compliance separately from any cloud discussion. If Oracle pushes OCI as a “solution” in an audit, ensure you negotiate favorable terms and only adopt them if they make sense to your business. Otherwise, you might just opt to pay for Java and keep your independence when choosing cloud providers.
Audit Process: Oracle Java audits often start with what some call a “soft audit” – an unsolicited email or phone call from Oracle’s compliance or sales team, referencing Java downloads or license status and offering to “assist” in reviewing your usage.
They may ask you to fill out a spreadsheet about how many instances of Java you have or even run Oracle’s Java usage script. If issues are found or if you don’t cooperate, it can escalate to a formal audit per your contract’s audit clause. In a formal audit, Oracle will typically send an official notice and may deploy audit scripts/tools to gather data on all installations of Oracle Java.
They will look for evidence of installed Oracle JDK/JRE versions, usage of commercial features, and so on. One data point they may request is the output from the java -XshowSettings:properties command on systems, which can identify if it’s an Oracle build and the version. They will compare this against your entitlements (if any). Oracle usually presents a bill for back support fees and subscriptions if unlicensed usage is found. For example, suppose you’ve been using Oracle Java for 2 years without a license.
In that case, Oracle might ask you to pay 2 years of back subscriptions (even though you never had a contract – this would effectively buy retroactive coverage) and commit to a subscription in the future. This is a negotiation point (it’s not automatic that you must pay back costs, but Oracle will push for it). The risk of non-compliance can be very costly if you suddenly have to license every deployment retroactively.
Therefore, preparing for an audit is essential: maintain records of where and how Java is used, keep proof if you’re using OpenJDK or other non-Oracle distributions (so you can show that to Oracle if needed), and have a clear policy internally for Java usage.
Gartner has predicted that by 2026, one in five organizations using Java will be audited by Oracle, leading to unbudgeted costs for many. This high chance of audit, combined with the broad new licensing model, makes Java a compliance topic that cannot be ignored.
Negotiation Strategies for Oracle Java Subscription Deals
If your organization decides to purchase Oracle Java licensing (or to renew under the new model), it’s important to approach the negotiation strategically.
Oracle’s initial quotes for Java (especially under the per-employee model) can be high, but there is often room to negotiate better terms.
Here are key strategies to consider when negotiating an Oracle Java subscription deal:
- Inventory and Optimize Your Java Usage First: Before engaging Oracle in negotiations, know your Java usage inside and out. Determine how many servers, applications, and users truly require Oracle’s Java. You may find that many workloads can be migrated to OpenJDK or already use open-source Java, reducing the scope of what you need to license. This data is your leverage – if Oracle quotes a price for all employees, but you know only 10% of them use Java, you can push back or consider alternatives. Knowing your usage also prevents over-buying “just in case.” It might be possible to reduce Java usage in certain areas (e.g. uninstall Oracle JRE from PCs that don’t need it) before committing to a subscription. Essentially, right-size your needs: the smaller the footprint, the better position you are in to negotiate or even avoid a deal. (Real-world example: One company discovered that many internal apps could run on OpenJDK with minimal testing, allowing them to cut the number of Oracle Java licenses by half before negotiations.)
- Leverage Multi-Year Commitments for Discounts: Oracle’s Java price list has standard volume discounts. However, you can often negotiate additional discounts by committing to a multi-year term or larger upfront purchase. Oracle sales reps are often willing to reduce the price per employee if you sign a 2- or 3-year deal upfront. A longer commitment is attractive to Oracle (guaranteed revenue), so in return insist on better pricing. For example, negotiate a 3-year subscription with an X% discount off the list, or lock in the current rate for 3 years to avoid annual increases. Always get any multi-year pricing or caps in the contract or ordering document.
- Take Advantage of Volume/Tier Negotiation: Oracle’s employee-based pricing has published tiers (as noted earlier, e.g., $15 down to $5.25 at certain thresholds). If you are near a tier boundary or well within a high tier, negotiate for a price corresponding to the next tier. For instance, if you have 3,500 employees ($10.50/emp/month list), push Oracle to give you the 10k employee tier price ($8.25) or something closer to it, arguing that your count might grow or simply as a discount. Oracle can sell at any price they agree to – those tiers are baseline. Also, if you have more than 50,000 employees (or close to it), negotiate since the price list stops at 49,999. Beyond that, it’s custom – Oracle will expect to negotiate a custom deal for very large enterprises.
- Bundle Java into Larger Deals: If possible, align your Java subscription negotiation with other Oracle negotiations. Oracle is more flexible on Java pricing if it’s part of a broader package or if the customer is making other strategic purchases (database, cloud services, applications, etc.). For example, if you’re also renewing an Oracle Database agreement or considering Oracle Cloud, use that as leverage: “We might move our databases to Oracle Cloud, but we need a better Java price.” Oracle may offer concessions on Java to secure other business. Even if not, being a bigger customer can improve your negotiation position. Conversely, if Java is the only thing you buy from Oracle, try to find any leverage, such as referencing competitive solutions (see next point).
- Consider Third-Party Java Alternatives (and let Oracle know): A powerful negotiating chip is that you have alternatives to paying Oracle for Java. Free and supported Java distributions are available (OpenJDK from various sources or third-party support vendors like Azul, IBM, Amazon Corretto, etc.). Many organizations are migrating to these to avoid Oracle’s new fees. If Oracle’s offer is too high, be willing to walk away and use an alternative – and let Oracle know you’re evaluating that. This often motivates Oracle to return with a lower price or a special discount to keep you. For example, mention that you are piloting a move to OpenJDK or another JDK vendor, eliminating the need for Oracle Java subscriptions unless Oracle can make its pricing compelling. Even if you ultimately prefer Oracle’s support, showing that you have a plan B prevents them from feeling they have monopoly power over you.
- Scope and Definition Negotiation: Carefully negotiate who counts as an “Employee” in your context. Oracle’s standard definition is very broad, but in some cases, large enterprises have negotiated exclusions. For instance, you may exclude employees of a recently acquired subsidiary for some time or contractors with zero IT system access. It’s tough – Oracle prefers not to carve out any groups – but if you have a unique situation (e.g., many of your “employees” are factory workers with no computers), try to make a case that they should not count. At the very least, ensure that non-human devices don’t accidentally count. Oracle’s employee definition shouldn’t count devices, but their old “NUP” sometimes counted non-human-operated devices as named users. Clarify that the employee count is just people, not service accounts or IoT devices. If you have many part-time or seasonal workers, see if Oracle will agree to count Full-Time Equivalents (FTEs) instead of raw headcount. However, there’s no indication they normally do that – but in negotiation, everything is on the table if the deal is big enough.
- Include Favorable Renewal Terms: Whatever you agree to now, protect yourself for the future. Try to include a cap on price increases for renewals (e.g., the renewal rate will not increase more than X% per year). Oracle subscriptions typically renew at the same price annually, but if you negotiated a special discount in the initial term, clarify whether that carries forward. If your employee count might drop, ask about true-down possibilities (Oracle contracts usually don’t allow reducing counts until renewal, but at renewal, you should be able to quote a new count). Negotiate flexibility to adjust the employee count annually if possible, so you’re not overpaying for employees you no longer have.
- Seek a Java ULA (Unlimited License Agreement) if Appropriate: In some cases, Oracle might offer a custom Java ULA – a fixed-price, unlimited-use agreement for a period (say, 2-3 years), after which you either certify usage or renew. Oracle has ULAs for database and other products; for Java, an employee-based model is already essentially unlimited, but a ULA could potentially be negotiated for a large enterprise that wants a cap on cost. If you have, say, 100,000+ employees or a very dynamic environment, a ULA might simplify things, though you’d need to ensure you define it to include future versions, etc. This is an advanced negotiation route and should be considered with expert help, but it’s worth mentioning if your scale is huge.
- Don’t Forget Support and SLAs: When buying an Oracle Java subscription, you primarily pay for the right to updates and support. Ensure you know what support response you’re entitled to (Oracle’s Java support is usually standard 24×7 for critical issues, etc., per their support policies). If Java is critical to you, consider negotiating a designated support contact or an escalation path as part of the deal (sometimes, large customers can get a named support manager). While Oracle may not budge on standard support terms, you can at least clarify them. Also, confirm if the subscription covers all versions (it should – one subscription lets you use Java 8, 11, 17, etc., as needed) and any special cases (e.g., does it cover Java on development machines as well – typically, yes, it’s all use).
Overall, treat the Java subscription like any major software agreement—there’s usually room to negotiate price and terms, especially given the market’s backlash against Oracle’s changes.
Oracle’s sales team has quotas for Java now, and they’ve been known to send “offers” to customers to start the conversation (sometimes even hinting at an upcoming audit to create urgency). Use that to your advantage by coming prepared.
And if Oracle isn’t reasonable, remember that you can invest those funds into migrating to a non-Oracle Java solution as an alternative – which might be even more cost-effective in the long run. Many companies are doing the cost-benefit analysis of paying Oracle versus switching, and that dynamic can lead to better deals or strategic decisions beyond just the negotiation table.
Oracle Java Commercial Features and License Requirements
In addition to the base Java runtime, Oracle historically offered “Java SE Advanced” features—often called commercial ones—that require licensing. It’s important to know these because using them without the proper license could trigger non-compliance.
Some of the key Java commercial features have included:
- Java Flight Recorder (JFR): A powerful tool integrated into the JVM for low-overhead profiling and diagnostics. JFR allows the recording of JVM events (CPU, memory, thread info, etc.) to troubleshoot performance issues. License requirement: In Oracle JDK 8 and Oracle JDK 11, JFR was considered a commercial feature – using it in production required a Java SE Advanced license or Java SE Subscription. Oracle even had a built-in check – to enable JFR, you had to unlock commercial features with a JVM flag accepting that you need a license. In short, JFR was not free to use in production on Oracle JDK. (Note: In OpenJDK, JFR was open-sourced later, so OpenJDK 11+ allowed JFR without fee. But Oracle’s official builds require a license until they open-source it.) There is a compliance gap if you used JFR on Oracle’s Java without paying. Under the new model, if you are subscribed enterprise-wide, you inherently have rights to JFR. But if you’re trying to avoid subscribing and just use the latest free JDK, you should be careful not to use JFR unless you move to an OpenJDK build that permits it.
- Java Mission Control (JMC): A GUI tool suite for monitoring and managing JVMs, and for analyzing Flight Recorder data. JMC enables detailed analysis of JFR recordings and live JVM metrics, which are useful for performance tuning. License requirement: JMC was bundled with Oracle JDK but required a commercial license for use in production when connecting to running applications. Using JMC to manage or observe a production JVM counted as using a commercial feature. (Using it on development was fine without a license.) As with JFR, Oracle later open-sourced JMC (now available as an open-source project). However, you need Java SE Advanced or an equivalent if you use Oracle’s JMC with Oracle JDK on production systems. Under the current Universal Subscription, JMC usage is allowed if you have the subscription (since it covers all Java features). But if you rely on free Oracle Java (NFTC), note that NFTC did not grant rights to commercial features – those features still need a subscription. So a company might think, “Java 17 is free under NFTC, let’s use JFR for debugging” – that would break the terms since free use didn’t extend to commercial add-ons.
- Advanced Management Console (AMC): A management tool Oracle provided to enterprises to track and control Java usage on desktops (it can inventory Java versions, manage deployment rules, etc.). AMC was part of the Java SE Advanced Desktop product. License requirement: Using AMC required a Java SE Advanced Desktop license (a paid license). You must be licensed if your organization installed AMC to help manage Java. Under the new model, AMC isn’t separately charged – if you have the Universal Subscription, you can use AMC. But without a subscription, using AMC to manage Java installations would not be allowed under the free license.
- Java SE Suite / JRockit Real-Time: Oracle (and BEA before acquisition) had specialized JVM features like JRockit Mission Control, JRockit Flight Recorder, and a Real-Time JVM for low-latency applications. These were packaged in high-end offerings (Java SE Suite). License requirement: These required purchasing the appropriate licenses. They’re legacy now (Oracle has unified on the HotSpot JVM with JFR/JMC), but if you happen to be running any legacy JRockit features, be aware those were commercial.
- Server-Side Java Deployment Features: Oracle’s commercial offerings also included things like Java Usage Tracker (which logs when and where the JRE is used on a system – ironically, Oracle required a license to use their tracking tool), and the MSI Enterprise JRE Installer for Windows (an MSI package to ease mass deployment of the JRE). These were conveniences for enterprise admins but were only available with a paid license. If you used the Oracle-provided MSI installer to roll out Java to 1,000 PCs, technically you needed a Java SE Advanced Desktop license for those, even if the JRE itself was free – because using the enterprise installer was a licensed feature.
Knowing what requires a license: Oracle has documented which features are considered “Commercial Features” in Java SE. A rule of thumb: anything beyond the core JVM and standard library for advanced monitoring/management is likely not free.
Oracle’s documentation explicitly stated: “Java Flight Recorder and Java Mission Control are commercial features and require a license for use in production.”. If your team enabled those or AMC, Oracle can penalize that usage in an audit.
Under the current Employee-based subscription model, if you subscribe, you automatically have rights to all those features across your enterprise (since the subscription also covers Java SE Advanced capabilities).
However, note an interesting implication: Under the new rules, if only a small team in your org needs JFR or JMC, you’d still have to license the entire company to allow that usage. For example, say an ops team of five people wants to use JFR to diagnose production performance issues on one application—in the old days, you could have bought a couple of Java SE Advanced per-processor licenses just for that system.
Oracle’s position is that you’d need the full Java SE Universal Subscription (all employees) to be properly licensed. This is one reason some companies choose to use OpenJDK alternatives where JFR/JMC are free, rather than pay Oracle just for a small need.
Practical example: Imagine a production outage during which an engineer turns on Java Flight Recorder on an Oracle JDK 8 system to collect data. If the company had no Java license, this action technically puts it out of compliance.
Oracle could claim they owe for Java SE Advanced licenses for that server (or now, a whole subscription). While Oracle might not find out unless an audit occurs, it’s a risk. Many companies weren’t even aware of these distinctions.
In 2025, Oracle can ask during audits, “Have you ever used Flight Recorder or Mission Control?” The honest answer, “Yes, occasionally for troubleshooting,” could lead to compliance issues. Therefore, it’s advisable to standardize on non-Oracle JDKs for such tools or ensure you’re licensed.
In summary, if you use any of the above features and are not fully licensed, address it. Either cease usage or acquire the proper Oracle subscription to cover it. Often, simply using OpenJDK builds (which have JFR and JMC open-sourced in newer versions) can sidestep the issue entirely.
The key is awareness: These tools are extremely useful but have a licensing obligation in Oracle’s ecosystem.
Oracle Java Licensing Costs: Legacy vs. Current Models
Understanding the cost implications of Oracle’s Java licensing is critical for budgeting and decision-making.
Here, we compare the legacy model costs to the current model, with examples:
Legacy Model Costs (Pre-2023): Under the old Java SE Subscription, you could buy licenses per user or processor. Oracle’s list prices were roughly $30 per Named User Plus per year (about $2.50/user/month) and $300 per processor per year (about $25/processor/month). These prices might have been discounted in enterprise agreements but serve as a baseline.
There was also a minimum of 25 NUP per processor for server deployments, meaning the cost for a lightly-used server had a floor of $750/year (25 × $30).
- Example 1 (Legacy): A small company runs a Java-based internal web application on a server with 4 CPU cores (2 Oracle processors after core factor) and has 20 employees who use a Java client application on their PCs. They could license 2 processor licenses for the server and 20 named user plus client licenses. Annual cost (list) = 2 × $300 + 20 × $30 = $600 + $600 = $1,200/year. This would cover that specific usage scope. If they later retire that Java app, they could choose not to renew those licenses, reducing cost.
- Example 2 (Legacy): A large enterprise with heavy Java usage – say 5,000 employees use Java in some form and have 100 Java application servers (with 200 processor licenses after core factoring). If they licensed everyone and everything under the old model, that’s 5,000 NUP and 200 Processors. Annual cost = 5,000 × $30 + 200 × $300 = $150,000 + $60,000 = $210,000/year (list). In practice, many such enterprises might not have licensed every employee – they may have only licensed 1,000 NUP for specific users and 150 processors for key servers if not all Java usage was caught or considered. The legacy model is scaled with actual usage, and companies could limit the scope of managing spend.
Current Employee Model Costs (2023 onward): Oracle’s Java SE Universal Subscription is priced per employee monthly, with tiered pricing as the employee count grows.
As of 2023, Oracle’s public price tiers are:
- 1–999 employees: $15 per employee per month
- 1,000–2,999: $12 per emp/month
- 3,000–9,999: $10.50 per emp/month
- 10,000–19,999: $8.25 per emp/month
- 20,000–29,999: $6.75 per emp/month
- 30,000–39,999: $5.70 per emp/month
- 40,000–49,999: $5.25 per emp/month
- 50,000 or more: contact Oracle (likely <$5 at this scale)
These are list prices. Oracle often applies additional discounts in real deals, which makes sense.
The cost is calculated on the total number of employees (as defined) at the time of contracting. That number is multiplied by the per-month rate and by 12 for an annual cost.
- Example 1 (Employee Model): Consider the small company from earlier (20 employees using Java out of 100 total employees and one 4-core server). Under the new rule, if they have 100 employees total, they must pay for 100. At 100 employees, that’s in the 1–999 tier, so $15/emp/month. Annual cost = 100 × $15 × 12 = $18,000 per year. This is drastically higher than the $1,200 it would have cost under the legacy model to cover just the 20 users and one server. They are paying for 100 users even though only 20 use Java – a classic “shelfware” situation. Many small and mid-sized businesses face this kind of spike, leading them to question whether they should continue using Oracle’s Java.
- Example 2 (Employee Model): The large enterprise example (5,000 employees used Java, 100 servers) – but note, the new model cares about all employees, not just 5,000. Suppose the company has 50,000 employees globally (a big company, where 5,000 was the subset using Java previously). Under the new scheme, they’d likely have to count all 50,000. At 50,000, it falls in the highest published tier, but they likely negotiate a bit lower than $5.25 – however, using a list for illustration: 50,000 × $5.25 × 12 = $3.15 million per year. Even if they get a discount of $5 or $4 per employee, it’s still $2.4M annually at $4.8 (just an example). Compare this to the $210,000/year we calculated under the old model for their actual usage. This is why Gartner observed 2–5x cost increases and, in some cases, far more. In one hypothetical given by Gartner: 49,500 employees on the new model cost about $3.12M vs. $1.64M on the old – roughly a 90% increase. The exact multiple depends on how much of the workforce uses Java. If only a small fraction of people have used it before, the increase is huge when you must license everyone.
- Example 3: A realistic medium scenario: A company with 2,309 employees (including full-time, part-time, contractors counted as per Oracle) – as illustrated by one analysis – would fall in the 1,000–2,999 tier at $12 per emp/month. That works out to $332,496 per year (2,309 × $12 × 12). If that company previously only needed, say, 200 NUP licenses and 10 processor licenses for their Java usage, the old cost would have been around $ (200×30 + 10×300) = $6,000 + $3,000 = $9,000/year. $9k vs $332k is an extreme case (only ~9% of employees used Java before), but it shows how the math can change.
Such cost differences are driving many organizations to rethink their Java strategy. Paying for every employee makes sense if Java is truly a ubiquitous internal platform (like an OS), but for many, it is not – it’s an important but not universal technology.
Current Cost Benefits: Are there any cheaper scenarios for the new model? Yes, if previously, you needed to license a majority of users or a very large number of processors, the employee model can potentially cap your costs.
For example, an unlimited model might save money if a company runs Java on thousands of servers and every employee’s machine. Imagine a company that would have needed 1,000 processor licenses and 20,000 NUP under the old model – at list, that’s $300k + $600k = $900k/year. Under the new model with 20,000 employees would be 20,000 × $6.75 × 12 = $1.62M/year (list).
That’s more, not less, so maybe not a saving there. You might need an even more extreme case (like near 50k processors to use up the cap). Oracle mentioned that the subscription covers up to 50k processors – effectively an unlimited license – which is not a limiting factor for most. So really, the cost benefit is rarely in favor of the new model except for simplicity or cases where compliance was so poor that they would have had to license almost everyone anyway under audit.
Budgeting and Examples Summary: The legacy model allowed fine-tuning costs to actual usage; the new model shifts to a fixed cost based on organization size. The employee subscription is often an order-of-magnitude increase for selective Java users.
Companies must weigh that cost against the risk/cost of alternatives (like migrating to OpenJDK or not getting support). Some have negotiated transitional discounts or multi-year deals to mitigate the impact.
One final note: Oracle’s Java subscription is a subscription – if you stop paying, you lose the right to updates and support in the future (and arguably lose the right to use Oracle Java in production, though for perpetual licenses that was a gray area, for subscriptions it’s clear you are not permanently entitled, it’s like renting).
Under the legacy model, some companies bought perpetual Java SE licenses (Oracle used to sell them, typically with 22% annual support).
Those were given the right to use Java indefinitely at a time, with optional support renewal. Oracle doesn’t advertise that now; it’s all subscription. So if you pay millions for Java for a few years and then decide to stop, you’re technically unlicensed for future use of Oracle Java.
This makes the decision strategic: many opt to put that money into an open-source strategy instead, which has a one-time migration cost but no ongoing per-employee fees.
Conclusion: Navigating Java Licensing Strategically
Oracle Java remains a critical platform for many enterprises, but Oracle’s licensing changes have turned it into a significant compliance and cost concern. Approach Oracle Java licensing strategically:
Stay informed on Oracle’s policies—they can change (as seen with NFTC and new metrics). Audit your Java usage internally to determine what needs licensing and what can be optimized.
Consider your options: Oracle’s Java SE Subscription (now employee-based) assures support and updates but at a steep cost for many; meanwhile, third-party JDKs or open-source routes can provide relief if used correctly (with some trade-offs, like needing to manage updates from another source).
If you engage with Oracle, do so from a position of knowledge: understand your contract terms, enforce your rights, and negotiate assertively. Always evaluate the cost-benefit – for some, paying Oracle for Java support is worth the convenience and risk avoidance; for others, the cost is unjustifiable, and migrating away is the prudent path.
Read more about Oracle Java licensing changes in 2024.
