JAVA SE – changes in updates and the licensing model

Legal perspective

INTRODUCTION, I.E. A DISCLAIMER

We have been dealing with licenses for years, but the ORACLE JAVA licensing and maintenance model still impresses us. Given the variety and universality of products, distribution models, agreements and legal solutions embedded in them, this is a minefield for every lawyer and license manager.

On the top of this grid of ambiguity there is also the current practice which is, to a large extent, well, optimistic, i.e. based on the belief that JAVA is free – which is not always true. rnrn rnWe will try to discuss the mainstream of changes. This is not a full analysis. We deliberately disregard issues such as JAVA Advanced details. This is rather an indication of the direction which Oracle has taken, a description of the most important consequences and some of our thoughts for users.

The material is based on our analysis, a mine of information from Google (of different quality), materials from Gartner and similar firms (typically of good quality), and, above all, the assistance of several teams associated with Oracle and JAVA and numerous conversations with our colleagues from audit and consulting firms from Europe and the US who have shared their experience.

We would like to thank for all these conversations – it is amazing that we are always able to surprise one another. This merely shows the complex and ambiguous nature of the model we are dealing with.

SUMMARY OUTLINE FOR THOSE WHO HAVE NO TIME TO READ THROUGH THE TEXT

As a rule, JAVA SE 8, the most popular edition licensed by Oracle, was free software. Everyone could download and use JAVA features, and the obligation to pay arose when you used the so-called commercial features. One can dwell on the consequences of going beyond the so-called general purpose. Updates (although not the entire support) were also free.

JAVA SE 8 as a whole was licensed under an OBCL license, which presumably hardly anyone read (such is the case with “clickable” licenses). It is worth reverting to this text if there are any license charges.

That was the case until January this year. The last patch for the old model is numbered 202 and was released precisely in January. Anything subsequently released is, briefly speaking, subject to a fee.

In most cases this will mean the need to enter into an agreement with Oracle on new terms – both the license content (OBCL is converted into OTN, although the good old OMA is still in play, even though it’s not mentioned anywhere, but we’ve gone through the subscription purchasing process and it has emerged at the end of the order), the license model (from perpetual to subscription-based, i.e. a legal cloud on-premise), and the fee model changes.

The new license, for the purposes of calculating fees, takes advantage of a whole range of Oracle solutions – per user, per processor (virtualization!) and unlimited model. The best solution needs to be suited to specific architecture.

Subscription (new model) is not the only option – the rights to JAVA may result from another agreement with Oracle (e.g. from WebLogic if the use of JAVA is associated with this software) or an agreement with another manufacturer who previously agreed with Oracle and provides support.

From the market perspective, however, these are exceptions. Most users have an OBCL license and must do something about it.

“Commercial use” is the key term within the meaning of the new OTN license.

JAVA remains free for teamal desktop use, development, testing, prototyping and demonstrating, but anything else – that is the commercial use – is subject to a fee. This also applies to JAVA solutions that are embedded in other applications – if, for example, an electronic signature has a JAVA feature, you might be liable to pay Oracle for its use. Sky is the limit

To sum up – we must check our environment. We check whether “commercial use” is involved. If it is and we wish to use the updates, we have to make up our minds.

There are several options to choose from:

Firstly, do nothing, continue to use update 202 and refrain from using further releases.

Secondly, purchase the subscription (OTN + OMA) or enter into another agreement granting the right to update.

Thirdly, migrate to OpenJDK from Oracle or other providers, while reviewing their licensing terms since even open source can be demanding (are you sure you want to see your solution infected with the GPL virus?).

As regards the third solution, it is worth taking a close look at the update policy as it may turn out – as is the case with the Oracle open version – that it forces a specific migration cycle to new versions (e.g. every half a year).

Fourthly, give up JAVA (no, this isn’t a joke – many customers have discovered unnecessary installations which are ready to be easily removed).

What will happen?

