Oracle Java Compliance — Multi-Source Discovery and a RED/YELLOW/GREEN Framework

When One Java Install Licenses the Whole Company

In January 2023, Oracle changed how Java SE is licensed. The old Named User Plus and Processor metrics were retired. The new metric is brutally simple: Employee — every employee in the organisation, regardless of who actually touches Java.

There is no partial deployment under this model. If even one Oracle Java installation requiring licensing exists anywhere in the environment, the organisation must license every employee on the payroll. There is no "we only use it on these servers" defence. There is no "only the dev team needs it" carve-out. One install, full headcount.

At Oracle's list price of $10.50 per employee per month, the cost across a typical enterprise headcount runs into seven figures per year — for a Java footprint that may have started as a single Oracle JDK download somebody made years ago without reading the licence.

That is the trap I set out to map for clients who came to us with a vague worry — "we have Java in our environment, are we exposed?" — and no inventory to answer it.

Why Flexera Inventory Isn't Enough

Flexera FNMS and FlexeraONE are excellent at discovering Java files. The agents scan thousands of machines, the recognition library identifies most major distributions, and the data flows neatly into reports.

But for Oracle Java compliance, "most" isn't enough.

In any large environment, a meaningful slice of the Java evidence is unrecognised by Flexera's built-in library. These are vendor-specific JDK builds, application-bundled Java runtimes, custom internal distributions, and Java installed in non-standard paths. Flexera sees the binary but cannot tell you whether you are looking at Eclipse Temurin (free) or Oracle Java SE 8u311 (RED, requires licensing).

Even on the recognised portion, Flexera reports the recognised title — "Java Runtime Environment 8" — not the precise build. The difference between Java 8 update 202 (free under BCL) and update 211 onward (paid under OTN) hinges on the exact build number, and that detail often lives only inside java -version output, not in the recognition title.

Compliance decisions need that level of precision. So Flexera is the foundation, not the answer.

Closing the Gap with Collection Scripts

To complement Flexera, I built collection scripts for Windows (.cmd) and Linux/SunOS (.sh). They run independently of any inventory agent — anywhere I have OS access, I can collect Java evidence.

The Windows script:

1. Scans the system PATH for java.exe (where java)
2. Enumerates fixed hard drives via wmic logicaldisk where "drivetype=3"
3. Recursively scans each drive for java.exe files (dir /s /b)
4. For every binary found, executes java -version and captures the output
5. Uses locale-independent date/time handling so results parse cleanly across regional settings

The Linux/SunOS script:

1. Enumerates first-level directories from /, excluding /proc, /.snapshots, and /dev
2. Searches each directory for executable files named java (using -executable on Linux, basic -type f on SunOS)
3. Runs java -version on every binary found

Both scripts produce a CSV with one row per installation: server name, full filesystem path, collection timestamp, collection method, and the complete java -version output — all three lines, vendor string included.

That last column is what makes the scripts valuable. The exact build number tells you which side of the BCL/OTN boundary you are on. The vendor string in line two of java -version reveals whether you are looking at Oracle, OpenJDK, Temurin, Zulu, Liberica, Semeru, Corretto, or SapMachine. Flexera's recognition library tries to infer this; the script reads it directly from the binary.

The RED / YELLOW / GREEN Framework

Once evidence is collected, every record needs a classification. I work with a three-colour framework that licensing specialists defined:

RED — Oracle Java requiring commercial licensing.

• Oracle Java SE 8 update 211 or higher (OTN licence — production use needs the Employee metric)
• Oracle Java SE 11+ commercial builds
• Oracle Java SE 17 (any version — the No-Fee Terms and Conditions window expired September 2024)
• Sun Microsystems Java (legacy, still Oracle property)
• Any installation where Oracle's GLAS agent reports active commercial features (Flight Recorder commercial mode, Advanced Management Console)

YELLOW — requires investigation.

• Oracle Java SE 8 updates 1–202 (free under the Binary Code License, but worth verifying that no OTN-licensed components are mixed in)
• Oracle Java SE 21 (currently free under NFTC, expiring September 2026 — flag for monitoring)
• Java embedded in third-party products (MATLAB, Adobe, hardware management tools) — covered by host-product licences, but document the dependency
• Unrecognised evidence that needs manual path analysis
• SapMachine and similar GPL+CPE distributions where the recognition library is ambiguous

GREEN — non-commercial Java, no Oracle obligation.

• Eclipse Temurin, Azul Zulu Community, BellSoft Liberica Standard, IBM Semeru, Amazon Corretto, Microsoft OpenJDK, Red Hat OpenJDK, Oracle OpenJDK from jdk.java.net
• Java embedded in Oracle Database / Client / Hyperion (covered by the host product licence — the Java is part of the Oracle DB stack, not a separate Java obligation)

