Java Licensing Cleanup: A Step-by-Step Guide to Reducing Your Oracle Java Exposure

Why a Java Licensing Cleanup Is Now Urgent

For most of the past decade, Oracle Java was treated as a commodity runtime that came bundled with developer tools, application servers, and third-party software packages. The concept that Java itself was a separately licensable product that required ongoing commercial compliance attention was not widely internalised in IT procurement or SAM teams. Oracle's January 2023 licensing change — replacing the old named-user and processor metrics with an enterprise-wide employee-count subscription — fundamentally changed that reality.

The years 2024 to 2026 represent the period during which Oracle has been systematically converting its intelligence on Oracle JDK download activity into formal and informal audit proceedings. Oracle knows who downloaded Oracle JDK — the download portal required an account or provided telemetry data — and that information is being used by Oracle's GLAS team to identify organisations that are using Oracle JDK without a current subscription. The window during which organisations can undertake a proactive cleanup before Oracle makes contact is narrowing. By the time an Oracle GLAS outreach arrives, the most effective window for voluntary remediation without back-charge liability has typically already passed.

A proactive Java licensing cleanup achieves two objectives simultaneously: it eliminates the ongoing and future Oracle Java subscription obligation by migrating to free OpenJDK alternatives, and it builds the documented evidence base that is essential if Oracle does initiate audit proceedings for historical use. Neither objective is achievable without a structured, systematic programme.

Phase 1: Discovery — Building Your Oracle Java Inventory

Discovery is the foundation of every Java licensing cleanup. Without an accurate, complete inventory of Oracle Java installations across the enterprise, neither the commercial decision-making nor the remediation planning can be done with confidence. Discovery must cover every environment: production servers, non-production and test environments, developer workstations, build servers, container images, and embedded runtimes within third-party applications.

Automated Discovery Tools

The most efficient approach to Java discovery uses automated tools from the organisation's existing Software Asset Management (SAM) or endpoint management infrastructure. Common platforms that can be configured to identify Java installations include Microsoft Endpoint Configuration Manager (SCCM) or Intune, ServiceNow Software Asset Management, Flexera FlexNet Manager, Snow Software, and Ivanti Neurons for ITAM. Each of these platforms can be queried for installed software by vendor and product name, identifying Oracle JDK and JRE installations across managed endpoints and servers.

For environments not covered by standard endpoint management — Linux servers, containers, and legacy systems — additional discovery scripts are typically required. A simple shell command can identify Java installations across Unix-like systems by locating java binaries and extracting version and vendor information from the JVM. The output should capture the full path, the distribution vendor string, and the version number for each installation found.

Containers deserve particular attention. Container images built on Oracle JDK base images, or that include Oracle JDK as part of their runtime layer, represent a discovery challenge because they may not appear in standard SAM tool inventories. A container image scan — using tools like Trivy, Anchore, or custom scripting against your image registry — is required to capture these installations. Any Oracle JDK found in a container base image should be treated as a deployment instance for licensing purposes, even if the container is not currently running.

Classifying Each Installation

The goal of discovery is not just to find Java installations but to classify each one accurately. For each installation, the cleanup programme needs to capture the distribution vendor (Oracle vs OpenJDK provider), the specific version number, the use type (production, test, development, build tooling), the owning application or service, and the date the current installation was deployed. This classification determines the remediation priority and the licence obligation associated with each instance.

The critical classification distinction is between Oracle-branded distributions and OpenJDK distributions. Oracle JDK and Oracle JRE — distributed from oracle.com — are subject to the Oracle licence terms. OpenJDK distributions from Amazon (Corretto), Eclipse Adoptium (Temurin), Azul (Zulu), Red Hat, IBM (Semeru), or BellSoft (Liberica) are not Oracle products and do not require an Oracle Java SE subscription. Installations that appear to be Java but are not Oracle-branded should be confirmed as such with specific vendor string verification, since misclassification in either direction has significant consequences.

Phase 2: Risk Assessment — Quantifying Your Exposure

Once the discovery inventory is complete, the next phase is quantifying the licensing exposure associated with the Oracle JDK installations found. This requires combining the installation count with two additional inputs: the organisation's Oracle-definition headcount and the historical timeline of Oracle JDK use.

Mapping Oracle JDK Use to Licence Terms

Not all Oracle JDK installations are equally problematic from a licensing perspective. The risk assessment must consider when each installation was deployed and under which licence terms. Oracle JDK 8 versions older than 8u202, deployed before Oracle's April 2019 licence change, were available under a more permissive licence that included some commercial production use. Versions deployed between April 2019 and January 2023 were subject to the OTN licence that restricted commercial production use to paying customers. Versions deployed after January 2023 without a Java SE Universal Subscription are clearly outside any free-use entitlement for commercial production purposes.

This historical mapping allows the risk assessment to identify the portion of Oracle JDK use that is genuinely uncontested versus the portion that represents clear unlicensed use. In most organisations, the bulk of the exposure falls in the 2019 to current period, and particularly in the 2023 to present window where Oracle's Universal Subscription model was in effect and the licence terms are unambiguous.

