Open source has become a fundamental part of how we develop software. Freely reusing source code from other developers, not having to continually reinvent the wheel and write code that has been written many times before, has had a profound impact on aspects such as reliability and productivity.
When using open-source software, it is essential that you understand the terms of the original author’s license. This can become more complex and more fraught with potential problems the more aggregation of code that occurs.
Recently, the Ruby-on-Rails project provided an excellent example of this.
Ruby-on-Rails (RoR) is a popular open-source web framework, which makes its code available under the MIT license. This is a very permissive license, meaning it imposes very few restrictions on how the code can be reused. This type of license has high license compatibility with other open-source licenses.
RoR uses code from other open-source projects, a widespread approach to including standard functionality without having to develop it from scratch. It’s what all sizeable software projects do: use libraries of existing code.
The library that caused an issue was mimemagic, which detects the MIME (Multipurpose Internet Mail Extension) type of a file by extension or content. That’s important but not terribly contentious functionality. The mimemagic code is also provided under the MIT license, so there is no incompatibility, and everyone should be happy. The problem was a discovery related to another library that mimemagic depends on called shared-mime-info. This is a database of MIME types created by merging several MIME information sources; the goal is a standard repository of MIME type information. In the case of shared-mime-info, the license used was the GNU Public License version 2 (GPLv2).
Unlike the MIT license, GPLv2 imposes quite strict requirements on how code can be reused (although, technically the licenses are compatible). The most significant of these requirements is the copyleft nature of the license. Copyleft grants the right to distribute and modify the source code freely but mandates that the same rights granted by the GPL must be preserved in any derivative works using the code. This is often referred to as a viral license as it forces anyone using code licensed under the GPL to license their code in the same way.
The mimemagic developer was notified about the incompatibility of using the MIT license and promptly changed the license to GPLv2 to resolve the issue. The ripple effect is that RoR is now using an incompatible license. Either they would need to shift RoR to use GPLv2 or find an alternative source of the 7645-line XML file and associated Ruby code that identifies the MIME type of a file.
The impact of changing the license of RoR could be staggering because of the knock-on copyleft effect. Anyone using RoR to build an application would be bound to license the code for that application under the GPL and provide a copy to anyone who asked for it (it’s an open-source license, after all). People like AirBnB, Bloomberg and Groupon (all RoR users) might not be too keen on that idea.
Now I’m sure you’re wondering why I just wrote 500 words about the licensing problems of Ruby on Rails when Azul is focused exclusively on Java.
Well, OpenJDK, the open-source implementation of the Java platform, is also licensed under the GPLv2. At least, most of it is; several components have been contributed to the project that uses other licenses like the BSD, Apache or MIT ones. Without some modification, the copyleft nature of the GPL would also extend to any code using the JVM, i.e. any Java application would need to be licensed under the GPLv2!
Clearly, that would not have been good for the Java ecosystem, and we would have seen significantly less adoption than we have since the creation of the OpenJDK project in 2007.
To remedy this situation, the OpenJDK license includes the Classpath Exception (CPE). This is an addendum to the GPLv2, which is word-for-word identical to the GPL Linking Exception used by the GNU Classpath Project.
The CPE states, “…the copyright holders of this library give you permission to link this library with independent modules … and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module.” Thus, any application code on either the class path or module path is not affected by the copyleft nature of the GPLv2.
Some people who look at this assume that all GPLv2 licensed code in OpenJDK includes the CPE, but this is not the case. If you search the hotspot source code directory (I took the one from jdk16u), of the 3291 files, only five include the Classpath exception. Conversely, looking at the java.base source directory, only 54 of the 3351 files don’t have the Classpath exception. This is because the Classpath exception is only required when application code touches JDK code directly.
Herein lies the question that all JDK users should consider, “How sure are you that all the files that need the CPE have the CPE?” If even one file is missing the CPE that needs it, it’s the same as no CPE at all.
At Azul, we provide certified builds of the JDK as part of our Zulu distribution. For these, we scan every source file used to build the JDK (both static and dynamically generated during the build process) to ensure that all files that need the CPE do indeed have it. We will even indemnify users against copyleft “contamination” through the propagation of the license requirements.
If the protection of your Java application code intellectual property is crucial to you, why not contact us to find out more about this?
