Changing Licenses and License Terms

It doesn't happen very often, but every once in a while companies that primarily control an open source project decide to change their license. (See MongoDB, Elasticsearch and Kibana, and MinIO.) If your organization is not regularly scanning and auditing what it uses, you can get caught facing some unpleasant and unplanned charges.

Changing Java

The latest to change is Oracle's Java. Java itself is primarily licensed under the GPLv2 with the classpath exception. However Oracle bundles proprietary software with its distribution of Java making it effectively proprietary software. Oracle is also the primary copyright holder, trademark holder, and is broad control of the evolution of the language.

There have been 3 different Java licensing changes, one in 2019, a second in 2021 and the last change in January of this year. The latest change rewrites the licensing model from "Named User" and "Processor" licenses to an enterprise-wide per-head license regardless of whether your employees are using Java or not.

This is a significant change, because the 2021 round of Oracle licensing changes included the NFTC, or Oracle No-Fee Terms and Conditions, which allowed for the free use of Java for internal purposes.

In addition, the 2019 Oracle changes made security updates beyond Java 8 release 211 commercial only, as well as prohibiting commercial uses of later editions of Java.

What OSPOs should do

Oracle's license change is an opportunity for OSPOs to help the company's bottom line. There is no need to use Oracle Java. There are many completely free (and fully open source) distributions of Java, including Adoptium (formerly AdoptOpenJDK) and Amazon Corretto. These distributions of Java include all the latest versions and security updates and do not carry the same relicensing risk as Oracle's Java. If commercial support is needed, there are vendors such as Red Hat, Microsoft, and Azul that have versions with commercial support.

However, changing is only reasonably possible if your organization is regularly scanning its use of code so that you know what code you are using and where it comes from. If you don't have your scanning infrastructure in place yet, avoiding the fees from Oracle may provide just the push your company needs.

You should also make explicit policies about downloading and using anything from Oracle's website. Oracle records all downloads from its website and its products "phone home" with information about their use in your environment. If even one employee downloads Oracle's Java, that can cause substantial costs under Oracle's new licensing model.

Supply chain risk

One final thing this change teaches us is that a key role for OSPOs is managing supply chain risk. Right now a lot of the supply chain risk is focused on security. But relicensing risk and maintainer burnout risk, especially for small projects, can be even more disruptive than a security hole.

Take time to evaluate the community aspects of your upstream dependencies and invest in keeping them healthy. Doing so can help you see and manage your risks before they come knocking at your door.