Java audit data collection: what to share.

When Oracle opens a Java audit, the headline tension is the eventual claim — the seven-figure number that lands in a settlement letter. But the claim is downstream of something far less dramatic: the data. Every figure Oracle puts in front of you is built from information you provided. The audit is, in effect, won or lost in the data-collection phase, when the question is not "how much do we owe?" but "what exactly are we going to hand over, and what are we not?" Treating data collection as a routine IT request — run the script, return the output, move on — is the single most expensive mistake an organisation can make in a Java audit. This article sets out what Oracle asks for, what you are genuinely obliged to provide, and how to run a data-collection process that produces an accurate, scoped, defensible record instead of a loaded weapon.

Why data collection decides the audit

An Oracle Java audit is not a search of your environment. Oracle does not walk your data centres or log into your servers. It works almost entirely from data you supply — spreadsheets, scan exports, deployment lists, answers to a questionnaire. That dependency is your single greatest point of leverage, and it cuts both ways. Hand over a clean, accurate, properly scoped dataset and the audit proceeds on facts you have verified. Hand over a sprawling, unverified, over-inclusive dataset and Oracle will build its claim from your worst-case numbers — counting dormant binaries, non-production installs, decommissioned hosts and duplicate detections as live commercial usage. The data-collection phase is where the size of the claim is actually set. By the time a number is on the table, the arithmetic has already been done on the inputs you chose to provide.

What Oracle typically asks for

A Java audit — whether it arrives as a formal LMS audit or a softer questionnaire — usually opens with a broad request for data. Common items include the following.

The defining feature of the opening request is breadth. Oracle asks for far more than the audit clause in your contract actually compels, on the reasonable expectation that most organisations will simply comply. The first job of a disciplined response is to separate what is requested from what is required.

What you are actually obliged to provide

Your obligation in an audit is defined by the audit clause in your Oracle agreement — nothing more. If you hold a Java SE Subscription or an OMA/OLSA, that clause sets the scope: the products covered, the notice period, the cooperation expected. It does not give Oracle an open-ended right to anything its auditors find convenient. Understanding that boundary is central, and it is covered in detail in our guides to your audit rights and obligations and the contractual basis of audit rights.

Several principles follow from the clause. You are generally obliged to provide accurate information about your use of the licensed Oracle products — not a tour of every system you own. You are entitled to a reasonable timeframe to assemble that information. You are not obliged to run software you have not reviewed, to answer questions outside the audited products, or to volunteer interpretations and admissions. Where a request goes beyond the products and scope the contract defines, you can — and should — push back. Scope limitation is a legitimate, contractually grounded part of audit defence, not obstruction.

The cost of over-sharing

Over-sharing is the most common and most expensive failure in Java audit data collection. It happens because the instinct to cooperate — to be seen as transparent and helpful — runs straight into an auditor whose job is to maximise the claim. Every additional data point you provide is a data point Oracle can interpret in the way least favourable to you.

Consider the concrete ways an over-broad dataset inflates a claim. A raw scan typically counts every Java binary it finds, including non-Oracle distributions like Temurin or Corretto that carry no licence cost at all — if the export is not cleaned, free installs get folded into the "Oracle" total. It counts dormant installations that are installed but never executed. It counts non-production environments — test, development, training, disaster recovery — that may be treated differently from production. It counts decommissioned hosts still lingering in a stale CMDB. It counts the same machine multiple times where a scan deduplicates poorly. Each of those is a line in a spreadsheet, and each line, unchallenged, becomes a unit in Oracle's claim. We have seen opening Java claims fall by well over half on data accuracy alone — before a single commercial argument is made — simply because the original submission counted things that should never have been counted.

The discipline is straightforward to state and hard to follow under pressure: provide what is accurate, relevant and required — and nothing else. Volunteered context, casual email commentary, and "while we're at it" extra exports are not goodwill. They are evidence.

Run your own scan first

The most important single move in Java audit data collection is to scan your own environment before you send Oracle anything. You cannot decide what to share until you know what is true. An independent internal assessment — ideally a structured compliance assessment — gives you several things Oracle's process will never give you.

• An accurate baseline. You learn how much genuine Oracle JDK usage exists, separated cleanly from free distributions that carry no cost.
• Time to remediate. Anything found before submission can often be removed, replaced with a free build, or relicensed — reducing exposure rather than documenting it.
• The ability to verify Oracle's figures. When Oracle's number arrives, you can check it against your own, line by line, instead of accepting it.
• Control of the narrative. You present a scoped, verified dataset on your terms, rather than reacting to whatever a raw script produces.

This is also where you understand how Oracle detects Java usage in the first place — download records, scripts, and prior support contacts — so that your own picture matches the evidence Oracle is likely to hold.

A disciplined handover process

Treat data collection as a controlled project with a single point of accountability, not a scattered set of IT tasks. A defensible process has a consistent shape.

• Route everything through one owner. A single named lead — supported by licensing counsel or an adviser — controls all communication and all data leaving the organisation. No engineer sends an export directly to Oracle.
• Confirm scope in writing first. Before collecting anything, establish which products, entities and environments the audit clause actually covers, and document that understanding.
• Collect internally, review internally. Gather data into a private working set. Review it for accuracy — deduplicate, exclude free distributions, separate non-production, remove decommissioned hosts — before any of it is considered for release.
• Map requested to required. For each Oracle request, decide whether the contract compels it. Provide what is required; decline or narrow the rest, with a contractual reason.
• Submit deliberately. Share scoped, verified datasets with a clear covering note describing what they contain and how they were prepared. Keep a copy of everything sent.
• Say nothing extra. No volunteered interpretation, no admissions, no informal commentary. Facts only, in writing, through the single channel.

Done this way, data collection stops being the phase where the audit is quietly lost and becomes the phase where it is quietly controlled. The numbers Oracle works from are numbers you have verified; the scope is the scope the contract defines; and the eventual negotiation starts from a defensible position rather than an inflated one. For how that connects to the rest of the process, see our guides to the first 48 hours of an audit and audit negotiation tactics.

Frequently asked questions

This article is general information on Oracle Java licensing, not legal advice. Oracle's terms vary and change over time. Consult qualified counsel and an independent Java licensing specialist for advice on your specific environment.