Oracle Java Licensing Changes and Impacts

Java underpins a wide variety of enterprise software, particularly on the server side, and has historically been considered ‘free’ by businesses. However, changes made in 2023 to how Oracle Java is licensed and supported have significantly impacted the way organisations can use Java to support their systems.

This Version 1 article is authored by our Java technical architects Alex Whyte, Tim Burns, Craig McCarthy, Lawrence Fazelynia, Akriti Sinha and Filippo Possenti, alongside license expert Paul Bullen. It combines our collective Oracle Java expertise and highlights the most critical customer-impacting elements that you should be aware of.

We will cover:

A comprehensive overview of the history of Java and alternatives
Discovering your Java usage and the steps involved if you decide to migrate to OpenJDK
Examination of the changes to your Java license and the commercial impacts
Overview of Oracle Java audits and what this means for your business

History of Java as Open Source

Timeline of Oracle Java Licensing Changes

Java was released in 1991 by Sun Microsystems and included the original and reference implementations, runtime environments, and class libraries. One of the key aims behind Java was its portability – write once, run everywhere, rather than needing a specific Operating System.

The Java Community Process (JCP) was established in 1998 as a formalised means for individuals or organisations to add to the Java platform. Anyone joining the JCP signs a legal agreement known as the Java Specification Participation Agreement (JSPA) which sets out rules around Java licensing.

At the JavaOne conference in May 2006, Sun Microsystems announced they were going to release Java as free software under the terms of the General Public License. This caused a great deal of excitement in the open-source community, that Java would at last become a free and open technology.

In 2009 Oracle Corporation acquired Sun Microsystems and in 2010 introduced an updated version of the Oracle Binary Code License Agreement (BCLA) for Java SE. SE refers to the Java Standard Edition which provides the core functionalities of the Java language. Most importantly, SE provides the JDK (Java Development Kit), a software environment which forms the basis for creating and running Java applications. A freely licensable version of this exists known as the OpenJDK which we will discuss more later.

Oracle then introduced the OTN License agreement in 2019 replacing BCLA for certain updates. In 2021, they added No-Fees Terms & Conditions (NFTC) License for Java 17 onwards, stating that it would be free even for commercial usage for an initial release period, subject to the condition of the license.

Most recently in 2023, Oracle released the Java SE Universal Subscription model, replacing all previous commercial models with a new metric. While the Java SE Universal Subscription offers all the same elements as previous commercial models including Java SE licensing and support from Oracle for use on desktop, cloud or server deployments, it makes changes to the way subscription fees are calculated. Subscriptions are now sold on an annual renewal basis using an ‘employee-based metric’ with the price based on how many employees and outsourcers the company has. This could lead to increased costs in your Java license. [Oracle No-Fee Terms & Conditions].

This could lead to increased costs in your Java license.

What if I am using Java SE under BCLA?

Even though Oracle has released different Java license agreements (BCLA, OTN & NFTC) over time, all three still remain valid dependent on the releases they govern or were agreed to when the software was downloaded. BCLA applies to any Java SE versions released before April 16th 2019 which are not using commercial features. At the time of downloading Java SE, you will have been prompted to accept the license terms, see the screenshot below.

Scenario 1 – You are using Java 7 but not using any commercial features, then as per the BCLA;

“General Purpose Desktop Computers and Servers” means computers, including desktop and laptop computers, or servers, used for general computing functions under end user control…”
“Oracle grants you a non-exclusive, non-transferable, limited license without license fees to reproduce and use internally the Software complete and unmodified for the sole purpose of running Programs.”

You can still use it for free but only if the usage of Java SE is under ‘General Purpose’ and you are not using commercial features. As ever, there is an obligation for an organisation to read and understand the terms before accepting them.

Scenario 2 – You are using Java 7 and the usage is not categorised under ‘General Purpose’ or you are using commercial features, then as per BCL;

“You may not use the Commercial Features for running Programs, Java applets or applications in your internal business operations or for any commercial or production purpose, or for any purpose other than as set forth in Sections B, C, D and E of these Supplemental Terms. If You want to use the Commercial Features for any purpose other than as permitted in this Agreement, You must obtain a separate license from Oracle.”

This means your usage will not be categorised as covered by the BCLA: ie you will need a commercial agreement. The recommendation here would be that if you are using any Java SE released before April 16th 2019, under the BCLA, it is recommended to upgrade to the latest version of Java, as well as arrange commercial license coverage. As per Oracle;

