The development of complex open source solutions is generally done by adapting and integrating multiple existing components. The resulting application (or “solution”) may look as a single program from the user point of view, but is in fact a combined work. The different components may be covered by different licences. Are they compatible and legally interoperable?
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).
Illustration: the EUPL compatibility
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. The EUPL v1.2, published in May 2017 (OJ 19/05/2017 L128 p. 59–64 ) has extended the EUPL compatibility to GPLv3, AGPL and other licences.
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 case of linking
In our opinion, linking two programs or linking an existing software with your own work does not – at least in Europe – produce a derivative or extend the coverage of the linked software licence to your own work. This opinion is based on the Directive 2009/24 EC on the legal protection of computer programs. This 2009 version codifies, without modifications, the original text written in 1991 (Directive 91/250/EEC). The aim of this Directive is to facilitate interoperability, making possible to connect all components of a computer system, including those of different manufacturers or authors, so that they can work together. Therefore the parts of the programs known as ‘interfaces’, which provide interconnection and interaction between elements of software and hardware may be reproduced by a legitimate licensee without any authorisation of their rightholder (“Whereas” (10) & (15) of the Directive). This implies that such interfaces escape to the copyleft provision of any licence, open source (like the GPL or EUPL) or proprietary. The technical way of linking for interoperability (static or dynamic) should not make any difference. For this purpose, the Directive (article 6) authorises the legitimate licensee to decompile the licensed program in order to obtain the information necessary to achieve the interoperability. This information can then be reproduced for the purpose of writing the interface. At the time the 1991 directive was written, the open source option was not considered: indeed, decompilation targets the case where the legitimate licensee has received the licensed program in object code only. However, it looks obvious that the exception implemented by the Directive could be used also when the licensee has access to the source code: in such case, code needed for interoperability is directly available, without the need for a decompilation. It remains that such an exception to the author's exclusive rights must be strictly limited to the parts that are needed for interoperability and may not be used in a way which prejudices the legitimate interests of the rightholder or which conflicts with a normal exploitation of the program.
A question to clarify at early stage
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).