Software Licensing Guides Series

Table of Contents

Licence Types

Open source licences can be classified into several categories. Below is a brief list of these categories.

Public domain offers the most permissive model and is not a licence. It is not always possible to waive all rights under some countries’ laws and regulations. For such cases, the CC0 public domain dedication can replace the public domain.

Permissive licences impose minimal requirements on how software may be modified or redistributed. This type of licence is used by almost two-thirds of open source software.

Copyleft licences allow the modification and distribution of new works based on the code provided that the requirements for redistribution under the same conditions are met.

  • Weak copyleft licences have a library or file scope.
  • Strong copyleft licences often require releasing the entire project or product under a licence that is the same or similar to the one used in the original works.
  • Network protective consider usage over a network as distribution, requiring modified code to be available to external users.

Every licence listed below is classified in one of the above categories below the title containing the licence name. For easier use with Mend reports, the licences are presented alphabetically after being grouped into the IPR risk groups. Mend defines three risk categories of software licences – Low Risk, Medium Risk and High Risk, which can broadly be matched with Permissive, Weak Copyleft and Strong Copyleft. This categorisation is not strict (e.g., Artistic 2.0 is a permissive licence but belongs to Mend’s medium risk category). In this document, licences are listed for each category in alphabetical order. This document lists only licences in GÉANT software projects that were detected by Mend.

Licence Compatibility

Figure 1: Relationships between software frequent licences in GÉANT projects

Most frequently used licences in GÉANT software projects and relationships between them can be found in Figure 1. Different colours indicate different categories of software licences. Licences marked with green are permissive licences, those marked with yellow are weak copyleft licences, and those marked with red represent strong copyleft licences. Different relationships between licences are represented with different arrow styles.

  • One-way line arrow means that the destination licence of this relation subsumes the origin licence. In certain cases, there may be additional conditions for such a relation.
  • One-way dashed arrow means that there is a newer version of the licence and that the author should replace the older version in his code.
  • One-way dotted arrow means that the older licence may be replaced with the new version of the licence, by an author that is using the code and modifying it or mixing it with their own, but only if the original code has not been distributed with additional licence(s).
  • Two-way line arrow means that both licences are interchangeable.
  • Two-way dashed arrow means that authors can license combined work under either of these licences. In this so-called two-way compatibility case, authors are recommended to publish combined work under both licences for better future compatibility.

In this document, wherever there is a statement “Licence A is subsumed by licence B,” it means that code under licence A can be included in work licensed under licence B; it is represented in Figure 1 by an arrow going from A to B. It is the same as stating “Licence B subsumes licence A. When some licence A is subsumed by licence B, a copy of licence A still needs to be included with all distributions of the combined program. Interchangeable means that code under licences A and B can be licensed under either one of them. It may also be stated that “Licence A is compatible with Licence B” – this means that it is allowed to publish or distribute combined work under one of these licences. When licences are compatible, that means it is possible to legally combine or merge several pieces of software, each licensed under one of those licences. The purpose of the document is to help with licensing of the combined program.

Open software licences typically require keeping the licence with the code that is covered by it, typically by providing its original text or, sometimes, a reference to it. In a strict sense, the licensing of the combined program includes the licences of all its parts. A summary description of the procedure for licensing the combined program.

To find out which licences can be used by authors of the combined program, authors should start with a list of all the licences used in their work. Then it is possible to delete from the list any licence that is subsumed by another in the list, that is, the code under it can be included in software under the other. It is said that licence A is subsumed by licence B when compliance with licence A implies compliance with licence B. For instance:

  • LGPL 2.1 is subsumed by LGPL 3.0, and both are subsumed by GPL 3.0 and AGPL 3.0.
  • LGPL 2.0 and GPL 2.0 are NOT automatically subsumed by LGPL 3.0 and GPL 3.0. The Apache 2.0 licence is subsumed by any GNU licence, version 3.0 or later.
  • Mozilla Public Licence 2.0 is subsumed by GNU GPL, version 2.0, 3.0 or later.
  • BSD, Expat, X11 and ISC licences and CC0 public domain dedication are subsumed by Apache 2.0 licence.
  • Expat, X11 and ISC licences are interchangeable with the BSD 2-clause licence.
  • BSD 2-clause is subsumed by BSD-3 clause.