“WARNING: These older versions of the JRE and JDK are provided to help developers debug issues in older systems. They are not updated with the latest security patches and are not recommended for use in production.

For production use Oracle recommends downloading the latest JDK and JRE versions and allowing auto-update.”

Where possible, we would advise upgrading to any version from Java 17 onwards as this was categorised free even for commercial purposes under the NFTC license. This will be covered in more detail later in the article.

Java in Enterprises

Despite changes to licensing over the years, Java continues to be widely used for many different applications. From large corporations to small businesses, Java has firmly established its presence as a reliable and efficient choice for building enterprise-grade systems for the following key reasons:

Platform Independence and Portability: Allows applications to run seamlessly on different operating systems and hardware architectures. This reduces deployment complexities and enables enterprises to develop once and deploy anywhere, making Java an ideal choice for businesses with diverse IT infrastructures.
Extensive Ecosystem and Tools: Java boasts an extensive ecosystem of libraries, frameworks, and development tools, providing developers with a wealth of resources to expedite application development. Frameworks like Spring and Hibernate offer robust solutions for building enterprise applications, facilitating rapid development, and simplifying complex tasks.
Scalability and Performance: Enterprise systems often need to handle significant volumes of data and support concurrent user interactions. Java’s scalability and performance capabilities make it an excellent choice for such demanding scenarios. Java’s Virtual Machine (JVM) optimises code execution, allowing applications to scale horizontally and vertically while maintaining high-performance levels.
Robust Security: Security is paramount in enterprise environments. Java’s built-in security features, such as bytecode verification and a robust security manager, contribute to Java’s reputation for safety and reliability.
Mature Language and Community Support: Java’s longevity and widespread adoption have resulted in a mature and stable language with extensive community support. The Java community actively contributes to the development of frameworks, libraries, and tools, ensuring a constant stream of updates, bug fixes, and enhancements.

Oracle’s Java SE Releases and Licensing Changes

If we look to Oracle’s roadmap for Java SE releases and support, here we see how they split releases into LTS (long-term support) and non-LTS releases. A non-LTS release, intended to be a transitionary version, will only receive support up until the subsequent release is available, LTS releases are intended to be more of a ‘mainstay’ version with longer support.

The last LTS version is Java 17, released in 2021. There have been incremental releases (non-LTS) every 6 months since then (versions 18, 19, 20) until the upcoming Java 21 release in September 2023, which is intended to be the next LTS release as outlined in the Oracle Java SE support roadmap.

Alternatives to Oracle’s Java

Aside from Oracle Java SE, several other distributions exist which are based on the non-commercially licensable OpenJDK: 

Amazon Corretto – A distribution of OpenJDK by Amazon under an open-source license at no cost. Corretto receives long-term support and patches including security fixes and performance enhancements. Long-term support (LTS) for Corretto includes performance enhancements and security updates for Corretto 8 until at least May 2026 and for Corretto 11 until at least September 2027 at no cost.
Azul Zulu – A free OpenJDK distributed by Azul Systems. It comes with a standard plan which is free to use, quarterly releases and limited support. However, there are other paid plans which include out of cycle bug fixes, early release access and more responsive support.
Eclipse Temurin – An open-source Java SE build based upon OpenJDK. Temurin is available for a wide range of platforms and Java SE versions and is regularly updated and supported by the Adoptium community.
RedHat – Red Hat is a member of OpenJDK governing board and the largest contributor after Oracle. The Red Hat build of OpenJDK is a cost-free and open-source rendition of the Java Platform, Standard Edition (Java SE). Support for OpenJDK is part of the subscriptions for Red Hat Enterprise Linux, Red Hat OpenShift, and Red Hat Application Services. Additionally, you have the option to obtain a separate subscription specifically for Windows. Long term support is also provided for 8, 11 and 17 with most of them ending by 2023.

All of the above JDKs use the GPLv2 license which is free to use in all environments and pass the Java SE TCK (technology compatibility kit) meaning they can be all labelled as ‘Java SE compatible’. In general, long-term support is provided on the above distributions however, the length and cost may differ for each distribution.

