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.
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.
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.
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.
GPL 2 is not compatible with GPL 3, and vice versa, as they both are restrictive licenses that restrict each other mutually.
Linux was licensed as a GPL2-only. To know more about this and why Linus Torvalds dislikes GPL3, follow this external link.
General Public License (GPL) 3
GPL 3 offers stronger protection against patents than GPL 2.
GPL-3.0 is more compatible than GPL-2.0. 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 freedom.