Licensing Oracle Java in Development, Test, and Production

Licensing Oracle Java in Development, Test, and Production

If your developers use Java, you’ve probably heard both:

• “It’s free for development!”
• “You need a subscription for everything!”

Both are partly true — and that’s the problem. This guide explains what’s actually free and what’s not, so you can stay compliant across development, test, and production environments. (For background on Oracle’s new licensing model and how it evolved, see our Licensing Models & Metrics Explained guide.)

Pro Tip: In Java licensing, where you use it matters more than how much you use it.

The Three Usage Environments That Matter

Oracle’s licensing model distinguishes between three key usage environments:

1. Development & Testing – Creating and validating software internally.
2. Internal Production – Running applications in live use for your business or employees.
3. Redistribution or Commercial Use – Embedding or delivering Java as part of a product or service to others.

Each has different licensing implications — and Oracle enforces them differently. Let’s break them down.

Oracle Java Licensing by Environment

Pro Tip: Development is free — until your build server becomes production. In other words, treat any critical system running Java as production once it’s part of delivering your business services.

Development Use – When It’s Truly Free

For modern Java versions, Oracle allows free use of the Oracle JDK for development and testing under certain conditions.

The key is which version and license you’re using:

• Oracle JDK 17 and later (NFTC builds): Oracle’s No-Fee Terms and Conditions (NFTC) license covers these for general-purpose internal use. This means local developer machines and internal test/CI servers running JDK 17+ can use Oracle’s official JDK at no cost. No paid subscription is needed as long as you stick to the NFTC versions (e.g,. Java 17, 21 during their free support window).
• OpenJDK and Third-Party Builds: Development teams can always use OpenJDK distributions (like Eclipse Adoptium, Amazon Corretto, Azul Zulu, etc.) freely. These builds are functionally equivalent to Oracle JDK without the commercial strings. For development purposes, they’re a safe bet if you want to avoid any Oracle licensing worries altogether.
• Older Oracle JDK versions (Java 8, Java 11 under OTN terms): Watch out! These were distributed under Oracle’s Technology Network License (OTN), which is much more restrictive. While OTN technically allowed “development and testing” use at no cost, it was only for non-commercial, evaluation purposes. In practice, if you’re using Oracle JDK 8 or 11 in a business environment today (even just on dev machines or build servers), you’re likely out of free-use territory. Oracle ended public free updates for these a long time ago, so any continued use in development requires a paid license or subscription (or else you should stick to an outdated build, which is risky). In short: upgrade to an NFTC-covered version or switch to OpenJDK to stay safe.

Real-world example: A developer writing code on a laptop with Oracle JDK 17 or an OpenJDK build is fine (no license needed).

But a developer using Oracle JDK 8u311 (an update released under OTN) on their work machine would need the company to have a Java SE subscription – because that version isn’t free for commercial use, even in dev.

The same goes for your Jenkins or CI server: if it’s running Oracle JDK 17, you’re in the clear under NFTC; if it’s running Oracle JDK 8 or 11, it’s time to either get a subscription or swap it out.

Pro Tip: Check your Java version — not your job title — to know if you’re covered. “Developer” usage is free only if it’s on a version of Java that Oracle permits free use.

Internal Production – Always Licensed

The moment Java is running in production, Oracle considers it a licensable activity. “Production” generally means any environment where Java is used to support business operations or provide services to end users (internal or external).

It’s not about whether the app is customer-facing or just internal; it’s about being actively used for the business. Here’s what that entails:

• Internal business applications: If you have enterprise applications, server-side services, batch jobs, or middleware running on Oracle Java (JDK or JRE) to serve your employees or internal processes, you need a paid Java license for those installations. Under Oracle’s policies, internal use for business purposes is considered commercial use. The free dev/test allowances do not apply once the system is doing real work.
• Same version, different rules: It might be the same Java 17 that your developers used for free in testing, but when you move that application into production (even inside your firewall), the NFTC free ride ends. Oracle’s No-Fee Terms explicitly do not cover production use beyond a certain point. In fact, as of 2025, Oracle JDK 17’s free period has expired – so any production use of JDK 17 now requires a subscription. For newer LTS versions like Java 21, Oracle provides a temporary free production window under NFTC, but it’s temporary. The rule of thumb: assume any production deployment needs licensing unless you’re 100% sure a no-fee policy still covers the specific version.
• Java SE Subscription: To license production use, Oracle offers Java SE subscriptions. Originally, these were per-server or per-user, but since 2023, Oracle has moved to an employee-based Java SE Universal Subscription model. That means if you have any Oracle Java in production (outside the free terms), you’re supposed to count all employees in your organization for licensing. This can get expensive fast (even if only a few apps use Java) – see our Licensing Models & Metrics Explained for a deeper dive. The key point is: there is no casual “just install it and forget it” free option for production. Either pay Oracle, or use an alternative Java distribution that doesn’t require Oracle licensing.
• Staging and “pre-prod” environments: Be careful here. Suppose a test or staging environment is connected to production data or is a critical part of rolling updates to production. In that case, Oracle might consider it part of your internal business operations. By strict definition, OTN free use is for non-production purposes only. But if that staging server is essentially a clone of prod and always running, it’s safer to treat it as production for licensing purposes (or use OpenJDK on it to avoid any doubt).