When describing relationships between licences in this document, the phrase “generally considered” is often used. This indicates that there is no explicit statement of the relationship in any licence text, but it is inferred from licence clauses, and there is no existing legal precedent.

Low-Risk Licences

Apache-2.0

Permissive

The Apache 2.0 licence allows the use, distribution and modification of software for any purpose. Derivative works may have stricter licences, but unaltered components must use Apache 2.0. There is strong OSI community support. Unlike MIT, recipients receive a patent licence. Applicable law and competent court are unspecified.

Requirements and mixing: The original copyright notice should be included in a separate file, with copying of the NOTICE file with attribution notes (if present) from the original library. The source code should include licence text and a notice of significant changes in modified files. There is no obligation to disclose affected source code, but modification notifications must be included. Sublicensing of relevant code is permitted.

Compatibility and linking: The licence is subsumed by GPL 3.0, LGPL 3.0 and CDDL. It is two-way compatible with MIT, BSD (2- and 3-clause) and MPL 2.0. It is linking permissive.

Patent rights: Patent rights to the software user/developer are explicitly granted.

Remarks: The Apache licence does not grant trademark rights, implying that users cannot use the project's name or associated trademarks without explicit permission.

BSL-1.0

Permissive

The Boost Software License (BSL) imposes minimal restrictions on code use and redistribution. Initially created for the Boost C++ Libraries, it encourages open collaboration in a business-friendly and flexible manner.

Requirements: The source code should include the original copyright notice. If distributing compiled code, this requirement does not apply. Include licence text, while a notice of significant changes is not required. There is no obligation to disclose affected source code. Users have the right to sublicense the software and its modifications, providing additional flexibility in licensing downstream recipients.

Compatibility, linking and mixing: It is subsumed by the entire GPL family (including LGPL and AGPL licences) and is linking permissive. The BSL 1.0 licence is two-way compatible with MIT, BSD (2- and 3-clause), Apache 2.0 and MPL. It can be included in projects licensed under Apache License 2.0.

Patent rights: The BSL 1.0 licence includes a patent grant, allowing users to use the software without concerns about patent-related issues from the original contributors.

Bouncy Castle License

Permissive

Should be read in the same way as the MIT licence. The Bouncy Castle License is specific to the Bouncy Castle Crypto APIs, a widely used cryptography library in Java and C#. Designed to be business-friendly while promoting the use of strong cryptography.

Requirements: The source code should include notice files and the original licence. Must retain and add new attributions for copyright/authorship/recognition. Modified files must be marked as such to maintain transparency. Users are allowed to sublicense the software and its modifications.

Compatibility, linking and mixing: Code under MIT, BSD (2- and 3-clause), Apache 2.0 and MPL 2.0 can be combined with code under the Bouncy Castle License and published under either of the input licences. Code under the Bouncy Castle License can be included in projects licensed under the GPL and LGPL.

Patent rights: The licence does not include specific patent or export control provisions.

BSD-2-Clause

Permissive

BSD licences are a family of permissive licences with minimal restrictions on the redistribution of covered software. BSD 2-Clause is the simplest BSD licence and the most compatible with other licences.

Requirements: The original copyright notice should be added to the licence text. The source code should include licence text. The source code does not have to include a notice of significant changes. There is no obligation to disclose affected source code. Sublicensing of relevant code is permitted.

Compatibility, linking and mixing: It is subsumed by the entire GPL family, including LGPL and AGPL licences, and is linking permissive. BSD 2-clause is interchangeable with MIT and ISC licences. MPL and Apache 2.0 licences are two-way compatible with BSD 2-clause licence. BSD 2-clause is subsumed by BSD 3-clause and 4-clause.