Calculating the Prospective Subscription Cost

Understanding what Oracle would charge for a prospective Java SE Universal Subscription — if you chose to purchase one rather than migrate — creates the financial baseline against which migration costs should be compared. The calculation requires the Oracle-definition headcount (not just your HR headcount) multiplied by the applicable per-employee monthly rate, multiplied by twelve months, with an 8 percent annual increase applied to each subsequent year of any multi-year commitment. For most enterprises with several thousand employees or more, this prospective cost calculation makes the investment case for migration to free OpenJDK distributions overwhelmingly clear.

Phase 3: Remediation Planning — Prioritising the Migration

The remediation plan converts the discovery inventory and risk assessment into an actionable programme of work. A well-structured remediation plan assigns each Oracle JDK installation to one of three categories: migrate immediately (highest priority), migrate in the next phase (medium priority), or handle separately (complex cases requiring individual analysis). The plan should also establish governance — who owns each installation, who is responsible for testing the migrated alternative, and what the acceptance criteria are for each migration.

Migration Priority Framework

Installations should be prioritised based on a combination of risk and ease of migration. High-priority installations are Oracle JDK versions in commercial production use with no current subscription — these represent the clear licensing exposure and should be migrated first. After that, development and test environments running Oracle JDK should be migrated, since while they may not be in commercial production, their presence creates complexity in any audit scenario. Build servers and CI/CD pipeline tooling that uses Oracle JDK should be migrated as part of the development environment cleanup, since these are often overlooked but clearly constitute commercial use.

The ease dimension prioritises standalone Oracle JDK installations over embedded ones. A standalone Oracle JDK on a Linux server is a simpler migration than Oracle JDK bundled into an Oracle WebLogic deployment, which in turn is simpler than Oracle JDK embedded in a third-party application package that the organisation cannot directly modify. The remediation plan should distinguish these categories and track them separately, with different approaches for each.

Choosing the Right OpenJDK Distribution

All major OpenJDK distributions are functionally equivalent to Oracle JDK and are TCK-certified to the same Java SE specification. The choice of which OpenJDK distribution to standardise on should be driven by the organisation's support requirements, existing vendor relationships, and the specific Java versions needed. Amazon Corretto is a strong choice for organisations running workloads on AWS, as Amazon provides long-term support for Corretto that is aligned with its own use at scale. Eclipse Temurin, backed by the Eclipse Foundation and companies including IBM and Red Hat, is a vendor-neutral option with broad community support. Azul Zulu and Azul Platform Core provide commercial support options for organisations that require contractual SLAs for their Java runtime. Red Hat OpenJDK is the natural choice for organisations standardised on Red Hat Enterprise Linux or the Red Hat software ecosystem.

