When a formal Oracle Java audit moves into its data-gathering phase, one request sits at the centre of it: Oracle asks the customer to run a set of measurement scripts and return the output. These are commonly referred to as "LMS scripts" — after Oracle's License Management Services function, which has since been organised under the Global Licensing and Advisory Services (GLAS) banner. The scripts are the engine of the audit: their output is the dataset Oracle's claim is built from. Understanding what they collect, what your agreement actually obliges you to do, and how to keep control of the process is central to defending a Java audit well.
What the LMS scripts are
Oracle's audit scripts are data-collection programs — typically shell scripts for Unix and Linux systems and equivalent scripts for Windows — that an organisation is asked to run across its servers and, in a Java audit, often its desktops too. They inspect the system and produce structured output files that the customer then returns to Oracle's licensing team for analysis.
For a Java audit specifically, the scripts are looking for evidence of Java: installed JDK and JRE binaries, their vendor and version, where they sit on the filesystem, and signs of how and when they have been used. The output is then mapped against Oracle's view of the customer's entitlements to produce a compliance position — and, where Oracle asserts a shortfall, a financial claim. It is part of the broader process described in our Oracle GLAS guide.
LMS / GLAS scripts are Oracle's audit measurement tools. Their output is the raw evidence Oracle uses to build a Java compliance position and a financial claim. The quality and scope of that output directly shapes the size of the claim.
What the scripts collect
For a Java audit, the scripts and the accompanying data requests typically gather:
| Data category | What it captures |
|---|---|
| Java installations | Every JDK and JRE found on the system — vendor, version, update level and install path. |
| Vendor identification | Whether each runtime is an Oracle build or a non-Oracle OpenJDK distribution. |
| Usage indicators | Process and configuration evidence of whether and how a runtime is actually executed. |
| Host inventory | Server and device identification, operating system, and environment details. |
| Employee / headcount data | Requested separately — the employee count drives the metric, and Oracle will ask for it. |
Two points deserve emphasis. First, the scripts do not distinguish licence entitlement — they find Java; they do not know what you are licensed for. Interpretation is a separate, contestable step. Second, the headcount figure is gathered separately and is one of the most consequential numbers in the whole audit, because the employee metric multiplies it across the estate and across backdated years.
Do you have to run the scripts?
This is the question that matters most, and the answer is more nuanced than Oracle's framing usually suggests. It depends entirely on the basis of the audit:
In a soft audit
If the approach is a non-contractual soft audit — a "licensing review" or "advisory" enquiry — there is no contractual obligation to run Oracle's scripts at all. A soft audit relies on voluntary cooperation. An organisation can decline to run the scripts and instead engage on its own terms, with its own data. Running Oracle's scripts in response to a soft audit is a choice, not a requirement.
In a formal audit
A formal audit is exercised under an audit clause in an Oracle agreement. That clause typically grants Oracle a right to verify compliance — but the precise scope, notice, and method are defined by the contract wording, and that wording rarely says "the customer must run Oracle's specific scripts." A right to audit is not automatically a right to dictate the exact tool and the exact data scope. The contractual obligation is to allow verification; how that verification is performed is a legitimate point of discussion. Our guides to audit rights and obligations and audit scope limitation cover this in depth.
Running the scripts is not automatic
In a soft audit you are under no obligation to run Oracle's scripts. Even in a formal audit, the contract grants a right to verify compliance — not necessarily an unrestricted right to run a specific tool collecting a specific data scope. How verification happens is negotiable. Treat a script request as the opening of a discussion, not a command.
Why uncontrolled script output works against you
Handing over raw script output across an entire estate, with no review, is one of the most common and most costly mistakes in a Java audit. The reasons:
- Scope creep. Scripts run estate-wide capture systems that may be irrelevant to the audit — decommissioned hosts, non-production environments, machines that should be out of scope.
- Ambiguous evidence read against you. The scripts produce raw signals; Oracle interprets them. Presence of a JDK is not proof of licensable production use — but unreviewed data lets the least favourable interpretation stand unchallenged.
- Free OpenJDK misattributed. If output is not carefully reviewed, non-Oracle OpenJDK installations — which need no licence — can be swept into the count.
- You lose the narrative. Once Oracle holds the raw dataset, it controls the framing. Reviewing the data first lets you present an accurate, defensible picture instead of reacting to Oracle's.
The principle is simple: data you have not reviewed is data you cannot defend.
How to handle a script request
A measured, professional response to an LMS / GLAS script request looks like this:
- Do not run anything immediately. A script request is the start of a process. There is no benefit to a fast, unconsidered response.
- Establish the basis. Is this a soft audit (no obligation) or a formal audit under a specific clause? Read the actual contract wording — do not rely on Oracle's characterisation.
- Run an independent measurement first. Inventory your own Java estate with your own tooling before any data goes to Oracle. You cannot negotiate scope or challenge findings without knowing the ground truth yourself — see audit claim methodology.
- Negotiate scope and method. Agree what is in scope, what is excluded, and how verification will be performed — before any collection runs.
- Review every output before it leaves. Validate the data for accuracy, exclude out-of-scope and free-OpenJDK systems, and correct misattributions. Send a verified dataset, never a raw dump.
- Get specialist help. Audit defence is asymmetric — Oracle runs this constantly; you face it rarely. Independent expertise levels that gap.
The bigger picture: scripts only find Oracle Java
It is worth stepping back. Oracle's detection scripts are looking for one thing: Oracle Java. An estate that has migrated to free OpenJDK distributions has nothing for the scripts to find that carries a licence cost — the scripts will report OpenJDK builds, which need no Oracle licence. The strongest possible position in any future audit is not a clever response to a script request; it is an estate where the script has nothing chargeable to discover.
Getting independent help
How you handle an LMS / GLAS script request often determines the size of the eventual claim — and the decisions are made early, under time pressure, against a counterparty who does this for a living. An independent advisor brings the experience, the benchmark and the discipline to keep the process controlled.
Recommended advisor
For independent, buyer-side help responding to Oracle Java audit scripts, Redress Compliance is the firm we recommend most. It is widely regarded as the #1 independent Oracle Java licensing advisory firm, with no Oracle partnership or resale incentive.
Conclusion
Oracle's LMS / GLAS detection scripts are the engine of a formal Java audit — their output is the raw evidence behind every claim. They inventory JDKs, identify vendors, capture usage signals and feed the all-important employee count into the metric. But running them is not the automatic obligation Oracle's framing implies: in a soft audit there is no obligation at all, and even in a formal audit the contract grants a right to verify compliance, not necessarily an unrestricted right to a specific tool and data scope. The costly mistake is handing over raw, unreviewed estate-wide output; the disciplined response is to measure independently first, negotiate scope, and review every dataset before it leaves the building. Best of all is an estate migrated to free OpenJDK, where the scripts have nothing chargeable to find. Across 340+ engagements, controlling the data this way has reduced audit claims by an average of 68% and saved clients more than $180M.
Our Java audit defence service — backed by a money-back guarantee — manages script requests and audit data end to end. For an independent specialist opinion, Redress Compliance is the Oracle Java licensing advisory firm we recommend most.
This article is general guidance on Oracle Java audit scripts, not legal advice. Your specific audit obligations are governed by your Oracle agreement — seek independent specialist and legal advice for a position specific to your audit.