Patent rights: Patent rights are likely implied. It provides a limited patent grant for the original contributions.

Remarks: Omitted prohibition to use the name of the project to promote work.

BSD-3-Clause

Permissive

Besides the conditions in BSD 2-clause, the name of the author may not be used to endorse or promote products derived from this software without specific prior written permission.

Requirements: The original copyright notice should be added to the licence text. The source code should include licence text. It does not have to include a notice of significant changes. There is no obligation to disclose affected source code. Sublicensing of relevant code is permitted.

Compatibility, linking and mixing: The licence is subsumed by GPL and LGPL licences. ISC, MIT, MPL and Apache 2.0 are two-way compatible with BSD 3-clause. BSD 3-clause is subsumed by BSD 4-clause. It is linking permissive.

Patent rights: Patent rights are likely implied. It provides a limited patent grant for the original contributions.

Remarks: Non-endorsement clause – prohibited from using the name of the project or its contributors without written permission.

BSD-4-Clause

Permissive

Besides the conditions in BSD 3-clause, neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

Requirements: The original copyright notice should be added to the licence text. The source code should include licence text. The source code should include an acknowledgement statement. It does not have to include a notice of significant changes. There is no obligation to disclose affected source code. Sublicensing of relevant code is permitted.

Compatibility, linking and mixing: BSD 4-clause is not GNU-GPL compatible and may cause issues when combined with other licences. Due to the advertising clause, BSD 4-clause is not compatible with other licences, especially those with more restrictive terms that prohibit the additional requirement of the advertising clause. Still, it subsumes other BSD licences.

Patent rights: Patent rights are likely implied.

CDDL-1.0

Weak Copyleft

The Common Development and Distribution License (CDDL) is derived from the Mozilla Public License 1.1. CDDL is used primarily for Oracle-related projects, allowing both commercial and non-commercial use.

Requirements: Must retain the original copyright notice, licence text and a list of conditions in the software documentation or other materials provided with the distribution. The original source code and modified derivatives must be made available. Sublicensing of relevant code is permitted.

Compatibility, linking and mixing: CDDL 1.0 is considered incompatible with GPL. CDDL is generally considered two-way compatible with 2-clause and 3-clause BSD, MIT and Apache 2.0. It is linking permissive.

Patent rights: The licence includes a patent grant clause, providing a limited patent licence to the patents owned by contributors.

CDDL-1.1

Weak Copyleft

CDDL 1.1 includes some corrections of CDDL 1.0 conflicts with European Copyright law and to allow single developers to use CDDL for their work. It is considered a weak copyleft licence, with copyleft at the file level.

Requirements: Original copyright notice should be added to the licence text. The source code should include licence text. It does not have to include a notice of significant changes, but you should disclose affected source code when distributing work. Developers should ensure that a derivative work is licensed under the same version of the licence.

Compatibility, linking and mixing: It is not compatible with the entire GPL family (including LGPL and AGPL licences). CDDL is generally considered two-way compatible with 2-clause and 3-clause BSD, MIT, MPL 2.0 and Apache 2.0. It is allowed to combine CDDL-licensed code with software under other licences to create an aggregate “larger work,” which can be kept proprietary or released under a different licence. It is linking permissive.

Patent rights: Patent rights are explicitly granted.

Remarks: Use dynamic linking in languages that also have static linking.

CC-BY-SA-4.0

Strong Copyleft

Commons Attribution-Share Alike 4.0 International (CC BY-SA 4.0) licence is a widely used open access licence for creative works, enabling creators to share their works while maintaining certain rights and control.

Requirements: Original copyright notice should be added to the licence text. The source code should include licence text or a URL link to the licence text. Include notice of modifications and retain previous indications. There is no obligation to disclose affected source code. You cannot sublicense relevant code.

Compatibility, linking and mixing: This licence is subsumed by GPL 3.0 but not by GPL 2.0. CC BY-SA 4.0 subsumes CC BY 4.0, CC BY-NC-SA 4.0 and other CC 4.0 licences. It is not linking permissive.

