License compatibility

License compatibility is a legal framework that allows for pieces of software with different software licenses to be distributed together. The need for such a framework arises because the different licenses can contain contradictory requirements, rendering it impossible to legally combine source code from separately-licensed software in order to create and publish a new program. Proprietary licenses are generally program-specific and incompatible; authors must negotiate to combine code. Copyleft licenses are commonly deliberately incompatible with proprietary licenses, in order to prevent copyleft software from being re-licensed under a proprietary license, turning it into proprietary software. Many copyleft licenses explicitly allow relicensing under some other copyleft licenses. Permissive licenses are (with minor exceptions) compatible with everything, including proprietary licenses; there is thus no guarantee that all derived works will remain under a permissive license.

Definitions

License compatibility can be defined around the concepts of "collective/combined/aggregated work" and "derivative work". The first "collective work" license compatibility definition allows the usage of variously-licensed works in a combined context:

A stronger definition includes the capability to change the license. The most prominent example is the copyleft license's demand that the "derived work" combined from code under various licenses as whole is applied to the copyleft license.

Kinds of combined works

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

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

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

For combined works with "strong copyleft" modules, a stronger isolation is required. This can be achieved by separating the programs by an own process and allowing communication only 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 exists 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 (LKM's) are derivative works of the GPL'd Linux kernel or not.

Compatibility of FOSS licenses

Licenses common to free and open-source software (FOSS) are not necessarily compatible with each other, and this can make it legally impossible to mix (or link) open-source code if the components have 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 terms of the licenses; this despite both licenses being approved by both the Open Source Initiative and the Free Software Foundation.

License compatibility between a copyleft license and another license is often only a one-way compatibility, making the copyleft license (GPL, and most other copyleft licenses) incompatible with proprietary commercial licenses, as well as with many non-proprietary licenses. This "one-way compatibility" characteristic has been criticized by the Apache Foundation, which licenses under the more permissive Apache license, such non-copyleft licenses being often less complicated and making for better license compatibility.

An example of a license that has excellent compatibility with other FOSS licenses is the Artistic License 2.0, due to its re-licensing clause which allows redistribution of the source code under any other FOSS license.

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

GPL compatibility

To minimize license proliferation and license incompatibilities in the FOSS ecosystem, some organizations (the Free Software Foundation, for instance) and individuals (David A. Wheeler), argue that compatibility with 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 (but the other license would not so apply).

Copyleft licenses and GPL

Copyleft software licenses are not inherently GPL-compatible; even the GPLv2 license by itself is not compatible with GPLv3 or LGPLv3. If you tried to combine code released under either of the later GPL licenses with GPLv2 code, you would violate section 6 of GPLv2, the source of the incompatibility. However, code under the later licenses can be combined with code licensed under GPL version 2 or later. Most software released under GPLv2 allow you to use the terms of later versions of the GPL as well, and some have exception clauses that allow combining them with software that is under different licenses or license versions. The Linux kernel is a notable exception that is distributed exclusively under the terms of GPLv2.

GFDL and GPL

The Free Software Foundation-recommended GNU Free Documentation License is incompatible with the GPL license, and text licensed under the GFDL cannot be incorporated into GPL software. Therefore, the Debian project decided, in a 2006 resolution, to license documentation under the GPL. The FLOSS Manuals foundation followed Debian in 2007. In 2009, the Wikimedia Foundation switched from the GFDL to a Creative Commons CC-BY-SA license as the main license for their projects.

CDDL and GPL

Another case where GPL compatibility is problematic 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 is distributed with FreeBSD) as the CDDL is considered incompatible with the GPL'ed Linux kernel, by the Free Software Foundation and some parties with relations with the FSF. The legal interpretation—of if and when this combination constitutes a combined work or derivative work of the GPLed kernel—is ambiguous and controversial. In 2015, the CDDL to GPL compatibility question reemerged when the linux distribution Ubuntu announced that it would 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 a binary kernel module in Linux. Others accepted Ubuntu's conclusion; for instance lawyer James E.J. Bottomley argued "a convincing theory of harm" cannot be developed, making it impossible to bring the case to court. Eben Moglen, co-author of the GPLv3 and founder of the SFLC, argued that while the letters of the GPL might be violated the spirit of both licenses is adhered to, which would be the relevant issue 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 intent to achieve clarity in this question, even by going to court.

CC BY-SA and GPLv3

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

Creative Commons license compatibility

The Creative Commons Licenses are widely used for content, but not all combinations of the seven recommended and supported licenses are compatible with each other. Additionally, this is often only a one-way directional compatibility, requiring a complete work to be licensed under the most restrictive license of the parent works.

JSON license

JSON developer Douglas Crockford, inspired by the words of then President Bush, formulated the "evil-doers" JSON license ("The Software shall be used for Good, not Evil.") This subjective and moral license clause led to license incompatibility problems with other open source licenses, and resulted in the JSON license not being a free and open-source license.

Re-licensing for compatibility

Sometimes projects wind up with incompatible licenses, and the only feasible way to solve it is the re-licensing of the incompatible parts. Re-licensing is achieved by contacting all involved developers and other parties and getting their agreement for the changed license. While in the free and open-source domain achieving 100% agreement is often impossible, due to the many contributors involved, the Mozilla re-licensing project assumes that achieving 95% is enough for the re-licensing of the complete code base. Others in the FOSS domain, such as Eric S. Raymond, came to different conclusions regarding the requirements for re-licensing of an entire code base.

Re-licensing examples

An early example of a project that successfully re-licensed for license incompatibility 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 Free Software Foundation (FSF) and OSI for being incompatible with the GNU General Public License (GPL). Around 2001 Time Warner, exercising its rights under the Netscape Public License, and at the request of the Mozilla Foundation, re-licensed 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, with the endorsement of Richard Stallman, the license was changed to the less restrictive BSD license, to accelerate the library's adoption.

The VLC project has a complicated license history due to license incompatibility, and in 2007 the project decided, for license compatibility, to not upgrade to the just released GPLv3. In October 2011, after the VLC had been removed from the Apple App Store at the start of 2011, the VLC project re-licensed the VLC library, from the GPLv2 to the LGPLv2, to achieve better compatibility. In July 2013, the software re-licensed under the Mozilla Public License, the VLC application would then be resubmitted to the iOS App Store.

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

Another interesting case was Google's re-licensing of GPLv2-licensed Linux kernel header files to the BSD license for their Android library Bionic. Google claimed that the header files were clean of any copyright-able work, reducing them to non-copyrightable "facts", and thus not covered by the GPL. This interpretation was challenged by Raymond Nimmer, a law professor at the University of Houston Law Center. Apps and drivers of Android, which provide an increasing amount of Android's functionality, have been gradually relicensed from permissive to proprietary licenses.

In 2014, the FreeCAD project changed their license from GPL to LGPLv2, due to GPLv3/GPLv2 incompatibilities. Also in 2014, Gang Garrison 2 was re-licensed from GPLv3 to MPL for improved library compatibility.

The KaiOS mobile operating system was derived from the Firefox OS/Boot to Gecko operating system, which was released under the permissive MPL 2.0. It does not redistribute itself under the same license, so it is now presumably relicensed, and proprietary (but still mostly open-source). KaiOS also uses the GPL Linux kernel also used in Android.

See also

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

References

{{Reflist, 30em

Copyright licenses
Terms of service