Combining open-source software licenses - The final chapter

14-07-2017 3 min read

In our previous two blog posts, we discussed why it is essential to add open-source software licenses to your published software and looked at two example licenses, Apache 2.0 and GPLv3. In the last blog post of this series, we will zoom in on the compatibility issues some of the licenses have with one another and will conclude this series with an overview of which licenses are compatible with one another.

Derivative work or not?

Compatibility issues between licenses can originate when you try to include open-source source code as a library in your existing project. Depending on the library's license, it could be considered a derivative work. This raises the interesting question; when is something a derivative work? Looking at different license texts, this is not clearly defined and is left up to the courts around the world to decide in case of a dispute.

When you look at GPLv3, for example, the license states that you have to license any modified version under the same license, even when you are linking to it dynamically, which means using it as a library. So, according to GPLv3, a derivative work or modified version is everything that uses the source code in any way possible.

Taken from: Välimäki, Mikko (2005). The Rise of Open Source Licensing: A Challenge to the Use of Intellectual Property in the Software Industry (Ph.D. thesis). Helsinki University of Technology. Retrieved 2015-12-30

So how should I license my project?

Depending on the situation, the answer might be quite tricky. If you have a software package licensed under an Apache 2.0 license and want to use this in a GPLv3-licensed project, then this will not be a problem. As we saw in our previous post, the Apache 2.0 terms are covered by GPLv3.

But what happens if it is not a GPLv3 but a GPLv2 license you want to combine with Apache 2.0? Here the situation is a lot more complex as the GPLv2 license is incompatible with Apache 2.0 due to a missing patent grant clause. The answer to this problem is unclear, and as there is no case law on this matter, the correct answer is not set in stone yet.

License upgrade paths

One way to solve the incompatibility issue is to get all the authors of all the software to agree to upgrade their old licenses to licenses that are compatible with each other. In the overview below, you see an upgrade path of licenses and which licenses are one- or two-way compatible.

The BSD 3-clause License has one additional condition and is therefore not compatible with the BSD 2-clause license and/or the MIT License.
The Apache 2.0 License has more conditions than the MIT and/or BSD 3-clause License.
See https://www.apache.org/licenses/GPL-compatibility.html and https://www.gnu.org/licenses/license-list.en.html#apache2.
See https://www.gnu.org/licenses/license-list.en.html#GPLv2 and https://www.gnu.org/licenses/gpl-faq.html#AllCompatibility.
See: https://www.gnu.org/licenses/license-list.en.html#AGPLv3.0

So the solution to our problem would be to get the authors of the GPLv2 license to upgrade to GPLv3. As GPLv3 is compatible with Apache 2.0, the problem disappears.

In conclusion

We reach our destination at the end of this blog series. In the last three posts, we introduced an issue we have encountered as a company providing development services around open-source software tools, often using source code previously made by others.

If you would like to know more about how we work with the licenses on a day-to-day basis or are interested in the services or tools we provide, feel free to contact us.