Java licensing on Google Cloud (GCP)

There is a persistent belief that moving a Java workload into a public cloud somehow changes its licensing — that the cloud provider, or the managed service, or the container, absorbs the responsibility. It does not. Google Cloud Platform gives you infrastructure. It does not give you an Oracle Java SE licence. If you run Oracle Java on Compute Engine, GKE, or Cloud Run, the Oracle Java SE Subscription rules apply exactly as they do in your own data centre — and on GCP, the larger problem is that nobody can see how much Oracle Java is actually running. This guide explains the rules, the GCP-specific traps, and the free alternatives.

The principle: the cloud does not license your Java

Start with the rule that governs everything else. An Oracle Java SE licence is a contract between your organisation and Oracle. Google Cloud is a contract between your organisation and Google for infrastructure — virtual machines, managed Kubernetes, serverless runtime, storage, networking. Those are two entirely separate agreements. Nothing in your GCP relationship grants, includes, or implies an Oracle Java entitlement.

So the test for whether you need an Oracle Java SE Subscription on Google Cloud is identical to the test on-premises: are you running Oracle JDK or Oracle JRE, in a build and for a use that Oracle charges for? If yes, you license it. If no — because you run OpenJDK, or a free distribution, or a version covered by the NFTC licence — you do not. The GCP wrapper around the workload is irrelevant to that test. What GCP changes is not the rule but the visibility: cloud estates sprawl, and Oracle Java has a way of arriving in machine images and base containers without anyone deciding it should.

The employee metric applies on GCP too

Since January 2023, Oracle Java SE is sold under the Java SE Universal Subscription, priced on the employee metric. You count your total employees — plus relevant contractors and agents — and pay a per-employee monthly fee, regardless of how many machines run Java. This matters enormously for cloud, because it severs the link between cost and deployment size.

On the old processor-based model, a small GCP footprint meant a small Java bill. Under the employee metric, a single unlicensed Oracle JDK on one Compute Engine VM creates the same licensing requirement as a thousand: once you need the subscription, you buy it for the whole workforce. A 6,000-employee company that discovers one stray Oracle JDK in a GCP image is looking at a subscription priced against 6,000 people. That asymmetry — tiny technical footprint, enterprise-wide financial consequence — is the single most important fact about Java licensing on Google Cloud.

Compute Engine and Oracle Java

Compute Engine is GCP’s infrastructure-as-a-service: you run virtual machines, and on those VMs you install whatever you like. From a Java licensing standpoint a Compute Engine VM is a server. If you install Oracle JDK on it for a commercial workload, you have the same obligation you would have installing Oracle JDK on a physical server in your own building.

Two Compute Engine specifics deserve attention. First, machine images and instance templates: GCP environments scale by cloning. If a custom image used by an instance template contains Oracle JDK, every VM created from that template inherits it. An auto-scaling managed instance group can multiply one image decision into hundreds of running Oracle JDK instances — all of them, under the employee metric, contributing to the same single licensing trigger. Second, marketplace and third-party images: some prebuilt images bundle a JDK, and not all of them are clear about which JDK. An image that ships Oracle JDK rather than a free OpenJDK build silently creates exposure the moment it boots.

GKE and Cloud Run: containers do not help

Google Kubernetes Engine and Cloud Run are where most Java licensing misconceptions on GCP cluster. The reasoning goes: the workload is a container, the container is ephemeral, the orchestration is managed by Google — surely the licensing dissolves somewhere in there. It does not. A container is just a packaging format. Inside the container is a JDK, and that JDK is either Oracle’s (licensable) or a free distribution (not). Kubernetes scheduling and serverless autoscaling do not change which JDK is in the image.

If anything, GKE and Cloud Run make the problem harder to see. A container image is built once and run thousands of times across nodes that come and go. Whatever JDK the base image carries is replicated into every pod and every Cloud Run revision. Nobody “installs” Oracle Java on GKE — it simply arrives, baked into a base image chosen months ago by whoever wrote the first Dockerfile. We cover this dynamic in depth in our guides to cloud-native Java licensing and Java on Kubernetes. The fix is the same on GCP as anywhere: control the base image.

The image trap on Google Cloud

The recurring theme across Compute Engine, GKE, and Cloud Run is the same: on Google Cloud, Oracle Java rarely gets chosen — it gets inherited. A few common paths into a GCP estate:

