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.
License compatibility can be defined differently with varying strength around the concepts of "combined work" and "derived work". The first "combined work" license compatibility definition allows the usage of various licensed code in a combined context.
"License compatibility: The characteristic of two (or more) licenses according to which the codes distributed under these licenses may be put together in order to create a bigger distributable software."— Philippe Laurent, European Open source Lawyers Event 2008, 
A stronger definition, also used by the FSF, includes the capability to change the license. As most prominent example, the copyleft licenses demand that the "derived work" combined from code under various licenses as whole is applied under the copyleft license.
"License compatibility: The characteristic of a license according to which the code distributed under this license may be integrated in a bigger software that will be distributed under another license."— Philippe Laurent, European Open source Lawyers Event 2008, 
Compatibility of FOSS licenses
Even accepted and common Open-source licenses are not necessarily compatible between each others. Which can make it legally impossible to mix (or link) even open-source code if the components are available 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. License compatibility between a copyleft license and another license is often only a one-way compatibility. This "one-way compatibility" characteristic is for instanced criticized by the Apache Foundation, who provides the more permissive Apache license which doesn't have this characteristic. Non-copyleft licenses as the FOSS permissive licenses have a less complicated license interaction and have most often a in general better license compatibility.
David A. Wheeler has argued that GPL compatibility is an important feature of software licenses for the Free and open-source ecosystem. Many of the most common free software licenses, especially the permissive 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 and the new combination would have the GPL applied to the whole (not the other license). 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.
Flask developer Armin Ronacher draw in July 2013 a negative resume on the GPL compatibility in the FOSS ecosystem when he concluded:"When the GPL is involved the complexities of licensing becomes a non fun version of a riddle.".
Also, the FSF recommended GNU Free Documentation License is incompatible with the GPL, text licensed under the GFDL cannot be incorporated into GPL software. Therefore, the Debian project decided in a 2006 resolution, as also the FLOSS Manuals foundation in 2007, to use for documentation the GPL.
Re-licensing for compatibility
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. Others in the FOSS domain, as Eric S. Raymond, came to different conclusions regarding the requirements for relicensing of a whole code base.
An example of a project who did successful relicensing for license compatibility reason is the FreeCAD project, who changed their license in 2014 from GPL to LGPLv2 due to GPLv3/GPLv2 incompatibilities.
The VLC project has also a complicated license history due to license compatibility: in 2007 it decided for license compatibility reasons to not upgrade to the just released GPLv3. After the VLC was removed from Apple App Store in begin of 2011, in October 2011 the VLC project re-licensed the VLC library part from the GPLv2 to the LGPLv2 to achieve better compatibility. In July 2013 the VLC application could then resubmitted to the iOS App Store relicensed under the Mozilla Public License.
- License proliferation
- Comparison of free and open-source software licenses (also license compatibility)
- Backward compatibility
- Forward compatibility
- List of FSF approved software licenses
- "How GPLv3 tackles license proliferation". linuxdevices.com. Archived from the original on 2007-12-18.
- LAURENT, Philippe (2008-09-24). "The GPLv3 and compatibility issues" (pdf). European Open source Lawyers Event 2008. University of Namur – Belgium. p. 3. Retrieved 2015-05-30.
The characteristic of two (or more) licenses according to which the codes distributed under these licenses may be put together in order to create a bigger distributable software.
- "Stallman explains license compatibility while discussing GPLv3".
- LAURENT, Philippe (2008-09-24). "The GPLv3 and compatibility issues" (pdf). European Open source Lawyers Event 2008. University of Namur – Belgium. p. 4. Retrieved 2015-05-30.
The characteristic of a licence according to which the code distributed under this license may be integrated in a bigger software that will be distributed under another license
- The Free-Libre / Open Source Software (FLOSS) License Slide by David A. Wheeler on September 27, 2007
- "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.
- LAURENT, Philippe (2008-09-24). "The GPLv3 and compatibility issues" (pdf). European Open source Lawyers Event 2008. University of Namur – Belgium. p. 7. Retrieved 2015-05-30.
Copyleft is the main source of compatibility problems
- Apache foundation (2015-05-30). "GPL compatibility". Retrieved 2015-05-30.
Apache 2 software can therefore be included in GPLv3 projects, because the GPLv3 license accepts our software into GPLv3 works. However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.
- Hanwell, Marcus D. (28 Jan 2014). "Should I use a permissive license? Copyleft? Or something in the middle?". opensource.com. Retrieved 2015-05-30.
Permissive licensing simplifies things One reason the business world, and more and more developers [...], favor permissive licenses is in the simplicity of reuse. The license usually only pertains to the source code that is licensed and makes no attempt to infer any conditions upon any other component, and because of this there is no need to define what constitutes a derived work. I have also never seen a license compatibility chart for permissive licenses; it seems that they are all compatible.
- "Licence Compatibility and Interoperability". Open-Source Software - Develop, share, and reuse open source software for public administrations. joinup.ec.europa.eu. Retrieved 2015-05-30.
The licences for distributing free or open source software (FOSS) are divided in two families: permissive and copyleft. Permissive licences (BSD, MIT, X11, Apache, Zope) are generally compatible and interoperable with most other licences, tolerating to merge, combine or improve the covered code and to re-distribute it under many licences (including non-free or “proprietary”).
- "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.
- Ronacher, Armin (2013-07-23). "Licensing in a Post Copyright World". lucumr.pocoo.org. Retrieved 2015-11-18.
The License Compatibility Clusterfuck - When the GPL is involved the complexities of licensing becomes a non fun version of a riddle. So many things to consider and so many interactions to consider. And that GPL incompatibilities are still an issue that actively effects people is something many appear to forget. For instance one would think that the incompatibility of the GPLv2 with the Apache Software License 2.0 should be a thing of the past now that everything upgrades to GPLv3, but it turns out that enough people are either stuck with GPLv2 only or do not agree with the GPLv3 that some Apache Software licensed projects are required to migrate. For instance Twitter's Bootstrap is currently migrating from ASL2.0 to MIT precisely because some people still need GPLv2 compatibility. Among those projects that were affected were Drupal, WordPress, Joomla, the MoinMoin Wiki and others. And even that case shows that people don't care that much about licenses any more as Joomla 3 just bundled bootstrap even though they were not licenses in a compatible way (GPLv2 vs ASL 2.0). The other traditional case of things not being GPL compatible is the OpenSSL project which has a license that does not go well with the GPL. That license is also still incompatible with the GPLv3. The whole ordeal is particularly interesting as some not so nice parties have started doing license trolling through GPL licenses.
- GNU project: Frequently Asked Questions about the GNU Licenses: Why don't you use the GPL for manuals? Retrieved 20 June 2009.
- Debian Project: Resolution: Why the GNU Free Documentation License is not suitable for Debian. Voted February–March 2006. Retrieved 20 June 2009.
- FLOSS Manuals foundation: License Change 6 June 2007. Retrieved 20 June 2009.
- 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" (accessed on 2015-11-21)
- 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
- Denis-Courmont, Rémi. "VLC media player to remain under GNU GPL version 2". videolan.org. Retrieved 2015-11-21.
In 2001, VLC was released under the OSI-approved GNU General Public version 2, with the commonly-offered option to use "any later version" thereof (though there was not any such later version at the time). Following the release by the Free Software Foundation (FSF) of the new version 3 of its GNU General Public License (GPL) on the 29th of June 2007, contributors to the VLC media player, and other software projects hosted at videolan.org, debated the possibility of updating the licensing terms for future version of the VLC media player and other hosted projects, to version 3 of the GPL. [...] There is strong concern that these new additional requirements might not match the industrial and economic reality of our time, especially in the market of consumer electronics. It is our belief that changing our licensing terms to GPL version 3 would currently not be in the best interest of our community as a whole. Consequently, we plan to keep distributing future versions of VLC media player under the terms of the GPL version 2. [...]we will continue to distribute the VLC media player source code under GPL "version 2 or any later version" until further notice.
- "Changing the VLC engine license to LGPL". Retrieved 23 October 2011.
- Vaughan-Nichols, Steven. "No GPL Apps for Apple's App Store". zdnet.com. Retrieved 23 October 2011.
- VLC under Mozilla public relaunched. Accessed 10/10/2013
- Mavrogiannopoulos, Nikos (2013-03-26). "The perils of LGPLv3". gnutls.org. Retrieved 2015-11-18.
LGPLv3 is the latest version of the GNU Lesser General Public License. It follows the successful LGPLv2.1 license, and was released by Free Software Foundation as a counterpart to its GNU General Public License version 3. The goal of the GNU Lesser General Public Licenses is to provide software that can be used by both proprietary and free software. This goal has been successfully handled so far by LGPLv2.1, and there is a multitude of libraries using that license. Now we have LGPLv3 as the latest, and the question is how successful is LGPLv3 on this goal? In my opinion, very little. If we assume that its primary goal is to be used by free software, then it blatantly fails that.
- Version 2.99.4 (released 2011-07-23)[...] ** libgnutls: license upgraded to LGPLv3
- 2013-03-14 Nikos Mavrogiannopoulos (email@example.com) * COPYING.LESSER, README: gnutls 3.1.10 is LGPLv2.1