Many other distributions also exist alongside the above, such as AdoptOpenJDK (with older releases still available through online archive), Alibaba Dragonwell, Azul Zing, GraalVM, IBM Semeru Runtime, Microsoft OpenJDK, Liberica JDK, SapMachine.

Oracle Licensing and Commercial Features

A separate license from Oracle is necessary to utilise Commercial Features. These features cannot be accessed under the Java BCLA, NFTC or under the OTN Java license agreement. Below is a list of Oracle’s Commercial Features:

Java Flight Recorder: a monitoring tool which collects information about events in a Java Virtual Machine during Java appliction execution. 
Java Mission Control: presents Java application metrics in more readable formats e.g. charts, diagrams and tables. Originally meant for use with Java Flight Recorder to consume the data produced by it.

Java Enterprise (MSI) Installer: The Java MSI Installer, allows system administrators to quickly and consistently roll out pre-configured Oracle JRE updates to Windows systems via automation tools.
Java Usage Tracker: The Java Usage Tracker is a functionality that gathers data on the usage and performance of Java applications. It captures details such as application startup times, duration of usage, and resource utilization. This information assists developers and administrators in comprehending application behaviour, optimizing performance, and making informed decisions related to resource allocation.
Java Advanced Management Console: Java Advanced Management Console is designed for streamlined Java update management and distribution within organizations. It grants administrators the ability to control Java version deployments, monitor usage, and enforce security policies. With AMC, Java administration becomes more efficient, ensuring consistent and secure Java deployments across the enterprise.
JRockit Mission Control, Flight Recorder and Real Time: Mission Control and Flight Recorder are detailed above. JRockit Real Time is Oracle’s JVM optimized for predictable, low-latency performance in time-critical applications, benefiting industries like finance, telecommunications, and aerospace.

The usage of Commercial Features for running programs, Java applets, or applications in your internal business operations, commercial purposes, production purposes, or any purpose not specified in the Supplemental Terms of BCLA (Binary Code License Agreement) is prohibited without obtaining a separate (commercial) license from Oracle. Therefore, it is important to consider the usage of these features, whether it be for testing and development or for production or ‘commercial’ purposes, before determining whether a license is required.

It is also worth noting that since the release of JDK version 11 in 2018, these commercial features have been made available in the OpenJDK with some minor differences. For example, features in the OpenJDK lack integration with other Oracle products.

Oracle Java Subscription Changes – A Comprehensive Overview of the History of Java and its Licensing Part 1

Learn more from Version 1’s Principal Solution Architect, Akriti Sinha on this customer impacting change – her short video (part 1) includes the history of Java, the license types, license metrics and the release model. Watch now and empower your organisation with the knowledge to clarify your Java estate and plan for migrations and/or any audit approach.

Alternatives to Oracle’s Subscription

The recent Java licensing changes have raised concerns among users. The shift in Oracle’s support model and the potential limitations on updates and patches for older Java versions have prompted some users to explore alternatives to Oracle JDK.

These are the options to consider if wanting to avoid an Oracle subscription:

Migrate from Oracle JDK to OpenJDK:

Commercial Features – If remaining with Oracle JDK, a separate license is required to access Commercial Features. These are included in the OpenJDK but with minor differences. For instance, the OpenJDK lacks easy integration with other Oracle products.

Support – There are various support levels available for Oracle JDK subscription holders. OpenJDK users are more likely to rely on the open-source community for support.

Upgrade to Oracle Java 17 – Oracle JDK version 17 is available free under NFTC license (no Oracle subscription required).

Under the NFTC license, each LTS (long-term support) version is due to receive free support and security updates until at least one year after the subsequent LTS release. As such, without a subscription to Oracle, this option would require regularly updating the Java version to the current LTS release to avoid applications going unsupported.

Migrate to Oracle Cloud Infrastructure (OCI) – Oracle Cloud Infrastructure (pg4) (OCI) is the cloud computing platform provided by Oracle Corporation. It offers a wide range of infrastructure services, including computing power, storage options, networking capabilities, and various cloud-based services.

OCI is designed to provide a highly scalable, secure, and reliable cloud environment for businesses and organisations. It offers Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) solutions.

OCI customers receive a free Oracle Java SE license for use in the Oracle Public Cloud as per the Oracle PaaS and IaaS Universal Credits and Service Descriptions (pg 33).