Patent rights: Patent rights are not granted.

Golang BSD + Patents

Permissive

The Golang BSD + Patents licence is based on the BSD 3-clause licence and also includes explicit patent rights.

Requirements: The original copyright notice should be added to the licence text. The source code should include licence text but not a notice of significant changes. There is no obligation to disclose affected source code. Sublicensing of relevant code is permitted.

Compatibility, linking and mixing: The licence is subsumed by all GPL and LGPL. Code under BSD 2-clause, BSD 3-clause, MIT and Apache 2.0 licences can be combined with code under the Golang BSD + Patents under either of the input licences. Golang BSD + Patents is two-way compatible with MPL. It is linking permissive.

Patent rights: The licence includes a patent grant.

Remarks: It essentially is BSD 3-clause with the added condition that users cannot sue Google for licence infringement.

ISC

Permissive

The ISC licence is a “stripped-down” version of the MIT and simplified 2-clause BSD, removing extraneous language.

Requirements: Original copyright notice should be added to the licence text. The source code should include licence text but not a notice of significant changes. There is no obligation to disclose affected source code. Sublicensing of relevant code is permitted.

Compatibility, linking and mixing: It is linking permissive. ISC is generally considered interchangeable with other permissive licences like MIT and BSD 2-clause licences. It is two-way compatible with BSD 3-clause licence. ISC-licensed code can be included in projects licensed under the GPL, LGPL, MPL, Apache 2.0 and CDDL.

Patent rights: Patent rights are not granted.

MIT

Permissive

The MIT licence is highly compatible with other permissive licences.

Requirements: Original copyright notice should be added to the licence text. The source code should include licence text but not a notice of significant changes. There is no obligation to disclose affected source code. Sublicensing of relevant code is permitted.

Compatibility, linking and mixing: It is linking permissive. Code under 2-clause BSD and ISC licences can be freely combined with MIT-licensed code and published under each of these licences. BSD 3-clause, MPL and Apache 2.0 licences are two-way compatible with MIT licence. MIT-licensed code can be used in GPL, LGPL and CDDL-licensed projects.

Patent rights: Implicit in the US due to “without restriction”.

Remarks: It allows the use or mention of trademarks.

Nunit

Permissive

NUnit is a unit-testing framework for all .Net languages. Its newer versions (starting from 3.0) are released under the MIT licence, while the older versions are using zlib/libpng licence. The licence allows the use of NUnit in free and commercial applications and libraries without restrictions.

Requirements: (By association with MIT licence) Original copyright notice should be added to the licence text. The source code should include licence text but not a notice of significant changes. There is no obligation to disclose affected source code. Sublicensing of relevant code is permitted.

Compatibility, linking and mixing: It is linking permissive by association with the MIT licence. Code under BSD 2-clause, ISC and other MIT-licensed code may be freely combined and published under either of input licences. BSD 3-clause, MPL and Apache 2.0 licences are two-way compatible with Nunit license. Nunit-licensed code can be used in GPL, LGPL and CDDL-licensed projects.

Patent rights: (By association with MIT licence) Implicit in the US due to "without restriction".

Public Domain

Public Domain

Public domain is not a licence as such, but “public domain dedication” means the creator relinquishes all rights to a work, placing it in the public domain. This allows anyone to freely use, modify, distribute and adapt the work without restrictions or licensing conditions. Since Public Domain is usually implicit, it is often formalised by applying CC0.

Requirements: None.

Compatibility, linking and mixing: There are no conflicts or restrictions related to licence compatibility when using or combining public domain works with works under any other licence, whether open source or proprietary. This means that Public Domain is subsumed by any licence.

Patent rights: Public-domain-equivalent formalisations (such as CC0, Unlicense, WTFPL) grant public-domain-like rights and/or act as waivers, without any conditions.

Python-2.0

Permissive

Python 2.0 is primarily used for the distribution of Python project software and documentation.

Requirements: The source code should include the original copyright notice and licence text, as well as notices of significant changes. There is no obligation to disclose affected source code. Sublicensing of relevant code is permitted.

