Oracle Java Versions 6–21: Free vs Licensed (CIO/CFO Advisory Guide)

Note: This guide focuses exclusively on Oracle’s official Java SE distributions (Java 6 through Java 21). It does not cover OpenJDK or third-party Java builds. CIOs and CFOs must understand Oracle’s Java licensing on a version-by-version basis – missteps can lead to compliance issues or unexpected costs.

Oracle’s Java licensing model has changed dramatically over the years, and “Java is free” is no longer a safe assumption in enterprise environments. Below, we break down each Java version (6 through 21), clearly stating whether it is free to use or requires a paid license, under what conditions, the license model in effect (BCL, OTN, NFTC, etc.), update availability, and key timeline milestones.

We then provide blunt, real-world considerations – including audit risks, timing traps (such as “free” Java 17 expiring), and common misunderstandings – followed by actionable recommendations for managing Oracle Java in your organization.

Background: Oracle Java Licensing Models Over Time

Oracle (and Sun Microsystems before it) has used several licensing models for Java SE. Understanding these acronyms will clarify why some Java versions are “free” and others require payment:

• Binary Code License (BCL): This was the original Sun/Oracle license used until Java 8, for public releases before 2019. BCL allowed free use of Java for general purposes, including commercial use, without a fee. Only certain optional “Commercial Features” (such as Flight Recorder in Java 7 and 8) require a license fee. Under BCL, Java was essentially free to download and use on servers and desktops, with Oracle only monetizing support or advanced add-ons.
• Oracle Technology Network (OTN) License: Introduced in April 2019, this license replaced BCL for Oracle Java 8 updates (8u211 and later) and Java 11 through Java 16. The OTN license restricts free use to specific purposes, namely personal use, development, testing, prototyping, and demonstration. Any commercial or production use under OTN requires a paid Java SE subscription or another commercial license​. In other words, after 2019, you could still download Oracle JDK for free, but using it to run business applications in production without a subscription became non-compliant​. This change ended the “free Java for businesses” era unless companies moved to alternatives or stayed on older builds. Oracle Java 8 and 11 (and later OTN-licensed releases) are still free for developers and individual hobbyists, but not free for companies to deploy in production​.
• No-Fee Terms and Conditions (NFTC) License: Introduced with Java 17 (Sept 2021), NFTC is Oracle’s attempt to offer a free Oracle JDK for a limited time on each Long-Term Support (LTS) release. Under NFTC, Oracle JDK 17 and later could be used in production at no cost, but only during a defined free period​. The catch: Oracle provides free updates for an LTS release under NFTC for up to one year after the next LTS release. After that, the license reverts to the stricter OTN model for further updates​. In practice, this meant that Java 17 was free, including for commercial use, from 2021 until late 2024. Once Java 21 (the next LTS) has been out for a year, Java 17’s free update period ends in September 2024 – beyond that, running an updated Oracle JDK 17 requires a subscription, or you must upgrade to a newer free version. Oracle JDK 21 (released in September 2023) is similarly free under NFTC until one year after Java 25’s release (Java 25 is due in September 2025) – i.e., free updates for JDK 21 are expected through September 2026. After that, Java 21 will switch to an OTN-style (pay-required) model for further patches. Non-LTS interim releases (Java 18, 19, 20, etc.) are all provided under NFTC for their brief 6-month lifespans​ , as the next version quickly supersedes them.
• Java SE Subscription (Java SE Universal Subscription): Oracle’s paid licensing program for Java, which gives access to updates/support for Java SE in production. Initially launched in 2018 as a per-processor or Named User Plus metric​, Oracle revamped this to an employee-based metric in 2023 (Java SE “Universal” Subscription). The subscription is effectively an enterprise-wide license – you pay per total employee count (e.g., ~$15 per employee/month for small orgs, scaling down for large ones)​. This can be costly, but it’s Oracle’s intended path if you want to use older Java versions in the long term or prefer not to update to each new free release. Crucially, if you use an Oracle JDK version in production that is not free, you must have a subscription to be compliant. Oracle’s contracts typically stipulate that if the subscription lapses, your right to use those Java versions in production also ends – it’s not a perpetual license. This means organizations must either continuously renew subscriptions or switch to a free alternative before the term ends.

With the above in mind, let’s examine each Java version 6 through 21 and detail whether it’s free to use or requires a license, and under what conditions.

We’ll also note each version’s support timeline (end of free public updates, etc.) as it relates to licensing.

Java SE 6 – Free (Legacy BCL), but Completely End-of-Life

Release: 2006. License: Oracle Binary Code License (Sun era BCL). Free to use? Yes, for all uses – Java 6 was covered by the old free license model. During its supported life, no subscription was needed to run Java 6 in production.

Updates: No longer available publicly. Oracle ended public security updates for Java 6 in February 2013​. Extended support for Java 6 (for paying customers) ended in December 2018. After 2018, Oracle stopped supporting Java 6.

• Usage in 2025: Java 6 is far beyond end-of-life. While you technically can still use the last public Java 6 release (under the free BCL terms) without paying Oracle, it is highly insecure and not recommended. No further patches are available from Oracle (even for $$$). In practice, Java 6 is “free” now only in the sense that it’s abandonware – any continued use is an operational risk rather than a licensing cost risk. Oracle won’t charge you for Java 6, but if Java 6 is still running critical systems, that’s a serious security and compliance concern in its own right.
• Audit risk: Running Java 6 in production is usually not a license violation (since its last binaries were freely licensed), but it flags your organization as outdated. Oracle’s auditors might not fine you for Java 6 use, but they will certainly point out you’re out of support – and might upsell you on upgrades or extended support from third parties. The real risk is that you’ve left your systems open to years of unpatched vulnerabilities.

Bottom line: Java 6 is free to use (no Oracle fees), but it is obsolete. Any enterprise still on six should urgently plan to upgrade or replace it. Oracle will not provide any fixes – consider this version unsupported.

Java SE 7 – Free (Legacy BCL), but End-of-Life (Extended Support ended 2022)

Release: 2011. License: Binary Code License (free use) during its support life. Free to use? Yes, originally free for all uses under BCL. However, public updates ended in April 2015​.

After 2015, Oracle provided security updates to Java 7 only for customers with a support contract, until it finally ended extended support in July 2022.