Oracle Approved Product Use – Oracle provides a list of products for which Java SE is permitted to be run without an additional commercial license. Per the Oracle website, ‘This includes applications developed using specified Oracle products. Schedule A Products and Schedule B Products is the exclusive list of products for the purposes of the definition of Oracle Approved Product Use under the Oracle Technology Network License Agreement for Oracle Java SE. And also, ‘You may run ‘Schedule A’ products on Oracle Java SE for any use. You may also run software applications that were developed by using ‘Schedule B’ products for any use. For example, you can use Oracle Java SE to run an ‘insurance claim’ application provided to you by an insurance company that is an Oracle Forms licensee and used Oracle Forms to develop the application. If you are unsure if the software application that you are using qualifies, please contact your application vendor. Oracle recommends that customers of ‘Schedule B’ products who make applications available to third parties provide guidance to their users regarding their right to use Java with the application. Note that Oracle customers using a ‘Schedule B’ product, which includes Java must maintain a commercial license for the ‘Schedule B’ product.’

Discover your Java usage

Firstly, it is best to start by gaining an understanding of how Java is used within your organisation across all applications and environments. Based upon the outcome of the discovery you should decide which one of the options mentioned in the above section (Alternatives to Oracle Subscription) is best for you.

To map out how Java is being used, you can follow a systematic approach that involves gathering information, conducting interviews, and analysing the existing systems and applications’

Here is a general outline of the process:

Identify Stakeholders:

Determine the key stakeholders who are involved in the development, deployment, and maintenance of Java applications within the company. This may include developers, architects, project managers, IT operations teams, and business owners.

2. Conduct Interviews and Surveys:

Schedule interviews with stakeholders to understand their roles, responsibilities, and involvement with Java applications.

Ask questions about the Java applications they work on, their purpose, the technologies and frameworks used, and any dependencies on specific Java versions or APIs.

Consider distributing surveys to gather information from a larger audience if necessary.

3. Inventory Existing Systems and Applications:

Compile a comprehensive inventory of all the systems and applications within the organisation that are built using Java.

Identify both internal and external-facing applications, including web applications, backend systems, microservices, APIs, and other Java-based solutions.

Capture details such as application names, owners, primary functionalities, Java versions used, third-party dependencies, and any relevant documentation or architecture diagrams.

4. Analyse Code Repositories and Build Tools:

Analyse code repositories, version control systems, and build tools used by development teams to gain insights into the Java codebase.

Identify Java projects, libraries, and modules within the repositories.

Determine the build tools and frameworks used, such as Maven, Gradle, or Ant, which provide clues about the Java projects and their dependencies.

5. Collaborate with IT Operations Teams:

Engage with IT operations teams responsible for managing the deployment and maintenance of Java applications.

Understand their processes for deploying and supporting Java applications, including infrastructure requirements, configuration management, monitoring, and incident management.

6. Review Documentation and Knowledge Repositories: Review existing documentation, knowledge bases, and wikis within the organisation.

Look for Java-related documentation, architectural guidelines, coding standards, and best practices that have been documented.

Identify any existing architectural diagrams or system flow diagrams that depict the usage of Java within the organisation.

7. Consolidate & Analyse the Information:

Consolidate all the gathered information, including stakeholder interviews, application inventories, code analysis, and documentation review.

Analyse the data to identify patterns, dependencies, and commonalities across Java applications.

Group applications based on their business functions, technical requirements, or shared dependencies.

8. Document the Java Landscape:

Create a comprehensive report or document that outlines the organisation’s Java landscape.

Include details about the Java applications, their functionalities, key stakeholders, technologies used, dependencies, and any specific considerations or challenges.

Visualise the information using diagrams or charts, if appropriate, to provide a clear overview of the Java ecosystem within the organisation.

Regularly updating and maintaining this Java landscape document will ensure that it remains a valuable reference for understanding how Java is used within the organisation. It can aid in decision-making, resource planning, and future technology evaluations.

Before committing to migrating to OpenJDK, it is crucial to consider all the factors mentioned above, such as the requirements of project stakeholders and the current utilisation of Java to fulfil those requirements. This assessment should occur after eliminating the final three choices outlined in the ‘Alternatives to Oracle Subscription’ section during the discovery phase. Once a comprehensive understanding of these factors is achieved, a well-informed decision to proceed with the migration can be made.

Migration to OpenJDK

Pilot Migration