Compatibility, linking and mixing: Python licences are subsumed by GPL and LGPL, except for Python versions 1.6b1 through 2.1. Code under MIT, Apache 2.0, MPL and BSD (2- and 3-clause) can be combined with Python 2.0-licensed code, as they are considered two-way compatible. Python 2.0 licence is subsumed by CDDL 1.1 licence. It is linking permissive.

Patent rights: Royalty-free patent rights can be obtained from original contributors.

Unlicense

Public Domain

The Unlicense is a public domain dedication. A work released under the Unlicense is dedicated to the public domain to the fullest extent permitted by law and comes with an additional lax licence that helps cover any cases where the dedication is inadequate.

Requirements: No copyright notice or licence text is required. The source code does not have to include a notice of significant changes. There is no obligation to disclose affected source code. Sublicensing of relevant code is permitted.

Compatibility, linking and mixing: The Unlicense, being a public domain dedication tool or waiver, can be inherently subsumed by all licences and works and is linking permissive.

Patent rights: Patent rights are not mentioned.

Zlib

Permissive

Zlib is used for various software libraries and applications, named after the zlib compression library and the libpng library for working with PNG image files.

Requirements: The source code should include the original copyright notice for source code only. Include licence text for source code only and include notice of significant changes. There is no obligation to disclose affected source code. Sublicensing of relevant code is permitted.

Compatibility, linking and mixing: Code under MIT and BSD licences (2- and 3-clause), Apache 2.0 and MPL can be combined with code under the Zlib licence (two-way compatible). Code under the Zlib licence can be used in GPL, LGPL and CDDL-licensed projects. It is linking permissive.

Patent rights: Patent rights are not mentioned.

Medium-Risk Licences

Artistic-2.0

Permissive

Artistic 2.0 is compatible with the GPL, thanks to the relicensing option in section 4(c)(ii). It is primarily used for Perl programming language software and related projects. It is recommended (wherever possible) to replace Artistic 1.1 with Artistic 2.0 for compatibility issues. Licensing compatibility is greatly improved with the relicensing clause.

Requirements: The source code should include the original copyright notice and licence text. Clearly document differences, but you do not have to disclose a modification if it can be replaced with the original in the combined work or if it is available to the original work copyright holder. Sublicensing of relevant code is permitted.

Compatibility, linking and mixing: Code under Apache 2.0, MPL, MIT and BSD licences (2- and 3-clause) may be freely combined with code under the Artistic License 2.0 and published under either of input licences. Code under the Artistic License 2.0 can be used in GPL, LGPL and CDDL-licensed projects. It is linking permissive.

Patent rights: Patent rights are explicitly granted.

EPL-1.0

Weak Copyleft

The Eclipse Public License (EPL) is similar to the Common Public License, with the removal of the broader patent retaliation language regarding patent infringement suits specifically against “Contributors to the EPL program”. EPL-licensed code in a program can only be released under the EPL, even if the full program is released under a different licence. It should be replaced with EPL 2.0 wherever possible.

Requirements: The source code should include the original copyright notice, licence text and notices of significant changes. You should disclose the affected source code when distributing work. Sublicensing of relevant code is permitted. A distributor can relicense to EPL-2.0.

Compatibility, linking and mixing: It is not compatible with the entire GPL family (including LGPL and AGPL licences). EPL 1.0-licensed code can be migrated to EPL 2.0 and vice versa. Code under MIT, Apache 2.0, MPL 2.0 and BSD (2- and 3-clause) licences can be combined with EPL 1.0-licensed code, but it requires licensing EPL-1.0 parts under EPL-1.0 licence. It is linking permissive.

Patent rights: Patent rights are explicitly granted.

Remarks: Unlike EPL 2.0, it is not suitable for scripting languages, as it does not require source code to be made available; there is no Secondary License; New York State is defined as “choice of law”. The affected code is ‘module’, not file.

EPL-2.0

Weak Copyleft