The key characteristics to verify for the chosen distribution are: coverage of the Java versions the organisation needs (Java 8 LTS, Java 11 LTS, Java 17 LTS, Java 21 LTS), long-term support commitments for each version, the patch cadence (aligned with Oracle's quarterly CPU release schedule is standard), and the vendor's own track record of maintaining the distribution. All of the distributions listed above meet these criteria and represent legitimate, compliant alternatives to Oracle JDK with zero Oracle Java licence cost.

Phase 4: Migration Execution — Replacing Oracle JDK

The migration from Oracle JDK to an OpenJDK distribution is technically straightforward in the majority of cases. Since Java 11, Oracle JDK and OpenJDK share the same codebase and deliver identical runtime behaviour — the switch is a binary replacement rather than a porting exercise. For most applications, the migration involves three steps: uninstalling Oracle JDK from the target system, installing the selected OpenJDK distribution to the same path or updating any path references, and validating that the application starts and functions correctly against a defined acceptance test.

Handling Java 8 Migrations

Java 8 migrations require slightly more care than Java 11+ migrations because the OpenJDK 8 codebase diverged from Oracle JDK 8 more than later versions. The practical risk is minimal for the vast majority of applications — the Java APIs are the same, the JVM behaviour is essentially identical, and OpenJDK 8 has been battle-tested in production environments for years. The additional care comes in the testing phase: applications with native code dependencies, JVM configuration flags that are specific to Oracle's implementation, or use of proprietary Oracle JDK APIs (the most common being sun.misc.Unsafe in legacy code) should be tested more thoroughly. Most of these cases are already known to development teams and are manageable within a structured test plan.

Container and CI/CD Migration

Container image migrations require a rebuild of each image using an OpenJDK base image in place of the Oracle JDK base image. The major container registries (Docker Hub, Amazon ECR, Google Artifact Registry) provide official OpenJDK images based on Amazon Corretto, Eclipse Temurin, and other distributions. Replacing the base image layer typically requires a single line change in the Dockerfile, followed by a build and validation cycle. CI/CD pipeline tooling should be updated in the same migration sprint to avoid Oracle JDK being reintroduced through build processes after it has been removed from production.

Documentation at Every Step

Documentation is not optional in a Java licensing cleanup — it is one of the primary deliverables. For each Oracle JDK installation that is removed, the remediation record should capture the hostname and system identifier, the Oracle JDK version and installation path, the date the Oracle JDK installation was removed, the replacement OpenJDK distribution and version installed, and the name of the engineer who performed the migration. This evidence base is your defence if Oracle subsequently claims that Oracle JDK was in use on a system where you have completed a migration — and it is the foundation for demonstrating to Oracle that a remediation programme was in progress during any period covered by a compliance claim.

Phase 5: Prevention — Stopping Oracle JDK from Re-Entering the Estate

A Java licensing cleanup that removes all Oracle JDK installations is only durable if controls are in place to prevent Oracle JDK from re-entering the estate through new deployments, developer tool installations, or third-party software updates. Prevention controls operate at multiple levels and should be implemented as part of the cleanup programme rather than as an afterthought.

Network-Level Controls

Blocking direct downloads from oracle.com/java is the most effective way to prevent Oracle JDK from being downloaded to enterprise systems by individual developers or automated build processes. This can be implemented through proxy configuration, DNS blocking, or firewall rules targeting the Oracle JDK download endpoints. Pair this with an approved OpenJDK distribution hosted on an internal repository (Artifactory, Nexus, or a package mirror) to provide developers with a compliant alternative without creating friction in their workflows.

Software Policy and Endpoint Controls

Enterprise endpoint management platforms — SCCM, Intune, Jamf — can be configured to flag or block installations of Oracle JDK and JRE. Software restriction policies, application control lists, or custom compliance rules can detect Oracle Java installations on managed endpoints and either prevent installation or generate alerts for the SAM team. Add Java distribution checks to the standard onboarding configuration for new servers and developer workstations to prevent Oracle JDK from being deployed as part of standard build images.

CI/CD Pipeline Scanning

Container image scanning in the CI/CD pipeline provides automated detection of Oracle JDK in container builds. Tools like Trivy, Snyk, or Anchore can be configured to fail a build that includes an Oracle JDK base image or layer, preventing Oracle JDK from being shipped in production container images. Package dependency scanning can also identify Oracle JDK being pulled in as a transitive dependency through build tool configurations (Maven, Gradle) that reference Oracle-hosted repositories.

Quarterly Compliance Scanning

Even with prevention controls in place, a quarterly Java compliance scan across the full estate provides ongoing assurance that no Oracle JDK has re-entered the environment. The scan uses the same discovery methodology as Phase 1 but on a regular cadence, producing a compliance report that demonstrates the sustained clean state of the estate. This report is a significant asset in any future audit scenario and demonstrates to Oracle that the organisation is managing its Java estate actively.

Handling Third-Party and Embedded Oracle Java

One of the most complex aspects of a Java licensing cleanup is dealing with Oracle JDK that arrives not through direct installation by the organisation's IT team but embedded in third-party software packages, commercial application servers, or ISV-supplied installations. In these cases, the organisation does not directly control the Java distribution and cannot simply replace it.

The correct approach for each embedded Oracle JDK case depends on the specific application and vendor. For applications supplied by software vendors with active maintenance agreements, the first step is to request that the vendor provide a version of their application that supports an OpenJDK runtime. Most major enterprise software vendors have updated their products to be OpenJDK-compatible in response to the widespread enterprise migration from Oracle JDK. For applications where the vendor cannot or will not provide an OpenJDK-compatible version, the options include purchasing an Oracle Java SE Universal Subscription that specifically covers the embedded use, engaging the vendor on a product roadmap commitment to OpenJDK compatibility, or evaluating alternative products that do not require Oracle Java.

In all cases, third-party embedded Oracle JDK should be explicitly documented in the cleanup programme with a clear status (remediated, in progress, or deferred with justification). Deferring remediation without documentation creates audit risk — Oracle will not accept "the vendor bundled it" as a defence without evidence that the organisation was actively managing the situation.

Cleanup Completion and Ongoing Governance

A Java licensing cleanup is complete when three conditions are met: all Oracle JDK installations have been either removed and replaced with OpenJDK, or covered by a documented and auditable subscription or contractual entitlement; prevention controls are in place and operating; and a regular compliance scan cadence is established to maintain the clean state. At that point, the organisation can engage with any Oracle Java audit or GLAS outreach from a position of genuine confidence — with the evidence to demonstrate a clean current state and a documented history of the remediation programme that addressed any historical exposure.

Ongoing governance should include a Java distribution standard that is incorporated into IT procurement policies, developer onboarding guidelines, and cloud platform configuration standards. Any new application deployment should include a Java distribution check as part of its approval process. The SAM team should include Java distribution compliance in its quarterly review agenda. These lightweight ongoing governance measures are what prevent a future accumulation of Oracle Java exposure and ensure the cleanup investment remains durable.

Redress Compliance advises enterprises on all aspects of Oracle Java licensing, from initial exposure assessment through migration planning, audit defence, and ongoing compliance governance. For a confidential discussion of your organisation's Java situation, contact us at redresscompliance.com/oracle-services.