Software Licensing Guides Series

Table of Contents

This page provides an overview of tools and resources for selecting, checking and managing open-source software licences and their compatible use in software projects. The structured list and illustrations of licence relationships support GÉANT’s software development and licence compliance practices.

Core GÉANT Resources

Supporting and Background Material

Learning and Training Resources

GÉANT Courses and Workshops

Authoritative Sources

Licence Selection and Comparison

Top Lists and Brief Comparisons

Licence Compatibility

Overview of Permissive and Copyleft Licences

Based on materials from ORCRO:

Permissive licences have simple requirements such as crediting the original work, describing changes, and providing a disclaimer. Copyleft licences (reciprocal, protective, restrictive, or, derogatorily, viral) require rights to be preserved in derivative works. Using components (libraries) with copyleft may oblige to make derived source code available, which may include the entire product or project.

  • Permissive – do anything
    • MIT – short and simple
    • ISC (OpenBSD) – further shortened equivalent
    • BSD – some variants require inclusion of disclaimer
    • Apache 2.0 – requires notice of changes, grants a licence to patents unless litigated, and preserves trademark rights
  • Weak copyleft – file or library scope
    • MPL 2.0 – simple, allows static linking and licence variants with additional terms
    • LGPL 2.1 – cleaned text of LGPL 2.0, allows dynamic linking without enforcing copyleft
    • LGPL 3.0 – grants patent use; end users must be able to install modified versions; prohibits closed devices, DRM, hardware encryption, or patent retaliation; compatible with Apache 2.0
  • Strong copyleft – project scope
    • GPL 2.0 – widely used
    • GPL 3.0 – grants patent use; users must be able to install modified software; compatible with Apache 2.0
    • AGPL 3.0 (Affero) – network-protective: external use of modified code requires its availability; network use counts as distribution
  • Proprietary – restrict user rights and protect the commercial interests of copyright holders

GPL Licence Compatibility

This diagram illustrates compatibility relationships between different free software licences. Arrows are transitive and go from the licences of components towards the licence of your project.


A chart illustrating compatibility relationships between different free software licenses. For details, see the FSF's license list page.

(From GNU: Quick Guide to GPLv3 Compatibility)

Above, the dotted line indicates that “GPL 2 only” is not compatible with “GPL 3”, but “GPL 2 or later” is.

(From David A. Wheeler, 2007: FLOSS Licence Slide,  SVG on Wikipedia)

Special Requirements and Risk Handling in GPL Licences

Some licences prohibit or require certain practices or behaviours, which may lead to risks of legal threats. These should be addressed or mitigated.

Frequently used protective and permissive licenses


AGPLv3

GPLv3

GPLv2.1

LGPLv3

LGPLv2.1

MPL-2

BSD

SaaS/cloud

Yes

No

No

No

No

No

No

Tivoization

Yes

Yes

No

Yes

No

No

No

Patent trolling

Yes

Yes

No

Yes

No

No

No

Proprietization

Yes

Yes

Yes

Partial

Partial

Partial

No

Granularity/reach

Project

Project

Project

Library

Library

File

N/A

Trademark grant

Yes

Yes

?

Yes

?

No

No

(From Wikipedia – Free-software licence)

EUPL 1.2 Compatibility

(From Interoperable Europe: EUPL – Licence Compatibility, Permissivity, Reciprocity and Interoperability)

Interoperable Europe matrices and guidance:

Relationship Between the Most Used Licences in GÉANT

The following graph provides a visual overview of most frequently used  licences in GÉANT projects.

Dual and Multi-Licensing Guidance and Implications

  • Dual and multi-licensing can help avoid licence compatibility issues, and make component use more flexible.

  • You may choose a licence compatible with that used for your software. However, you cannot dual-licence your software by matching some components with one licence, and others with another. Licences of all used components must be compatible with all your licences.

  • “Or later” (often expressed as “+”) variants imply applicability of future, possibly non-existent, versions of those licences. This is sometimes assumed unless explicitly declined.

  • Some licences include automatic relicensing (MPL 2.0, EUPL 1.2, CeCILL); EUPL lists all licences it can be combined with.

