Article Java: The New Cash Cow for Oracle
Java: The New Cash Cow for Oracle
By Insight UK / 6 Dec 2023 / Topics: Software Software Asset Management (SAM)
By Insight UK / 6 Dec 2023 / Topics: Software Software Asset Management (SAM)
Oracle's recent changes to its Java licensing policy model have been a cause for concern for many businesses and individuals that rely on the popular programming language. In the past, Java was available to use for free in most cases. However since January 2023, when Oracle stepped away from usage related to the Universal Employee model created a shock in the market. Businesses that have any Java usage today, can pay up for all their employees, which can imply they have to pay 2 – 20 times more compared to the previous metrics (NUPs and PROC, which are usage based).
This new policy has caused concerns for many businesses who rely on Java for their daily work. Most companies may not have budgeted for these costs, while others may not agree with the pricing structure. Additionally, it will push businesses to seek out alternatives for Oracle Java, which will have a negative impact on Java's dominance in the market. Nevertheless Oracle made 2 billion in Java Revenue last fiscal year, which is all booked as cloud revenue (given the metric is subscription based).
As with any change, it will take time to see the full impact of Oracle's new licensing policy on the market. We see most businesses still use Java v8 for a variety of Applications (between 75 – 95% of the usage). This impacts also the suggested solutions to overcome the Oracle Java issue.
We see 7 possible solutions for Java:
1. Switching to OpenJDK. This will require significant testing work and is only viable if no paid support is required. Application provider has to approve, to avoid support disruptions and compatibility issues. Only viable when no active Support is required.
2. Switching to third-party Java products. Will also require significant testing work to check for compatibility. Support will be provided by the third-party Java provider. In the viable-but-hard-work category come the options of switching to third-party Java products. Application provider has to approve, to avoid support disruptions and compatibility issues. (Azure Zulu, AWS Corretto and AZUL or RedHat, depending on what Java functionality is used and if Java support is required).
3. Downgrading to Java 8 update 202. This is the last publicly available update and will not require a subscription. This is risky in terms of security, and might conflict with (your) Security Policies.
4. Upgrading to Java 17. This will require significant effort as most functionalities used in Java 8 are no longer available in Java 17. Application provider has to approve, to avoid support disruptions and compatibility issues.
5. Switch to Oracle Cloud Infrastructure (OCI), where Java support is included. Moving all unlicensed Oracle JDK workloads to Oracle Cloud Infrastructure (As Java is included in OCI, similar to Azure Zulu and AWS Corretto).
6. Do nothing, and awaiting Oracle’s attention (Oracle Audit Threat, with all risks and financial exposure). Effectively this will lead to solution 7, with the risk of additional fees for the period of non-compliancy.
7. Lastly, users could simply pay for the new Java SE Universal Subscription, which is simple, but the most expensive option given the new Universal Employee model. Be aware of the metric description, as this also includes, on top of the number of your employees, 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.
We see most clients opting for option 1 or 2, depending on the requirements and internal policies. This is why Option 3, downgrading to Java 8 update 202, should be considered a (very) short term solution.
Option 4: Upgrading to Java v17 or higher, is not considered a valid solution. As Oracle started to modernize the Java programming language from Java v11 onwards, and has declared a lot of functionalities obsolete and removed it in the next version. The impact is that most Java 8 applications will not work on Java 17 (or higher).
The remaining solutions all include engaging with Oracle. These are not advised, as they will have a significant impact on your roadmap, budgeting and/or financial risk.
For sure Oracle is the easiest option to solve your Java issue; however, it is also by far the most expensive one. Assuming you will continue using Java 8 (as you likely might have done for the last 15 years), there is very limited value to get from Oracle Support. As Support is limited to 4 patching rounds per annum, which solve only very rare and niche issues, this might be a very expensive solution. In order to save money we suggest to apply for an exception for the policy (especially if you count all your specific Java Support tickets, you have issued the last 15 years).
So when using predominantly Java 8, you should ask if you want to pay significant fees to Oracle, for limited value. This could only be considered an alternative when switching to other Java is more costly (money or effort wise).
Main questions are two-fold:
1. Does the Application support the OpenJDK version you want?
2. Do you need a supported version of Java?
If the answer to question 1 is affirmative, you could possibly save money and apply for a non-supported version of Java, although internal security policies or local legislation might prevent this.
For on-premise the most popular supported Java versions are Redhat and Azul. Main benefit for these Java versions is the support and knowledge base they provide to do the migration and remove the Oracle Java installations successfully.
For usage in the Public Cloud the relevant versions are Zulu for Azure, Corretto for AWS and Oracle Java (!) for OCI. All these Java versions are supported by the platform (so no additional fee will apply). Please note that, license-wise, deploying Java on any other Public Cloud platform is not allowed by Oracle.
For any clients that already have subscriptions based on the old metrics (NUP and PROC) a new challenge seems to occur. Although Oracle has confirmed that they will keep the old metrics at the next renewal, customers will receive an unsolicited request from Oracle Sales, usually supported by (former LMS or GLAS people), to check that the correct values have been ordered. Especially interest is shown in the VMware architecture, and you are pushed to run scripts or provide data to show that you do not keep any threshold when ordering your subscriptions.
As this is not an official audit, as no notification letter or official announcement was send, it seems the only way to get your subscriptions renewed on the old metrics. We see no contractual or legal ground why you should cooperate with these requests and send any data to Oracle.
Also for next year we doubt if Oracle will still allow to renew on the old metrics, as the Sales guys keep pushing for the upgrade to the new Universal Employee model (where the Oracle Sales will make 5 – 100 times more money per year!).
What does Insight advise when you have Java Subscriptions based on NUPs and PROCs:
1. Do not share any data with Oracle, unless you fully understand what the consequences will imply. Again, the data is requested by Java Sales, so it is not an official audit. Also there is no contractual nor legal basis why you should share such data with Oracle.
2. If you decide to share data anyway, just share, high-level, data only. Meaning only data, which show you have the usage under control (active management).
3. If you decide not to share any data with Oracle, Insight can support you in your journey to move away from Oracle Java.
As a head start Insight can support you with creating a Java strategy that will mandate control and prevent future exposure (governance). So when new hardware or software comes in, it has to be without any Oracle Java. This is also something that the architects of your organization should be aware
If you seek support for solving your Java issue, do not hesitate to contact your Insight contact for more information.
Oracle ULA: How to get the most out of your investment? Watch our on-demand webinar