To map out how Java is being used, you can follow a systematic approach that involves gathering information, conducting interviews, and analysing the existing systems and applications’

Here is a general outline of the process:

9. Identify Stakeholders:

Determine the key stakeholders who are involved in the development, deployment, and maintenance of Java applications within the company. This may include developers, architects, project managers, IT operations teams, and business owners.

10. Conduct Interviews and Surveys:

Schedule interviews with stakeholders to understand their roles, responsibilities, and involvement with Java applications.

Ask questions about the Java applications they work on, their purpose, the technologies and frameworks used, and any dependencies on specific Java versions or APIs.

Consider distributing surveys to gather information from a larger audience if necessary.

11. Inventory Existing Systems and Applications:

Compile a comprehensive inventory of all the systems and applications within the organisation that are built using Java.

Identify both internal and external-facing applications, including web applications, backend systems, microservices, APIs, and other Java-based solutions.

Capture details such as application names, owners, primary functionalities, Java versions used, third-party dependencies, and any relevant documentation or architecture diagrams.

12. Analyse Code Repositories and Build Tools:

Analyse code repositories, version control systems, and build tools used by development teams to gain insights into the Java codebase.

Identify Java projects, libraries, and modules within the repositories.

Determine the build tools and frameworks used, such as Maven, Gradle, or Ant, which provide clues about the Java projects and their dependencies.

13. Collaborate with IT Operations Teams:

Engage with IT operations teams responsible for managing the deployment and maintenance of Java applications.

Understand their processes for deploying and supporting Java applications, including infrastructure requirements, configuration management, monitoring, and incident management.

14. Review Documentation and Knowledge Repositories: Review existing documentation, knowledge bases, and wikis within the organisation.

Look for Java-related documentation, architectural guidelines, coding standards, and best practices that have been documented.

Identify any existing architectural diagrams or system flow diagrams that depict the usage of Java within the organisation.

15. Consolidate & Analyse the Information:

Consolidate all the gathered information, including stakeholder interviews, application inventories, code analysis, and documentation review.

Analyse the data to identify patterns, dependencies, and commonalities across Java applications.

Group applications based on their business functions, technical requirements, or shared dependencies.

16. Document the Java Landscape:

Create a comprehensive report or document that outlines the organisation’s Java landscape.

Include details about the Java applications, their functionalities, key stakeholders, technologies used, dependencies, and any specific considerations or challenges.

Visualise the information using diagrams or charts, if appropriate, to provide a clear overview of the Java ecosystem within the organisation.

Regularly updating and maintaining this Java landscape document will ensure that it remains a valuable reference for understanding how Java is used within the organisation. It can aid in decision-making, resource planning, and future technology evaluations.

Risks of Migrating to OpenJDK

See below a list of possible risks and challenges that may be faced during migration and some ways these might be mitigated:

Performance Variations & Compatibility Issues: Oracle-specific features, APIs, or libraries may require significant code modifications or replacement with suitable alternatives in the OpenJDK distribution.

Mitigation – Comprehensive Testing: Conduct thorough testing and validation at each stage of the migration process to identify and resolve compatibility, performance, and security issues.

Performance Variations: Differences in JVM implementation between Oracle JDK and the OpenJDK distribution may lead to performance variations that need to be addressed.

Mitigation – Performance Optimisation: Monitor performance metrics and utilise profiling tools to identify performance disparities and optimise applications for the OpenJDK distribution.

Security Considerations: Ensuring the same or higher level of security as with Oracle JDK may require understanding the security features and applying necessary configurations in the OpenJDK distribution.

Mitigation – Security Best Practices: Implement secure coding practices, configure security features of the OpenJDK distribution, and stay updated with security patches and advisories.

Training & Knowledge Transfer: Ensuring a smooth transition requires effectively training developers and teams on working with the OpenJDK distribution and its specific features.

Mitigation – Documentation and Training: Provide comprehensive documentation and training resources to enable developers and teams to effectively work with the OpenJDK distribution and address any knowledge gaps.

Code Change Risk: Any change in a code base will warrant some risk to even the most long-standing and well-established projects.

Mitigation – Collaborative Development: Foster collaboration between development teams, architects, and stakeholders to address challenges and make informed decisions during the migration.

Critical Issues: At any point during the migration process, something may go wrong, whether that’s during build/compilation of a project or post-deployment to a production environment.