Licence Compatibility Matrices and Checkers

In-licences (component licences) are in rows and out-licences are in columns.

(Source: GitHub – Licence Compatibility Checker)

Open Source Automation Development Lab (OSADL) Matrix and Rules

In-licences are in columns, out-licences in rows.

(Source: Meeker & von Wendorff, 2019, Fulfilling Open Source Licence Obligations: Can Checklists Help?)
More at the OSADL site:

Creative Commons Licences Compatibility

Select two works to combine or remix. Find the first work’s licence in the top row and the second in the first column. If a check mark appears at their intersection, the works can be combined. Use the more restrictive licence (the one further right or lower in the table) for the resulting work.

(From Wiki/CC License Compatibility)

Compliance, SCA, and SBOM Tools

Software Composition Analysis (SCA and Software Inventory) Tools

Commercial SCA tools and services:

OSS tools that perform SCA:

Software Bill of Materials (SBOM) tools:

  • Trivy – Generates SBOM

  • Parlay – Enriches an SBOM with third-party data

  • Syft – Generates SBOMs from container images and filesystems

  • Tern – Container analysis tool; generates SBOMs for container images and Docker files

  • CycloneDX Tool Center – Marketplace of tools and solutions to optimize and secure the software supply chain
  • Anchore Syft/Grype – SBOM generation and vulnerability analysis
  • Ortelius – Microservice SBOM and dependency tracking
  • DependencyTrack – Continuous monitoring of components and licences using SBOM input

Integration - Ideally, compliance should be continuously monitored as a part of the CI/CD process/pipeline.

GÉANT resources:

Other:

Artefact Creation and Compliance Guides and Tools

Compliance Frameworks and Governance

EU Policy and Context

Advanced and Comparative Legal Resources

