License compatibility is an issue that arises when licenses applied to copyrighted works, particularly licenses of software packages, can contain contradictory requirements, rendering it impossible to combine source code or content from such works in order to create new ones.
Suppose a software package has a license that says, "modified versions must mention the developers in any advertising materials," and another package's license says "modified versions cannot contain additional attribution requirements." Without direct permission from the copyright holder(s) for at least one of the two packages, it would be impossible to legally distribute a combination of the two because these specific license requirements cannot be simultaneously fulfilled. Thus, these two packages would be license-incompatible.
Not even open-source licenses are necessarily compatible, which can make it legally impossible to mix (or link) even open-source code if the components are released under different licenses. For example, software that combined code released under version 1.1 of the Mozilla Public License (MPL) with code under the GNU General Public License (GPL) could not be distributed without violating one of the licenses' terms by default. This is despite both licenses being approved by the Open Source Initiative and Free Software Foundation.
David A. Wheeler has argued that GPL compatibility is an important feature of software licenses. Many of the most common free software licenses, such as the original MIT/X license, BSD licenses (in the three-clause and two-clause forms, though not the original four-clause form), MPL 2.0, and LGPL, are "GPL-compatible". That is, their code can be combined with a program under the GPL without conflict (the new combination would have the GPL applied to the whole). When it comes to copyleft software licenses, they are not inherently GPL-compatible, even the GPLv2 is, by itself, not compatible with GPLv3. However, most software released under GPLv2 allows you to use the terms of later versions of the GPL as well but some have exception clauses that allow combining them with software that is under different licenses or license versions.
Re-licensing due to incompatibility
Sometimes projects gets stuck in a license incompatibility situation and the only feasible way to solve it is the re-licensing of the incompatible parts. Relicensing is achieved by contacting all involved developers and parties and getting their agreement for the changed license. While in the free and open-source domain achieving 100% coverage is often impossible, due to the many contributors involved, the Mozilla relicensing project assumes achieving 95% is enough for the relicensing of the complete code base, while others in the FOSS domain come to different conclusions regarding the requirements for relicensing of a code base. Examples of projects who did successful relicensing are FreeCAD who changed their license in 2014 from GPL to LGPLv2 and the Dolphin project who changed their license from "GPLv2 only" to "GPLv2 or any later" in 2015.
- List of FSF approved software licenses
- License proliferation
- Backward compatibility
- Forward compatibility
- "How GPLv3 tackles license proliferation". linuxdevices.com. Archived from the original on 2007-12-18.
- "Stallman explains license compatibility while discussing GPLv3".
- "MPL 1.1 FAQ - Historical Use Only". Mozilla Foundation. 1 February 2012. Retrieved 26 February 2012.
- "Mozilla Public License 1.1: Licensing". Open Source Initiative. Retrieved 26 February 2012.
- "GPL-Incompatible Free Software Licenses". Free Software Foundation. 22 February 2012. Retrieved 26 February 2012.
- "Frequently Asked Questions about the GNU Licenses – Is GPLv3 compatible with GPLv2?". gnu.org. Retrieved 2014-06-03.
No. Some of the requirements in GPLv3, such as the requirement to provide Installation Information, do not exist in GPLv2. As a result, the licenses are not compatible: if you tried to combine code released under both these licenses, you would violate section 6 of GPLv2. However, if code is released under GPL “version 2 or later,” that is compatible with GPLv3 because GPLv3 is one of the options it permits.
- Landley, Rob. "CELF 2013 Toybox talk - http://landley.net/talks/celf-2013.txt". landley.net. Retrieved 2013-08-21.
GPLv3 broke "the" GPL into incompatible forks that can't share code.
- "GPL-Compatible Free Software Licenses". 2014-11-20. Retrieved 2014-12-29.
- O’Riordan, Ciaran (2006-10-06). "(About GPLv3) Can the Linux Kernel Relicense?". fsfe.org. Retrieved 2015-05-28.
Someone who works with many lawyers on free software copyright issues later told me that it is not necessary to get permission from 100% of the copyright holders. It would suffice if there was permission from the copyright holders of 95% of the source code and no objections from the holders of the other 5%. This, I’m told, is how Mozilla was able to relicense to the GPL in 2003 despite years of community contributions.
- Licensing HOWTO by Eric Steven Raymond&Catherine Olanich Raymond "Changing an existing license [...]You can change the license on a piece of code under any of the following conditions: If you are the sole copyright holder[...]If you are the sole registered copyright holder[...]If you obtain the consent of all other copyright holders[...]If no other copyright holder could be harmed by the change"
- Prokoudine, Alexandre (2012-12-27). "LibreDWG drama: the end or the new beginning?". libregraphicsworld.org. Retrieved 2013-08-23.
[...]the unfortunate situation with support for DWG files in free CAD software via LibreDWG. We feel, by now it ought to be closed. We have the final answer from FSF. [...] "We are not going to change the license."
- "license". freecadweb.org. 2014. Retrieved 2015-03-25.
Licences used in FreeCAD - FreeCAD uses two different licenses, one for the application itself, and one for the documentation: Lesser General Public Licence, version 2 or superior (LGPL2+) […] Open Publication Licence
- Relicensing Dolphin: The long road to GPLv2+ Written by JMC47, MaJoR on May 25, 2015