A well-formated PDF version of this document is attached.

This work  is licensed under  CC This work is licensed under CC BY-SA 4.0 Image RemovedImage RemovedImage Removed

Table of Contents

...

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

• Weak Copyleft Licences: These have a library or file scope.
• Strong Copyleft Licences: These often require releasing the entire project or product under a licence that is the same as or similar to the one used in the original works.
• Network Protective Licences: Under these, distribution over a network is considered a form of distribution, thus requiring modified code to be made available to external users.

Every licence listed below is classified into one of the above categories, under the title containing the licence name. For easier use with Mend reports, the licences are presented alphabetically after being grouped into IPR risk categories. Mend defines three risk categories for software licences: Low Risk, Medium Risk and High Risk. These categories broadly correspond to Permissive, Weak Copyleft and Strong Copyleft licences. However, this classification 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 alphabetically within each risk category. Only licences detected by Mend in GÉANT software projects are included.

...

In Figure 1, different colours indicate categories of software licences. Licences marked in green are permissive, those in yellow are weak copyleft and those in red are strong copyleft. Relationships between licences are illustrated using different arrow styles:

• A one-way solid arrow means the destination licence subsumes the origin licence. In some cases, as noted in Figure 1, additional conditions may apply.
• A one-way dashed arrow indicates that there is a newer version of the licence, suggesting the author should replace the older version in their code.
• A one-way dotted arrow signifies that the older licence can be replaced with the new version by an author using and modifying the code or mixing it with their own, provided the original code has not been distributed with additional licences.
• A two-way solid arrow means both licences are interchangeable.
• A two-way dashed arrow signifies that authors can license combined work under either of the licences. For better future compatibility, it is recommended to publish the combined work under both.

In this document, the statement “Licence A is subsumed by Licence B” means that code under Licence A can be included in work licensed under Licence B, represented in Figure 1 by an arrow from A to B. This is equivalent to stating “Licence B subsumes Licence A.” When Licence A is subsumed by Licence B, a copy of Licence A must still be included with all distributions of the combined program. “Interchangeable” means that code under Licences A and B can be licensed under either one. “Licence A is compatible with Licence B” means it is permitted to publish or distribute combined work under a licence, typically at least one of the input licences. In other words, when licences are compatible, it is legally possible to combine or merge multiple pieces of software. These nuances matter when selecting a licence for the combined program.

...

To determine which licences can be used for a combined program, authors should start with a list of all the licences used in their work. They can then remove any licence subsumed by another on the list, meaning the code under it can be included in software under the other licence. A licence is subsumed by another when compliance with the former implies compliance with the latter. For example:

• 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, MIT/X11 and ISC licences and CC0 public domain dedication are subsumed by the Apache 2.0 licence.
• Expat, MIT/X11 and ISC licences are interchangeable with the BSD 2-clause licence.
• BSD 2-clause is subsumed by BSD 3-clause.

In this document, the phrase “generally considered” is used to indicate that there is no explicit statement of the relationship in the licence text, but it is inferred from the licence clauses and lacks legal precedent.

...

Relicensing is the act of changing the current licence to another. This is possible if the original licence is permissive (thus includes the right to change the licence), allows relicensing to a secondary licence named in its terms or if all contributors agree to the change. It includes two scenarios:

• Switching to another copyleft licence where the original one explicitly allows relicensing under it (e.g. CeCILL permits relicensing to GPL v2 or later).
• Changing the licence entirely, which requires explicit written permission from all contributors. Permissive licences often do not explicitly mention relicensing or sublicensing, but their permissive terms effectively allow it.

Sublicensing allows the licensee (the individual or organisation granted the licence) to pass on certain rights, such as changing the licence, to a third party. This can be essential for broader distribution, integration or software use, particularly in commercial or collaborative projects. Sublicensing depends heavily on the terms of the original licence. Common use cases include:

