With the new metric, a single dependency could result in huge expenses
Java is a backbone for millions of applications.
Over the years, the performance, scalability and faster processing provided by Java have led to the development of most enterprise applicationsin Java, which consequently depend on its capabilities to perform some key tasks.
For example, in the financial environment where software programs are used to perform front and back office electronic trading activities, data processing, etc., Java plays a key role in writing server-side applications that receive data from a server, process it, and send the processed data to other servers or processes.
These dependenciesdo not exclude the application that the italian Revenue Agency makes available to users and companies for the purpose of using telematics tools for tax management and collection. The use involves downloading Java to allow it to function smoothly.
Until now (almost) no problem: companies, in licensing Java, counted users and processors that used Java. But with the new per-employee metric, which was introduced in January 2023, the tables are turned: the new licensing model provides that the count for commercial use of Java will end up with all the company personnel, not just the users and processors that use the programs.
Therefore a single dependency of applications used by Java versions that require licensing can present an expensive bill. If the cost of licensing is $15 per month/employee up to 999 employees and $5.25 per month/employee for users between 40,000 and 49,000, you could have an expense increase up to 15 /20 times, to be multiplied by the number of applications requiring Java licensing.
Not all uses of Java require licensing: there is a difference between downloading a Java application under a GNU license (as from the open source OpenJDK platform) or under a BCL/OTN agreement (OracleJDK). This difference has roots in the history of Java, which prior to its purchase by Oracle was free for commercial use.
In the case of downloads from Oracle, which has added proprietary features to the Java suite, it plays a key role in determining wheter or not to license the version of Java that has been downloaded
When we are looking at the Java installations that we have on our pc, we need to take into account all the software that forced us to "house" Java and trace it back to the agreement and consequently to the downloaded version. For a more in-depth discussion of which versions require licensing, we refer to this article.
We come to the example case of the italian Revenue Agency. To use the applications on which the telematics tools depend, users and companies must download Java, as specified by the italian Revenue Agency:
Java Virtual Machine version 1.8 and higher must be used to perform the software installation..
Below screenshot from the Revenue Agency website (authentication required):
The common thought regarding these installations is the following: since the download is not intentional, but "forced" by an external entity (in this case the Italian PA tax agency), the downloader is not responsible for the use of Java (and consequently for the license).
As a general rule it might also be valid, but we should not leave anything out: when we discover any application dependencies from Java for third-party software, we need to read what are the ISV (Independent Software Vendor) programs in order to find out the actual responsibility for using Java.
ISV programs are those relationships between those who produce a complete solution and those who provide tools for that solution to work and so in our case Oracle with Java. From reading ISVs, two cases can emerge:
Let us give examples related to ISVs.
The ACME software house, in order for its software to work, needs to integrate Oracle Java: therefore, it has entered into an agreement with Oracle in which it is reported that it is ACME that gives the right to use Java and assumes towards Oracle all the relevant responsibilities. If we think of its wide use in PA, in catering for example, the non-liability on the license allows us to breathe a sigh of relief.
BLOB's case is different: it knows that for its software to work, Oracle Java must also be installed on the client where its application will run, but it decides not to make any agreement with Oracle. BLOB leaves it up to the user of its product to comply with any obligations to Oracle.
Let’s go back to the case of the italian Revenue Agency: who is responsible for Oracle Java? Is there an ISV program between the authority and Oracle? We are in the second scenario: there is no agreement between Oracle and the italian Revenue Agency, so any licensing of Java is the responsibility of the end user.
At this point, we need to evaluate the options.
The first idea we came up with is soon refuted: from the tests we have done, Agency applications do not work with OpenJDK; therefore, we cannot think of replacing Oracle Java with OpenJDK. So by necessity we must have Oracle Java installed: is that a problem?
We have verified that the Revenue Agency applications work with Oracle Java 1.8, version 202. So they run with a version that still meets the Binary Code License (BCL), an agreement that provides for free use in case of "general purpose."
General Purpose includes all those activities that are in support of our day-to-day business and do not contribute to our -- to use Oracle's words -- "internal business." Thus, if indeed the use of Revenue Agency applications falls under the General Purpose (and here it is to be ascertained with the vendor), the use is NOT subject to license payment.
What is certain is that each software application using Java may have a different scenario, so we recommend a thorough investigation of application dependencies and licensing responsibilities for Java. Especially given the high licensing costs that await us with the new metrics, it is imperative to evaluate all alternatives. We also discussed this in our last webinar (link to get the recording qui).
At WEGG we are experts in Java licensing, so if you need support in learning more about these issues, please do not hesitate to contact us.
Article by Giulio Gregori, SAM/ITAM Consultant in WEGG
Insights
OUR OFFICES
OUR OFFICES
PADUA
Via Arnaldo Fusinato 42, 35137
MILAN
Viale Enrico Forlanini 23, 20134
ROME
Viale Giorgio Ribotta 11, 00144
Copyright © 2022 WEGG S.r.l. • P.I 03447430285 • C.F. 02371140233 • REA 311023
Certified company ISO 9001:2015