• Post-2015: If an organization kept using Oracle Java 7 in production past 2015, they would have been stuck on the last free public release (Java 7u80) unless they paid for Oracle’s Java SE support. Oracle delivered additional patches (up to Java 7u331 or higher) to paying subscribers through mid-2022, but those were not publicly available.
• Current status: As of 2025, Java 7 is no longer supported. Oracle ceased all updates after July 2022. The last free public update (7u80, released in 2015) is now long outdated. Like Java 6, Java 7 can still be used under the terms of its original free license (BCL) without direct cost. However, doing so means running almost a decade’s worth of unpatched vulnerabilities.
• License compliance: Using an old Java 7 build (e.g., 7u80) that was downloaded when it was free does not, in itself, constitute an Oracle license violation. However, downloading any later Java 7 update from Oracle’s site would require a support login, and thus a contract. If Oracle audits you and finds you deployed builds of Java 7 that were supposed to be customer-only, that’s a compliance issue. Even if you only use the old, free bits, Oracle will view continued use of Java 7 in production as highly problematic. (They may not fine you for license fees, but they’ll push you to either upgrade or purchase support from a third party.)

Bottom line: Java 7 was free under the old model, but there have been no free updates since 2015. Extended support ended in 2022 – if you need Java 7 fixes now, Oracle can’t help (they’ve completely ended support for it). Running Java 7 without a support contract after 2015 meant running unpatched code or using third-party support.

By now, any enterprise still on Java 7 should consider it an emergency to migrate. The only “free” aspect of Java 7 today is that there is no Oracle fee, but the cost may come in the form of security incidents or forced upgrades.

Java SE 8 – Partially Free; Requires License for Commercial Production (post-2019)

Release: 2014 (LTS). License: Initially BCL (free) for several years; then switched to OTN in 2019. Free to use? Free for certain uses only.

Oracle Java 8 was free for all users until early 2019. Oracle then stopped free public updates for business users and moved Java 8 onto the restrictive OTN license for further updates.

Here’s the breakdown for Java 8:

• Public Updates and License Change: Oracle provided free public Java 8 updates for commercial use up through Java 8 Update 202 (January 2019). After that, beginning with Java 8 update 211 (April 2019), Oracle changed the license to OTN and no longer allowed commercial production use for free​. This means that any Java 8 update released in April 2019 or later requires a Java SE subscription if it is used in production. Oracle’s own FAQ states that Java 8 updates (Oracle JDK 8 and the JRE) are now available to Oracle customers either through support or under the OTN License for limited (non-production) use.
• Free Usage Permitted: Under the OTN license, Java 8 remains free for personal use and development/Testing. Personal use means an individual running Java on their PC for non-business purposes (e.g., games or personal applications) – Oracle continues to offer free Java 8 updates for consumers on the Java official website. Development use (coding, testing, prototyping) is also free. So, a developer can download Oracle JDK 8 and write or test software without paying. However, any “Internal Business Operations’ use – i.e., running Java 8 in production or on employee desktops as part of business operations – now requires a paid license. Simply put, companies cannot legally use updated Oracle Java 8 in production without a subscription. Running Oracle’s Java 8 on a server that processes commercial transactions, for example, triggers the license fee requirement as of 2019.
• Updates and Support Timeline: Public (free) updates for Java 8 effectively ended in January 2019 for commercial users. Oracle has continued to produce Java 8 patches beyond that, but these are delivered to customers with a Java SE Subscription through Oracle’s support portal​. Oracle has committed to providing extended support for Java 8 until at least December 2030 for paying customers​. (Notably, Oracle even waived the extended support fee for Java 8 from 2022-2030, meaning subscribers get those updates as part of the base subscription). For personal users, Oracle has said it will keep Java 8 JRE auto-updates available indefinitely, with at least 18 months’ notice before any cutoff ​ – so home users won’t be forced off Java 8. But for businesses, after 201,9 the only way to get new Java 8 security fixes is via a paid subscription​.
• Common Misunderstanding: Many organizations were caught off guard by this change around 2019​. It’s worth emphasizing: Just because Java 8 was free for years doesn’t mean the latest Java 8 update you downloaded is free now. Oracle’s download page might not slap a price tag on it, but the license file changed. If your admins kept Java 8 updated through 2019-2020 out of habit, you may have unknowingly accepted updates that are “OTN-licensed,” which are not free for production use. In Oracle’s eyes, that puts you out of compliance unless you have a subscription. This is a classic audit trap: companies think “we’re just updating our free Java 8,” but those post-2019 updates are not free for commercial use. Oracle’s Java licensing FAQ explicitly warns that, as of the April 2019 update, commercial users must obtain Java 8 updates through My Oracle Support (i.e. with a subscription).
• Current status (2025): Is Java 8 free or not? – **It’s free for individuals and development use, but a license is required for any commercial production deployment​. ** If your business is running Java 8 in production and you haven’t paid Oracle since 2019, you’re likely out of compliance. Oracle can audit this and demand back subscriptions. The safest free option for businesses still using Java 8 is to use an alternative Java distribution (outside of Oracle) or upgrade to a newer Java version that is free under NFTC (e.g., Java 17 or 21). But sticking with Oracle’s JDK 8 without a subscription is officially not allowed.

Bottom line: Java 8 is no longer universally free for organizations. Development and personal use remain free, but running Oracle Java 8 in production now requires a Java SE Subscription. Public security updates for business users stopped in 2019​, so without paying, you’re either unpatched or non-compliant (or both).

Audit risk is high – Oracle knows that Java 8 was widely used, and they have actively audited firms for unlicensed use of Java 8. If your servers or employee PCs still run Oracle’s Java 8, ensure you either have a subscription or a plan to remediate (upgrade or replace it) immediately. Countless firms have had to true-up licensing costs after Oracle audited their Java 8 installations.

Java SE 9 & Java SE 10 – Short-Lived Interim Releases (Free to use, but obsolete)

Releases: 2017 (Java 9) and 2018 (Java 10). These were non-LTS feature releases with only a 6-month support window each.