• Commercial distribution, where companies sublicense software to customers as part of a larger product or service offering.
• Partnerships, where organisations sublicense software to partners for collaboration or integration into joint projects.
• Custom solutions, where developers sublicense components of permissively licensed software for client-specific applications or bespoke solutions.

Permissive licences typically grant sublicensing rights explicitly, though with varying conditions. Therefore, projects under permissive licences can be relicensed, changing the licence of the original or modified code. This is typically done to apply a commercial licence, which some may disguise by applying an open source looking “source-available” licence, often referred to as “fauxpen.” This may be undesirable if the original intent was to keep the software free. Copyleft licences generally prohibit sublicensing for the code within their scope by requiring redistribution under the same terms.

...

Patents and patent rights are sometimes addressed in licences through explicit patent grants, as seen in LGPL, GPL, AGPL, Apache 2.0, EPL and EUPL. Some licences do not mention patent rights explicitly, but their language may imply such grants. Patent-related concerns may arise when derived works are distributed under a different licence along with permissively licensed original parts. Licence texts may include patent-related clauses such as:

• Defensive termination, which automatically revokes patent rights if the licensee initiates patent litigation against the authors or contributors.
• Broad patent grants, covering all current and future patents owned by contributors that could be infringed by the entire codebase and through modifications or combinations, and not just by specific (existing or new) contributions.

Most open source licences exclude trademark rights unless explicitly stated. Trademarks of the original work are typically preserved through applicable trademark law and supported by the licence’s requirement to include copyright notices. However, some licences regulate trademark use explicitly:

• Apache 2.0: “… does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor…”
• BSD 3- and 4-clause: the non-endorsement clause prohibits use of project and contributor names without written permission.
• Artistic 2.0: “… does not grant you the right to use any trademark, service mark, tradename, or logo of the Copyright Holder.”

Low Risk Licences

Apache-2.0

...

Remarks: Closes the IoT gap. Include installation information for consumer devices. Interactive programs must use their usual user interface to display copyright notices, warranty disclaimers, state that the program is covered by GPL 3.0, explain that there is no warranty and how to view a copy of the licence.

Glossary

• Copyleft: A method making a program free, requiring all modified and extended versions to be free as well.
• Derivative Work: A new, original product that includes aspects of an existing copyrighted work.
• FOSS (Free and Open Source Software): Software that is both free software and open source, ensuring users have the freedom to use, modify and distribute it.
• FSF (Free Software Foundation): A non-profit organisation that promotes computer user freedom and defends the rights of all free software users.
• GPL (General Public License): A widely used free software licence that guarantees users freedom to run, study, share and modify software.
• IPR (Intellectual Property Rights): Legal rights granted to creators or owners of works, including patents, copyrights and trademarks.
• Licensing: The granting of permission to use intellectual property under defined conditions.
• OSI (Open Source Initiative): A non-profit organisation that promotes and protects open source software by certifying licences as Open Source Definition-compliant.
• OSS (Open Source Software): Software for which the source code is freely available and may be redistributed and modified.
• Permissive Licence: A type of free software licence with minimal restrictions on software use, modification and distribution.
• Software Licence: A legal instrument governing software use or redistribution; the UK spelling for the noun is “licence.” “License” is used within licence names.
• Strong Copyleft: A licensing model that requires derivative works to adhere to the original work’s licence terms.
• Weak Copyleft: A licensing model that allows linking with other software licensed under different terms, providing more flexibility than strong copyleft licences.

Licence Cheat Sheet

Table 1: Software licences that are frequently used in GÉANT projects or are otherwise significant

Additional explanations for patent grants descriptions:

