Two open licences are compatible if a derived work can satisfy every clause of both at the same time; the technical quality of the code has nothing to do with it. Where that possibility does not exist, the code stays unusable in combination even when it compiles, runs and does exactly what is needed.

Context

An open licence is an instrument for managing copyright. In place of the legal order’s default rule — all rights reserved to the author — it puts an explicit grant of certain rights to third parties: access to the source code, study, copying, modification, redistribution. The Open Source Definition lists the criteria a licence must meet to count as such. Its Annotated Version reminds us that a licence does not exist in isolation from the applicable law: reading it without regard to the mandatory rules of the state where it operates is like reading a text while ignoring the dictionary of its language.

Open software rarely starts from scratch. The value lies in reuse: modules of different provenance are put together, each governed by its own licence. Here practice collides with the developer’s common intuition, by which one can “do anything” with code. In the abstract that holds. The moment I distribute a derived work, that “anything” shrinks to the operations the licence grants, and the set may be empty.

The problem

Putting two programs under different licences together produces a derived work that must satisfy both source licences at the same time. If the two impose obligations that cannot coexist, the derived work cannot be distributed lawfully: either the combination is dropped, or it is distributed anyway and copyright is infringed.

The most frequent incompatibility arises between two strong copyleft licences. Copyleft requires every derived work to be redistributed under the same licence. If licence A wants the derivative released under A, and licence B wants it released under B, the derivative would have to be A and B at the same time — mutually exclusive conditions. No derivative satisfies both, so no derivative is lawful.

The other source of incompatibility, less obvious, is patent clauses. Much of the recent friction turns on these, and they deserve a section of their own.

The architecture of the clauses

It helps to read licences not as monolithic blocks but as sets of clauses whose effects do or do not combine. Three families recur.

Permissive licences of the BSD kind impose few obligations: keep the copyright notice, reproduce the licence text, and in some variants do not use the author’s name to promote derivatives without permission. On the licence of the derived work they say nothing. That is why they combine with almost anything, proprietary code included: a BSD module is linked into a closed program with no compatibility problem, provided authorship is acknowledged.

Per-file or per-module copyleft licences, such as the Mozilla Public License 1.1, apply reciprocity to the single modified file rather than to the whole aggregate. With them one builds a work in which an MPL module and a proprietary module stay distinct and licensed separately, on condition that changes to the MPL files stay under MPL. It is a fine-grained copyleft, designed precisely to coexist with closed code.

Strong copyleft licences, such as the GNU GPL, extend the obligation to the entire derived work. Anyone who puts GPL code and other code together into a single work must release the whole under the GPL. This makes the GPL structurally incompatible with proprietary licences when combined derived works are created, and incompatible with any other licence that imposes conditions the GPL does not allow. The GNU LGPL loosens the constraint to permit linking from programs under other licences, but keeps the library itself copyleft.

The critical point: patents and the versions of the GPL

The case that shows how fragile compatibility is concerns the Apache License 2.0 and the GPL.

The Apache License 2.0 carries an express patent grant from contributors and a termination clause: anyone who starts patent action over the software loses the rights granted. The Free Software Foundation reads these clauses — patent termination and indemnity — as additional restrictions that the GPLv2 neither provides nor admits. For that reason Apache 2.0 and GPLv2 are incompatible: Apache 2.0 code cannot be incorporated into a GPLv2 work (Apache Software Foundation, GPL compatibility).

The GPLv3, published by the FSF on 29 June 2007 alongside the LGPLv3, was written with exactly these clauses in mind. It has its own patent grant and retaliation mechanism and expressly declares certain additional restrictions compatible, among them those of Apache 2.0. So the FSF considers Apache 2.0 compatible with GPLv3: Apache 2.0 code can be included in a GPLv3 project, while the reverse does not hold, because GPLv3 imposes conditions that Apache 2.0 does not reproduce.

Apache 2.0 and the GPL stay the same; the version of the counterpart changes, and the compatibility verdict flips. Compatibility is not an attribute of a single licence, but a relation between pairs of clauses, sensitive to revisions.

Implications for Italian law

The technical conclusion — a derivative is lawful only if it respects every source clause — coincides with what Italian copyright law provides. Article 4 of law 633/1941 protects creative elaborations of a work “without prejudice to the rights existing on the original work”. In the case of open software, the rights existing on the original work are those its licence defines. A derived work that breaches the source licence prejudices those rights, and the author’s authorisation lapses: the default reservation returns, all rights reserved. The software one meant to distribute becomes an infringement.

This brings back together two planes the developer tends to keep apart. The compatibility check is not a formality to be done after the code is written. It is a design constraint on a par with the technical dependencies, to be settled while the architecture is drawn, when there is still a choice of which library to adopt and under which licence to release.

Limits

The above fixes the general criterion but does not replace analysis of the concrete case. The line between “derived work” and “mere aggregation” is not crisp and depends on the mode of combination — static linking, dynamic linking, communication between separate processes — on which the communities themselves do not fully agree. On Apache 2.0 and GPLv3 compatibility there were conflicting readings, before the FSF positions settled. And every clause has to be read within the jurisdiction where it will apply: a licence written on a US model interacts with law 633/1941 in ways the original author did not always anticipate. Any release or commercial decision still calls for a specific study of the licences in play and of how they interact.

https://opensource.org/docs/osd https://www.gnu.org/licenses/license-list.html http://www.apache.org/licenses/GPL-compatibility.html https://www.gnu.org/licenses/gpl-3.0.html https://www.gnu.org/licenses/quick-guide-gplv3.html https://www.mozilla.org/MPL/1.1/ https://www.noze.it/en/insights/compatibilita-licenze-open-proprietarie/

Cover image: Arrow diagram showing compatibility among major open source software licenses — from permissive BSD-style licenses through MPL and… — diagram by David A. Wheeler, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Floss-license-slide-image.svg