License: Both were provided under the Binary Code License (the old free model) since they predated the 2019 OTN change. Free to use? Yes, in principle, free Oracle JDK 9 and 10 could be used in production without a fee under the terms at the time. There was no subscription for Java 9 or 10 because Oracle never offered extended support for them, as they were quickly superseded by Java 11.

Updates: Very limited. Java 9 received its final public update (9.0.4) in early 2018, and Java 10 followed with its final update (10.0.2) in September 2018, just before Java 11 was launched. After that, Oracle provided no further updates for 9 or 10 – not even to paying customers – because these were not Long-Term Support (LTS) releases.

• Production use considerations: If any organization ran Java 9 or 10 in production, they technically didn’t owe Oracle money (since those versions were under the free BCL). However, they would have been running a Java version with maybe one or two patch updates total. Essentially, Java 9 and 10 were transitional versions designed for developers to try out new features, such as modularization in Java 9, rather than for long-term deployments. By late 2018, everyone had to move to Java 11 or revert to version 8, because updates for versions 9 and 10 had ceased.
• Current status: By 2025, Java 9 and 10 will be long obsolete. There’s no support and no updates. They remain “free” only because Oracle never commercialized them, but practically nobody should be running them now. Any enterprise systems stuck on 9 or 10 would be in a worse position than staying on 8, since 9 and 10 had even fewer fixes. Oracle’s support roadmap treats these as footnotes; non-LTS releases are “superseded” once the next version is released.
• License risk: It’s unlikely Oracle will find an organization out of compliance for using Java 9 or 10, because if you’re using them at all, you’re likely not downloading any new binaries (none exist beyond 2018), and those binaries were freely licensed. The bigger risk is operational or security – you’re running an unsupported platform.

Bottom line: Java 9 and 10 were free to use but had essentially zero support lifespan. They are now historical artifacts. If somehow still in use, they should be upgraded immediately.

From a licensing perspective, Oracle isn’t chasing Java 9/10 usage (there’s no subscription offering for them), but their use would indicate extremely poor IT practices. Java 9 and 10 don’t factor into the ongoing licensing strategy – they were free, but “free” isn’t useful if the version is dangerously outdated.

Java SE 11 (LTS) – Not Free for Production (OTN license – Subscription Required)

Release: September 2018 (LTS). License: Oracle JDK 11 is distributed under the Oracle Technology Network (OTN) License Agreement (for public downloads). Free to use? Only for development, testing, or personal use. Commercial use of Oracle Java 11 in production requires a paid license.

Java 11 was a pivotal release: it was the first Long-Term Support version after Java 8, and it arrived just as Oracle changed Java licensing.

Oracle did not offer Java 11 as a free-for-production release (unlike Java 17 later). Instead, they encouraged businesses to either pay for a Java SE subscription or use the open-source OpenJDK builds for Java 11.

Here are the key points for Java 11:

• OTN License restrictions: Oracle’s Java 11 downloads are under the OTN license, which permits use only for personal, development, testing, and demonstration purposes at no cost. Any internal business or commercial production use of Oracle JDK 11 requires a subscription​. Oracle’s FAQ explicitly lists Java 11 as being available to customers via support or under OTN for limited (non-production) use​. In short, if you run Oracle JDK 11 in your enterprise’s servers or workstations, you must be a paying Oracle customer (or you are in violation).
• Public updates: Oracle provided a few public Java 11 updates in the first six months after release (through Java 11.0.2 in early 2019). However, after that, all Oracle JDK 11 updates became available only to Oracle Customers via My Oracle Support. Free public updates for Java 11 ended when the OTN license took effect. (Oracle continued to release OpenJDK 11 updates publicly every quarter, but those were under GPL, not relevant to Oracle’s proprietary build licensing.)
• Support timeline: As an LTS, Oracle offers long-term support for Java 11 for a fee. Premier Support for Java 11 ran through September 2023, and Extended Support is available until at least January 2032 for Oracle customers. That means Oracle will continue to issue Java 11 security fixes for many years – but again, only to paying customers. If you don’t have a subscription, you have no legal access to those fixes.
• Current status (free or not): Java 11 is not free for production use under Oracle’s terms. In 2025, the only way to use Oracle Java 11 with updates is via an active Java SE Subscription. Java 11 is basically in the same boat as Java 8 from a licensing perspective: an OTN license (free for development and personal use, not free for production). The difference is that for Java 11, even the initial release was never “universally free” – Oracle signaled from the start that businesses should either pay or stick with OpenJDK. Many organizations chose to skip Oracle JDK 11 entirely due to these terms, either staying with JDK 8 (in the short term) or moving to alternative JDKs.
• Audit risk: Oracle certainly audits for Java 11 usage. If your IT staff downloaded Oracle JDK 11 to servers without a license, that’s low-hanging fruit for Oracle’s auditors. There’s a known pattern: Oracle tracks who downloads Oracle JDK 11 from their site. If they see downloads from your company domain and you haven’t purchased licenses, expect an inquiry. Running Oracle Java 11 in production without a subscription is exactly what Oracle’s Java compliance teams are looking for post-2019.

Bottom line: For Oracle’s official JDK 11, assume it’s a “paid-only” version for businesses. Unless your use case is strictly non-commercial (development, personal projects), you need a Java SE subscription to use Java 11 in production.

If you want a free solution, Oracle intended that you either upgrade to Java 17 (which later became free under NFTC for a time) or use OpenJDK. But sticking with Oracle JDK 11 without paying is non-compliant. In summary, Java 11 requires a license for commercial use – budget for it or use it at your own risk.

Java SE 12–16 – Interim Releases (OTN licensed – Not free for production)

Releases: 2019–2021 (Java 12, 13, 14, 15, 16 were six-month non-LTS releases). License: OTN License, same model as Java 11.

Free to use? Free for development and testing only; not free for production.

All these versions came out after Oracle’s 2019 licensing change but before the NFTC model. Oracle treated Java 12 through 16 as follows:

