According to research by The University of Law, 68% of people either don’t read or don’t understand the contracts they sign. We dare assume that the situation is even worse in the open-source software development world. Developers pull dependencies or projects from public repositories, such as Maven, Docker Hub, and GitHub, without reading the licenses. This negligence may lead to grave legal consequences for them or the enterprises they work for.
Take Java, for example. The OpenJDK code is licensed under GPLv2 + Classpath Exception. What does it imply? What are the benefits of this license? Does it impose any legal risks for corporate Java development?
This article will look into the intricacies of open-source licenses, including GPLv2. It doesn’t give legal advice and only provides a general overview of the topic.
Table of Contents
The importance of software licenses for developers
Software licensing may seem like a tedious legal technicality of no interest to developers, but this technicality is a cornerstone of the Open Source world.
Licenses regulate the way developers interact with each other. When utilizing your colleagues’ code, you must meet their software’s license requirements (legal compliance). Violating licensing conditions may lead to lawsuits, which will devour your or your company’s time and money. On the other hand, licenses also help you protect your intellectual property.
Rights and obligations imposed by different software licenses form a specific community. There are plenty of such communities worldwide: apart from open-source software, any platform or proprietary technology can have its user group interested in its evolution.
Therefore, choosing a license means choosing friends, colleagues, and even the career path for many years ahead. After all, developing financial algorithms in banking or building open-source web frameworks in Java belongs to two different fields.
Special aspects of open-source licensing
Most third-party code you use is licensed. Closed proprietary code is distributed under EULA (End User License Agreement) written by the vendor, whereas open software utilizes one of the Open Source Initiative or Free Software Foundation licenses. We will talk about the differences between the two organizations later on.
Software licenses are classified by the types of intellectual property they protect: copyright, patents, and trademarks. In general terms, copyright protects works of authorship and permits or prohibits using the code. Patents protect inventions or processes and help preserve the rights for implementing a mechanism not necessarily tied to a specific code. A trademark is a symbol, word, or phrase registered by a company or a community so nobody can pass a random fork for their work.
Most open-source licenses are associated with copyright and patents and don’t give rights to trademarks. In other words, they form communities working on the same codebase utilized for various software products. For instance, there is a shared codebase in Java — OpenJDK, and numerous technologies built around it, including Oracle Java, Liberica JDK, etc.
The coexistence of different open software communities gave birth to two related ideologies, Open Source and Free Software.
OSI and FSF
When we say “Open Source,” we usually mean the definition published on the OSI (Open Source Initiative) website, consisting of ten fundamental rules.
OSI was founded in 1998 by Bruce Perens and Eric S. Raymond. Perens is famous for leading the Debian project and creating BusyBox and Linux Standard Base. Raymond is the editor of Jargon File and author of The Cathedral and the Bazaar, The Art of Unix Programming, and other books.
FSF (Free Software Foundation) was founded in 1985 by Richard Stallman, who also launched the GNU Project and wrote the GNU General Public License (GPL). By “free” software, Stallman means the software that respects users’ freedom to run, copy, distribute, study, change, and improve the software.
Both OSI and FSF advocate free software whose source code can be modified by any developer. But OSI’s approach is more flexible. While FSF promotes the idea that all software should be open-sourced without any restrictions on its use and modification, OSI is more pragmatic. OSI-approved licenses don’t oblige that all software distributed with open software must also be open source.
These organizations were created by legendary developers whose work laid the foundation for modern open-source development. Years of experience enabled them to establish best practices for building open systems and communities. With the aid of legal advisers, these practices turned into clear licenses that any developer can apply.
There are currently dozens of open and free licenses, and although they follow the OSI or FSF principles, each has its own nuances. Both organizations approve some licenses, some by OSI or FSF only.
Every time you decide to use a new library in your project, read its license, then read the commentary in the FSF registry, or verify its compliance with basic principles if it is not on the list. Large companies usually have a legal department to deal with such tasks. Still, in some cases, it is evident from the first lines of the text that the license violates many principles, and there’s no need to waste the lawyer’s time on it.
Key principles of the GPL license
Almost all OpenJDK code is licensed under GPLv2 + Classpath Exception. But before delving into its features, let’s look at its ancestor, the GNU General Public License, which is a set of free software licenses written by Stallman and aimed at securing four freedoms to
- Use the software for any purpose;
- Study the source code and change the software to suit your needs;
- Share the software with your colleagues;
- Share the changes you make to promote innovations and community evolution.
GPL works virally to implement these rules in real-world scenarios, meaning that everything based on the GPL-licensed code must also be licensed under GPL. The viral nature of GPL is well thought through and functions perfectly in practice.
These are wonderful rules for open scientific research, but they clash with the interests of many commercial organizations that don’t want to share their proprietary know-how with the rest of the world.
One may point out that if a company has no desire to share its work, it should simply use another license. Unfortunately, there’s always a risk of accidentally implementing a piece of GPL code, forcing the enterprise to open the whole project. The risk is significant because each corporate application utilizes hundreds of open-source dependencies.
However, we don’t believe that GPL is pure evil. On the contrary, it made software development easier, faster, and cheaper than two decades ago. The key is to master handling it in the right way.
GPL and OpenJDK
Java and OpenJDK are intended for any purpose, including commercial software. Therefore, the OpenJDK license had to consider the Free Software ideology and the needs of individual developers, major enterprises, state organizations, etc.
The solution was found in the modified version of GPL, which is called GPLv2 + Classpath Exception (CPE). It includes the following remark:
“... 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.”
This amendment enables you to use the OpenJDK and proprietary code in one application. You only have to put proprietary libraries into CLASSPATH, so there’s no legal obligation to open their source code. The license is easy to use and very efficient, that’s why Java became a predominant platform for corporate development.
At the same time, GPLv2 + CPE helps OpenJDK remain one of the flagships of Open Source development. At the moment of writing this article, the JCP Executive Committee included 18 companies, among them Oracle, IBM, Intel, BellSoft, and other industry leaders. The GitHub repository contains 74,000 commits, and the number constantly increases, making OpenJDK one of the biggest open-source projects in the world.
To conclude, OpenJDK licenses allow the creation of both open and proprietary Java-based products. They facilitate and accelerate application development and foster a highly efficient OpenJDK community that works incessantly on Java improvement.
How to eliminate the risks related to non-GPLv2 + CPE code in OpenJDK
Nevertheless, there’s a fly in OpenJDK ointment — not all OpenJDK code is licensed under GPLv2 + CPE. Some files in the project codebase have GPL only without Classpath Exception, which resurrects the problem of viral GPL code. Enterprises have to be 100% certain that all components of Java runtime that link with their code have the CPE. This is why BellSoft provides Liberica JDK builds, for which we scan the JDK files and ensure that all public Java SE API components that link to your app’s code have the GPLv2 + CPE license. We also provide patent and non-contamination indemnification. Both services are part of our enterprise support.
Don’t get stuck in licensing cobweb — contact us, and we will help you protect your software.
