The latest news from The Hyve on Open Source solutions for bioinformatics

Recent Posts

Open source license compatibility - GPLv3 and Apache 2.0

May 24, 2017 | By Seher Room

In our previous blog post you could read about Open Source Software and why it is important to add a software license to your software. In this blog we will start off by looking at two of the open source licenses we use at The Hyve, Apache 2.0 and GPLv3. A list of the most popular open source software licenses can be found here. For an overview of which licenses are compatible with each other please read our next blog post.

 

Open source license compatibility

 

Why do we use Apache and GPL at The Hyve?
In principle we could use any of the Open Source Initiative (OSI) approved licenses. However, as reuse is one of our core values we are somewhat dependent on licenses used by the original author of the software. As we will go into later, some licenses add obligations to the reuse and redistribution of the software.

A lot of the tools we use are licensed with an Apache 2.0 license (e.g. Grails, Spark, Hadoop, Kafka). To avoid compatibility issues it is easiest for us to use the same license. Apache 2.0 is a permissive license that grants users rights to use, modify and distribute the source code. Using this license brings some obligations like the need to include state changes of the source code and to add a license and copyright notice.

As GPL licenses are the copyleft licenses to use for open source software it fits in our company vision of sharing and reusing. Version 2 of the GPL licenses have compatibility issues with Apache 2.0 making it hard to use it for the tools we support. GPL version 3 is the latest version and is compatible with Apache 2.0, ensuring we can use it together with the tools we already support. Compared to Apache 2.0 users have the same rights with GPLv3.0, however the obligations for GPLv3.0 are more extensive. On top of the state changes and license and copyright notice, GPLv3.0 obliges you to disclose the source of the code and use the same license when you redistribute the source code.

 

Copyleft versus Permissive licenses
As mentioned earlier a license ensures users have certain rights when using the software. Next to rights a license also adds obligations when using and modifying the source of the code. Depending on which license you use these rights and obligations may be different and can lead to compatibility issues.

Permissive licenses are simple licenses that allow you to do whatever you want with the software as long as you honor the obligations of the license. Like every other open source license they provide the software without any warranties and contain a limitation of liability.

Copyleft licenses are more complex, in that they add additional obligations on derivative work of the original source code. They provide the same rights, limitation of liability and provide software without any warranties but require the user to redistribute derivative works under the same license. This is different from the Permissive licenses were you are allowed to keep your own adjusted code closed.

 

Permissive Copyleft License terms
Do whatever you want with the code
Use the code at your own risk
Acknowledge whoever wrote that piece of software
Include state changes with source code
  Include copyright notice and license with source code
  Provide source code when distributing binaries
  Derivative work must have same license as original code
  Cannot place additional restrictions on the rights granted by the license

 

 

As you can see rights and obligations under Apache 2.0 are covered by GPLv3, making sure the Apache license terms are met when using the GPLv3 license. The GPLv3 user terms are not met when using the Apache 2.0 license to redistribute GPLv3 licensed software, making the licenses one-way incompatible with each other.

Next time we will expand on license compatibility when making adjustments to the source code of the original work. Some licenses tell you which license you have to use in case of derivative work and this could potentially lead to incompatibility problems when combining work from different sources. For more on this tune in on our next and final blog post in this series.