License compatibility

License compatibility is an issue that arises when licenses are applied to copyrighted works, particularly licenses of software packages (software source code as also binary representation). Licenses can contain contradictory requirements, rendering it impossible to combine source code or content from such works in order to create new ones.

Example

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.

Definitions

License compatibility can be defined differently on with varying strength around the concepts of "collective/combined/aggregated work" and "derivative work". The first "collective work" license compatibility definition allows the usage of various licensed works 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,

License compatibility: Compatibility for derived works and combined works of own code and external developed open source licensed code (adapted from Mikko 2005). "Derived works" are mixing code, "combined works" have components under differing license. From right to left needs a combined work a stronger separation between differently licensed parts to prevent them in becoming a derived work ("separation": combined by statically linking or source file separation with all components living in the same process and address space, "strong separation": components connected only via binary interfaces and which live in separated processes).

Kinds of combined works

A "combined work" consists of multiple differently-licensed parts (avoiding relicensing). To achieve a combined work including also copyleft licensed components (which have a viral property leading potentially to a "derived work"), proper isolation/separation needs to be applied.

With individually licensed source code files multiple non-reciprocal licenses (as permissive licenses or own proprietary code) can be separated, while the combined compiled program could be relicensed (but is not required). Such source code file separation is too weak for copyleft/reciprocal licenses (as the GPL), as they require then the complete work to be relicensed under the reciprocal license as derivative.

A slightly stronger approach is a separation on the linking stage with binary object code (static linking) with all the components living in the resulting program in the same process and address space. This satisfies "weak copyleft/standard reciprocal" combined works (as LGPL licensed ones), but not "strong copyleft/strong reciprocal" combined works. While commonly accepted that linking (static and even dynamic linking) constitutes a derivative of a strong copyleft'd work, there are individual alternative interpretations.

For "combined works" with "strong copyleft" modules, a stronger isolation is required. This can be achieved for instance by separating the programs by an own process and only communication via binary ABIs or other indirect means. Examples are Android's kernel space-to-user space separation via Bionic, or Linux distros which have proprietary binary blobs included despite having a strong copyleft kernel.

While for some domains agreement exist if an isolation is suitable, there are domains in dispute and up to now untested in court. For instance, in 2015 the SFC sued VMware in an ongoing dispute whether loadable kernel modules (LKMs) are derivative works of the GPL'ed Linux kernel or not.

Compatibility of FOSS licenses

License compatibility between common FOSS software licenses according to David A. Wheeler (2007): the vector arrows denote a one directional compatibility, therefore better compatibility on the left side than on the right side.

Even accepted and common Open-source licenses are not necessarily compatible between each other. 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 characteristic makes the copyleft GPL (and most other copyleft licenses) incompatible with proprietary commercial licenses and also many non-proprietary licenses. This "one-way compatibility" characteristic is for instance 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 often have in general better license compatibility.

The Artistic license 2.0 is here notable for an excellent license compatibility with all other FOSS licenses due to a relicensing clause which allows redistribution of the source code under any other FOSS license.

You may Distribute your Modified Version as Source (either gratis or for a Distributor Fee, and with or without a Compiled form of the Modified Version) [...] provided that you do at least ONE of the following:

[...] (c) allow anyone who receives a copy of the Modified Version to make the Source form of the Modified Version available to others under

(i) the Original License or

(ii) a license that permits the licensee to freely copy, modify and redistribute the Modified Version using the same licensing terms that apply to the copy that the licensee received, and requires that the Source form of the Modified Version, and of any works derived from it, be made freely available in that license fees are prohibited but Distributor Fees are allowed.

The Common Development and Distribution License, a weak copyleft license in-between GPL license and BSD/MIT permissive licenses, tries to address license compatibility problems by permitting mixing of CDDL licensed source code files with source code files under other licenses without relicensing. The resulting binary can be licensed and sold under a different license as long as the source code is still available under CDDL, enabling more use cases.

GPL compatibility

See also: GNU General Public License § Compatibility and multi-licensing

To minimize license proliferation and license incompatibilities in the FOSS ecosystem, some organizations (for instance the FSF) and individuals (for instance David A. Wheeler), argue that compatibility to the widely used GPL is an important feature of software licenses. 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).

Copyleft licenses and GPL

When it comes to copyleft software licenses, they are not inherently GPL-compatible, even the GPLv2 is, by itself, not compatible with GPLv3. If you tried to combine code released under both these licenses, you would violate section 6 of GPLv2, resulting in the incompatibility. 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. 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.

GFDL and GPL

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 to use for documentation the GPL. The FLOSS Manuals foundation followed Debian in 2007. In 2009 the Wikimedia Foundation switched also from the GFDL to a CC-BY-SA license as main license for their projects.

CDDL and GPL