Pro Tip: Production starts where the business runs — not where the code builds. In other words, if a Java instance is actively supporting business users or processes (even behind the scenes), treat it as production and ensure it’s licensed.

Read about Java NFTC agreement, Understanding Oracle’s No-Fee Java License (NFTC).

Redistribution or Third-Party Use

Another scenario with clear licensing rules is when you redistribute Java or allow third parties to use it as part of your product or service.

Oracle draws a hard line here:

• Embedding Java in your software: If you package Oracle’s Java runtime (JRE/JDK) with an application you deliver to customers or include it in a device/appliance, you must have a distribution license from Oracle. You cannot legally ship Oracle’s Java to third parties just under the free terms. This kind of use is considered beyond “internal” or “development” – it’s a commercial redistribution. Oracle typically requires ISVs and device manufacturers to sign a separate agreement (and usually pay royalties or fees) for this privilege.
• SaaS and cloud services: Even if you aren’t handing out the Java binaries, if you’re running a service for customers that relies on Oracle Java, that’s effectively commercial use. For example, a SaaS platform or a public website running on Oracle JDK is customer-facing production – it needs to be licensed. Oracle might not call this “redistribution” since you aren’t packaging Java for download. Still, it falls under the same umbrella of not being free because third parties (your customers) benefit from it. The only scenario where this might be free is if you strictly use an OpenJDK build for your service instead.
• Third-party software in your environment: What if you use a vendor’s product that includes Oracle Java? This is tricky. Generally, if a third-party application you installed comes with Oracle’s JRE, you are responsible for licensing it unless that vendor has an Oracle distribution license covering customer use. Most vendors do not cover it—they often just expect clients to have Java installed. So, from a compliance perspective, that embedded Java counts as your usage. Always verify with your vendors: if their software requires Oracle Java, do they include it in a deal with Oracle, or is it on you to license? Don’t assume it’s free because it came bundled.
• No-Fee Terms and redistribution: Oracle’s NFTC license for Java explicitly allows internal use and even “hosting” (running services for others) as long as you aren’t actually giving anyone the Java binaries. However, redistribution for a fee is prohibited under NFTC. If your product includes Java in any form and you charge for that product, you’re squarely in commercial territory and need an Oracle license.

Pro Tip: Once Java leaves your firewall, it leaves the free zone. If Oracle Java is part of anything you deliver to customers or users outside your company, assume you need to pay for it (or find an open alternative).

Common Confusion Scenarios (and Answers)

To solidify the rules, let’s look at some real-world scenarios and whether they require an Oracle Java license:

• Scenario: Developers using Oracle JDK on their laptops (writing code, compiling, local testing).
  License Needed? No, if they’re using an Oracle JDK version covered by NFTC (Java 17 or newer during its free period) or an OpenJDK build. Developer workstations are considered for development use, which is free under those terms.
  Explanation: Oracle permits free internal development use on newer JDKs. Just avoid using an old Oracle JDK that’s not covered by free terms (or you’ll need a subscription).
• Scenario: A Jenkins CI server running tests on Oracle JDK 17.
  License Needed? No, as long as JDK 17 was obtained under NFTC. That testing server can use Java 17 at no cost for internal testing tasks.
  Explanation: NFTC covers general-purpose use, including testing. A continuous integration server that’s not serving end-users can run Oracle JDK 17 without a fee. (If that same server were using an older Java version, it would be a different story.)
• Scenario: A Jenkins server (or other build automation) using Oracle JDK 8 to compile and test software.
  License Needed? Yes. Oracle JDK 8 (updates after early 2019) is under the OTN license, which, in a company setting, requires a subscription outside of pure personal or evaluation use.
  Explanation: Even though this is a “test” system, Java 8’s license no longer allows free use in a commercial context. You’d either need to have Oracle Java SE subscriptions for that server or replace it with an OpenJDK 8 distribution, which is free.
• Scenario: An internal web application running on Oracle JDK 17 in production (accessible by employees only).
  License Needed? Yes. Once you deploy that app for real use in the business, you need to count it under your Oracle Java subscription.
  Explanation: The NFTC’s free usage of Java 17 does not extend to production use after the free support window. As of now, running Java 17 in any production capacity (even internal) without paying violates Oracle’s terms. Production = license required.
• Scenario: A public-facing SaaS product or website built on Oracle Java.
  License Needed? Absolutely yes.
  Explanation: This is a commercial service running on Java, which requires a paid license (Java subscription) for however many servers or employees Oracle’s metric demands. No free use covers customer-facing production. If you want to avoid that, you’d need to run it on an OpenJDK distribution instead of Oracle’s.
