Determining whether the various licences involved are compatible is important when the aim is to redistribute the application to third parties: under what open source licence should it be distributed? Is this always possible?
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”).
At the contrary, the “copyleft” licences impose the use of the same licence as soon the distributed work is a derivative of the covered work. To avoid software appropriation by third parties, a majority of open source projects have adopted copyleft licensing terms: the two Gnu GPLs and the EUPL are “copyleft”.
Some licences like the LGPL or the MPL try to compromise between the permissive and copyleft requirements: covered components (and their specific derivatives) will always keep their primary licence, but the combined application “as a whole” (even if it may be considered globally as a derivative) or its executable binary (a single program from the user point of view) can be distributed under any licence.
Licence incompatibility exists when a program is derivative of components licensed under two different copyleft licences (for example, the GPLv2, which is still the most used copyleft licence, is not compatible with GPLv3, and vice-versa).
A logical incompatibility issue may be resolved through dual licensing: the original licensor (owning full copyright) may provide the same program under two or more licences, even if these licenses are not compatible.
The most frequent cases apply to licensors distributing their work under the “GPL” (without mentioning the version number): in such case, recipients can use the work under any of these licences (GPLv2 or GPLv3), which is in practice a dual licensing.
When the licences are mutually incompatible, the risk of dual licensing is the forking of the program in various legally incompatible releases, which even the original licensor will not be able to reunify.
An alternative way to resolve incompatibility issues without the risk of forking is the constitution of an exception list. The advantage is to maintain the licensed component under a single licence including its specific derivatives, while allowing combined derivative works where the component is integrated or merged to be licensed under an alternate licence. The difference with the more permissive LGPL system is that exception lists specify which licence(s) are accepted (not “any” licence).
Exception lists can be implemented at licence level: this is done by the EUPL, where an appendix of “compatible licences” specifies which licences can be used in case of “combined derivative” (when the program is a derivative of both a EUPLed component and another component licensed under a compatible licence). The disadvantage of such practice is that it does not facilitate very frequent updates: adapting the list (for example in case a compatible licence is updated with a new version number) modifies the licence (producing a new version that will not be automatically OSI-approved) and impact its whole community of users (some of them may disagree with the extension…).
Exception lists can also (and in addition) be implemented by a specific licensor. This is especially recommended when a licensor distributes a library of components under a copyleft licence (as the GPLv2 or V3) instead of using the more permissive LGPL or MPL (which are generally the most adapted licences for such components). For example, Oracle distributes MySQL component libraries under the GPLv2, but has implemented the “MySQL FOSS Exception List” authorising the distribution of combined derivatives under about 20 other FOSS licences (including the copyleft GPLv3 and the EUPL). Similarly, a licensor could distribute a library of components under the EUPL and implement an exception list for some licences that are not in the EUPL compatibility list (for example the GPLv3).
The EUPL upstream (incoming components) and downstream compatibility (distribution of the resulting work) can be illustrated as follows:
For a complete analysis of the EUPL compatibility (with all OSI-approved licences) please refer to the EUPL compatibility matrix
In many cases, simply using or combining a component (even if the combined software is perceived by the end user as a single program) does not produce a “derivative work” according to the applicable copyright law. For example, such combined work could be distributed under the EUPL even if one of its components was obtained under the GPLv3.
In general, the distribution of a combined work does not change (producing a forking) the licence of its covered components.
If the combined work is a derivative of its components (because their source codes are merged) you cannot distribute it under the EUPL if at least one of these components is covered by the GPLv2 and if there is no exception list including the EUPL. This is the main case where you must distribute under the GPLv2 (similar solution for components covered by the CeCILL licence, which is occasionally used in France).
The sooner you examine licence compatibility, the better it is. If the intention of the software producer is to distribute the work under a specific licence, it is advised to declare this licence in the specifications (if software developers are contractors, they will be responsible for using new or compatible components) or in a contributor’s agreement (if the software is produced by a FOSS community of developers).