Mitigation – Contingency Plans: Have a rollback plan in place to revert to the previous Oracle JDK version or explore alternative solutions in case critical issues arise during the migration.

By proactively addressing potential challenges and risks through meticulous planning, collaboration, thorough testing, and utilising available resources, it is possible to successfully migrate from Oracle JDK to an OpenJDK distribution while minimising disruptions and ensuring a smooth transition.

Oracle Java Subscription Changes – A Comprehensive Overview of the History of Java and its Licensing Part 2

Learn more from Version 1’s Principal Solution Architect, Akriti Sinha on this customer impacting change – her short video (part 2) includes a commercial overview, Oracle Java alternatives and OpenJDK options. Watch now and empower your organisation with the knowledge to clarify your Java estate and plan for migrations and/or any audit approach.

Oracle Java Subscription Changes and the Commercial Impacts

There has been a great deal of confusion in the market surrounding the subscription changes and commercial impacts – this section will take you through these changes in more detail.

By way of background: Oracle (and previously Sun) provided Java SE under the BCLA, typically considered to be zero cost (although not always the case in reality) until early 2019. At this time, Oracle Java SE 8 (and 7) updates became subject to the potential need for a commercial subscription, combining license and support into a recurring cost.

These releases allow access to updated/more secure binaries and were released under the Oracle Technology Network Java SE agreement (OTN Agreement) which provides some rights without a commercial license (see below).

It is important to note that users of Oracle Java SE commercial features (such as the MSI Installer) have always needed some form of commercial license.

Oracle released Java SE 17 in 2021 under yet another license agreement, one which permits usage (in any way) without a commercial license. This is the ‘No Fees Terms and Conditions’ (NFTC) agreement.

The table below summarises your subscription requirements dependent on version/update and usage.

Table

The table above should be used in combination with the explanations below along with the methodology summarised later in this post.

Oracle Commercial Features

The commercial features are outlined in the Oracle Java SE Licensing User Manual (LIUM), relevant based on the version of Java SE in use and features available in each. See this page for more information, however, note that commonly used features such as the Java MSI Enterprise JRE Installer, Advanced Management Console (AMC) or GraalVM will ‘automatically’ require a subscription irrespective of usage/environment. We find a large number of customers in this situation who have inadvertently been using such features (especially MSI Enterprise JRE Installer) who are unaware of the license implications.

OTN Agreement

The OTN Agreement, provided as a ‘click through’ agreement governing later versions of Oracle Java SE, is the set of terms and conditions most users will agree to (on behalf of your organisation) upon download of Oracle Java 8 update 211 through to Java 16 inclusive. Without the existence of a commercial agreement or subscription, these will be the terms and conditions which state the rights under which this Oracle Java SE release can be used (without a commercial agreement).

These rights are summarised below:

You may develop, test, prototype and demonstrate Your Applications – i.e. non-production use of Oracle Java SE which can be classed as development/test or prototyping.
Oracle Approved Product Use – certain Oracle products which have a prerequisite of Oracle Java SE (e.g. Forms and Reports, Oracle applications).
Oracle Cloud Infrastructure use (deploying onto Oracle’s public cloud).

Binary Code License Agreement (BCLA)

As mentioned above, Oracle Java SE was distributed for many years under this agreement without ‘overt’ costs – it goes without saying that you should review the BCL to determine your position. Additionally, given the requirement for a paid-form license for any use of commercial features, it is also important for you to understand your usage in detail.

If your downloads and the usage of these downloads is covered by the rights in the BCLA (and you are not using extra cost features) it is very likely you can continue to be ‘covered’ by this agreement. This will mean that you cannot apply the latest security patches (or any patches since March 2019) to your Oracle Java SE 8 estate.

No Fees Terms and Conditions (NFTC)

This agreement applies to Oracle Java SE 17 for the first three years of its release, at which point, a new Long-Term Support (LTS) release will be made available and a 1 year ‘grace period’ will be permitted to allow migration from the previous LTS version (17) to the next. Should you not undertake this upgrade in the 1-year period, a commercial subscription will be required.

I already had Oracle Java SE subscriptions; do I need to move to the Employee Metric?