• They were made available as Oracle JDK downloads under the OTN license terms (click-through on OTN), which means no-cost use was limited to non-production purposes. If a company, for some reason, deployed, say, Java 14 in production, that would have required a Java SE subscription, just like Java 11.
• In practice, almost no one runs these in production long-term. Each of these releases was superseded within half a year by the next version. Oracle did publish a few quarterly updates for each during its short life. Still, once the next version arrived, the previous one was end of life (non-LTS releases have “Not Available” for extended support in Oracle’s roadmap). Oracle doesn’t offer extended support for non-LTS releases, so even paying customers won’t stay on them.
• Usage scenario: These versions were mainly used by developers to test new features and by early adopters. Enterprises typically either stayed on LTS (8 or 11 at the time) or skipped to the next LTS. If any enterprise used 12–16 in production, it was likely for ephemeral or specific testing environments. Nonetheless, from a legal standpoint, Oracle JDK 12–16 in production without a subscription would be unlicensed usage (OTN violation) – the same as Java 11.
• Current status: All versions of Java 12 through 16 are now out of support, as each was superseded years ago. They are no longer receiving updates, and Oracle now offers no support for them (except to encourage moving to an LTS). If you, for some reason, still run an Oracle JDK 13 binary in production, not only is it unpatched, but you also technically didn’t have the right to run it in prod unless you had a subscription at the time. At this point, Oracle would tell you to move off it (probably to an LTS under subscription or to a current free LTS).

Bottom line: Java 12, 13, 14, 15, 16 followed the “Java 11 rule” – they were not free for commercial use under Oracle’s license. They were short-lived and are now obsolete.

Any enterprise usage should have been under a subscription (though few likely bothered with a subscription specifically for these, instea,d they would have a broader Java SE subscription covering all versions).

For practical purposes in 2025, these versions are irrelevant, except as a historical note; treat them as non-free and no longer run them. If they’re lurking in some environment, eliminate or upgrade them.

Java SE 17 (LTS) – Initially Free under NFTC (through Sept 2024), Now Requires License

Release: September 2021 (LTS). License: Oracle No-Fee Terms and Conditions (NFTC) for initial releases and updates through Sept 2024, then reverts to OTN (paid support required) for later updates​.

Free to use? Yes, but only during the defined free period. Oracle JDK 17 was a major shift: Oracle allowed it to be used for free in production for a limited time as a gesture to win back users. However, that free period has now ended.

Let’s break it down:

• NFTC period (Sept 2021 – Sept 2024): Upon Java 17’s release, Oracle announced that Java 17 would be free for all users (including commercial use) under the NFTC license. This meant organizations could deploy Oracle JDK 17 without needing a subscription, and still receive quarterly updates from Oracle at no cost for a while. According to Oracle’s terms, the plan was to keep Java 17 free until one year after the next Long-Term Support (LTS) release, Java 21. Java 21 was released in September 2023, so Oracle continued to provide Java 17 updates under NFTC through September 2024. Indeed, Oracle’s last free NFTC update for Java 17 was 17.0.8 (released in July 2024) and 17.0.8.1 (a critical fix released in August 2024). The final planned NFTC update was 17.0.8; by October 2024, Oracle JDK 17.0.9 entered the next phase.
• Reversion to OTN (after Sept 2024): After the free window closed, Oracle moved Java 17 updates back to the OTN/Support model. As of October 2024, any new Java 17 update (17.0.9 and onwards) is available only to Oracle Customers via support and under the OTN license for others​. The Oracle roadmap states: “Further update releases of Oracle JDK 17, released as of Oct 15, 2024, are under the Java SE OTN license (same as Java 8 and 11)… Users wanting to continue with permissively licensed (free) versions of Java should move to Oracle JDK 21 or later”. In plain terms: Java 17’s free ride is over. If you want to continue using Oracle JDK 17 in production after 2024 with security patches, you now need to pay for a subscription (or upgrade to version 21).
• Conditions during free period: The NFTC license for Java 17 was quite liberal – it permitted free use in internal business operations and production. Companies could treat Oracle JDK 17 almost like an OpenJDK build for those 3 years. The only major restriction was that you couldn’t redistribute Oracle’s JDK for a fee or bundle it in a paid product (if you were an ISV)​. For most end-user organizations, NFTC’s restrictions were a non-issue. Essentially, Oracle said, “Here’s Java 17; it’s free to use, even commercially. Enjoy… (but we might charge later).”
• Support timeline: Oracle offers Premier Support for Java 17 through September 2026 and Extended Support through September 2029 for customers. So, paying customers can stay on Java 17 until 2029 with updates. But free users have support only through 2024 (the NFTC period). After that, you’re frozen on the last free update. Notably, Oracle continued to provide OpenJDK 17 updates under the GPL through January 2022 (17.0.2), but then relied on NFTC for Oracle JDK users and left long-term 17 updates to the subscription model (and to other OpenJDK providers).
• Current status (2025): If your organization jumped on Java 17 thinking “Oracle finally made Java free again,” note that as of Q4 2024, you must take action. Using Oracle JDK 17 in 2025 now carries the same license requirements as Java 8 or 11 did. The product didn’t suddenly stop working, of course, and the NFTC license does allow you to keep using the versions you downloaded during the free period. (If you have Java 17.0.8 installed, NFTC terms still cover that installation.) However, you will receive no further free updates. Continuing to run Java 17 without updates is risky, but updating to 17.0.9 or later from Oracle means accepting an Oracle Technology Network (OTN) license, which prohibits production use without a subscription. Oracle’s intention is clear: free users of Java 17 should migrate to Java 21 to stay on a free, supported path, or start paying for a subscription.
• Audit risk and “trap”: The Java 17 free period is a potential trap for the unwary. Many companies welcomed Java 17’s free status and deployed it, but might not have documented the “expiry” of that free status. Now, those systems might be stuck on an outdated 17.0.x build. Oracle can audit and won’t find a license violation if you’re still on, say, 17.0.6 (which was under NFTC). But if your admins, not realizing the change, downloaded 17.0.9 in late 2024 or later and applied it, you would technically be running an OTN-licensed update in production without a license – a compliance issue. Oracle has given notice on its website and in the FAQ about Java 17’s NFTC period ending, so they expect organizations to be aware of this. This is a prime example of a timeline trap: free Java isn’t free forever, and one must keep track of those deadlines.

Bottom line: Java 17 was a free LTS for 3 years, but that window has now closed. Through September 2024, Oracle JDK 17 (up to 17.0.8) was free, even for production​use; after that, continued use with updates requires a paid subscription. If you continue using Java 17 without paying, you won’t receive critical fixes, or you’ll violate the license by applying new ones.