• Scenario: Using Amazon Corretto or Eclipse Adoptium (OpenJDK builds) for any of the above.
  License Needed? No (specifically for Oracle Java).
  Explanation: These distributions are not Oracle’s commercial binaries; they are free and open source. Oracle’s licensing doesn’t apply to them, so you owe Oracle nothing. Just ensure you download updates from those providers and not Oracle. Many companies switch to these to sidestep Oracle fees, though you won’t get Oracle’s support or certain proprietary tools.

Checklist – License Self-Check by Use Case

Use this quick checklist to self-audit your Java usage and avoid accidental non-compliance:

• Identify all Java installations, builds, and versions in each environment (Dev, Test, Staging, Prod). You can’t secure what you haven’t discovered – make an inventory.
• Verify the licenses for each Oracle JDK in use. Are they version 17 or later (covered by NFTC during its free period)? Or older versions that fall under the stricter OTN license? If older, do you have subscriptions in place, or can you replace them with a free alternative?
• Confirm that you are not unknowingly redistributing Oracle Java. This includes installers, containers, or embedded devices that might package the JRE/JDK. Also, confirm that no Oracle Java is hidden in any third-party apps you deliver to customers. If it is, address it with the vendor or plan to license it.
• Ensure all production systems running Oracle’s Java have the appropriate paid subscription coverage. This could mean having a Java SE Universal Subscription that covers your whole company, or legacy Java SE subscriptions for specific servers/users if you’re still on those. Production use without a license is a ticking time bomb for audits.
• Document the separation between free and paid usage. Keep clear records of which Java versions are deployed to which environments. For example, you might use Oracle JDK 21 (NFTC) in dev/test but Red Hat OpenJDK in prod to avoid fees. Make sure it’s recorded. If Oracle comes knocking, you’ll want an audit trail showing you’ve kept usage within the free entitlements.

Pro Tip: Audit your pipelines and lab environments – your CI server or “sandbox” VMs might be quietly running Oracle Java. Those are exactly the targets Oracle’s auditors look for in companies that assume “it’s just dev, we’re fine.” Be proactive and you won’t be caught off guard.

Old perpetual licenses vs subscription, Java SE Subscription vs Java SE (Perpetual) License.

5 Rules for Using Oracle Java Safely Across Environments

Keep these five rules in mind to stay on the right side of Oracle’s licensing terms:

1. Development ≠ Free Forever: Just because Java is free in development now doesn’t mean it stays free later. Only Oracle’s NFTC builds (current LTS versions during their no-fee period) qualify for truly free use in dev/test. As soon as that period ends or if you’re on an older version, you need to re-evaluate licensing. Don’t get too comfortable thinking “we’re just developers, we don’t pay” — it depends on the Java version and license.
2. Test Servers Can Be “Production”: If a test or QA server is accessible to end users or integrated with live production data/systems, treat it as production for licensing purposes. Oracle cares about internal business use. A QA environment that’s constantly up, used in operations, or customer-facing for demos is effectively a production environment. License it or use a free alternative, but don’t assume “test” always means free.
3. Never Redistribute Oracle Java Without Permission: Packaging Oracle’s JRE/JDK with your software or device requires a contract with Oracle. There’s no grey area here — you either don’t bundle it, or you get a redistribution license (or ensure the end-user downloads Oracle Java themselves under their own license). If you ignore this, you risk liability for unlicensed distribution. When in doubt, use an open-source JDK if you need to embed Java.
4. Use OpenJDK Where Feasible: The easiest way to avoid Java licensing headaches is to use an OpenJDK-based distribution whenever possible. It’s the same code (Oracle’s OpenJDK is the reference for Oracle JDK), just under a GPL license. Whether it’s Adoptium, Corretto, Zulu, or another, these can run your dev, test, and even production workloads with no Oracle fees. This isn’t always possible (some enterprises require Oracle support or specific Oracle-only features), but when it is, it’s a big weight off your compliance checklist.
5. Track Your Java Usage Over Time: Keep records of which Java builds run where, and update them whenever you upgrade or patch. Version drift causes audit pain. For instance, if you quietly updated a server from Java 17.0.10 to 17.0.13, you crossed from free to licensed territory in late 2024. You should know that and have a plan (upgrade to 21, buy a subscription, or switch to OpenJDK) before Oracle asks. Good asset management and regular reviews of Java usage across environments will save you from nasty surprises.

Pro Tip: Free Java is real — but only if you control your environments. Staying safe means staying on top of which Java you use, where you use it, and under what terms. A little homework now prevents a lot of compliance pain later.

Following these guidelines will help ensure you can leverage Java for development and operations without stepping on Oracle’s licensing landmines.

When in doubt, err on the side of caution: assume production use isn’t free, double-check the license of any Oracle JDK you deploy, and consider OpenJDK if the restrictions are too heavy.

By understanding when Oracle Java can be used freely and when a paid subscription is required—and being mindful of redistribution triggers—you can keep your team productive and your organization compliant.

Read about our Java Advisory Services

Do you want to know more about our Java Advisory Services?

Please enable JavaScript in your browser to complete this form.

Name *

Email *

Company

Message *

Submit