Copyleft licenses are also known as reciprocate, share-alike or restrictive licenses.
These licenses allow you to modify the licensed code and distribute new works based on it, as long as you distribute any new works or adaptations under the same software license.
Inside copyleft, some consider two different sub-types:
- Weak: source code can be combined with other licenses, including proprietary, without modifying the original license
- Strong: when source code is combined with other source code, the latter loses its original license and adopts the strong copyleft license
Two source codes that have different strong copyleft licenses are incompatible, because both expects the other to change its license.
Example of copyleft licenses:
- Weak copyleft
- Mozilla Public License (MPL)
- Eclipse Public License (EPL) 2.0
- European Union Public License (EUPL) 1.2
- LGPL v2.1
- Strong copyleft
- GNU GPL v2.0
- GNU GPL v3.0
- GNU Affero GPL (AGPL) v3.0
GPL licenses are the most popular of copyleft licenses.
Take into account that all GPL licenses has two option: the “only” and the “or later”. If you choose the GPL “only” version, you only apply the selected version of the GPL license. If you choose the “or later” version, it means that it will be compatible and agree with future GPL versions.
FSF recommends that project leaders choose the “or later” version because copyright lasts decades later than people deceases, and it is a difficult situation to handle.
Some notes about GPL licenses compatibility:
- GPLv2.0-only code is NOT compatible with GPLv3.0 (neither “only” nor “or-later”) code.
- GPLv2.0-or-later code is compatible with GPLv3.0 (both “only” and “or-later”) code. The resulting code would be GPLv3.0.
- Apache 2.0 code is NOT compatible with GPLv2.0 (neither “only” nor “or-later”) code.
- Apache 2.0 code is compatible with GPLv3.0 (both “only” and “or-later”) code.
Some project leaders that look for strong copyleft licenses prefer to release the code as GPLv2.0-or-later to ensure compatibility with other projects. On the other hand, FSF recommends that all code is released as GPLv3.0-or-later as it is a more mature license.
The terms license inheritance or license contamination are used to refer to the situation where the use of a strong copyleft license in a project forces the adoption of this license to code originally released in a different license.
License isolation, license interoperability or license safety may refer to the approaches to avoid the referred situation.
You can find more information about what is copyleft on this external link.
Mozilla Public License (MPL) 2.0
Mozilla Public License (MPL) 2.0, shorten as MPL-2.0, is a copyleft license compatible to some extend with other copyleft or proprietary licenses.
You can distribute binaries under a proprietary license, as long as you make the source available under MPL.
Eclipse Public License (EPL) 2.0
Eclipse Public License (EPL) 2.0, shorten as EPL-2.0, is a copyleft license.
Binaries can be licensed under any license, as long as the source code stay available under EPL.
It is mostly used on projects by Eclipse foundation.
European Union Public License (EUPL) 1.2
EUPL was released in 2017.
The main reason for the European Union to create its own restrictive license instead of reusing an existing one:
- The licence should have equal legal value in many languages
- The terminology regarding intellectual property rights had to be conformant with the European law requirements
- To be valid in all Member States, limitations of liability or warranty had to be precise, and not formulated “to the extent allowed by the law” as in most licences designed with the legal environment of the United States in mind
It would be copyleft, as clarified on this external link:
the EUPL v1.2 is copyleft (or share-alike) for protecting the covered software only from exclusive appropriation, but it has no pretention for any “viral extension” to other software in case of linking.
The Interoperability National Schema of Spain (in Spanish, Esquema Nacional de Interoperabilidad, ENI) in the article 16 establishes that the desired license is it.
Lesser General Public License (LGPL)
Lesser General Public License (LGPL) is considered a weak copyleft license.
It is derived from GPL license. In fact, LGPL is a set of additional permissions on top of the GPL.
LGPL allows you to link to open source libraries in your software. If you simply compile or link an LGPL-licensed library with your own code, you can release your application under any license you want, even a proprietary license. But if you modify the library or copy parts of it into your code, you will have to release your application under similar terms as the LGPL.
In conclusion, LGPL may be linked to proprietary code if no changes are applied to original code. In contrast, software with licenses strong copyleft GPL, for example, could never be linked to proprietary code.
General Public License (GPL) 2
GPL is the original GNU GPL family of licenses. It is probably the most popular family of copyleft or restrictive licenses.
Software that received under the GPL may be referred with the adjective “GLPed”.
GPL license is only triggered when software is distributed to users.
GPL2 was issued in 1991.
GPL2 license inheritance
GPL licenses have a “viral” extension of licence coverage so other linked software will be GPLed. This viral aspect is part of the criticism against the license.
GPL2 upgradability
GPL 2 is not compatible with GPL3, and vice versa, as they both are restrictive licenses that restrict each other mutually.
Some GPL2 licenses allow to be upgraded to GPL3 or any later version of the GPL family.
To ascertain whether a GPL2 project is GPL2-or-later or GPL2-only, the license accompanying the project should be reviewed and the following paragraph located:
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
If the “any later version” phrasing is included, it is GPL2-or-later. Otherwise is GPL2-only.
Because of this, saying that a project has a “GPL2” license may not be accurate enough; it is more specific to say whether a project is GPL2-or-later or GPL2-only.
Linux is one of the best examples of GPL2-only license. To know more about the particular situation of Linux towards the GPL2 license and why Linus Torvalds dislikes GPL3, follow this external link.
GPL2 source code availability requirement
GPL2 required either embedding the source code with the binaries or a written offer.
The written offer must include the postal address. This is a reminiscent of the early 1990’s, when e-mail addresses and websites were not mainstreams.
Modern GPL2 projects include the written offer in the README or NOTICE files or the user manual.
This requirement was updated in GPL3.
General Public License (GPL) 3
GPL3 offers stronger protection against patents than GPL 2. It was issued in 2007.
GPL-3.0 was designed to enhance compatibility with other licenses. For example, Apache-2.0 and CC BY-SA 4.0 is one-way compatible with GPL-3.0, while they are incompatible with GPL-2.0.
You can read more about CC BY-SA 4.0 and GPL-3.0 compatibility on this external link.
GPL-3.0 is not compatible with GPL-2.0-only, and vice versa. However GPL-2.0-or-later is one-way compatible with GPL-3.0.
Affero General Public License (AGPL)
Affero General Public License (AGPL) would be the same as GPL but adding a clause that adds the obligation to share the source code if it is run to offer service to a computer network. This was done to avoid a loophole on GPL license.
GPL license is only triggered when software is distributed. In web applications, software may be never distributed and it is run only from servers. This allows to run modified versions of GPLed software in servers without sharing the source code.
AGPL tries to avoid this situation by adding the extra clause.
This situation is explained by FSF on this external link.
GNU AGPL is not compatible with GPLv2.
The drawback of using an AGPL is that modifications to source code must be published even if software is internally used without offering a external service or software, for example by a particular or company. It means that AGPL adds more obligations to developers that does not exist on GPL; simplifying, AGPL enforces collaboration over individual freedom.
How to interface with strong copyleft code without license inheritance
This section explains how to integrate strong copyleft code with another code of a different license while avoiding the adoption of the former, with a strong focus on GPL2 and GPL2 licenses.
The key is to avoid that the new code is considered “derivative work” of the strong copyleft ones, and consider it “mere aggregation” instead. This means that both parts of the code should not be considered a single work where one cannot exist without the other.
Hints when interoperating with strong copyleft code without license inheritance:
- Avoid linking code. Do not make direct calls to the strong copyleft code.
- Use process separation. Execute the restrictive binaries using IPC or an executable call.
- Keep the interface generic. The interface must work on any program that follows a documented protocol.
- Distribute binaries separately. Instruct user to download the strong copyleft part manually, or download at user request after displaying and requering acceptance of the license terms.
- Document independence. Make it clear in the documentation that the program can interact with different implementations of the interfaced program.
- Comply with the strong copyleft license.
In case of using launcher and plugins:
- Display License Terms Clearly
- Display the license terms for each plugin, including GPLv2 and MIT ones.
- This can be done in a plugin info screen, a license viewer, or a “plugin details” section.
- For GPL plugins, you must:
- Include the GPL license text.
- Include the copyright notice of the plugin.
- Provide access to the source code or a written offer to obtain it.2
- Avoid tight coupling
- Ensure your launcher is not hardcoded to only work with the GPL plugin.
- Use a generic plugin interface so that users can choose from multiple plugin sources and licenses.
- Document Plugin Origin
- Make it clear that the GPL plugin is third-party software.
- If the launcher downloads it, clarify that it is not bundled but fetched from an external source.
- Separate Distribution
- If possible, avoid distributing the GPL plugin together with the launcher.
- Instead, let users download it themselves via the launcher or manually.
- Support multiple plugin types.