Java licensing

As you are aware Oracle has modified licensing conditions and now permits free download and installation for personal use, development, testing, prototyping, demonstration purposes. We are about to deploy a self-hosted Windows Aggregate setup to production and are faced with the possibility that a license will be required which is undesirable as the intention is to provide an open-source solution for health. Is there a clause we are missing that excludes ODK installation from requiring a license?

2 Likes

This is a great question, @Naomi_Waithira. I am not a lawyer, but here's my understanding. Bear with me, because it's a little complicated.

According to the Oracle Java SE Licensing FAQ, Oracle as of Java 9 provides two distinct Java releases:

  • Oracle OpenJDK releases under the open source GNU General Public License v2, with the Classpath Exception (GPLv2+CPE) (since Java 9)
  • Oracle Java SE product releases, which includes the Oracle JDK for Java 8 and later, and Oracle JRE with Java Web Start in Java 8, under the OTN License Agreement for Java SE. This license permits personal use, development, testing, prototyping, demonstrating and some other uses at no cost.

There are two places to check compliance with these licenses. The first place is in the building of the tools. That is ODK's responsibility. The second place is in the running of the tools. That is a user responsibility.

The tools in ODK that could use Oracle Java are Validate, Briefcase, Aggregate (including the Java inside the VM), and JavaRosa (a library that runs inside the previously mentioned tools).

As of today, we use Oracle Java to build JavaRosa. I believe our use falls under the "development" category of the Oracle license, but I've sent in a JavaRosa pull request to switch to OpenJDK out of an abundance of caution. Even with this change, we cannot verify that the libraries inside JavaRosa itself are built with OpenJDK, so I'm not sure my caution even matters. I would be very surprised if Oracle cares about compliance at this level of the stack.

The Aggregate VM includes OpenJDK and Validate builds with OpenJDK. I believe Briefcase and Aggregate are also built with OpenJDK (@ggalmazor correct me if I'm wrong). Note that regardless of how these are built, they all include JavaRosa and other libraries and dependencies that may or may not be compliant.

The Java runtime environment users install on their machine to run these ODK tools is their choice and this is where I think Oracle cares about compliance. If users choose to install Oracle Java, it's up to them to ensure they are complying with Oracle's license. Our recommendation these days is to install OpenJDK because then you can be sure that your stack is OSI-certified and open-source.

One thing that ODK should do to help users stay complaint is to update our documentation and ask users to download OpenJDK, not Oracle Java SE. I've filed a docs issue for us to update the docs. Pull requests are welcome.

What would I recommend in this particular case, @Naomi_Waithira? First, I'd encourage you to speak with your IT and legal folks about how you should proceed. If you have no IT and legal team at your disposal, I'd recommend you install OpenJDK, not Oracle Java when you use Aggregate. Next, make sure you are always running the latest versions of said tools because we will continue to improve our compliance with licenses.

1 Like

Thanks for all the details, @yanokwa!

Some thoughts:

  • It's generally OK to recommend AdoptOpenJDK's builds to our users, although we should note that any other OpenJDK vendor should do the trick. Users might have other vendors installed already, and dealing with multiple JVMs can be a nuisance.
  • We should specify a minimum fully qualified version because we know that some lower patch versions of Java 8 can act up when dealing with crypto.

I'll write a note in the docs issue with this.

Just to close this topic out...

  • JavaRosa v2.16.0 is now built with AdoptOpenJDK. Future releases of Validate, Briefcase, and Aggregate will be built with AdoptOpenJDK.
  • Our docs now suggest folks should use AdoptOpenJDK v8.0.222 or later.
1 Like