Most likely, sooner or later, an audit will be launched. The worst solution is to download subsequent versions without a strategy and management model. In short, do not update Java without a developed strategy.

We anticipate three areas of disputes:

  • manifest breaches that will be frequent – downloading new versions for commercial use and failing to look through a new license model, that is, acting “by heart”. It is particularly dangerous in situations where there are numerous employees who can update JAVA on their own. This may also involve thousands of customers who do not even know that they use Oracle solutions – mainly in combination with other applications (as a side note, it is worth to include this element in an agreement with the application provider and, for example, assign the burden of fees to him).
  • gray zone, i.e. acting within the limits of “commercial use” or use of JAVA solutions embedded in other applications. This will always require reflection.
  • very gray zone, i.e. well-known virtualization problem, now involving JAVA as well, not just databases. In many cases this is tenable.

What to do?

Firstly, you need to know whether you have JAVA, in what version and on what legal basis (map of contracts).

Secondly, decide which version will still be in use, which to migrate to open source, which is unnecessary and is to be uninstalled.

Thirdly, decide if JAVA provided by Oracle, which will continue to be used, needs new versions and updates.

Fourthly, take a look at the architecture as a whole, including virtualization.

Fifthly, once again compare it with the map of rights and, if necessary, purchase whatever you still need – or go back to step two.

OUR (A BIT LONGER) ANALYSIS

What has happened?

After many years of stress-free use of Java SE products, which were commonly (though not necessarily correctly) perceived as free, and thus triggering no audit risks, the situation (comfortable for users) has changed. In a nutshell, the use of Java SE 8 and updates and security patches will require monthly subscription fees. The latest LTS version (Java SE 11) has from the very beginning been available (in principle – see the disclaimer) only under the subscription model.

The changes concern two key areas: the licensing model and the update delivery model.

They affect a very wide range of entities, including developers, IT solution vendors and users of third-party applications. Below we present a high-level summary of the most critical issues that entities from the above-mentioned groups should pay attention to when performing activities related to license management.

Licensing perspective:

So far, Java products provided by Oracle were licensed under perpetual licenses, and patches and updates were provided free of charge (except for specific products, including so-called commercial features, e.g. Java Flight Recorder or Java Mission Control). The licensing terms were contained in the Oracle Binary Code License Agreement (OBCL).

With the introduction of the subscription model, the OBCL was replaced by a new license agreement, i.e. Oracle Technology Network License Agreement (OTN). Until January this year, SE 8 operated under the OBCL license and anyone using the earlier version is still bound by this license. It is worth mentioning that in the JAVA ordering process we will be also forced to accept OMA agreement (however, as it seems, without Price List, i.e. without the processor definition that may be of key importance in terms of determining the amount of licenses required on virtual machines).

New users who wish to use subsequent SE 8 editions (those from patch 202 onwards) can no longer enter into an OBCL. The only model that can be used is the subscription model (as for version 11) under which users are granted license rights under the OTN license agreement, updates and support for all Java SE products. As a consequence, the distinction between commercial and non-commercial features, which triggered much concern for users and which was a frequent audit charge, is no longer there. The subscription is payable monthly, as per NUP or processor metrics (an unlimited model is possible), with an agreement being entered into for at least one year. Choosing metrics is simply an architectural and business decision.

Below is a brief comparison of old and new licensing terms:

  • The use of Java SE features (including commercial features) for development, testing, demonstrating and prototyping purposes is free of charge under both licenses. The broader use, including, as OTN license agreement describes, “for any data processing or any commercial, production, or internal business purposes other than developing (etc.)” (apparently, the space for interpretation here is broad), goes beyond the scope of the rights (as such, it requires separate, paid licensing);
  • The OTN license agreement does not distinguish (as the OBCL did) general purpose computing use and non-general purpose computing use (which, in any event, are one of more difficult to interpret concepts under the OBCL agreement). The purpose of use (commercial or non-commercial) becomes crucial – the definition is still unclear, but commercial purpose appears to be wider than “general purpose”;
  • While under an OTN license agreement it is not allowed to “distribute, give or transfer” (again, the terms are not clear), these activities were compliant with the OBCL terms so long as certain conditions were satisfied;
  • None of the licenses allow for any “modification of Java programs”.