Another important and controversial debated case of GPL compatibility is the CDDL licensed ZFS file system with the GPLv2 licensed Linux kernel. Despite that both are free software under a copyleft license, ZFS is not distributed with most linux distros like Debian (but with FreeBSD and even Mac OS) as the CDDL is considered incompatible to the GPL'ed linux kernel by the FSF and most other FOSS parties. There exist also alternative positions as the legal interpretation, if and when this combination constitutes a "combined work" or "derivated work" of the GPL'ed kernel, is ambiguous and controversial. In 2015 the CDDL to GPL compatiblity question reemerged when the linux distribution Ubuntu announced to include OpenZFS by default. In 2016 Ubuntu announced that a legal review resulted in the conclusion that it is legally safe to use ZFS as binary kernel module in linux. Others followed Ubuntu's conclusion, for instance lawyer James E.J. Bottomley argued there can't be "a convincing theory of harm" developed making it impossible to bring the case to court. Eben Moglen, co-author of the GPLv3 and founder of the SFLC, argues that while the letters of the GPL might be violated the spirit of both licenses is unharmed, which would be the relevant aspect in court. On the other hand, Bradley M. Kuhn and Karen M. Sandler from the Software Freedom Conservancy argued that Ubuntu would violate both licenses as a binary ZFS module would be a derivative work of the linux kernel and announced their will to achieve clarity in this question, even by court.

CC BY-SA and GPLv3

On October 8, 2015 Creative Commons concluded that the CC BY-SA 4.0 is one-way compatible with the GPLv3.

Creative Commons license compatibility

A license compatibility chart for combining or mixing two CC licensed works.

The Creative Commons Licenses are widely used for content, but not all combinations of the seven recommended and supported licenses are compatible among each other. Also, this is often a one directional compatibility, requiring the complete work to be licensed under the more restrictive license of both.

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.

Relicensing examples

An early example of a project who did successfully re-license for license compatibility reasons is the Mozilla project and their Firefox browser. The source code of Netscape's Communicator 4.0 browser was originally released in 1998 under the Netscape Public License/Mozilla Public License but was criticised by the FSF and OSI for being incompatible. Around 2001 Time Warner, exercising its rights under the Netscape Public License, and at the request of the Mozilla Foundation, relicensed all code in Mozilla that was under the Netscape Public License (including code by other contributors) to an MPL 1.1/GPL 2.0/LGPL 2.1 tri-license, thus achieving GPL-compatibility.

The Vorbis library was originally licensed as LGPL, but in 2001 the license was changed to the BSD license with endorsement of Richard Stallman to encourage adoption.

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.

7-Zip's LZMA SDK, originally dual-licensed under both the GNU LGPL and Common Public License, with an additional special exception for linked binaries, was placed by Igor Pavlov in the public domain on December 2, 2008.

Another example is the GNU TLS project, which adopted in 2011 the LGPLv3 license but relicensed in 2013 their code back to LGPLv2.1 due to serious license compatibility problems.

The GNU Free Documentation License in version 1.2 is not compatible with the widely used Creative Commons Attribution-ShareAlike license, which was a problem for instance for the Wikipedia. Therefore, at the request of the Wikimedia Foundation the FSF added with version 1.3 of the GFDL a time-limited section allowing specific types of websites using the GFDL to additionally offer their work under the CC BY-SA license. Following in June 2009, the Wikimedia Foundation migrated their projects (Wikipedia, etc.) by dual licensing to the Creative Commons Attribution-ShareAlike as main license, additional to the previously used GFDL. An improved license compatibility with the greater free content ecosystem was given as reason for the license change.

Another interesting case was the relicensing of GPLv2 licensed linux kernel header files to the BSD license by Google for their Android library Bionic. To get rid of the GPL, Google claimed that the header files were cleaned from any copyright-able work, reducing them to non-copyrightable "facts". This interpretation was challenged for instance by Raymond Nimmer, a law professor at the University of Houston Law Center.

In 2014 the FreeCAD project changed their license from GPL to LGPLv2 due to GPLv3/GPLv2 incompatibilities.

Also the Dolphin project changed their license from "GPLv2 only" to "GPLv2 or any later" for better compatibility in May 2015.

In June 2015 mpv started the relicensation process of the project's source code for improved license compatibility under LGPLv2 by getting consent from the majority (95%+) of the contributing developers.

In July 2015 Seafile switched for improved license compatibility, especially with Git, from the GPLv3 to the GPLv2.

In 2016 MAME achieved a relicensing of the code base to BSD/GPL after struggeling for years with an own written custom license, with non-commercial license terms.

See also

• License proliferation
• Comparison of free and open-source software licenses (also license compatibility)
• Backward compatibility
• Forward compatibility

External links

• FLOSS Compatibility Diagram by David A. Wheeler (2007, some licenses superseded)sv:Kompatibilitet mellan licenser