If you bought Oracle Java SE subscriptions in Processor / Named User Plus metrics, Oracle says they will allow renewal using these ‘legacy’ metrics. However, this is only if you submit to scrutiny from Oracle Global License Advisory Services (GLAS) as to whether your previous subscriptions were sufficient. If you fail to satisfy Oracle of your ability to count (according to their VMware policy), they are unlikely to honour this renewal and require you to purchase subscriptions on the Employee metric.

How to buy Oracle Java SE

As of Q1 2023, Oracle only officially only sells ‘new’ Java SE deals on the basis of the ‘Employee’ metric; meaning all employees of your organisation plus any outsourcers regardless of whether they use Oracle Java SE. The definition is given below:

all of Your full-time, part-time, temporary employees, and
all of the full-time employees, part-time employees and temporary employees of Your agents, contractors, outsourcers, and consultants that support Your internal business operations.

As a result, Oracle can determine your bill with zero input from you, though of course you verify the true number rather than relying on your annual report. Note that this metric is explicitly measuring your employee population irrespective of usage. Even if only a few of your employees use Oracle Java SE, you will pay a fee for every employee at your company.

Even if only a few of your employees use Oracle Java SE, you will pay a fee for every employee at your company.

Pricing

A ‘tiered’ pricing model is in place and you should expect very low or no discounts, certainly nothing like the 60%-85% often seen in large purchases of ‘classic’ licenses. Oracle’s tiered pricing ‘builds in’ their view of the appropriate discount based on volume.

How to Determine if I Need an Oracle Subscription?

This is not a simple question to answer.

You need to discover all Java in your estate and then classify each installation based on its commercial license requirement, on version / update use and also which Java license agreement could cover the installation e.g. OTN usage for development only/Oracle applications usage.

Typically, organisations discover their desktop and server estates separately, and it is essential to get the correct information. Unfortunately, some of this discovery will be a manual process, talking to people with knowledge of the estate and applications. At this stage, we often find organisations discover either unexpected or ‘excess’ Java installations, e.g. where Oracle Java SE is deployed by default. Of course, there are many good reasons besides licensing to minimise such deployments and streamline your estate.

The diagram below shows a high-level overview of how to approach a discovery of an estate running Oracle Java SE.

If you can ‘easily’ ascertain or already know that you need Oracle Java SE, you do not necessarily undergo the process below (though it is useful to have in order to ‘benchmark’ pricing per the old metrics) and instead purchase subscriptions in line with your employee count or undertake a rapid migration / decommission.

Oracle Java Audits

At this point, the final stage in understanding the implications of Oracle Java’s licensing changes is to consider your approach in the event of a Java audit.

Oracle’s ability to audit your entire Oracle Java estate is limited, as any audit would likely cover only a subset of your estate due to the various types of agreements that will cover your Java SE estate. A comprehensive Java-only audit for a typical enterprise cannot meaningfully take place unless you are bound by one single agreement (which is very unlikely to be the case).

It is crucial to understand your audit obligations and Oracle’s rights as outlined in the mutual agreements you have in place. Evaluating your obligations based on the agreement type is complex but essential for your organisation’s compliance.

Oracle Java Audits and the Associated Threats: The Truth

We frequently receive questions about the likelihood and frequency of receiving an audit notification, the level of risk involved, and whether you should be worried about being audited.

Alarms have been raised in the Java community, however, the reality is that Oracle Java audits are still very rare, and standalone audits focused solely on Oracle Java SE for a typical business (excluding ISVs and distributors) are unheard of. What we have observed are:

Audits that include Java as part of a broader scope.
Extensive inquiries from Oracle before transactions (for renewals).
Requests/demands for ‘assistance sessions’ or declarations.

These generally include conversations with Oracle LMS/GLAS to clarify how you have determined your legacy metric requirements (such as Processor and Named User Plus); specifically focused on VMware.

However, it is important to note that these are not formal audits and do not impose any obligations on licensees. In these situations, there is a delicate balance to be struck. Cooperating with Oracle increases the likelihood of approval for sales under the older metrics.

So, are audits more likely in the future? And what could the cost be to your business?

Remember, under the Employee metric, Oracle can provide a bill without your input by looking at your employee numbers in your annual report. In this case, you are not obliged to pay without a formal audit. Oracle does monitor downloads of later versions of Oracle Java SE and will contact organisations where downloads of newer Oracle Java SE covered by the OTN Java License agreement have taken place.