In a nutshell – if we wish to use Java by Oracle for purposes other than those expressly permitted by the OTN license agreement, we must

  • purchase a subscription ,
  • be entitled to such use under any other separate agreement with Oracle (an autonomous one, such as the Java SE Advanced models, or entered into for the purpose of using another Oracle product, such as WebLogic) ,
  • be entitled under an agreement with another provider that provides Java by Oracle as part of its product (e.g. certain VMware products).

Apparently, another solution is the transition to open source, including third-party products (e.g. IBM, SAP, Azul, etc.).

Updates:

As from January 2019, updates to SE 8 and subsequent versions will be payable under the subscription model (including the license, similarly to cloud models). On January 15, 2019 the Critical Patch Update 8u201 and the related Patch Set Update 8u202 marked the end to the era of JDK 8 free updates. The update scheduled for April 16, 2019 (8u211 and 8u212) will only be available to authorized users under the new OTN license agreement[1].

It’s simple here – if you do not need further versions, you can continue to use version 202. If anyone downloads anything released after January 2019, the risk of subscription fees materializes (unless, as described above, they have a different legal basis for JAVA, for example under WebLogic or any other agreement).

Who can continue to use Java for free?

Bearing in mind the changes in the licensing model and high uncertainty regarding the interpretation of individual provisions and information published by Oracle, it should be assumed that only the so-called teamal users can undoubtedly use Oracle Java SE for free (Oracle declares free Java 8 support for entities using B2C applications through at least 2020) and entities using Java for development, testing, demonstrating or prototyping purposes based on OBCL or OTN licenses[2].

Entities using Java (in versions from version 202 onwards) on broadly understood commercial environments should take into account the need to purchase certain licenses (user / processor), the number of which must be estimated as part of a detailed inventory.

What next?

In order to protect yourself against the risks associated with the use of Oracle software in an unauthorized manner and to develop a model of using Java in the future, which is optimal for your organization, you need to answer a number of questions, such as:

  • Do I use Oracle Java products (you should consider available tools for detecting Java in systems; be aware of the Oracle Usage Tracker which contains paid features)?
  • Which Java version do I use, for what purpose and to what extent (inventory)?
  • Are the so-called commercial features used (which for version 8 were separately payable before January 2019 – it can be established during an audit that someone failed to pay)?
  • What is the legal basis for using the software – OBCL, OTN, GPL licenses, rights related to the use of another Oracle product, such as WebLogic, or to the use of solutions provided by other vendors such as IBM, Azul, SAP, etc.?
  • Are updates necessary (including the need to investigate the risks associated with the absence of security updates)?

Depending on the answers given (with a full list of questions being even longer), it will be possible to identify potential licensing irregularities and to decide on further steps.

Currently available basic action scenarios are as follows:

  • Using Oracle support – for commercial purposes, accepting payment obligations
  • Using Oracle OpenJDK – free of charge under GPLv2 + CE, but with the (real) need to make updates every six months on your own;
  • Using the services of external providers (Independent Software Providers) – on the provider’s terms; when migrating to another provider, take into account TCK / JCK certificates and a limited support period for such solutions;
  • Maintaining Java on your own – free of charge; however, this option is not really viable for most organizations.

[1] In addition, it is worth noting that according to Oracle SE Support Roadmap Java SE 8 support as part of Premier Support is to be provided by Oracle through 2022, and as part of Extended Support – through 2025.
[2] This is confirmed by Oracle itself as part of its publications: https://blogs.oracle.com/java-platform-group/oracle-java-se-releases-faq


Zobacz inne artykuły autorów