Glossary of Terms

  • AGPL (Affero General Public Licence) – Strong copyleft licence requiring source code availability for network use
  • Apache Licence 2.0 – Permissive licence with patent protection and attribution requirements
  • Attribution – Providing a notice (text or section), required by some licences (e.g. Apache 2.0, CC BY, BSD), to preserve credits to original authors and contributors, and identify modifications
  • BSD Licence – Family of permissive licences with minimal redistribution conditions, but requiring attribution notices to be retained
  • CeCILL Licence – French open-source licence family compatible with the GNU GPL, designed for legal validity within French and EU law
  • Change Log / Changelog – Record of significant software changes, including versions, features, and fixes, often linked to licence compliance, typically in the CHANGELOG file

  • CLA (Contributor Licence Agreement) – Agreement by which contributors grant rights to use, modify, and relicense their contributions, typically in the CLA file

  • Closed Source Software – Software distributed without source code access or modification rights

  • Code of Conduct – Document defining expected contributor behaviour within open-source communities or projects
  • Compatibility – Ability to combine components under different licences without violating their terms
  • Compliance – Process of ensuring software use adheres to all relevant licence terms and security requirements

  • CONTRIBUTING File – File describing how to contribute to a project, including copyright and licence conditions

  • Copyleft – Licensing principle requiring derivative works to remain under the same or a compatible licence

  • Copyright Holder – Legal entity or individual owning the exclusive rights to a software work

  • DCO (Developer Certificate of Origin) – Lightweight alternative to a CLA, where contributors indicate acceptance of the project licence and contribution rules by adding a “Signed-off-by” line in commits
  • Dependency – Component or library used by another program

  • Derivative Licence – New licence applied to a derivative work, subject to compatibility and original licence terms

  • Derivative Work – Software based on or incorporating another work; licensing rules depend on how it was modified or combined
  • Distribution – Providing or offering software to third parties, triggering licence obligations

  • Documentation Licence – Licence covering non-code artefacts such as manuals, datasets, or diagrams (e.g. CC BY, CC BY-SA)

  • Downstream – Recipient project, organisation, or user using or redistributing upstream software, often integrating or modifying it

  • Dual and Multi-Licensing – Distribution under more than one licence, often combining open and proprietary terms; the user chooses which one to apply

  • EUPL (European Union Public Licence) – EU-approved licence ensuring legal interoperability and compatibility with major OSS licences
  • FSF (Free Software Foundation) – Organisation promoting user freedoms in software and maintaining the GNU licences (GPL, LGPL, and AGPL)
  • FSFE (Free Software Foundation Europe) – Organisation promoting free software in Europe, supporting legal and policy work on software freedom, and maintaining the REUSE specification
  • GPL (GNU General Public Licence) – Strong copyleft licence requiring that distributed modified versions of software remain under the GPL
  • Inbound Licence – Licence governing software or components received from external sources or contributors

  • LGPL (GNU Lesser General Public Licence) – Weaker copyleft permitting linking with proprietary code, often used for libraries

  • Licence Compatibility Matrix – Table showing which licences can be legally combined within a single software product

  • MIT Licence – Simple permissive licence requiring only attribution and copyright notice retention

  • NOTICE File – File accompanying software to acknowledge included components, copyrights, and licence attributions

  • Notice Preservation – Requirement to retain licence and copyright notices in redistributed or derivative works
  • OpenChain – International ISO/IEC standard defining processes for open-source licence compliance

  • OSADL (Open Source Automation Development Lab) – Consortium offering licence compliance tools

  • OSI (Open Source Initiative) – Authority approving licences that meet the Open Source Definition and maintaining the list of OSI-approved OSS licences

  • OSPO (Open Source Program Office) – Organisational unit or function managing open-source strategy, compliance, and community engagement
  • OSS (Open Source Software) – Software available for use, modification, and distribution with source code access
  • Outbound Licence – Licence applied to the distributed or published version of software
  • Patent Retaliation Clause – Clause (e.g. in GPLv3, Apache 2.0) terminating rights if a licensee initiates a patent claim against contributors or users
  • Patent Trolling – Asserting patent claims to obtain licensing fees or settlements rather than to promote innovation or protect invention; some licences include patent retaliation clauses to discourage this

  • Permissive Licence – Licence allowing broad reuse with minimal restrictions, permitting reuse in both open and proprietary software

  • Proprietary Software – Software distributed under restrictive terms that limit use, modification, or redistribution
  • Public Domain – Works not protected by copyright or released without restriction for free reuse
  • Reciprocity – Requirement that derivative or combined works are shared under the same or compatible terms (synonym of copyleft)
  • Relicensing – Applying a different licence to an existing codebase, often permitted only by copyright holders
  • REUSE – European initiative and specification (from FSFE) for standardised licence and copyright documentation
  • REUSE Specification – Standard by FSFE defining file headers, placement of licence texts, project metadata, and use of SPDX identifiers and file references to enable automated compliance verification
  • SBOM (Software Bill of Materials) – Structured list of all components in a software product and their licences, typically using the SPDX or CycloneDX format
  • SCA (Software Composition Analysis) – Automated analysis of code to identify dependencies, associated licences, security vulnerabilities, and compliance risks
  • Software Artefact – Any file, document, or output created as part of software development (e.g. README, LICENCE, NOTICE, CHANGELOG)
  • Source Code – Human-readable form of software, as opposed to compiled binaries

  • SPDX (Software Package Data Exchange) – Standard format for licence and component metadata for machine-readability; it defines standardised labels (e.g. MIT, Apache-2.0) or consistent automation

  • Strong Copyleft – Licences (e.g. GPL, AGPL) that require derivative works to be distributed under the same terms
  • Tivoisation – Practice of restricting user modification of software in hardware devices; prohibited by GPLv3 and AGPLv3
  • Upstream – Original source or project from which software components are obtained or derived
  • Upstream Contribution – Improvement or fix submitted back to the original project to maintain synchronisation
  • Warranty Disclaimer – Statement included in most OSS licences denying liability for damages or malfunctions
  • Weak Copyleft – Licences (e.g. LGPL, MPL, EPL) that allow linking or combining with differently licensed code
  • No labels