But there is good news. Typically, auditors for software vendors conduct audits based on their perceived requirements rather than your actual contractual obligations. Several factors come into play here (which also apply to non-Java audits):

The contracts or agreements that Oracle invokes for conducting an audit.
The specific entity being audited.
Your obligations to fulfil the contractually agreed audit rights, including the data you may need to provide.
Timelines.
The scope of the product audit, including the specific products involved (such as Oracle Java SE).

Out of all these factors, the contracts or agreements that grant Oracle the right to conduct audits are the most crucial. Let’s be clear: if you have no agreement with Oracle, they have no authority to audit your organisation.

Let’s be clear: if you have no agreement with Oracle, they have no authority to audit your organisation.

There are a variety of agreement types which govern Oracle Java SE. These are summarised below. It is critical you understand these agreements and the rights Oracle has to audit your organisation.

Table of Oracle Java Agreement Types

Links

Oracle Java License Options

Naturally, customers don’t want to face the risk of audit or unnecessarily pay a large bill for software they may not realise full value from, especially on the basis of employees rather than users.

As a result, many customers are looking to alternatives which may cover their requirements that are commercially favourable to their organisation.

The choices available are wholly dependent on the usage of Oracle Java SE within an organisation and so the below options are necessarily ‘generic’:

Only use Oracle Java SE for Oracle applications; you are very likely to have license coverage for the latest versions under the Oracle Approved Product Use list, as referenced from the OTN Java SE License agreement and found here. If this is the case, then you are permitted to apply / use later versions of Oracle Java SE to support your Oracle applications. Non-Oracle applications cannot use these Java installations, however.
Stay with Oracle Java SE; require latest patches and versions of 7, 8 and 11 across environments: this will require an Oracle Java SE subscription, probably based on the Employee metric.
Stay with Oracle Java SE; require latest patches and versions of 7, 8 and 11 in development only: you may be covered under the OTN Java License agreement (not requiring a commercial agreement) however it is expected this is a ‘theoretical’ scenario as organisations typically use the same versions/updates ‘in sync’ between environments.
Stay with Oracle Java SE; do not apply latest patches to versions of 7 and 8 or use Oracle Java SE 17 (updates 1-12) and not use Oracle Java SE 11 through 16. Assuming the BCL and NFTC agreements are applicable and valid to your use case, there will be no cost for this. However your estate is likely to be vulnerable from a security point of view.
Migrate away from Oracle Java SE; either entirely or for new requirements, and do not use later versions of Oracle Java SE 7u85, 8u211, 11-16. As long as this position can be maintained, and on the assumption that the BCL / NFTC agreements are applicable to your use cases and you aren’t using any commercial features, a paid-for subscription is not required. This option is a panacea for many organisations and you should read this section on the technical considerations for moving away from Oracle Java SE (Discovering your Java usage and the steps involved if you decide to migrate to OpenJDK).

The various scenarios are summarised below. As can be seen, if commercial features OR latest versions are ever in use (except in development only), a subscription will be required.

Table Explaining Necessity for Oracle Java Licensing

Moving from Oracle Java SE to another Java provider

To understand your license requirement for Oracle Java SE, a review of your estate, followed by classification of usage, is required. Depending on how you are using later updates of Oracle Java SE 7, 8 or 11-16, you are likely to require a subscription.

Reviewing your estate is an area Version 1 specialise in. This will enable your organisation to understand the risks and requirements that exist in your estate. Depending on the results of such a review, you may consider moving away from Oracle Java SE to another implementation of Java. This is a technical assessment which requires further considerations both from a technical viability perspective and also for considering license agreements with non-Oracle suppliers of Java.

You will need to understand all deployments and usage within your organisation to assess any residual installations of Oracle Java SE which may require a subscription to be in place.

If you are considering your options and your potential to migrate away from Oracle Java SE, we recommend using this article as your initial guide.

Version 1’s Java license and technical consultants have an unrivalled level of experience and expertise in this technology space and can support you in assessing your Java options. If you have any questions or wish to confidentially clarify your Java position, contact us for assistance.

Video Blog – Oracle Java SE Universal Subscription Changes

In Version 1’s video, Principal Oracle License consultant Paul Bullen will explain what has changed and what you need to do next. Discover the specific steps to gain clarity on your Java estate and the updated pricing for Java SE. Watch now and empower your organisation with the knowledge needed to make informed decisions on your Java strategy.