If an initial contributor releases a specific piece of code and designates GPL 2.0 or later as a secondary licence, it provides explicit compatibility with these GPL versions. However, the EPL 2.0 without this designation is incompatible with the GPL.

Requirements: The source code should include the original copyright notice and licence text. The source code does not have to include notice of significant changes, but you should disclose affected source code when distributing work. Sublicensing of relevant code is permitted. The same or later EPL is applicable for affected code, can add a Secondary Licence to enable GPL 2.0+ compatibility and allows sublicensing binaries under other terms.

Compatibility, linking and mixing: It is not compatible with the entire GPL family (including LGPL and AGPL licences, except for special cases stated in “Description”). EPL 2.0 and EPL 1.0 are generally considered to be interchangeable. Code under MIT, Apache 2.0, MPL 2.0 and BSD (2- and 3-clause) licences can be combined with code under EPL 2.0 licence, but it requires licensing EPL-2.0 parts under EPL-2.0 licence. It is linking permissive.

Patent rights: Patent rights are explicitly granted.

Remarks: Commercial distributors should defend contributors from any lawsuits/legal damages (unique feature).

EUPL-1.2

Strong Copyleft

European Union Public License 1.2 is designed for software that is created and distributed by public administrations of European Union Member States. The EUPL aims to promote the sharing and reuse of software developed by public administrations.

Requirements: The source code should include the original copyright notice and licence text. Include notices of significant changes and disclose affected source code when distributing work. Sublicensing of relevant code is permitted.

Compatibility, linking and mixing: It is subsumed by GPL 2.0 and later, AGPL 3.0, CeCILL 2.0, OSL 2.1, OSL 3.0.

EUPL 1.2 is explicitly two-way compatible with LGPL 2.1 and later, LiLiQ, CeCILL 2.1, CPL 1.0, EPL 1.0 and later, MPL 1.1 and later, and with other EUPL versions. EUPL 1.2 subsumes Apache 2.0, Artistic, BSL 1.0, BSD 2-clause and 3-clause, CDDL 1.0 and later, ISC, MIT, Python 2.0, Zlib. It is linking permissive since linking makes no derivatives. When combining EUPL 1.2 licensed code with source code licensed differently, the resulting derivative can be licensed under a subsuming licence.

Patent rights: Patent rights are explicitly granted.

GPL-2.0-with-classpath-exception

Strong Copyleft

The exception allows you to link your GPL-licensed code with specific non-GPL libraries (like the Java Classpath libraries) without making your code subject to the GPL. The Classpath exception only applies to the specific libraries or circumstances mentioned in the exception itself.

Requirements: The source code should include the original copyright notice and licence text. Include notices of significant changes with dates and disclose affected source code when distributing any derived work, but not for private use. You cannot sublicense relevant code.

Compatibility, linking and mixing: It is subsumed by the entire GPL family (including LGPL and AGPL licences). The Classpath exception allows GPL-licensed code to be linked with specific non-GPL libraries without forcing GPL requirements on the entire work. It is linking permissive only for executables.

Patent rights: Patent rights are explicitly granted.

LGPL-2.0

Weak Copyleft

Library GPL 2.0 is an older version of the LGPL, now obsolete, and should be replaced with 2.1. LGPL is primarily used for software libraries, enabling their use in open source and proprietary applications. You only need to share modifications to the library and you can dynamically link it in your application without sharing your application's source code.

Requirements: The source code should include the original copyright notice and licence text. Include notices of significant changes with dates and disclose the affected source code when distributing work. You cannot sublicense relevant code. Modifications to the LGPL 2.0-licensed library must be released under the LGPL 2.0, but the rest of the application that uses the library can be under any licence.

Compatibility, linking and mixing: It is subsumed by GPL 2.0 but not compatible with GPL 3.0 and is linking permissive. The LGPL 2.0 permits dynamic linking of the library with both open source and proprietary applications. This allows mixing of LGPL 2.0 code with MIT, 2- and 3-clause BSD, Apache2.0 and CDDL. If the library is statically linked with an application (i.e., the library becomes part of the application), the application must also be made available in an object code or other relevant format, allowing for modification and re-linking of the application.