Organizations should treat Java 17 now similarly to Java 8 and 11: if you need to stay on it, budget for Oracle support or consider switching to an alternative.

Oracle’s advice is to move to Java 21 for a renewed free period​. Just don’t forget that Java 21’s free period will also end eventually (in 2026). The era of “set and forget” LTS (like we had with Java 8) is over; now it’s “upgrade frequently or pay Oracle.”

Java SE 18, 19, 20 – Modern Interim Releases (NFTC – Free, but short-lived)

Releases: March 2022 (Java 18), Sept 2022 (Java 19), March 2023 (Java 20). These are non-LTS feature releases on the 6-month cadence after Java 17. License: Oracle No-Fee Terms and Conditions (NFTC) throughout their support life​.

Free to use? Yes – free for all uses (including production) during their active support window. However, each of these had only a six-month support lifespan, after which they were superseded, and Oracle provided no further updates.

• NFTC usage: Oracle’s FAQ makes it clear that all Oracle JDK releases for these short-term versions were under NFTC (free for all users)​. That means if you, for example, wanted to run Java 19 in production in 2022, you could do so without any Oracle license fee. Oracle made these interim builds free to encourage adoption of new features and smooth the path for developers to test on the latest version.
• Updates: Each of Java 18, 19, and 20 received at most two quarterly updates before reaching end of life (for example, Java 20 reached 20.0.2 by July 2023). Oracle also provided those updates as NFTC or free downloads. After the next version was released, Oracle stopped updating the previous one, as non-LTS versions are not supported in the long term. There is no extended support for these – Oracle expects users to move on to the next release or an LTS.
• Current status: All of these (18, 19, 20) are obsolete by 2025, as Java 21 and 22 have been released after them. They were free while active and remain free to use, in the sense that the NFTC license for them does not expire. But since they have no updates, any production use now is inadvisable. If someone still runs an app on Java 19 in 2025, they are 1) running it for free (no license issues), and 2) running it with no support or patches (a significant security issue). Oracle would simply tell you to upgrade to a Long-Term Support (LTS) version.
• Compliance: Since these were NFTC, using them in production is still not a license violation. Oracle can’t retroactively charge fees for these versions – they explicitly made them free. That said, Oracle also probably doesn’t expect anyone to be on them now. You won’t encounter a license audit problem with Java 18, 19, or 20 use. Still, an auditor might question why you’re on an unsupported version and encourage you to follow a supported path (which likely means upgrading to 21 or purchasing support for an LTS).

Bottom line: Java 18, 19, 20 were all free (NFTC) releases for their short lives. No Oracle fees are required for any use. But they are now effectively “throwaway” versions. Enterprises should no longer run them, except perhaps in ephemeral test environments.

The key point is that Oracle did not attempt to monetize these interim versions directly – they used NFTC to keep them free. The real monetization comes with the LTS strategy: either you upgrade to each new free LTS or you pay to stay on an older one. While 18, 19, and 20 posed no licensing cost, their practical value was limited to bridging gaps between LTS releases.

Java SE 21 (LTS) – Currently Free under NFTC (through Sept 2026); License Required After

Release: September 2023 (LTS). License: Oracle No-Fee Terms and Conditions license for all Java 21 releases until at least September 2026.

After that, Oracle plans to switch Java 21 to the OTN (paid) model for further updates. Free to use? Yes – Java 21 is free for all users at least until its free period ends.

Java 21 is the latest LTS and, as of 2025, is the preferred free Oracle JDK version for enterprises that don’t want to pay.

Here are the details:

• NFTC terms: Oracle JDK 21 is under the same NFTC license as Java 17 was initially, which “permits free use for all users – even for commercial and production use​.” There is no click-through or named-user nonsense; Oracle treats it as free software for now. This is explicitly intended to cover internal business operations as well (Oracle even clarifies that you can use it to provide services to third parties as part of your internal operations, and you may charge your end customers for your service – that’s still fine under NFTC)​. The only real restriction is you can’t redistribute Oracle’s Java binaries for a fee​ (which is not something end-user organizations typically do anyway).
• Free update period: Oracle has stated it will provide Java 21 updates under NFTC until September 2026​. This is “one year after the next planned LTS (Java 25 in Sept 2025)”. So Java 21 will get about 3 years of free support. This means quarterly updates (21.0.1, 21.0.2, etc.) from Oracle are free to download and use through that date. Important: by September 2026, assuming Java 25 is released by then, Oracle will switch Java 21’s updates to the OTN license (requiring a subscription) for any updates made after that point. In other words, the clock is ticking – Java 21’s free window is finite.
• As of 2025, Java 21 is free and fully supported, with free updates. Enterprises can standardize on Java 21 without incurring Oracle fees for the time being. This is Oracle’s carrot to encourage migration off older Java. If you’re on Java 11 or 17 and didn’t want to pay, moving to 21 gets you back into a “no fee” zone – at least temporarily.
• After the free period: If history repeats, by late 2026, Oracle will expect organizations to either migrate to Java 25 (the next Long-Term Support release, presumably under NFTC at launch) or start paying for Java 21 support. Oracle’s FAQ confirms this plan: after the free period, Java 21 will use the OTN license (the same as used for 8, 11, and 17) for subsequent updates. So, presumably Java 21 update 21.0.13 (if versioning continues) in late 2026 would be subscription-only. Oracle Premier Support for 21 runs through September 2028, Extended to September 2031 – meaning paying customers can stick with 21 through 2031. Free users will effectively be cut off two years into Premier Support.
• Audit/compliance: Right now, using Oracle JDK 21 in production is compliant with no strings attached (NFTC). Oracle can’t penalize you for using what they’ve made free. They want you on it. The main compliance concern is the future: if you remain on 21 beyond the free window, you need to track when that ends. If Oracle audits in, say, 2027 and finds you on Oracle JDK 21 without a subscription after they’ve ended free updates, that could be an issue. Oracle has promised at least a year’s notice for any such change, and it is already spelled out in their roadmap. So, there’s no excuse for being unaware, but it’s up to you to execute upgrades or licensing on time.
• Real-world note: Java 21 includes many new features (e.g., pattern matching, virtual threads, etc.), and Oracle making it free is attractive. But organizations must be careful not to fall into a complacency trap – thinking “we’re safe on Java 21 forever.” The timeline trap here is similar to Java 17’s: if you don’t plan, September 2026 will arrive, and you’ll either scramble to jump to Java 25 or face paying Oracle. Two years can pass quickly in enterprise IT planning. Oracle hopes that frequent LTS upgrades become the norm, effectively forcing an upgrade every 2–3 years for those who want to avoid fees.

