Java licensing for government contractors.
Cleared workforce, air gaps, and audit risk.

Government and defence contractors run some of the most Java-dependent IT estates in existence — mission systems, integration platforms, data services and legacy applications that have run on the JVM for decades. They also operate under constraints no commercial enterprise faces: cleared workforces, classified and air-gapped networks, supply-chain transparency mandates, and contract structures that determine who ultimately pays for software. Each of those constraints interacts with Oracle Java licensing in ways that can produce surprising exposure. This article walks through the Oracle Java licensing issues specific to government contractors and how to manage them.

Why government contractors are a distinct case

Three things make government contractors different. First, their workforce is unusual: large numbers of cleared staff, subcontractors and consultants, often spread across multiple programmes and facilities. Second, their environments are unusual: classified enclaves, air-gapped networks and accreditation regimes that constrain how software is installed and updated. Third, their commercial structure is unusual: software is frequently bought to deliver a government contract, and the cost flows through to the customer agency under defined contract terms. Every one of these features changes the Oracle Java analysis.

The employee metric and a contractor workforce

Since January 2023, Oracle's Java SE Universal Subscription is priced on the employee metric — total headcount, not Java users. Oracle's definition of "employee" is broad: full-time, part-time and temporary staff, plus the staff of contractors, consultants and outsourcers who support internal operations.

For a government contractor this definition is consequential in both directions. A prime contractor that engages subcontractors to support its own operations may have to count that subcontractor headcount in its Java subscription scope. Conversely, a firm that operates largely as a subcontractor providing staff to a prime is itself an "employee population" that could be pulled into the prime's count. The boundaries of the licensable population are genuinely hard to draw, and getting them wrong — in either direction — produces either overpayment or a backdated audit correction. The starting point is an accurate, defensible headcount definition, agreed before any subscription is scoped.

Java embedded in programme systems and pass-through cost

Much of a contractor's Java does not run on its corporate estate at all — it runs in the systems it builds and operates for a government customer. This raises a question that contracts must answer clearly: who licenses that Java, and who ultimately pays?

If a contractor deploys Oracle JDK inside a delivered system, the contractor is typically the entity using the software and therefore the licensee. Whether that cost is recoverable from the agency depends entirely on the contract — the type of contract, the allowability of the cost, and whether the software was specified or chosen. The risk is a gap: the contractor incurs an Oracle Java obligation it cannot pass through, because the contract never anticipated it. The clean answer is almost always to deploy free OpenJDK in delivered systems, so there is no Oracle Java cost to allocate, recover or dispute in the first place.

Classified and air-gapped environments

Government work routinely happens on networks with no internet connectivity — classified enclaves and air-gapped systems. This collides with how Oracle Java is normally kept current. Oracle's free-use terms for recent JDKs, the NFTC, make a given release free only for a limited period; staying on free, supported Java means continually updating to newer releases. In an air-gapped environment, updates must be manually staged through an accreditation process, which is slow and tightly controlled.

The result is a structural tension: classified systems tend to run older, frozen Java versions for long periods, precisely the versions whose free window may have closed. An air-gapped enclave running an out-of-window Oracle JDK is a clean compliance gap. The remedy is the same as elsewhere — free OpenJDK builds carry no time-limited free window and no commercial-use trap, so an air-gapped system standardised on OpenJDK can run a stable version indefinitely without creating Oracle exposure. Our guide to air-gapped Java licensing covers this in detail.

Supply-chain and SBOM requirements

Government customers increasingly require contractors to deliver a Software Bill of Materials (SBOM) — a complete, itemised list of the software components in a delivered system, including the Java runtime. SBOM mandates are a security and transparency measure, but they have a licensing side effect: an SBOM explicitly documents which Java distribution and version is present.

That documentation cuts both ways. It is excellent compliance hygiene — a contractor that maintains accurate SBOMs always knows its Java footprint. But it also means a contractor can no longer be vague: if an SBOM records Oracle JDK in a delivered system, that is a written, customer-held record of Oracle Java use. The disciplined approach is to use SBOM generation as a forcing function: standardise on a named free OpenJDK distribution so that every SBOM consistently shows a no-cost runtime, and the transparency requirement becomes an asset rather than a liability.

Why contractors face elevated audit risk

Government contractors tend to be visible, well-resourced organisations with large, Java-heavy estates — exactly the profile Oracle's licensing teams prioritise. Several factors raise the audit probability: substantial historical use of Oracle JDK, complex multi-programme environments that are hard to keep consistent, and the perception that contractors can recover costs from government customers (making a claim look more collectable).

The defensive posture is not exotic — it is the standard discipline applied with extra rigour: know your own estate before Oracle does, never hand over raw unreviewed data, and understand that the modern employee metric means a single Oracle JDK instance can be leveraged into a claim priced on the whole headcount. Contractors should treat a Java self-assessment as routine programme hygiene, not a one-off exercise.

A practical approach for contractors

1. Define the licensable population. Establish a defensible, documented headcount definition covering staff, subcontractors and consultants before scoping any subscription.
2. Standardise on free OpenJDK. Mandate a named distribution — Eclipse Temurin, Amazon Corretto, the Microsoft Build of OpenJDK — for both the corporate estate and delivered programme systems.
3. Inventory classified enclaves. Bring air-gapped and classified environments fully into Java compliance scope, even though they sit outside the network.
4. Use SBOMs as control points. Treat every required SBOM as a checkpoint confirming a no-cost Java runtime.
5. Fix contract language. Ensure programme contracts address who licenses and pays for Java — or, better, ensure no Oracle Java cost exists to allocate.
6. Maintain a register. Track every finding and remediation in a Java compliance risk register.

Getting independent help

Government contractors juggle Oracle Java exposure across corporate, programme and classified environments at once — and headcount and pass-through questions have no obvious answers. An independent advisor brings the experience to scope it correctly and the discipline to keep it controlled.

Conclusion

Government contractors carry Oracle Java licensing risk on two fronts: a corporate estate priced on a broad employee metric that may sweep in subcontractor headcount, and the programme systems they build for agencies, where classified enclaves, air-gapped networks and pass-through cost questions all complicate compliance. The employee metric makes the licensable population genuinely hard to define; air-gapped systems drift onto frozen, out-of-window Oracle JDK versions; SBOM mandates put any Oracle Java use in writing; and the contractor profile attracts audit attention. The single most effective response — for the corporate estate and for delivered systems alike — is to standardise on free OpenJDK, which has no time-limited free window, no commercial-use trap and no audit clause, so there is simply nothing chargeable for an audit to find. Across 340+ engagements, this discipline has helped reduce Oracle Java audit claims by an average of 68% and saved clients more than $180M.

Our Java compliance assessment and migration services — backed by a money-back guarantee on audit defence — cover complex contractor estates including classified and air-gapped environments. 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 licensing for government contractors, not legal or contractual advice. Your obligations are governed by your Oracle and government contracts — seek independent specialist and legal advice for your situation.