Patent rights: Patent rights are explicitly granted.

Remarks: Use dynamic linking in languages that also have static linking.

LGPL-2.1

Weak Copyleft

Lesser GPL 2.1 is an older version of the LGPL that permits linking with modules under licences that are not considered as free by the FSF.

Requirements: The source code should include the original copyright notice and licence text. The source code should include notices of significant changes with dates and disclose the affected source code when distributing work. You cannot sublicense relevant code. Modifications to the LGPL 2.1-licensed library must be released under the LGPL 2.1, but the rest of the application that uses the library can be under any licence.

Compatibility, linking and mixing: Derivative works of LGPL 2.1 code must be licensed under the same (or, if allowed by the licensor, a later version of LGPL), or GPL 2.0 or later. LGPL 2.1 allows dynamic linking from code under MIT, BSD (2- and 3-clause), Apache 2.0 and MPL licences. LGPL 2.1 is explicitly two-way compatible with EUPL 1.2 licence.

Patent rights: Patent rights are explicitly granted.

Remarks: Use dynamic linking in languages that also have static linking, and provide copyright and licence in UI if copyrights are already shown.

LGPL-3.0

Weak Copyleft

Lesser GPL 3.0 is the current version of the LGPL, permitting linking with non-free modules.

Requirements: The source code should include the original copyright notice and licence text. Include notices of significant changes with dates and disclose the affected source code when distributing work. You cannot sublicense relevant code. Modifications to the LGPL-licensed library must be released under the LGPL 3.0, but the rest of the application that uses the library can be under any licence.

Compatibility, linking and mixing: Derivative works of LGPL 3.0 code must be licensed under the LGPL 3.0 (or later) or GPL 3.0 (or later). LGPL 3.0 allows dynamic linking from code under MIT, BSD (2- and 3-clause), Apache 2.0 and MPL licences. LGPL 3.0 is explicitly two-way compatible with EUPL 1.2 licence.

Patent rights: Patent rights are explicitly granted.

Remarks: Use dynamic linking in languages that also have static linking. Include installation information for consumer devices. Provide copyright and licence in the UI if copyrights are already shown.

MPL-1.1

Weak Copyleft

The Mozilla Public License 1.1 is a weak copyleft licence; it has some complex restrictions that make it incompatible with the GNU GPL. A module covered by the GPL and a module covered by the MPL cannot legally be linked together, but it may include a choice of another licence.

Requirements: The source code should include the original copyright notice and licence text. Include notices of significant changes with dates and disclose affected source code under the same licence when distributing the combined work.

Compatibility, linking and mixing: It is not compatible with the entire GPL family (including LGPL and AGPL licences). Code under Mozilla 1.1 Licence can include code under Apache 2.0, MIT and BSD licences (2- and 3-clause) licences. It is linking permissive.

Patent rights: Includes specific provisions related to patents.

MPL-2.0

Weak Copyleft

The Mozilla Public License 2.0 permits relicensing to the GNU GPL, except when the code explicitly denies this permission.

Requirements: For licensing, authors must state that the code is under the MPL and indicate where to find the licence. The source code should include the original copyright notice but does not have to state significant changes. When distributing combined work, disclose the affected source code. You can sublicense binaries of aggregate works. Derivative works can be licensed under any future version of the licence.

Compatibility, linking and mixing: Software under previous versions of the MPL can be upgraded to MPL 2.0. Any software that is not already available under one of the GNU licences listed in the licence text must be marked as “Incompatible with Secondary Licenses” in places where the licence is stated, as described in “Exhibit B” of the licence text. It is subsumed by GPL 2.0, LGPL 2.1, AGPL 3.0 and all later versions of those licences. You must ensure that files that were originally under the MPL are still available under the MPL's terms as well. You can combine MPL 2.0-licensed code with code under Apache 2.0 and publish under either licence. Code distributed under Mozilla 1.1 licence can include code under ISC, MIT and BSD (2- and 3-clause) licences. It is linking permissive.

