Versions Compared

Old Version 43

changes.mady.by.user Anđela Arsović

Saved on

compared with

New Version 48

changes.mady.by.user Anđela Arsović

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info
titleSoftware Licensing Guides Series

Table of Contents

Table of Contents

This page provides an overview of various tools and resources for selecting, checking and selecting managing open-source software licences and their compatibility.

Overall information and licence lists

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

Permissive and copyleft licences

Image Removed

(Based on materials from ORCRO)

Permissive licences have simple requirements – to credit original work, describe changes, provide a disclaimer, etc. Copyleft licences (“reciprocal”, “protective”, “restrictive”, derogatory: “viral”) require the rights to be preserved in derivative works. If you use any components (libraries) with copyleft, you are obliged to make derived source code available, which may include the entire product/project!

  • Permissive – do anything
    • MIT – short and simple
    • ISC (OpenBSD) – further shortened equivalent
    • BSD – some versions require including the disclaimer
    • Apache 2.0 – requires notice of changes, grants a license to patents unless litigating and mentions the preservation of trademark rights
  • Weak copyleft – file (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 the use of patents; the end-user must be able to install a modified version – it prohibits closed devices, DRM or hardware encryption or patents retaliation; compatible with Apache 2.0
  • Strong copyleft – project scope
    • GPL 2.0 – often used
    • GPL 3.0 – grants the use of patents, the end-user 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 is a distribution of the software, modified source code must be available
  • Proprietary – these licences restrict user rights and protect the commercial interests of copyright owners

Per-feature or tabular comparisons of licences and categorised lists

Licence compatibility

GPL licences compatibility

Arrows are transitive and go from licences of the components toward the licence of your project

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

(From https://www.gnu.org/licenses/quick-guide-gplv3.html)

Above, per the dotted line, “GPL 2 only” is not compatible with GPL 3”, but ”GPL 2 or later” is. A more detailed view with precisely stated licences:

Image Removed

(From David A. Wheeler 2007, https://web.archive.org/web/20210101030518/https://dwheeler.com/essays/floss-license-slide.html, SVG variant: https://en.wikipedia.org/wiki/License_compatibility#/media/File:Floss-license-slide-image.svg)

On AGPL compatibility:

  • (L)GPL 3.0(+) components can be used in software under AGPL, thanks to an explicit rule in GPL
  • Code under AGPL cannot be used in (L)GPL projects unless dual-licensed

Relationship between most used licences in GÉANT

Following is a graph of licences that are most frequently used in GÉANT projects that were scanned using the Mend tool. It is based on the two previous graphs.

Image Removed

Dual and multi-licensing

Authoritative Sources

Licence Selection and Comparison

Top Lists and Brief Comparisons

Licence Compatibility

Overview of Permissive and Copyleft Licences

Image Added

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.Image Added

(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.

Image Added

(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

Image Added

(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.

Image Added

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,

  • Dual and multi-licences can help avoid licence compatibility issues, making the use of components more flexible.
    • You can choose a licence compatible with the one used for your software. But you cannot dual-license your software to match some components with one licence

  • and others with another. Licences of all used components must be compatible with all

    • of

  • your licences.

  • “Or later” (often expressed as “+”)

    • licence

  • variants imply

    • the

  • applicability of

    • later

  • future, possibly

    • still

  • non-

    • existing

  • existent, versions of

    • these

  • those licences. This is sometimes

    • implied

  • assumed unless

    • you

  • explicitly

    • decline it

  • declined.

  • Some licences include automatic relicensing (MPL 2.0, EUPL 1.2, CeCILL)

    • , while EUPL comes with a full list of

  • ; EUPL lists all licences it can be combined with.

Licence

...

Compatibility Matrices and Checkers

In-licences (component licences)

Joinup Licensing Assistant – Compatibility Checker, https://joinup.ec.europa.eu/collection/eupl/solution/joinup-licensing-assistant/jla-compatibility-checker

Licence Compatibility Checker software

In-licences (licences of components) are in rows and out-licences are in columns:.

(Source: https://github.com/HansHammel/license-compatibility-checker GitHub – Licence Compatibility Checker)

Open Source Automation Development Lab (OSADL)

...

Matrix and

...

Rules

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

(Source:  Meeker, H.,  Meeker & von Wendorff, C. ( 2019). Fulfilling open source license obligations: Can checklists help?, https://events19.linuxfoundation.org/wp-content/uploads/2018/07/OSLS-2019-Fulfilling-Open-Source-license-obligations-Can-checklists-help.pdf)

More at

GNU GPL licences compatibility 

EUPL 1.2

Creative Commons licences

Risks of licences

Risk mitigation against potentially harmful legal threats or behaviours by free-software licences

...

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

(Source: https://en.wikipedia.org/wiki/Free-software_license)

Mend resources

Other software composition analysis (SCA, software inventory) tools

Ideally, compliance should be continuously monitored as a part of the build process.

Commercial SCA tools and services:

OSS tools that perform SCA:

Licence selection tools and resources

...

...

, 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.

Image Added

(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

Compliance methodology