In our previous two blogs posts we touched upon why it is important to add open source software licenses to your published software and had a look at two example licenses, Apache 2.0 and GPLv3. In our last blog post of this series we will zoom in to the compatibility issues some of the licenses have with one another and we would like to close the series with an overview of which licenses are compatible with one another.
Derivative work or not?
Compatibility issues between licenses can originate when you are trying to include open source source code as a library in your existing project. Depending on the license of the library it could considered as a derivative work. This raises the interesting question; when is something a derivative work? Looking at different license text 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 anyway 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 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 not compatible with Apache 2.0 due to a patent grant clause that is missing. The answer to this problem is not clear 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 license 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 the end…
we reach our destination at the end of this blog series. During the last three posts we introduced an issue that is something we personally encounter as a company providing development services around open source software tools often making use of source code previously made by other people.
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.