Bottom line: Java 21 is free—for—now. It’s Oracle’s current free long-term support (LTS) release under NFTC. CIOs and CFOs can use it today without incurring direct costs. However, mark your calendars for 2026: if you intend to avoid Java fees, you’ll need to migrate to Java 25 or later by the time Java 21’s free support ends.

Otherwise, budget for a subscription starting in late 2026 to keep getting patches on Java 21. Java 21’s free status is a generous window, but not an indefinite promise.

Summary Table – Oracle Java Versions 6–21: License Type & Usage Rights

The table below summarizes each Java version (Oracle builds) from 6 to 21, the applicable Oracle license model, and whether it is free to use or requires a license for production. It also notes key conditions or time limits for free use:

(Sources: Oracle Java SE Support Roadmap​; Oracle Java Licensing FAQs​; Oracle End-of-Life notices)

As the table shows, Oracle’s licensing requirements vary by version and period. In summary:

• Java 6 & 7 – legacy free licenses, but completely unsupported now.
• Java 8 – started free, now effectively requires a subscription for any business use (after 2019).
• Java 9 & 10 – free, but no one should be using them (non-LTS, EOL).
• Java 11 – first version under OTN: not free for prod at all.
• Java 12–16 – all OTN: not free for prod (though short-lived anyway).
• Java 17 – a special case: free LTS until late 2024, now not free for updates.
• Java 18–20 – interim releases under NFTC: free but short-term.
• Java 21 – current free LTS until 2026; will become paid thereafter.

Next, we address the practical implications of these facts – the audit risks, timeline “gotchas,” and misconceptions to guard against – and then give recommendations for managing Java licensing.

Real-World Considerations and Common Pitfalls

Having the raw data is one thing; understanding how it affects your organization is another.

Here are blunt points for CIOs and CFOs to consider:

• “Free Java” Misconception: It’s dangerous to assume any Oracle Java you download is free. Many in IT still think “Java = free” because it was true for a long time. Oracle’s changes in 2019 ended that era​. Now, using the wrong Java version in production without a license is as much a compliance risk as using unlicensed databases or ERP software. Ensure your teams understand that only certain versions (e.g., Java 17 from 2021 to 2024, Java 21 now) are free for production, and even those have expiration dates. Everything else requires a subscription or an alternative distribution.
• Audit and Enforcement Risk: Oracle is actively auditing Java deployments. Java has become a revenue focus for Oracle’s License Management Services. Since 2019, Oracle’s audit strategy has included Java, and many organizations have received unpleasant surprises after assuming Java usage was benign. Oracle tracks downloads – if your admins downloaded Oracle JDK 8 updates or Oracle JDK 11/17 installers from Oracle’s website without a corresponding license, Oracle likely knows​. Oracle reportedly retains download logs for years as evidence​. They also identify companies that bought subscriptions and let them lapse, or companies that have never bought Java despite heavy Java usage (e.g., via tech surveys or Oracle sales insights)​. Expect an audit inquiry if you fit those criteria. Oracle often starts with a “soft audit” (an email asking about your Java usage) – ignoring it or responding inadequately can trigger a formal audit. In short, Java is now on Oracle’s radar: treat it with the same license diligence as any other Oracle software.
• Subscription Model Changes: Oracle’s switch to an employee-based subscription model in 2023 can drastically increase costs. If you anticipated perhaps paying per server, you might be shocked to find Oracle now wants a fee for every employee in your company if you need Java SE licenses. This “all-you-can-eat” model means that even light Java use in a large company can incur a large bill (e.g., a 500-employee firm would pay around $ 90,000/year at list prices). Be aware of this when considering “do we just pay Oracle?” – the cost structure might be very different from the old processor metrics. There’s also no partial compliance: if you use Oracle Java across the org, Oracle will push an enterprise-wide license.
• Timeline Traps – Plan Ahead: The LTS free-period expirations are a trap for the unwary. As mentioned, Java 17’s free period ended in 2024 – any shop that doesn’t keep up will either fall out of compliance or fall behind on patches. Looking forward: Java 21’s free support ends in Sept 2026. It’s wise to put that on your IT roadmap now. Don’t let it sneak up; otherwise, you’ll face a scramble between paying Oracle or rushing an upgrade. Oracle has signaled that it intends to continue this pattern (LTS every 2 years, each free for approximately 3 years). This means a continuous upgrade cycle if you want to stay on free Oracle Java Development Kits (JDKs). Many organizations are not used to upgrading Java every 2-3 years (Java 8 was around for nearly a decade!). This is a cultural shift – plan testing and upgrade processes to handle it, or budget for support if that’s too onerous.
• End of Public Updates vs. Usage: Just because Oracle stopped “public updates” for a version doesn’t mean you can’t use the old version, but it usually means you shouldn’t. For example, Java 8 public updates ended in 2019​; some companies chose to keep using 8u202 indefinitely. License-wise, running 8u202 (the last free public build) is compliant, as it was under BCL. But by 2025, that build is massively out of date – a big security risk. So the choice is either to accept risk, pay Oracle for new updates, or migrate to a newer Java. Staying on an old “free” build is technically an option, but a risky one. CFOs should be aware that not paying Oracle might mean accepting security exposure unless you invest in timely upgrades or third-party support.
• Oracle Approved Product Use Exception: One nuance – Oracle’s OTN license allows the use of Java without a separate license if it is only used to run certain Oracle products (so-called “Oracle Approved Product Use”). For example, if you have an Oracle database or WebLogic server that includes Java, and you use that Java only for that product, Oracle permits that under the product’s license. This means if your only use of Java is embedded in other Oracle software you’ve licensed, you might not need a separate Java SE subscription. However, the moment you use Java for anything else on those systems, that exception doesn’t cover you. Many Oracle enterprise apps bundle Java 8. Oracle has a list of approved products that allow the use of bundled Java. This is a corner case, but worth noting: don’t double-pay Oracle if you’re already entitled via another Oracle product – but also don’t assume that covers all your Java usage.
• Third-Party Java Distributions: Although outside the scope of this article, it’s important to acknowledge that Oracle is not the only source of Java. Many organizations have mitigated Oracle’s licensing changes by switching to open-source or third-party JDK builds, such as Eclipse Temurin, Amazon Corretto, IBM Semeru, and Azul. These are typically based on OpenJDK and are free or have different support models. Oracle even explicitly points out that it stewards OpenJDK, which is open source and free to use​. The existence of these alternatives means Oracle does face market pressure, which likely influenced the free license for NFTC in new LTS versions. However, switching distributions can require testing and validation, and some organizations prefer to stay with Oracle’s certified builds, especially if they rely on Oracle’s support. Just be aware that you have options beyond Oracle if the licensing becomes too costly or cumbersome. (Many CIOs opt to run a free OpenJDK distribution in production to avoid any Oracle license risk, while perhaps using Oracle JDK in dev, where it’s free, then containerize their apps with an OpenJDK runtime. This strategy can eliminate Oracle fees. But it requires alignment between dev and ops to ensure compatibility.)
• Common License Violations: The most common compliance issues we see: (1) Companies still running Oracle Java 8 updates >201 in production without a subscription. (2) Companies running Oracle JDK 11 (or 12-16) in prod with no license (perhaps assuming dev use was okay and not realizing prod wasn’t). (3) Companies that deployed Java 17, got comfortable, and failed to act when it went out of free support, but kept applying updates. These scenarios are exactly what Oracle auditors look for. The cost of back-licensing can be significant, especially under the per-employee model. Oracle may try to charge for the period of unlicensed use retroactively or force a subscription as we progress​. It’s much cheaper to proactively address these issues than to settle an audit after the fact.
• Security and Patching Considerations: Ultimately, beyond licensing, Java is the infrastructure that requires updates. Running an out-of-date Java can expose your business to exploits. Oracle’s patch updates, known as Critical Patch Updates (CPUs), are released quarterly and fix numerous vulnerabilities in Java. If you forego an Oracle subscription, you will either need to accept not having those fixes or rely on an alternative source, such as another vendor’s builds or upgrading to a version that receives free updates. This is an important risk calculus for CFOs: the “savings” of not paying Oracle should be weighed against the potential cost of a security breach or emergency upgrade caused by running an unpatched JVM. In some cases, paying Oracle for peace of mind on an older but stable Java version may be the lesser of two evils compared to a forced, rushed upgrade of a mission-critical system. This is especially true if an application cannot be easily upgraded to a new Java version.