Patent rights: Patent rights are explicitly granted.

Remarks: It does not allow the use or mention of trademarks.

High-Risk Licences

AGPL-3.0

Strong Copyleft, Network Protective

The Affero GPL 3.0 licence terms effectively consist of the terms of GPL 3.0, with an additional paragraph allowing users who interact with the licensed software over a network to receive the source for that program. AGPL 3.0 and GPL 3.0 licensed code can be combined into a single program under the AGPL 3.0 licence. AGPL is recommended for network-based software but restricts future proprietary versions. If you modify AGPL software used over a network, you must provide access to the modified source code.

Requirements: The source code should include the original copyright notice and licence text. Include notices of significant changes with dates and disclose affected source code when distributing combined work. You cannot sublicense relevant code.

Compatibility, linking and mixing: AGPL 3.0 subsumes GPL 3.0. It is not linking permissive.

Patent rights: Patent rights are explicitly granted.

Remarks: The AGPL's notable feature is the additional clause addressing usage over a network. It explicitly states that if users interact with the software over a network, the server must provide the source code for that version of the program.

GPL-2.0

Strong Copyleft

Focuses primarily on software licensing and distribution. It is considered very US-centric.

Requirements: The source code should include the original copyright notice and licence text. Include notices of significant changes with dates and disclose affected source code when distributing any derived work, but not for private use. You cannot sublicense relevant code.

Compatibility, linking and mixing: It is compatible only with GPL 2.0. The FSF provides original authors with an upgrade option to GPL 3.0 or later for projects licensed under GPL 2.0. You can combine GPL 2.0-licensed code with AGPL 3.0-licensed code under AGPL 3.0. When distributing the combined work with LGPL 2.1, you can choose to license it under either GPL 2.0 or LGPL 2.1. When distributing the combined work with Apache 2.0, you must license it under GPL 2.0. MIT, ISC and BSD 2-clause and 3-clause licensed code can be used in GPL 2.0 licensed works. It is not linking permissive.

Patent rights: Patent rights are explicitly granted.

Remarks: It has the IoT gap, which is addressed by GPL-3.0. Requires displaying appropriate legal notices.

GPL-3.0

Strong Copyleft

One major danger that GPL 3.0 blocks is tivoization (AKA IoT gap). Tivoization means certain “appliances” (which have computers inside) contain GPL-covered software that you cannot effectively change because the appliance shuts down if it detects modified software. The GPL 3.0 provides an option for licensors to add or upgrade to any later version of the GPL.

Requirements: The source code should include the original copyright notice and licence text. Include notices of significant changes with dates and disclose affected source code when distributing any derived work, but not for private use. You cannot sublicense relevant code. This licence eases GPL 2.0's interactive display requirement: if software has interactive parts showing legal notices, ensure their visibility. If this impractical, there is no obligation to enforce it, but an existing display cannot be removed. An “About” box is with full notices is suggested, or, as alternative, a brief copyright notice indicating no warranty, free redistribution under GPL 3.0 and instruction for getting details.

Compatibility, linking and mixing: It is not linking permissive. Code licensed under GPL 3.0 can be combined with AGPL 3.0-licensed code, and the resulting work is licensed under AGPL 3.0. GPL 3.0 is not compatible with GPL 2.0. However, FSF provides an option for projects licensed under GPL 2.0 to "upgrade" to GPL 3.0 or later. Code licensed under GPL 3.0 can be combined with Apache 2.0 or LGPL 3.0-licensed code, and the resulting work is licensed under GPL 3.0. You can combine code under GPL 3.0 with code under the MIT, ISC and BSD (2-clause and 3-clause) licences, but when distributing the combined work, you must follow the terms of the GPL 3.0.

Patent rights: Patent rights are explicitly granted.

Remarks: It closes the IoT gap. Requires including installation information for consumer devices.

  • No labels