• A base container image built on a tag that resolves to Oracle JDK rather than an OpenJDK build, copied into dozens of downstream Dockerfiles.
• A custom Compute Engine image created years ago with Oracle JDK pre-installed, still feeding an instance template.
• A vendor or marketplace image that bundles Oracle JDK as its runtime without making that obvious.
• An application install script that pulls Oracle JDK from an Oracle download endpoint as part of provisioning.

None of these involves anyone deciding “we will take on an Oracle Java liability.” They are defaults, inheritances, and conveniences. But under the employee metric, an inherited Oracle JDK costs exactly as much as a deliberate one. Treating base images and machine images as licensing-relevant artifacts — things that get reviewed, approved, and tracked — is the core discipline of staying clean on GCP.

Free Java options for GCP workloads

The good news is that almost no GCP workload needs Oracle JDK. The OpenJDK ecosystem provides production-grade, free, commercially usable builds that run identically on Google Cloud:

• Eclipse Temurin — the widely adopted community build from the Adoptium project, free for commercial use. See our Temurin comparison.
• Amazon Corretto — a free, supported OpenJDK distribution that runs perfectly well on GCP despite the vendor name.
• Azul Zulu and BellSoft Liberica — free OpenJDK builds with optional paid support if you want a commercial backstop.
• Oracle’s own no-fee builds under the NFTC licence — usable without a subscription, but only while a given release stays inside its no-fee window, which makes them a maintenance trap if you do not track end dates.

For the vast majority of GCP Java — microservices on GKE, batch jobs on Compute Engine, functions on Cloud Run — a free OpenJDK distribution is a drop-in replacement. Migrating to one removes the Oracle Java licensing question from the GCP estate entirely. Our migration guide walks through how to do it safely.

How a GCP estate looks in an audit

When Oracle examines a Java audit with a significant Google Cloud footprint, the workflow is familiar. Oracle establishes which Java distributions are in use, looks for Oracle JDK specifically, and — because cloud scales by replication — expects to find the same image running many times. Our guide to how Oracle detects Java covers the discovery side; download records tied to your corporate identity from Oracle’s own endpoints are a frequent starting thread.

The customers who handle a GCP audit well share one trait: they already had an accurate inventory. They could state, with evidence, exactly which images carried Oracle JDK and which carried free OpenJDK, and they had already remediated the Oracle ones. The customers who struggle are those who assumed “it’s in the cloud, it’s Google’s problem” and never inventoried at all — then could not answer the basic question of how much Oracle Java was running. The defence is not an argument; it is an inventory.

A GCP Java compliance checklist

1. Inventory every JDK on GCP. Across Compute Engine, GKE, and Cloud Run, identify the vendor and version of every Java runtime. Distinguish Oracle JDK from free OpenJDK precisely.
2. Audit your base images. Review every custom Compute Engine image, instance template, and container base image for an Oracle JDK. This is where most exposure originates.
3. Check marketplace and vendor images. Confirm what JDK any prebuilt or third-party image actually ships.
4. Map the blast radius. For each Oracle JDK found, trace how many running resources inherit it via templates and image references.
5. Remediate to free OpenJDK. Replace Oracle JDK with a free distribution in the source images — fix it once at the image, not VM by VM.
6. Govern image creation. Make JDK choice a reviewed, approved decision so Oracle Java cannot re-enter the estate by default.

Getting independent help

Java licensing on Google Cloud is not legally complicated — the rule is simply that running Oracle Java means licensing Oracle Java. It is operationally hard, because GCP estates are large, dynamic, and built on inherited images that nobody re-examines. The work that protects you is unglamorous: a complete, accurate inventory, an image audit, and a clean migration to free OpenJDK where Oracle JDK is not needed.

Independent, buyer-side advisers do that work without an Oracle partnership shaping the conclusions. Across 340+ Java engagements, that has helped enterprises find inherited Oracle Java in cloud estates before an audit did and remove it cleanly — contributing to more than $180M in client savings and a 68% average reduction on the claims that did arise. Our Java Compliance Assessment produces the GCP inventory and image audit, our Migration service moves workloads to free OpenJDK, and our Audit Defence service, backed by a money-back guarantee, defends a Java audit if one arrives.

Frequently asked questions