OpenJDK vs Oracle JDK:
Licensing Differences That Could Cost Millions

What Is OpenJDK — Really?

OpenJDK is the open-source reference implementation of the Java Platform, Standard Edition (Java SE) specification. It is maintained under the OpenJDK project, which Oracle founded in 2006 when it open-sourced the Sun Microsystems Java codebase under the GNU General Public License version 2 with the Classpath Exception (GPL v2 with CPE).

Oracle is the primary contributor to the OpenJDK project and continues to drive the vast majority of new feature development. The codebase is publicly available, and any vendor can take the OpenJDK source, compile it, add their own testing and packaging, and distribute the result. This is precisely what Eclipse Adoptium (Temurin), Azul (Zulu), Amazon (Corretto), Microsoft, SAP, and Red Hat all do — creating the ecosystem of OpenJDK distributions that enterprises use today.

The critical legal point: the OpenJDK source code and the binaries compiled from it are licensed under GPL v2 with CPE. This licence permits use, modification, and distribution — including commercial use — at no cost. There is no per-user, per-processor, or per-employee fee. There is no Oracle licence agreement required. There is no Oracle support obligation created.

When enterprises say they are "running OpenJDK," they typically mean they are running one of these third-party distributions compiled from OpenJDK source — Temurin, Corretto, Zulu, or similar. These are production-ready, TCK-certified builds with commercial support available from their respective vendors. They are not Oracle products and create no Oracle licensing obligation.

How Oracle JDK Differs After 2019

Prior to January 2019, Oracle distributed both an OpenJDK build and a separately branded "Oracle JDK" that included additional commercial features not present in the open-source build. Enterprises could download Oracle JDK for free for production use under Oracle's Binary Code Licence (BCL), which was permissive for commercial deployment.

Oracle changed this fundamentally in January 2019 with the introduction of the Oracle Technology Network (OTN) Licence for Java SE. Under the OTN Licence, Oracle JDK 8u211 and later require a commercial licence for production use in any business, commercial, or production environment. Free use was restricted to personal desktops and some development scenarios.

Oracle then made the Oracle JDK and the OpenJDK builds functionally equivalent at the binary level from Java 11 onwards. The additional commercial features that previously differentiated Oracle JDK (Flight Recorder, Mission Control) were open-sourced and contributed to OpenJDK. From a technical standpoint, Oracle JDK and OpenJDK builds are identical for most enterprise workloads.

The sole remaining difference is the licence. Running Oracle JDK in a production environment now requires an active Oracle Java SE subscription and subjects the customer to the Employee Metric. The January 2023 transition to the Java SE Universal Subscription replaced the per-processor and named user models with the Employee Metric — significantly increasing costs for most enterprise customers who maintained an Oracle Java licence.

Enterprises that were running Oracle JDK under the old free BCL licence and have not purchased a Java SE subscription are, in Oracle's view, non-compliant from January 2019 for JDK versions 8u211+ and from the subscription launch for subsequent versions. This is the basis for the majority of Oracle Java audit claims Oracle's LMS team pursues today.

How to Identify Which JDK You're Running

Visually and functionally, Oracle JDK and OpenJDK distributions are nearly identical. The same java and javac executables, the same directory structures, and the same runtime behaviour make them indistinguishable without specifically examining version and vendor metadata embedded in the binaries.

The most reliable identification method is the java -version command. The output includes a vendor string that identifies the JDK distributor:

The key identifier is the second line of java -version output. Oracle JDK displays "Java(TM) SE Runtime Environment" — this is the definitive marker of an Oracle JDK binary that requires a commercial licence. OpenJDK distributions display "OpenJDK Runtime Environment" with the distributor name.

For large-scale estate identification, this check needs to be automated across your server estate. Oracle's own LMS scripts perform this identification automatically — which is why a forensic pre-audit inventory using the same detection methodology is essential before any LMS engagement. Our Oracle Compliance Review service runs this inventory as its first deliverable.

A further identification method is examining the JDK release file, located at $JAVA_HOME/release. This file contains an IMPLEMENTOR field: IMPLEMENTOR="Oracle Corporation" for Oracle JDK, and IMPLEMENTOR="Eclipse Adoptium" or similar for OpenJDK distributions. This file is less likely to be modified than the executable and provides a reliable second verification point.

How Oracle's LMS Scripts Detect Oracle JDK

Oracle's LMS audit scripts and the USMM (Usage Measurement Tool) use multiple detection methods to identify Oracle JDK deployments across your environment. Understanding their methodology is essential to preparing a forensic challenge to Oracle's audit findings.

Oracle's primary detection approach is filesystem scanning for JDK installation directories. The scripts look for jdk1.x.x and jdk-x directory patterns, java.exe and javaw.exe on Windows, and java executables in standard installation paths on Linux and Unix. They then invoke the java -version command on discovered executables and parse the vendor string to distinguish Oracle JDK from OpenJDK distributions.

