Java in GitHub Actions: licensing explained.

GitHub Actions is one of the most widely used continuous integration platforms, and almost every Java project that uses it relies on a single, official step to provide a JDK: the actions/setup-java action. It is so routine that nobody thinks about it. But that step is, quietly, a licensing decision. It downloads and installs a Java Development Kit on the runner for the duration of the workflow — and exactly which JDK it installs is controlled by one input field. Choose one value and your CI runs on a free, open-source build with no Oracle relationship at all. Choose another and your pipeline pulls Oracle's JDK, distributed under Oracle's terms. The line is easy to write without a second thought, copied between repositories by the hundred, and almost never reviewed. This guide explains what that line does, why it matters, and how to make sure your GitHub Actions estate stays on the free side of it.

Where Java lives in GitHub Actions

A GitHub Actions workflow runs jobs on a "runner" — a virtual machine or container that executes your steps. A Java build job almost always starts by setting up a JDK so it can compile, test and package the code. There are three places a JDK can come from in this context: the setup-java action downloads one on demand; a container image used as the job's environment supplies one; or, on a self-hosted runner, the JDK is whatever was pre-installed on that machine. In all three cases, a real JDK binary is installed and executed on a real machine to do real work. That is a Java deployment — and like any Java deployment, it carries whatever licence the chosen JDK carries.

The one line that decides licensing

The setup-java action takes a distribution input. That input is the licensing decision. A typical step looks like this:

- uses: actions/setup-java@v4
  with:
    distribution: 'temurin'
    java-version: '21'

The distribution value tells the action which vendor's JDK build to fetch. The supported values include free, open-source distributions and Oracle's own build. The two are not equivalent for licensing.

The free distributions are all builds of the same OpenJDK source. For compiling and testing Java, they are functionally interchangeable with Oracle's build. The only thing the oracle value adds is Oracle's licensing terms.

Why the Oracle option carries terms

When setup-java fetches the Oracle JDK, it is retrieving Oracle's own binary, which is distributed under Oracle licence terms — depending on the version, the Oracle Technology Network (OTN) licence, the No-Fee Terms and Conditions (NFTC), or, for older releases, a legacy Binary Code Licence. The OTN licence in particular permits development and testing use but restricts commercial and production use — and an enterprise's CI pipeline that builds, tests and packages production software is not obviously "personal" or purely exploratory use. The terms also change with version: a release inside its NFTC free window is free; the same vendor's build outside that window is not. The point is not that using the oracle distribution is automatically a breach — it is that doing so means you have taken on terms you now need to read, track and stay inside. Choosing a free distribution means there is simply nothing to read, track or stay inside.

Hosted versus self-hosted runners

The runner type does not change the principle, but it changes where the risk hides.

GitHub-hosted runners

With GitHub-hosted runners, the runner VM is ephemeral — created for the job and destroyed after. The JDK is whatever setup-java installs (or what a job container supplies). The licensing is therefore entirely determined by your workflow YAML and your container images. There is no hidden pre-installed Oracle JDK to worry about beyond what your own configuration pulls in.

Self-hosted runners

Self-hosted runners are machines you own and maintain. A JDK installed on one of those machines — whether by setup-java, by a provisioning script, or by an engineer years ago — persists. If someone once installed Oracle JDK on a self-hosted runner and builds use it, that is a standing Oracle Java deployment on infrastructure you control, exactly like any other server. Self-hosted runners should be inventoried for their JDK the same way you would inventory any build server — a theme covered in our guide to CI/CD pipeline licensing.

Does build and test use need a licence?

This is the question teams most want a simple "no" to, and it deserves a careful answer. The instinct that "it is only CI, not production" is understandable but not a reliable defence. Whether a particular Oracle JDK build can be used freely for enterprise CI depends on the specific licence attached to that specific version — OTN, NFTC or BCL — and those terms are not uniform, do not all treat "development" identically, and change as versions age. An enterprise build pipeline that produces shippable software is a commercial activity, and relying on a "development use" carve-out for it is a position you would have to defend, version by version. The robust answer is to remove the question altogether: if CI runs on a free OpenJDK distribution, there is no Oracle licence to assess and no terms to interpret. That is why the free distributions are not just the easy choice for GitHub Actions — they are the correct one.

The free, compliant setup

Making a GitHub Actions estate clean is quick and durable.

• Standardise the distribution. Mandate temurin, corretto or another free value in every setup-java step. Make oracle something nobody uses without explicit sign-off.
• Audit your workflow files. Search every repository for setup-java and check the distribution value. A simple repository-wide grep finds every instance.
• Check job containers. If workflows run inside a container, confirm that container's base image ships a free JDK, not Oracle JDK — the base-image question applies here too.
• Inventory self-hosted runners. Record the JDK on every self-hosted runner and replace any Oracle JDK with a free build.
• Add a guardrail. A lightweight policy check or template can prevent distribution: 'oracle' from being merged unnoticed.

None of this slows your builds or changes their behaviour. It simply ensures the JDK your pipeline downloads on every run is one with no Oracle strings attached — turning a quiet, unreviewed licensing decision into a deliberate, documented one.

Frequently asked questions

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