In light of all the above, what should organizations do? The next section provides recommendations and actionable steps to manage Oracle Java effectively.

Recommendations for Managing Oracle Java (CIO/CFO Action Plan)

To avoid both financial surprises and security risks, organizations should take a strategic approach to using Oracle Java.

Here are concrete steps and best practices:

1. Audit Your Java Usage Immediately: Conduct an internal audit to inventory all Java installations in your organization. Identify the version (6, 7, 8, 11, 17, etc.), the vendor (Oracle vs OpenJDK vs others), where it’s installed, and how it’s being used (dev, test, production, desktop apps, server apps, etc.). This is crucial baseline data. Many firms are shocked to discover outdated Oracle JREs on hundreds of PCs or legacy servers still running Java 8 or 7. As a CIO/CFO, demand a clear report. You cannot manage license risk you don’t see. Include build numbers – e.g., Java 8 update 271 (which is an OTN-licensed build) – as that determines whether a license is needed.

2. Identify Non-Compliant Deployments: From the inventory, flag any Oracle builds in production that, according to our breakdown above, require a license. Common culprits: Oracle Java 8 (updates after 8u202) on servers, Oracle JDK 11 on any system, Oracle Java 17 deployments updated after 2024, and Oracle Java 12-16 (if present). These are the installations likely out of compliance. Quantify the scope (how many servers, how many CPUs, or employees are using them) because that’s what Oracle will do in an audit.

3. Decide – Migrate or Subscribe: For each non-compliant or high-risk Java usage, make a decision: either migrate to a free, supported Java path or pay Oracle. For example, suppose you have a critical system on Oracle JDK 8. In that case, options include upgrading it to Java 17 or 21 (to remain free), switching to an OpenJDK 8 build from another vendor (free, third-party support), or purchasing Oracle Java SE subscriptions to cover the cost. Evaluate the effort and cost of each route:

• Upgrading to a newer Java version (17/21): This eliminates license fees and puts you on a supported version, but it may require code testing or even application vendor certification. If feasible, it’s a long-term win (remember to plan the next upgrade by 2026).
• Switching to OpenJDK or third-party builds: This keeps you on the same Java version but with a different distribution that is free or cheaper. This can often be done with minimal or no code change since Oracle JDK and OpenJDK are byte-for-byte the same in many versions. The risk is low, but you should test for any subtle differences (e.g., font rendering, default cryptography providers); these are usually minor or non-issues. Many organizations have done this successfully to avoid Oracle fees.
• Purchasing an Oracle Subscription: If neither upgrading nor switching is viable in the short term (perhaps due to application vendor support or internal resource constraints), budgeting for Oracle’s Java SE Universal Subscription is a fallback option. Be mindful of the employee-based model – it may be expensive. However, Oracle has also been known to negotiate, especially if it’s part of a broader deal. If you go this route, ensure you right-size the contract. Maybe you don’t need to license every single employee if not all use Java – negotiate what “employee” means in your context. And factor this into your IT budget multi-year planning.

4. Prioritize High-Risk Environments: Focus on remediation in production and widely used desktop environments. Development-only uses of Oracle Java (like an engineer’s IDE using Oracle JDK) are low risk (they’re allowed under OTN​), and you can address those eventually by moving to OpenJDK to simplify. But an internal business application running on Oracle JDK without a license is a ticking bomb. Also, focus on externally facing apps and critical infrastructure – those should be on supported (patched) Java, whether via Oracle or not. An internal app that a handful of users run might be lower urgency.