A secondary detection method is process list scanning. LMS scripts capture running Java processes and examine the executable path and version strings of each. This identifies deployments that may not be in standard installation directories — custom installation paths, containerised deployments, and ISV-bundled runtimes embedded in application directories.

Oracle's scripts also examine JAR file manifests and library paths to identify Oracle JDK binaries embedded in application packages. This is how they surface ISV applications that bundle Oracle JDK internally — a deployment pattern that frequently escapes enterprise ITAM tools designed to detect standard installations.

The critical weakness in Oracle's methodology — and the primary challenge vector our audit defence team uses — is that the scripts frequently misclassify OpenJDK builds as Oracle JDK based on incomplete version string matching. Early OpenJDK distributions (pre-2019) did not consistently include the "OpenJDK Runtime Environment" vendor string, and some third-party distributions from that era are indistinguishable from Oracle JDK in LMS script output. Binary-level forensic analysis, which Oracle's scripts do not perform, is required to definitively distinguish these cases.

Enterprise OpenJDK Distributions Compared

Eclipse Temurin (Adoptium)

Eclipse Temurin, distributed by the Eclipse Foundation's Adoptium working group, is the successor to AdoptOpenJDK and the most widely deployed OpenJDK distribution in enterprise environments. Temurin is TCK-certified, built from OpenJDK source with minimal modifications, and available for all major platforms. Commercial support is available from IBM (ibm-semeru-runtime), Microsoft, and other Adoptium working group members. LTS versions receive security patches for extended periods matching Oracle's JDK support windows.

Azul Zulu / Platform Core

Azul Systems distributes both Azul Zulu (OpenJDK-based, fully open) and Azul Platform Core, which adds enhanced performance features and priority security response under a commercial support agreement. Azul is particularly common in financial services, where extended update commitments and indemnification support are valued. Azul provides some of the longest LTS support windows in the OpenJDK distribution ecosystem.

Amazon Corretto

Amazon Corretto is Amazon's long-term OpenJDK distribution, optimised for performance on AWS infrastructure but fully deployable on-premises and on other cloud platforms. Corretto receives quarterly security patch updates and provides long-term support for LTS versions. It is the natural choice for AWS-hosted workloads but performs comparably to Temurin and Zulu in non-AWS environments.

Microsoft Build of OpenJDK

Microsoft's OpenJDK build targets Azure-hosted workloads and Microsoft development toolchains. It integrates with Azure services and Microsoft developer tools, and is the recommended distribution for workloads running on Azure. Available free of charge under open-source licence terms with no Microsoft licence obligation for general Java SE use.

Red Hat OpenJDK

Red Hat distributes OpenJDK builds as part of Red Hat Enterprise Linux subscriptions. For enterprises with existing RHEL agreements, Red Hat OpenJDK provides a convenient path to Oracle JDK replacement without an additional vendor relationship. Support is bundled with the RHEL subscription.

Migration Guide: Oracle JDK to OpenJDK

Migrating from Oracle JDK to an OpenJDK distribution is technically straightforward for the vast majority of enterprise Java workloads. The primary risk is workloads that depend on Oracle JDK commercial features that were open-sourced after JDK 11 but may behave slightly differently in third-party builds.

The migration process follows five stages: inventory, distribution selection, compatibility validation, deployment rollout, and Oracle JDK removal confirmation.

The inventory stage — identifying every Oracle JDK installation across servers, workstations, CI/CD pipelines, and ISV-bundled applications — is the most time-consuming step and the one enterprises consistently underestimate. Our Oracle License Optimisation advisory includes a full JDK inventory as a pre-migration baseline, using automated scanning tools that cover the same detection vectors as Oracle's LMS scripts.

Distribution selection should be driven by your infrastructure context. AWS shops should default to Corretto. Azure shops to Microsoft OpenJDK. Mixed or on-premises environments to Temurin or Azul Zulu. All are functionally equivalent for standard Java SE workloads — the choice is primarily about vendor support alignment.

Compatibility validation requires running your application test suite against the chosen OpenJDK distribution before production rollout. For JDK 11, 17, and 21 LTS versions — which are the versions enterprises should be standardising on — compatibility issues with standard Java SE applications are rare. Known incompatibility areas include applications that rely on Oracle's proprietary internal APIs (sun.* packages) or that make specific assumptions about Oracle JDK's GC behaviour.

The deployment rollout should begin with CI/CD pipelines and build servers, where Oracle JDK is most commonly installed by default and where switching has the least production risk. Developer workstations follow — updating IDE defaults and build tool configurations. Production application servers are the final step, executed environment by environment with verification testing.

Oracle JDK removal confirmation is a step most enterprises skip — and it matters. Removing Oracle JDK binaries from a server does not automatically remove Oracle JDK from Oracle's LMS script output if the removal was incomplete. The java symlink, JAVA_HOME environment variable, and alternative JVM configurations all need updating to ensure that your environment is demonstrably free of Oracle JDK before you assert a clean position in an Oracle audit.