• Defensive termination (in Apache 2.0, CDDL, Golang BSD + Patents, Artistic 2.0, EPL, EUPL 1.2, MPL and GPL 3.0 including its derivatives) automatically revokes granted patent rights if the licensee initiates patent litigation against the authors or contributors.
• Broad patent grants (like in Apache 2.0, Golang BSD + Patents) cover any patents owned by contributors that are necessary to use by the distributed code, its modifications or combinations with other software. These grants extend to potential future uses or modifications.
• Essential patent grants (in CDDL, GPL 3.0 family, EPL, MPL) cover patents that would necessarily be infringed by exercising the rights to use, make or sell the program as distributed. This means the rights under the licence cannot be exercised without infringing those patents. These grants apply only to patents that must be infringed to use the code as-is, limiting the grant strictly to the distributed code. Such grants do not cover patents that might be infringed through modifications or combinations beyond the original distribution.
• The implicit patent grant interpretation of GPL 2.0, LGPL 2.0 and LGPL 2.1 by some legal scholars and practitioners, as well as the less contested interpretation for MIT and BSD, arises from licence language about the freedom to use, modify and distribute the software. They argue that these freedoms would be meaningless without the underlying patent rights to exercise them. However, this remains a legal interpretation rather than an explicit provision stated in the licence text. At the same time, the implicit patent grants of BSD are less disputed.

Importance of Declaring a Licence with Code in Repositories (Including FAIR Principles)

Declaring an open source licence when publishing code in a public repository is essential for ensuring legal clarity, responsible reuse and alignment with community and funder expectations. From a legal standpoint, code shared without an explicit licence is treated as “all rights reserved”, meaning others cannot legally use, modify or redistribute it – even if it is publicly visible. By attaching a well-defined licence, you ensure that the code meets the licence requirements and that others are empowered to reuse the work.

In addition, licensing plays a critical role in supporting the FAIR principles – Findable, Accessible, Interoperable and Reusable – which are widely adopted in research and open science domains. The Reusability of digital objects, including software, is fundamentally dependent on the presence of a clear usage licence. Without a declared licence, code cannot be reused or repurposed in other projects, workflows or datasets, undermining both reproducibility and collaboration. Declaring a licence also supports Accessibility by removing legal ambiguity and Interoperability, especially when integrating across projects with different licensing models.

Declaring a licence when publishing open source code in a public repository is critical for both legal clarity and community trust. Without an explicit licence, the code is by default “all rights reserved”, meaning others cannot legally use, modify or distribute it – even if it is publicly visible. Adding a licence communicates the terms under which the code can be used and protects both the developer’s rights and the users’ obligations (e.g. attribution, disclaimers, redistribution conditions). This is particularly important in collaborative environments and for any code used in projects funded by public money where compliance, reuse and transparency are essential values.

Attention to GPL

Among open source licences, the GNU General Public License (GPL) imposes specific obligations. As a copyleft licence, GPL ensures that derivative works or redistributed versions must also be licenced under the GPL. If you distribute software that incorporates GPL-licensed code, you are legally required to make the source code publicly available under the same terms. This aligns with open science goals of transparency and knowledge sharing but requires conscious planning to ensure compliance – especially in collaborative or commercial contexts.

🛠️ How to Declare an Open Source Licence (Step-by-Step)

1. Choose a licence
   Use a standard OSI-approved licence that fits your goals (e.g. MIT, Apache-2.0, GPL-3.0, BSD).
   → Use tools like https://choosealicense.com to help decide.

2. Create a LICENSE file in your repository

   • Name the file exactly LICENSE or LICENSE.txt

   • Copy and paste the full licence text

   • Add your name (or organisation) and the year, if required by the licence

3. Reference the licence in your README
   Add a short note, e.g.

   “This project is licensed under the MIT License – see the LICENSE file for details.”

4. Add licence headers (optional)
   For multi-file projects, consider adding a short licence notice (e.g. MIT header) at the top of source files. This typically also includes a copyright statement.

5. Ensure SPDX licence identifiers are used (if applicable)
   If integrating with other systems or package managers (e.g. npm, PyPI), include the licence using SPDX identifiers like MIT in the project’s metadata file (package.json, pyproject.toml etc.)

📦 Example: Declaring the MIT Licence

...