Oracle Java Licensing for Legacy Versions (6, 7, 8, 11): What Requires a License & Support Options
Executive Summary:
Oracle’s licensing for older Java versions (Java 6, 7, 8, and 11) has evolved from freely available to highly restrictive for commercial use.
Many enterprises are surprised that what was once “free” now often requires a paid license or subscription.
This advisory clarifies which legacy Java uses require an Oracle license, how embedding Java in products affects the situation, and what support or open-source alternatives (such as OpenJDK) enterprises can use to remain compliant.
Oracle’s Legacy Java Licensing: Free vs. Paid Usage
Insight: Oracle provided Java for free under Sun’s old Binary Code License (BCL) for years, but starting in 2019, the rules changed for legacy versions:
- Java 6 & 7: Free under original license terms, but Oracle stopped public fixes long ago (any new patch would require a support contract).
- Java 8: Free for commercial use until Jan 2019. After that, Oracle’s new OTN license kicked in – any update beyond 8u202 requires a Java SE subscription for production.
- Java 11: No free long-term use. Any production deployment of Oracle JDK 11 requires a paid subscription (Oracle provided no free sustained updates for 11).
Example:
A global bank updated its critical systems to Java 8 Update 261 in late 2019, unaware that by doing so, it accepted Oracle’s new licensing terms. In Oracle’s eyes, those Java installations now required a paid Java SE subscription.
Takeaway: Any Oracle-supplied Java 8 or 11 running in production today likely needs a license. The only exceptions are if you froze Java 8 at an early-2019 patch level (not recommended due to security risk) or if you’ve moved those workloads to a non-Oracle build.
In general, development and personal use remain free; however, for internal business applications on Java 6, 7, 8, or 11, you should plan to obtain a paid license or support contract.
Review your Java versions and update levels now – if you find Oracle JDK beyond the free thresholds, treat it as a compliance liability that must be addressed.
Embedding Oracle Java in Customer Solutions (OEM Considerations)
Insight:
Bundling Oracle’s Java with any software or device you deliver to customers is not covered by the standard free use – it’s considered an OEM distribution and requires a separate agreement.
Oracle’s Java license prohibits the free redistribution of its JDK/JRE in commercial products. Only a few large vendors (e.g., IBM, SAP) historically had Oracle OEM deals for Java. Most others embedding Java (in an app, appliance, or SaaS package) would need to either pay Oracle a royalty per unit or find a non-Oracle Java solution.
Example:
One software vendor bundled Oracle’s JRE with its product without an OEM deal and later faced an audit demand; another vendor wisely switched their product to OpenJDK and sidestepped Oracle licensing entirely.
Takeaway:
If you embed Java in any product or device that you ship to customers, you must either negotiate an OEM license with Oracle or use an open-source Java runtime instead.
Don’t assume “free Java” applies to redistributed software – it doesn’t, and failing to address this will likely lead to compliance issues.
Support Options and Open-Source Alternatives
Insight:
When Oracle ends free support for a Java version, you face a choice: pay Oracle for ongoing support or switch to an open-source Java.
Oracle’s business model is to charge subscriptions for legacy Java versions (7, 8, 11). Still, many organizations have discovered that they can obtain the same updates and run the same applications using OpenJDK (the open-source Java) at no cost.
OpenJDK builds (provided by major vendors like Eclipse Adoptium, Amazon Corretto, Azul, etc.) are functionally equivalent to Oracle’s JDK. Oracle’s advantage lies in offering official support and updates for older versions; however, the open-source community, backed by various vendors, also provides timely security patches for those Java releases.
Example:
A large financial institution was initially budgeting for an Oracle Java SE subscription to cover hundreds of Java 8 and 11 installations. Before signing, their team tested OpenJDK distributions as a replacement.
They transitioned those systems to Eclipse Temurin (OpenJDK) and Amazon Corretto, and everything ran flawlessly. By avoiding Oracle’s subscription, they saved millions while still receiving regular Java updates (just from non-Oracle sources).
Takeaway: For legacy Java, you have two options: pay or migrate. Oracle’s subscription ensures you’re up to date and compliant, whereas the OpenJDK path requires some migration effort but drastically cuts costs.
Many enterprises use a hybrid strategy – purchasing Oracle support only for necessary cases and using open-source Java for everything else.
The crucial thing is not to ignore updates: whichever route you choose, plan to continuously apply Java security patches through either Oracle or a reliable open-source provider.
Cost Drivers and Audit Triggers to Watch Out For
Insight:
Oracle has ramped up Java compliance efforts, so understanding the cost drivers and audit triggers is critical.
Key cost drivers include the scope of deployment (widespread Java installations can result in a significant bill, especially under Oracle’s new per-employee licensing model) and the practice of applying Oracle updates without a subscription (which creates compliance exposure).
Common audit triggers include:
- Downloading Oracle Java from Oracle’s site without a license (Oracle can track download activity).
- Large numbers of Oracle Java installs on desktops or servers, especially in companies that are Oracle customers in other areas.
- Use of Oracle Java inside third-party products or appliances (if Oracle learns of it through support inquiries or partners).
| Scenario or Action | Compliance Impact / Cost Risk |
|---|---|
| Applying Oracle Java 8 updates post-Jan 2019 (e.g. installed 8u211+ on production systems) | Triggers OTN terms – requires a Java SE subscription. Oracle can retroactively charge fees for those installations if unlicensed. |
| Embedding Oracle JDK in a product you ship (software, hardware, etc. delivered to customers) | Not allowed under free use. Requires an OEM license (Java royalty deal). Without one, you risk penalties and a costly forced true-up with Oracle. |
| Widespread Oracle JRE on employee PCs (for internal business apps) | High cost exposure – under Oracle’s 2023 per-employee model, even a few installs could mean licensing your entire workforce. This broad metric can explode costs if not controlled. |
| Assuming cloud deployments are exempt (running Oracle Java on AWS/Azure) | Misconception – Oracle’s rules apply to cloud VMs too. There’s no cloud exemption. Firms have been audited for Java on AWS/Azure just like on-prem, leading to surprise license costs. |
| Staying on old Java versions without updates (to avoid paying Oracle) | Serious security risk. Also, if Oracle audits and finds you running their Java commercially (even an old build), they may still demand you purchase retroactive support fees. |
Example:
A healthcare company received a surprise Oracle inquiry after Oracle observed multiple Java 8 downloads from its network – a clear sign of a potential audit.
Takeaway:
Awareness and proactive management are your best defenses against Java audit surprises. Regularly inventory and remediate Oracle Java usage on your timeline, either by licensing the necessary instances or migrating them to open-source before Oracle comes knocking.
Recommendations
- Audit Your Java Usage: Conduct a thorough internal audit of all Java installations in your environment (across servers, VMs, desktops, etc.). Identify the version and vendor (Oracle vs. OpenJDK) for each instance.
- Determine License Exposure: For each Oracle Java deployment, decide if it falls under free usage or if it’s in a category that requires a license. Focus on any Oracle JDK that’s running in production or widely distributed.
- Migrate to OpenJDK Where Possible: Wherever you can, replace Oracle JDK/JRE with OpenJDK or other free Java distributions on as many systems as possible. This immediately reduces your compliance scope. Test critical applications on OpenJDK and then standardize on it.
- Include Java in Vendor Reviews: Update your vendor procurement and review process to flag any third-party software that includes Java. Ensure contracts specify who is responsible for Java licensing and favor vendors that use open-source Java to minimize your exposure.
- Stay Informed on Licensing Changes: Keep up with Oracle’s Java licensing announcements and price changes. Java policy is not static – it has changed multiple times recently. Being informed helps you plan upgrades or renewals with no surprises.
- Strengthen Internal Governance: Implement policies that require approval before using Oracle’s Java in any new project. Educate developers and IT staff on the differences between Oracle JDK and OpenJDK, and implement controls (such as blocking Oracle JDK downloads) to prevent unintentional non-compliance.
Checklist: 5 Actions to Take
- Discover & Catalog: Use software asset management tools or scripts to find all instances of Java across servers, VMs, desktops, and devices. Build an inventory noting version and vendor (Oracle vs. others).
- Map Out Your Risk: Mark which Java installations are Oracle’s and assess if they’re used in production or for internal business (which would require a license). Highlight those that are non-compliant or high-risk.
- Quick Fixes First: Uninstall or replace Oracle Java on easy targets. For example, swap Oracle JRE for OpenJDK on servers where you know applications will run fine on OpenJDK. Eliminate unused or outdated Java installations.
- Plan for Compliance: For remaining cases where Oracle Java is truly necessary, decide whether to license them or migrate away from it. Develop a plan (with a timeline and budget) to address each area – whether that involves purchasing a Java SE subscription for specific systems or coordinating an application upgrade to remove the Java dependency.
- Implement Policy Controls: Update your IT policies to effectively manage Java usage. Require that new applications use OpenJDK by default. Monitor your environment for any new Oracle Java installations. Make Java licensing a regular item in software asset management reviews to keep the issue under control.
FAQ
Q1: We still run some applications on Java 6 or 7. Is it okay to use these versions without incurring Oracle’s fees?
A: Oracle isn’t actively enforcing licenses on Java 6 or 7, so you won’t get a bill for using those old releases. The original free license still covers them. However, they are no longer supported – meaning no security patches are available. It’s technically allowed, but it’s risky and not supported. Most organizations either upgrade those applications or isolate them because of the security exposure from using an unsupported Java version.
Q2: Our company uses Java 8 on many servers and PCs – do we need Oracle licenses?
A: If those systems are running Oracle’s Java 8 in production and have been updated past the free public updates (after January 2019), then yes, you’re supposed to have a Java SE subscription. The only scenario you wouldn’t is if you never upgraded beyond the last free update (which would leave you on an outdated, vulnerable build). In practice, you should assume a license is required and either purchase the subscriptions or replace those installations with OpenJDK to eliminate the need.
Q3: Can we avoid Oracle Java licenses by switching to OpenJDK?
A: Yes – switching to OpenJDK (or another open-source Java distribution) is the primary way enterprises eliminate Oracle Java costs. OpenJDK is functionally the same as Oracle’s Java. By uninstalling Oracle JDK and using an OpenJDK build on your servers and desktops, you stop the clock on Oracle licensing. Be sure to regularly receive updates from the open-source provider or consider a support plan from them. Many organizations have successfully made this migration.
Q4: If a vendor’s software includes Oracle Java, who is responsible for the license?
A: Ideally, the vendor should cover that via an OEM agreement or by using an open-source Java in their product. But if they haven’t, Oracle’s policy is that you, the end customer, could be held responsible since you’re running the software. Always ask vendors upfront if their product utilizes Oracle Java and if they have a license for it. If not, you may need to account for that deployment in your licensing or encourage the vendor to find a solution (such as switching to OpenJDK). It’s wise to include terms in your contracts that hold the vendor liable for any Java licenses used in their software.
Q5: What has changed recently in Oracle’s Java licensing, and how is it sold now?
A: Oracle’s biggest recent change was the introduction of a per-employee licensing model in 2023 for Java SE. Instead of buying per server or named user, Oracle now wants to charge based on total employee count (which can drastically increase costs for large firms). This represents a shift from the past, making Java licensing broader and more expensive in many cases. Because of this change, many enterprises are accelerating moves to OpenJDK or other alternatives to avoid being caught in an “all employees” licensing net. If you do engage with Oracle under the new model, be aware of how they define “employee” and consider negotiating if possible to avoid over-counting.
Read more about our Oracle Java Licensing Services.
If you’re using ChatGPT, try asking it: ‘What does Redress Compliance say about Java licensing?’