5. Stay on Supported Versions (LTS Strategy): Given Oracle’s new release cadence, a sensible strategy is to standardize on Long-Term Support (LTS) versions and regularly upgrade them. For example, many organizations plan to widely deploy Java 17 (or 21) and already have it on their roadmap to move to Java 21 (or 25) within a year of its release. Treat it like you treat Windows or RHEL upgrades – part of the maintenance cycle. This approach lets you leverage the free period of each Long-Term Support (LTS) release. Yes, it means an upgrade every 2-3 years, but Java upgrades have gotten smoother (Java’s backward compatibility is strong). The benefit is no license fees and always having a recent, supported Java. If this upgrade tempo is too fast for your slower-moving applications, then you might decide to keep some apps on one LTS and pay Oracle for extended support. Do this consciously: e.g., “Application X is vendor-locked on Java 11, we’ll pay Oracle support for Java 11 through 2025 while we work with the vendor or plan its replacement.” That beats ignoring it and then facing an audit.

6. Educate and Institute Controls: Ensure that your IT staff, including developers, system administrators, DevOps, and desktop support, are aware of Oracle’s Java licensing traps. Implement policies such as:

• Downloading Oracle JDK: Require approval before anyone downloads Oracle Java from the official site for use in production. Oracle tracks it​. It may be better to forbid using Oracle’s distribution for production altogether, to avoid mistakes. Use OpenJDK builds for production and perhaps allow Oracle JDK only in development if needed.
• Auto-update on desktops: If Oracle JRE 8 is installed on PCs, the auto-update can quietly update to an OTN-licensed build. For personal use, that’s fine, but on corporate-managed PCs, that’s arguably not “personal use.” It’s a gray area. Many firms decided to turn off auto-update and freeze on the last free Java Runtime Environment (JRE), or replace it with an alternative JRE. Ideally, remove the dependency on Oracle JRE on desktops entirely (most browsers dropped Applet support; if internal apps need Java, package a runtime with them).
• Procurement involvement: Ensure that any procurement of software that includes Java or any vendor communications about Java support are reviewed for license implications. Some third-party app vendors started bundling OpenJDK to avoid exposing customers to Oracle licenses. But others might tell customers, “You need to have Java installed (bring your own).” If it’s the latter, you must take that into account in your compliance.
• Retire Unused Java installs: Many PCs or servers have Java installed “just in case” or because an old app needed it. If it’s not actively needed, remove it. This reduces your potential non-compliance footprint. Oracle can’t audit what isn’t there. Principle of least installed software.

7. Stay Up-to-Date with Oracle’s Announcements: Oracle has promised at least 18 months’ notice for ending free updates for Java 8 on consumers​ and will presumably similarly communicate about the end of Java 21’s free period. Monitor the Java SE Support Roadmap on Oracle’s site and Oracle’s Java newsletters. Mark the next LTS releases on your calendar (Java 25 in September 2025, Java 27 in 2027, etc., following the two-year cycle). Oracle’s policies can evolve – for instance, if Oracle decides the NFTC model isn’t working, they could change course (though they would still have to honor existing license terms for what has already been released). Staying informed will help you avoid being caught off guard by a licensing change.

8. Consider Third-Party Support if Stuck: If you have an older Java (say Java 6, 7, or even 8) that you absolutely cannot upgrade due to legacy system constraints, and Oracle’s support is too expensive or no longer available, consider third-party Java support vendors (like Azul, IBM, Red Hat etc., depending on version). For example, Azul provides extended support for Java 6 and 7 beyond Oracle’s end of life (EOL​). They supply security fixes under their license. This can keep you secure and legally compliant, even without Oracle, though it comes with its own costs and testing considerations. The key is not to run unsupported and unpatched to avoid Oracle fees. If you can’t upgrade and won’t pay Oracle, pay someone to help or increase the mitigation of security (segmentation, monitoring).

9. Segregate Oracle Java uses if licensing. In some cases, you might decide to pay Oracle for certain environments (e.g., production) but not for development or testing. Oracle’s OTN license does allow free dev/test use for free​, and Oracle typically doesn’t require a license for non-production use. However, their new subscription counts employees, not machines, which complicates this. If you truly only need to license a subset of use, speak with Oracle or a licensing expert about structuring that – for example, you might keep most usage on OpenJDK and buy a small number of Oracle licenses for a specific product that requires Oracle JDK. Be careful, though: the per-employee model is all or nothing in many cases, although Oracle might make exceptions. Suppose you can isolate an Oracle-Java-dependent application (e.g., an Oracle E-Business Suite that needs Oracle JDK) on certain servers and not use Oracle Java elsewhere. In that case, you have a case to argue for limited licensing.

10. Document Your Java License Posture: Finally, keep a current document of your Java license posture and the decisions you make. Note which Java versions you use, under what licenses, and why it’s compliant (e.g., “Java 17 on App X – using Oracle JDK 17.0.6, which was under NFTC free license, will upgrade or purchase support by Sept 2024”). Having this on record will help demonstrate to any auditor that you are on top of the situation, potentially preventing an audit from escalating. It also helps internally to avoid institutional knowledge gaps – if key IT staff leave, you don’t want the organization to forget that a certain upgrade was needed.

Closing thought: Treat Oracle Java like you would treat any proprietary software that had a license ticking clock. Oracle has bifurcated Java into two paths: a fast lane (upgrade frequently, but for free) and a slow lane (stay on old versions, but pay). There’s no universally right or wrong choice – it depends on your organization’s ability to adapt and its appetite for subscription costs. CIOs and CFOs should weigh the cost of subscriptions vs. the operational cost of regular upgrades.

Some will find it cost-effective to pay and not worry about upgrades for, say, five years or more on a stable LTS. Others will prefer to invest in automation and testing to stay current and never pay a dime. What’s crucial is that this is a conscious, informed decision, not an accidental outcome. The worst scenario is to do nothing and end up both out of date and out of compliance.

By following the above steps and staying vigilant, you can avoid the common Java licensing pitfalls. Oracle’s Java is powerful and still widely used – there’s nothing wrong with using it, as long as you manage it proactively.

In summary, know your Java estate, stay on supported versions (or pay for support), and avoid being caught off guard. Java may not be free like it once was, but with careful planning you can minimize costs and risks associated with Oracle’s Java licensing.