The licensing rules behind this framework — what counts as RED versus YELLOW, where the version boundaries fall, which embedded scenarios are covered — were defined by dedicated Oracle licensing specialists. My job was to encode their decisions into something repeatable across thousands of installations and to surface every piece of evidence in a form they could actually review.

The Version Boundary Problem

Most of the manual analysis effort isn't on RED or GREEN — it is on the version boundaries inside YELLOW.

Java SE 8 has a hard cliff at update 211. Anything from 8u1 through 8u202 was published under the Binary Code Licence, free for commercial use. Anything from 8u211 onward switched to the Oracle Technology Network licence — production use requires the Employee metric. The transition happened in 2019, but installs from before and after still coexist in nearly every environment I have worked in.

Java SE 17 had a similar inflection point in September 2024, when its NFTC window expired. Before that date, every Java 17 install was free. After that date, every Java 17 install — even ones installed years earlier — became licensable. NFTC expiry is retroactive: it does not grandfather existing installations.

Java SE 21 is on the same trajectory, with NFTC expiring September 2026. That is not a far-future problem; it is an 18-month planning horizon for any organisation standardising on 21 today.

Encoding these boundaries into the classification logic means I can answer "how exposed are we right now?" and "how exposed will we be after the next NFTC expiry?" using the same dataset.

Embedded Java — The Quiet Majority

A surprisingly large share of Java in any enterprise isn't installed by anyone — it is bundled inside other products. Oracle Database ships with embedded Java. Oracle Hyperion does too. So do MATLAB, Adobe Creative Cloud, SAP NetWeaver, hardware management agents from Broadcom and Emulex, and dozens of other applications.

The classification rule: if the host product's licence covers the Java, the installation is GREEN (Oracle DB embedded) or YELLOW (third-party — covered, but document it). If the parent product's licence is unclear, it stays YELLOW until investigated.

Path-based recognition handles most of this. An Oracle Database Client install lives at predictable patterns like ...\Oracle\product\<version>\client\bin\java.exe. A MATLAB install is under ...\MATLAB\<release>\sys\java\jre\. SAP runtimes are under ...\SAP\...\jvm\. Encoding these patterns as recognition rules means thousands of installations classify automatically — leaving only the genuinely ambiguous cases for human review.

Don't Send Raw Data to Oracle

One non-technical lesson belongs in every Java compliance engagement, and it goes in the first customer meeting: never send raw Flexera Java reports — or the output of Flexera's Java module — directly to Oracle.

These reports include unrecognised evidence, embedded Java that is actually covered by other licences, and ambiguous cases that have not been classified yet. Sent to Oracle as-is, they look like a much larger licensable footprint than the customer actually has. They can trigger a licence review the customer was not ready for.

All Oracle-facing data goes through the licensing specialist for review, curation, and sanitisation first. The classification step exists precisely so the customer has a defensible position before any conversation with Oracle starts.

Quantifying Exposure, Identifying Migration Candidates

Once classification is done, the financial picture writes itself: total employees × $10.50/month × 12 = annual list-price exposure. That number is usually what unlocks the migration conversation internally.

The remediation guidance follows directly from the RED list. Every RED installation gets a recommended replacement — typically Eclipse Temurin for general-purpose use, or a vendor-aligned alternative (Microsoft OpenJDK on Azure-heavy environments, Amazon Corretto on AWS, Red Hat OpenJDK on RHEL).

One scope boundary I am always explicit about: I identify what to migrate and recommend the alternative. I don't test whether the customer's applications run correctly on the alternative. That validation belongs with the customer's application and QA teams. Most modern Java apps migrate cleanly to OpenJDK, but a few rely on Oracle commercial features (Flight Recorder commercial mode, Advanced Management Console, GraalVM Enterprise) that don't exist in Temurin. GLAS data, when available, surfaces those cases; the customer's testing confirms them.

Lessons Learned

Multi-source discovery beats single-source every time. Flexera covers most of the fleet but misses the long tail of unrecognised binaries, and it lacks the precise version detail that BCL/OTN classification needs. The collection scripts fill exactly that gap.

Version boundaries are cliffs, not slopes. 8u202 vs. 8u211 looks like a minor update; in licensing terms it is the difference between $0 and a full Employee metric obligation. NFTC expiry is the same — installations don't change, but their licence status flips on a calendar date.

Embedded Java is most of the puzzle. In every environment I have worked in, the majority of Java evidence is embedded in other products. Path-based recognition handles the bulk; the rest needs the licensing specialist's judgment. Without that distinction, RED counts inflate massively and the financial exposure looks worse than it actually is.

The classification work is what buys negotiation room. A customer with raw Flexera data has a problem. A customer with a curated, defensible RED/YELLOW/GREEN position has a starting point — and time to migrate before the conversation with Oracle becomes urgent.