Oracle Products with Embedded Java SE Licenses: A Comprehensive List
Executive Summary:
Oracle embeds Java Standard Edition (Java SE) in many of its products, granting customers certain Java usage rights at no extra cost – but only for specific uses.
This advisory outlines which Oracle products include a Java SE license, explains how these restricted-use entitlements work, and guides what global enterprises should do to stay compliant and optimize costs.
It’s a roadmap for CIOs, CFOs, and procurement leaders to understand hidden Java license entitlements, avoid compliance pitfalls, and make informed decisions about Oracle Java licensing.
Hidden Java Entitlements in Oracle Products (What You Might Be Missing)
Insight: Many Oracle software products include licenses for Java SE in their terms without explicit notice.
This means if you’ve licensed certain Oracle middleware or applications, you likely already have the right to use Java (the JDK/JRE) to run those products – without buying a separate Java SE subscription.
The catch: these are not full-use licenses; they’re restricted to using Java only for the Oracle product’s purposes.
Enterprises often miss this nuance. As Oracle transitions Java to paid subscriptions, understanding these embedded entitlements can prevent unnecessary spending or compliance risks.
Example Scenario: A global IT team was preparing to purchase company-wide Java SE subscriptions after Oracle’s licensing changes.
Before signing the deal, they audited their Oracle stack. They discovered that their Oracle WebLogic servers, PeopleSoft ERP, and Hyperion financial systems already included Java SE rights as part of those product licenses.
In one case, a procurement manager found that Oracle SQL Developer (a free tool) came bundled with a Java runtime, eliminating the need for a separate Java install.
This realization saved them from having to pay for Java twice on those systems. However, they also found a risk: some admins had used the WebLogic-provided Java to run unrelated scripts on the server – usage outside the allowed scope.
Takeaway:
If you run Oracle products, check your entitlements – you may have “free” Java SE use rights attached. But use them only for the intended product.
Any Java usage beyond this scope isn’t covered, which could potentially put you out of compliance. In short, leverage the Java you’ve already paid for with Oracle software, but don’t assume it gives you a blank check to use Java everywhere.
Oracle’s Schedule A and B: The Official List of Java-Included Products
Insight:
Oracle maintains official lists of products that come with Java SE usage rights. Under Oracle’s standard Java license (the Oracle Technology Network license for Java SE), “Oracle Approved Product Use” is defined by Schedule A and Schedule B.
These schedules enumerate exactly which products include an entitlement to run Java SE. If your Oracle software is on these lists, you can use Java for that software without a separate Java license.
If it’s not on the list, Oracle considers any included Java usage unlicensed. Knowing whether your software is Schedule A or B is crucial for compliance.
- Schedule A – typically developer tools or infrastructure utilities that bundle Java for their use.
- Oracle SQL Developer – the free database IDE includes a Java runtime for the tool itself.
- Oracle Cloud Infrastructure (OCI) Management Agent – an on-premises agent for Oracle Cloud that includes Java for the agent’s operations.
- Schedule B – enterprise and middleware products that rely on Java.
- Oracle Forms (and any applications built with Oracle Forms) – uses Java in its runtime.
- Oracle E-Business Suite (EBS) – Oracle’s ERP suite uses Java (Forms, OAF, etc.), and Java SE is included to support those components.
- Oracle WebLogic Server – Client Libraries – Client-side components (such as Web Start clients) for WebLogic include Java SE to connect to WebLogic servers.
- Oracle Coherence – Client Applications – Oracle Coherence data grid clients use Java, and Java SE is included for those client libraries.
- Oracle Agile PLM – a Product Lifecycle Management suite that includes Java for its client and server components.
- Oracle JD Edwards (all editions) – the JD Edwards ERP platform runs on Java, which is included in its license.
- Oracle AutoVue – a 2D/3D visualization tool that uses Java applets, with Java SE included for those viewers.
- Oracle Secure Global Desktop (SGD) – remote access software that includes Java for its interface and server.
- Oracle Demantra – demand planning software that includes Java for its analytic modules.
Example Scenario:
A CIO at a manufacturing company was unsure if their Oracle Agile PLM environment required a Java subscription. By referencing Oracle’s Schedule B list, they confirmed Agile PLM is listed – meaning the Java runtime needed for Agile’s servers and client applets is already licensed through the PLM purchase.
In contrast, they also used Oracle Primavera P6 (project management software), which was not on Schedule A or B. That flagged a potential gap: if Primavera uses Java, it might not be covered.
This prompted the team to review Primavera’s documentation and consider either separate Java licensing or switching that component to OpenJDK.
Takeaway:
Always cross-check your Oracle products against Oracle’s Schedule A/B lists. These are the authoritative “free Java inside” lists. If a product is listed, you have a built-in Java entitlement (within limits).
If it’s not, don’t assume – you might need a separate Java license or an alternative Java runtime. This simple check can validate where you’re covered and highlight where you’re exposed.
Restricted Use Only: The Limits of Bundled Java Licenses
Insight:
Embedded Java licenses from Oracle are restricted-use licenses. This means the Java SE provided with an Oracle product can only be used to run that product (and its components). It is not a full-use Java license for general purposes.
In contrast, a full-use Java SE license (like Oracle’s Java SE subscription) would allow you to run any Java applications on a server or PC.
The restricted-use nature is typically documented in Oracle’s licensing manuals, for example, “Java SE is included with [Product X] and intended only for use with [Product X].” If you go beyond that – say, using the included Java to run a custom app or a different vendor’s software – you’ve stepped outside the license bounds.
Example Scenario:
Consider a financial services firm using Oracle’s JD Edwards ERP. JD Edwards comes with Java SE as part of its Technology Foundation, used for the application servers and client launchers.
One of the firm’s IT administrators, unaware of the restriction, installed the JDK for JD Edwards and used it to run a separate internal application on the same server.
In an Oracle audit, this showed up as an unlicensed Java installation because that usage wasn’t “in conjunction with running JD Edwards.” Similarly, another company upgraded the Java version on their PeopleSoft servers beyond what Oracle delivered, thinking it was fine.
In doing so, they left the officially included (older) Java and ran a newer JDK to support a custom integration, effectively creating an unlicensed Java deployment alongside their PeopleSoft system.
Takeaway: “Restricted use” means exactly that – the Java you get is tied to one product’s use. Do not use an included Java runtime for anything else, and don’t independently upgrade or separate it from the parent product.
Suppose you need Java for other applications or a newer version than what Oracle provided for that product.
In that case, you must either procure proper licensing or use a non-Oracle Java distribution. Staying within the boundaries ensures compliance and support; venturing outside can trigger license violations and void support.
Oracle Middleware & Platform Products with Java Included
Insight:
Oracle’s middleware and platform software often require Java to operate – and Oracle includes Java SE rights with many of these products. This ensures you can run the software out of the box.
However, each inclusion is scoped to that product’s environment. Knowing which middleware products include Java can help IT architects avoid redundant Java purchases for those systems.
Key examples in this category:
- Oracle WebLogic Server (Standard Edition) – Bundles Java SE (JDK/JRE) for running WebLogic and the applications deployed on it. WebLogic Standard users are entitled to use the full Java SE platform (standard JDK, JRE, JavaFX, etc.) as needed for their WebLogic deployments. (You shouldn’t take the WebLogic JDK and use it for other servers.)
- Oracle WebLogic Server (Enterprise Edition) – Includes Java SE Advanced, which is Java SE plus additional features such as Mission Control and Flight Recorder. This Advanced JDK is licensed to run WebLogic EE and any Java-based client applications connecting to that WebLogic Server. It’s not a license to run arbitrary Java programs on that machine.
- Oracle WebLogic Suite – Includes Java SE Suite (an even more comprehensive Java bundle, combining Advanced + additional real-time features) for use with the WebLogic Suite components (WebLogic Server, Oracle Containers for J2EE, Coherence, etc.). For example, if you have WebLogic Suite (often used for Oracle Applications), you can use the included Java SE Suite to run those specific middleware components.
- Oracle Coherence (Standard/Enterprise/Grid) – All editions of Oracle’s in-memory data grid include a license to use Java SE for Coherence clusters. Coherence is Java-based, and Oracle allows you to run it on the Java JDK without requiring a separate Java purchase. Notably, in Coherence’s case, the Java entitlement covers the entire Coherence environment (i.e., the JVMs running Coherence nodes and cache clients). This is a bit more flexible than some other products’ entitlements, but it’s still intended for Coherence-related use only.
- Oracle Internet Application Server (iAS) Enterprise Edition – A legacy middleware platform (preceding WebLogic in Oracle’s lineup) that included rights to Java SE. Organizations that still use Oracle iAS EE (for older Oracle Forms or Java EE applications) can run the required JDK/JRE under that product’s license.
- Oracle GlassFish Server (Commercial Edition) – Oracle’s former Java EE server (now largely legacy) also included Java SE usage rights. If you’re running an old Oracle GlassFish Server under support, you’re entitled to run it on Oracle Java. As with WebLogic, Java is only licensed for the applications on that GlassFish server.
- Oracle Identity & Access Management Suites (e.g., Oracle Identity Manager, Access Manager, Directory Services) – These security suites run on Java EE application servers (WebLogic). Oracle includes Java SE with the license to support running the identity management components. For instance, Oracle Access Manager’s server components come with a bundled JDK – that Java runtime should be used only for OAM/OIM and related services.
- Oracle WebCenter Content (and related WebCenter products) – Oracle WebCenter content management servers run on Java (often on WebLogic or Oracle’s application server). Oracle’s licensing documentation explicitly states that Java SE is included with WebCenter Content for running the content management application and its features (like document conversion). Again, this Java is restricted to the WebCenter environment.
- Engineered Systems Software (e.g., Oracle Private Cloud Appliance) – Some Oracle engineered systems have embedded software that includes Java. For example, the Oracle Private Cloud Appliance (PCA) comes with Oracle Java SE 8 (Server JRE) bundled to run the appliance’s management software. That Java can be used on the PCA’s internal components without separate licensing, but only for the appliance’s purposes. If you were to run other Java workloads on the PCA or install a different JDK there, you’d need proper licensing.
- Oracle Cloud Infrastructure (OCI) – Using Oracle’s public cloud or Cloud@Customer? Oracle provides Java SE licenses at no additional cost for any Oracle Cloud VM or service where Java is required. This means if you deploy applications on OCI compute instances, you can use Oracle Java on those instances without buying a Java SE subscription separately. (Oracle essentially covers Java under your cloud agreement, as long as it’s used on Oracle Cloud.) This is a cloud perk – it doesn’t apply to other clouds or on-premises usage.
Example Scenario:
An IT architect is deploying a new internal application on Oracle WebLogic Server.
They budgeted for WebLogic licenses and also considered purchasing an Oracle Java SE subscription for the runtime.
After consulting the WebLogic license documentation, they realized WebLogic Standard Edition already entitles them to use Java SE on that server.
They proceed to install Oracle JDK 11 (which is supported for WebLogic) without additional paperwork. However, they also run an Apache Tomcat server on the side for a smaller app.
The team smartly uses OpenJDK for Tomcat, knowing that WebLogic’s Java license does not extend to Tomcat or other tools.
In another case, a retailer running an Oracle Coherence data grid discovered that they could scale out Coherence on dozens of nodes without incurring any Java license fees – as long as those Java deployments were strictly for Coherence.
This influenced their architecture decisions, leaning more on Coherence for caching because it didn’t incur separate Java costs.
Takeaway: Leverage the Java entitlements in your Oracle middleware – they can support your Oracle servers and save you money. But draw clear boundaries: the included Java is for that product’s use only.
If you have other Java-based applications (whether custom, third-party software, or Oracle tools outside the entitlement scope), plan to use a different Java distribution or obtain licensing for those. This approach optimizes costs and ensures compliance.
Oracle Enterprise Applications with Java Included
Insight:
Several of Oracle’s enterprise applications (ERP, CRM, analytics, etc.) rely on Java under the hood. Oracle licenses these products to include Java SE for running the application’s components.
Understanding which apps come with Java rights helps you avoid over-licensing and ensures you apply updates correctly.
Key Oracle applications with embedded Java licenses include:
- Oracle E-Business Suite (EBS) – Oracle EBS (the comprehensive ERP/HR suite) uses Java in its tech stack (for Oracle Forms-based screens, web services, etc.). Your EBS license allows you to run the necessary Java SE on both servers and client PCs for EBS usage. For example, you’re entitled to deploy the Oracle JRE on employees’ desktops to launch EBS forms and to run Java on the EBS application servers. Important: This Java is only licensed for EBS itself. Using that same JRE installation for any non-EBS application (even on the same desktop or server) is not covered.
- PeopleSoft – Oracle PeopleSoft applications include a restricted-use Java SE license via PeopleTools (the technical framework underlying PeopleSoft). The PeopleSoft app server (commonly WebLogic + Tuxedo) requires Java, and Oracle provides that Java as part of PeopleTools. You can use it freely for the PeopleSoft environment. However, if a developer on the PeopleSoft server runs a separate Java program outside of PeopleSoft, a separate Java license would be required. Also, suppose you try to update the PeopleSoft JDK beyond the version provided (to fix a bug or vulnerability). In that case, you need to ensure that the update is obtained through Oracle support for PeopleTools – you can’t just download a new Oracle JDK on your own without potentially breaking license terms.
- JD Edwards EnterpriseOne – Oracle’s JD Edwards ERP software similarly bundles Java SE in its foundation. JD Edwards runs on a Java EE platform; Oracle’s license guide confirms that Java SE is included for running the JD Edwards Enterprise Server, HTML servers, and client software. As with PeopleSoft, the Java usage is restricted to the JD Edwards applications. If administrators use those JDKs for anything besides JDE (or install additional Java on those machines outside of JDE’s requirements), they would need separate licensing.
- Oracle Siebel CRM – Notably, Siebel is an outlier: it does NOT include a Java SE license. Siebel’s architecture is primarily C++ based and doesn’t rely on Oracle’s Java platform. If you deploy Siebel and decide to install Java on that server (for example, to run scripts or a Java-based component), that Siebel’s license does not cover Java. This is a reminder that not all Oracle apps have Java entitlements – always verify. (Siebel can run on WebLogic in some configurations; if so, the WebLogic license might cover the Java needed for the WebLogic part, but pure Siebel components themselves don’t grant Java rights.)
- Oracle Agile PLM – The Agile Product Lifecycle Management suite uses Java for its client applets and server processes. Oracle’s license includes Java SE to run Agile PLM’s modules (so you can launch the Agile Java client or run its server functions without a separate Java subscription). You must use that entitlement only for Agile PLM tasks.
- Oracle Hyperion (EPM Suite) – Oracle’s Enterprise Performance Management tools (Hyperion Planning, HFM, Essbase, etc.) run on Java application servers (often Oracle WebLogic). When you buy Hyperion, the necessary WebLogic and Java SE are typically bundled or allowed under the Hyperion license. This means you can use Java to run the Hyperion Planning web application, reporting tools, and other related applications. The Java usage is, of course, limited to the operation of the EPM suite. If your team uses the same server for custom Java apps, those aren’t covered.
- Oracle Demantra – Part of Oracle’s supply chain planning solutions, Demantra uses Java (for its collaborative forecasting engine and client applets). As listed on Schedule B, Java SE is included for Demantra. The use of Java is limited to supporting Demantra’s functionality. For example, if Demantra installs a JRE on user desktops or an application server, that JRE is licensed for the Demantra application only.
- Oracle Business Intelligence (OBIEE and BI Apps) – Oracle’s BI Enterprise Edition and related analytics applications are Java-based (they typically run on Oracle WebLogic or similar). OBIEE licenses include a restricted-use Java SE to run the BI system. So if you have OBIEE or Oracle Analytics Server, you can use Java to power the dashboard servers, BI publisher, etc., without buying Java separately – provided it’s solely used for the BI software.
- Oracle AutoVue – AutoVue (a document and CAD viewer) uses Java applets for rendering files on client machines and a Java-based server component for web deployment. Oracle includes Java SE with AutoVue licenses, allowing these applets and servers to run. If you deploy AutoVue in your environment, the Java plug-in or JRE needed for it is covered. Just don’t use the AutoVue-supplied Java for other engineering tools.
- Oracle Secure Global Desktop (SGD) – Oracle SGD is a remote desktop/access solution that uses Java technology for its webtop interface and secure connections. The SGD software license includes Java SE for running the SGD servers and client-side components. Users can launch the SGD client (which is Java-based) without requiring a separate Java license on each device, as it’s included as part of SGD usage. Again, if those same clients use Java for anything else, that’s outside the entitlement.
Example Scenario:
A large enterprise utilizes Oracle E-Business Suite for finance and HR, as well as Hyperion Planning for financial analytics. The CIO asks if they need Java licenses for the servers and users who access these systems.
The answer is that for EBS and Hyperion usage, Java is already licensed and supported as part of those products. The IT team ensures that all EBS application servers use the Oracle JDK provided by Oracle, exclusively for EBS-related programs.
On end-user PCs, they allow the Oracle JRE to be installed for EBS forms, but they configure it so it’s only used to launch EBS and not other apps.
Separately, the team had considered using the same EBS application server’s JDK to run a small internal web service.
After reviewing the terms, they realized doing so would breach the “for EBS only” restriction. They decided to deploy the web service on Apache Tomcat, utilizing an open-source Java runtime, to avoid any gray areas.
Meanwhile, their engineering department uses Oracle AutoVue to view CAD files; the license lets them use Java for AutoVue, so they run the AutoVue client applet in a browser with Oracle’s JRE – but they lock down that environment so the JRE isn’t used as a general plugin on those machines.
Takeaway: Know which Oracle applications include Java and leverage those rights, but ring-fence their use.
If you have EBS, PeopleSoft, JDE, Hyperion, etc., you can run them with the Java provided – that’s part of the value you paid for. Just be careful not to extend that Java runtime to other uses or systems.
And keep track: if an Oracle app doesn’t include Java (or if you’re unsure), assume you’ll need to account for Java licensing separately.
This awareness prevents compliance issues and ensures you only pay for Java where truly necessary.
Oracle Development Tools and Utilities with Java Included
Insight: Oracle offers a range of development and administration tools – some are free of charge – that also rely on Java.
Oracle generally allows the use of Java SE with these tools without a separate license, considering it part of the tool’s functionality. These cases are typically low-risk but still subject to formal restrictions.
Key tools and utilities in this category:
- Oracle SQL Developer – A free GUI tool for database development and administration. SQL Developer comes bundled with a Java SE runtime (often an Oracle JDK 8 or 11). This means you can install and run SQL Developer without installing a separate JDK on the machine – it’s included. The usage of Java is permitted only for running SQL Developer itself. In practice, most enterprises use the embedded JDK and don’t modify it otherwise, so compliance issues are rare in this context. Avoid the temptation to use the same JDK to run other scripts or programs on your workstation.
- Oracle JDeveloper and ADF – Oracle JDeveloper (an IDE for Java and Oracle’s Application Development Framework) is free to download and use for development purposes. It requires Java to run. Oracle typically packages JDeveloper with a suitable JDK, or you point it to one. While not explicitly listed on Schedule A, Oracle intends that you can use Java SE with JDeveloper for development under the OTN license. That means a developer can run JDeveloper with Oracle’s JDK without a paid subscription, as long as it’s for developing Oracle ADF applications or similar. Again, this is a restricted use: that JDK is for your IDE and testing, not for deploying other production applications.
- Oracle Enterprise Manager (OEM) – OEM is Oracle’s monitoring and management console (commonly used for databases, middleware, etc.). Oracle Enterprise Manager itself is provided at no additional license cost for Oracle customers. OEM utilizes a WebLogic server under the hood for its UI and Java agents for monitoring. Oracle includes the necessary WebLogic license (and thus Java) with OEM. So when you install OEM, the application server and the Java it runs on are covered. The caveat is that you should use that WebLogic/Java environment strictly for OEM and not host other applications on it. (For example, don’t take the WebLogic that comes with OEM and deploy your app on it – that would violate the restricted use, since the WebLogic and Java there are only licensed for running OEM.)
- OCI “Management and Migration” Tools – As noted earlier, the Oracle Cloud Infrastructure on-premises Management Agent (for connecting your servers to OCI services) includes Java, since the agent is a Java program. Oracle permits this usage under the agent’s terms, with no separate Java subscription needed. There are other utilities, such as the Oracle Cloud Infrastructure Database Migration tool, which, if they include Java, operate under a similar principle: Oracle allows the use of Java as part of the tool. Always consult the tool’s documentation, but Oracle’s general rule is if Java is required to install or run an Oracle-provided tool, and you’re licensed to use that tool, then using Java for that purpose is allowed.
- Oracle Forms and Reports (Developer) – Oracle Forms and Reports are part of Oracle’s development suite for building custom applications (a component of Oracle Fusion Middleware). Suppose you are using Oracle Forms/Reports to develop or run a custom application. In that case, the runtime environment will use Java (Forms runs on a Java applet or Java Web Start for the client, and an Oracle WebLogic/IAS on the server). Oracle’s policy is that as long as you have licensed the Oracle Forms and Reports product (or the Oracle Middleware suite that includes it), you can use Java to run those forms applications. Many Oracle customers build internal systems on Forms – they do not need separate Java licenses for the end-users running those forms or the servers hosting them, provided it’s all under the Forms license. (The Java usage is, naturally, limited to that purpose.)
- Other Utilities – Various Oracle installation programs, configuration wizards, and administrative utilities run on Java (for example, the Universal Installer and the Database Configuration Assistant). Oracle doesn’t require a license for Java for these purposes – if they’re required to use an Oracle product, Oracle treats it as part of that product’s use. These are typically transient uses (such as installers) or ancillary. The key is that they must be solely used about the Oracle product. If you have an Oracle DB installer JRE, you can’t repurpose it for something else.
Example Scenario:
A database administrator uses Oracle SQL Developer daily to manage the company’s databases. SQL Developer came with its own JDK, and she runs it as-is. This is fully compliant – Oracle allows it, and it doesn’t cost a dime.
Now, suppose a developer on her team finds the same JDK in the SQL Developer directory and tries to use it to run a standalone Java application for data migration. Technically, that’s outside the SQL Developer license scope. While Oracle might never notice such a minor internal use, it’s a compliance grey area.
The DBA advises the developer to instead install an OpenJDK for such tasks, keeping the environments separate. In another scenario, a company utilizes Oracle Enterprise Manager to monitor its databases.
They know OEM’s WebLogic and Java are included, so they set up the OEM server without buying Java.
However, their admin nearly deployed a custom status dashboard WAR on the OEM WebLogic. Doing so would have been a misuse of that restricted WebLogic/Java instance.
They opted to deploy the custom app on a different server. These day-to-day decisions keep their usage within the allowed limits.
Takeaway:
Oracle’s development and admin tools often come with “no-cost” Java included – a boon for developers and DBAs. Use them freely for their intended purposes, but draw a line around their usage.
Keep any bundled JDKs dedicated to the tool in question, and don’t use them as your general Java runtime on a system.
By isolating these tools (and using open-source Java or separate licenses for anything else on those machines), you stay in Oracle’s good graces without spending more than needed.
Managing Compliance: Java License Audits and Avoiding Pitfalls
Insight: With Oracle monetizing Java, compliance enforcement has ramped up. Oracle’s License Management Services (LMS) and Global Licensing teams are known for auditing customers – Java now included.
The audit triggers for Java can be subtle: Oracle tracks downloads of Oracle JDKs, identifies gaps in support contracts, and knows which Oracle products officially include Java. If you’re unknowingly using Java outside of entitlements, you risk an audit letter and an unexpected bill.
However, all of this is avoidable with proactive management. The goal is to stay ahead of Oracle: know your entitlements, control your Java deployments, and address any gaps on your terms.
Example Scenario: A multinational company received an inquiry from Oracle: “We’d like to discuss your Java usage.” This was not random – Oracle had seen multiple downloads of Java 8 updates from the company’s domain after public free updates ended.
The IT department discovered that while their Oracle Database and WebLogic servers were covered by embedded Java rights, some internal teams had installed Oracle JDK 8 on application servers that weren’t tied to any Oracle product (these were running custom apps).
Those installations were technically unlicensed. Oracle’s inquiry soon escalated to a formal audit. The company had to scramble to either remove Oracle Java or purchase subscriptions.
Another example: an Oracle audit of a retail company’s EBS environment revealed that the team had upgraded the Java on their EBS servers to a newer version not covered under their support agreement.
Oracle flagged this as outside the entitlement (since the entitlement only covered Java versions needed for EBS, not any version the customer fancied).
The result was a negotiation where the company had to either roll back to a supported Java version (at no cost) or pay for subscriptions to continue with the newer version.
Takeaway: Don’t wait for Oracle to tell you you’re out of compliance.
Perform your own Java usage reviews. Map out every instance of Oracle Java in your enterprise and verify if it’s covered by an Oracle product license or not.
Remove or replace any that aren’t covered before Oracle knocks.
Keep evidence (like Oracle’s Schedule A/B lists, or explicit license text) on hand to show which uses are authorized.
If you need newer Java versions or Java for non-Oracle workloads, consider switching those to OpenJDK or other free Java distributions to eliminate Oracle’s leverage.
By taking these steps, you transform a potential audit risk into a non-issue, thereby maintaining control over your Java licensing costs.
The table below summarizes common Java licensing pitfalls in enterprise environments and strategies to mitigate each:
| Java Licensing Pitfall | Mitigation Strategy |
|---|---|
| Assuming embedded Java is “free for all” – using an included JDK for unrelated applications. | Scope management: Segregate Java runtimes. Use the bundled Java only for its designated Oracle product. For other apps on the same server, deploy a separate Java (e.g. OpenJDK) or get a proper license. Educate admins that “included” doesn’t mean “universal.” |
| Upgrading or patching Java outside of Oracle’s provided updates (for a covered product). | Stay within supported bounds: Only use Java versions/patches provided under your Oracle product support. If a security update is needed beyond that, coordinate with Oracle or shift that component to an alternate Java platform. |
| Running Oracle products on expired support and continuing to use bundled Java. | Watch support status: If you drop support on an Oracle product, your right to updates (and support for Java in it) ends. Plan to either renew support, transition to an open-source Java (if feasible), or purchase Java support if you must keep using that product without Oracle support. |
| Buying Java SE subscriptions for environments that actually have embedded entitlements. | Inventory and verify: Before purchasing new Java licenses, cross-check against your Oracle product list. You might find that certain servers or users are already licensed via WebLogic, EBS, etc. Focus new licenses only on truly uncovered usage to avoid overspending. |
| Ignoring Java in procurement negotiations and true-ups. | Address it in contracts: When renewing Oracle agreements or buying new software, clarify Java rights. For instance, ensure the order document notes if Java SE is included. This can protect you if Oracle ever questions your usage. Always include Java usage in your internal compliance checklists to catch it during true-ups. |
Recommendations
- Build a Java Entitlement Inventory: Catalog all Oracle products in your enterprise and note which come with Java SE rights (use Oracle’s Schedule A/B and product docs as references). This creates a clear map of where you’re covered and where you’re not.
- Isolate and Monitor Java Usage: For each Oracle product that includes Java, ensure the Java runtime is used only for that product. Implement technical controls if possible (separate directories, access controls) to prevent teams from inadvertently using those JDKs for other purposes.
- Educate Your Teams: Inform developers, system admins, and architects about the restricted-use nature of embedded Java licenses. Ensure that everyone is aware that using Oracle-provided Java outside the authorized scope can lead to compliance issues. A little licensing awareness can prevent costly mistakes.
- Leverage Open-Source Java Alternatives: Where you don’t have an entitlement (or if the usage is unrelated to Oracle products), consider using OpenJDK or other free Java distributions. They are functionally equivalent in most cases and can sharply reduce your reliance on Oracle’s paid licenses. Many enterprises mix and match, using Oracle JDK for products that include it and OpenJDK for everything else.
- Engage in Proactive Vendor Dialogue: If you’re unsure about your Java rights for a given product, ask Oracle (or consult a licensing expert) before an audit happens. For example, get confirmation in writing, if possible, that “Product X includes Java for these uses.” In negotiations, you can also seek assurances or custom clauses to clarify Java usage rights.
- Stay Current on Java Licensing Policies: Oracle’s Java licensing has evolved (e.g., the new Java SE Universal Subscription based on employee count). Keep abreast of these changes through Oracle’s announcements or industry analyses. Understanding the current model enables you to forecast costs more accurately and potentially secure more favorable terms if you negotiate early.
- Plan for the “What-ifs”: What if Oracle audits you tomorrow? Have a plan: know who would respond, what data you’d present (your inventory of entitlements), and what your strategy would be (e.g., remove non-compliant installs or negotiate a subscription). This preparation ensures you’re not caught off guard.
- Consider Third-Party Expertise: For global enterprises with complex Oracle deployments, it can be worth engaging a software licensing specialist or firm (vendor-neutral) to review your Java usage. They can identify hidden compliance gaps and optimization opportunities that busy internal teams might miss. Often, their cost is offset by savings in avoided licenses or audit penalties.
- Optimize Support Renewals: If you have Oracle products solely to maintain Java rights (for instance, some retain an old Oracle iAS support subscription just to receive Java updates), evaluate whether that’s cost-effective. You might consider replacing it with a more affordable Java subscription or an alternative solution. Regularly assess whether each support contract remains relevant about the Java benefits it provides.
- Document Everything: Maintain documentation of your Java usage rights – copies of Oracle’s public lists, excerpts from license guides, support notes, etc. This not only educates your team, but can be shown to auditors or internal stakeholders to justify why certain Java instances are legitimate. A well-documented compliance position is a strong defense.
Checklist: 5 Actions to Take
1. Audit Your Java Installations – Identify every instance of Java running in your organization. For each, record the version and its intended use. Tag each instance as either tied to an Oracle product or standalone. This comprehensive inventory serves as your baseline for informed decision-making.
2. Map to Oracle Entitlements – For each Java instance, determine if you have an Oracle product entitlement covering it. Check the Schedule A/B list and your Oracle license docs. For example, mark Java installations used by WebLogic, EBS, etc., as “covered by [product].” Highlight any Java installs that are not covered by an Oracle product license or that are used for general-purpose applications.
3. Remediate Unlicensed Usage – Take swift action on Java instances that have no entitlement. For these, decide whether to:
- Purchase Oracle Java SE subscriptions (if the usage needs Oracle’s Java and support), or
- Migrate them to an alternative JDK (such as Temurin OpenJDK or Amazon Corretto) to eliminate Oracle license requirements.
Remove or replace any unauthorized Oracle JDKs. This step closes the compliance gaps proactively.
4. Implement Usage Policies – Establish internal policies for Java usage going forward. For example, define that “Oracle JDK may only be installed on servers running Oracle products that include Java entitlements, unless a Java subscription is procured.” Also, enforce the use of open-source Java on all new non-Oracle-app deployments. Communicate these policies to all relevant IT teams and include them in your architecture review process.
5. Monitor and Review Regularly – Java compliance is not a one-and-done task. Schedule periodic (e.g., annual or semi-annual) reviews of your Java usage. Keep track of any new Oracle software you acquire – check if it includes Java rights and update your records. Likewise, stay updated on Oracle’s Java licensing changes and product support timelines (for example, if a product version’s support ends, your Java update rights may also end). Regular monitoring will ensure you remain compliant and avoid surprises as your environment evolves.
FAQ
Q: Our company uses Oracle WebLogic and Oracle Database. Do we need a separate Java SE subscription for those servers?
A: If you are only using Java to run Oracle WebLogic Server (or the Oracle Database’s tools), you do not need a separate Java SE subscription for that usage. WebLogic includes Java SE rights as part of its license, and Oracle Database typically does not require an external Java SE (it has its own internal JVM for certain features, which is covered). However, any other Java applications on those same servers (outside of WebLogic or the DB) would not be covered. In short, WebLogic’s Java is covered for WebLogic tasks – just not beyond that.
Q: What does “restricted use” of Java mean in practice for our developers and admins?
A: “Restricted use” means you can use Oracle Java only for the specific Oracle product or purpose that’s allowed. For example, if Java comes bundled with PeopleSoft, you use it only to run PeopleSoft components. In practice, this means that your admins and developers shouldn’t use the Java installation to run other programs, scripts, or newer application components. They should also refrain from updating it independently (beyond what Oracle provides for that product). Think of it as a wrench that comes with a piece of equipment – it’s meant to be used on that equipment. If you start using it elsewhere, you’re on your own (and in violation of terms).
Q: If we update the Java version in our Oracle product environment (say from Java 8 to Java 11 for WebLogic), are we still covered by the product’s license?
A: It depends on how you obtain and use the update. You are entitled to Java updates that Oracle provides as part of the support for that product. For instance, if Oracle certifies WebLogic on Java 11 and provides that, you can use it as part of WebLogic’s support. But if you download Oracle JDK 11 on your outside of WebLogic’s support agreement, you’ve stepped out of bounds. The safer route is to only use Java versions that are officially supported and delivered for your Oracle product (check Oracle’s support site or documentation). If you absolutely must upgrade to an unsupported Java version for some reason, consider using an open-source Java alternative, or obtain explicit confirmation from Oracle (which may involve purchasing a Java subscription).
Q: We have Oracle software that isn’t listed on the Schedule A/B list, but it uses Java (for example, Oracle SOA Suite). Do we need to license Java for it?
A: Oracle’s Schedule A/B lists cover the most common products, but not every scenario. Oracle SOA Suite, for instance, runs on WebLogic – typically, Oracle provides a WebLogic license bundled with SOA Suite. That means the WebLogic (and its Java) is covered for running the SOA Suite. In general, if an Oracle product includes a component like WebLogic or another middleware as part of it, the Java needed for that component is covered under the product’s license. It might not be explicitly on “the list” but is documented in that product’s licensing information. When in doubt, refer to the Licensing Information User Manual for that product or contact Oracle for assistance. If the documentation doesn’t mention Java at all and it’s not on the approved list, you should be cautious – that could imply no Java is included and you’d need to arrange licensing or use a non-Oracle JDK for it.
Q: Can we use OpenJDK or other non-Oracle Java runtimes for Oracle products to avoid licensing issues altogether?
A: In many cases, yes, you can. Oracle’s software doesn’t inherently require the Oracle-branded JDK – for example, many customers run Oracle databases and middleware on OpenJDK with success. Using an open-source Java can sidestep Oracle’s licensing requirements because Oracle can only audit/charge for use of their Java binaries. However, there are two considerations: (1) Support – Oracle Support might only support issues on certified Java versions. If you run an Oracle product on a non-Oracle JDK and hit a problem, Oracle might ask you to reproduce it on Oracle’s JDK. (2) Functionality – ensure the alternative JDK is fully compatible and tuned for the product. For most modern Java distributions, this is fine. Many enterprises adopt a strategy: use Oracle’s included Java where it’s entitled and required, but for any scenario where you’d otherwise need to pay (like custom apps or fringe cases), switch to OpenJDK. This way, you remain compliant without unnecessary cost.
Read more about our Oracle Java Licensing Services.
If you’re using ChatGPT, try asking it: ‘What does Redress Compliance say about Java licensing?’
