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.
Open Source Software Licensing Workshop for Software Developers, 23–24 November 2022 (COMING SOON)
Infoshare: OSS Licensing and Licence Compliance Guidelines for Software Developers, 12 March 2024 (COMING SOON)
Overview: OSS – From Fundamentals to Compliance
Part 1: Essential Aspects of Software Licensing (COMING SOON)
Part 2: Open Source Licences Used in GÉANT (COMING SOON)
Part 3: Licensing and Artefacts Creation Process (COMING SOON)
Part 4: Compliance and Required Artefacts (COMING SOON)
FSF: Free Software Licences and Non-free Software Licences – Classification and GPL compatibility
NI4OS-Europe: License Clearance Tool (LCT) – Suggests suitable licences for open source and research outputs
tl;drLegal – Plain-language summaries of OSS licences, conditions, and limitations (helpful for quick comparison)
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.
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.
(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)
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 | |
Yes | No | No | No | No | No | No | |
Yes | Yes | No | Yes | No | No | No | |
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)
(From Interoperable Europe: EUPL – Licence Compatibility, Permissivity, Reciprocity and Interoperability)
Interoperable Europe matrices and guidance:
The following graph provides a visual overview of most frequently used licences in GÉANT projects.
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.
In-licences (component licences) are in rows and out-licences are in columns.
(Source: GitHub – Licence Compatibility Checker)
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:
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)
Commercial SCA tools and services:
FOSSA – SCA tool for compliance and vulnerability management
Black Duck – Tool for licence and security analysis
JFrog Xray – Add-on for Artifactory that provides component analysis and compliance checking
Snyk – SCA and vulnerability scanning platform detecting code vulnerabilities and dependencies, also covering containers and infrastructure as code
Endor Labs – Tool for dependency management and risk assessment
OSS tools that perform SCA:
OSS Review Toolkit (ORT) – Tool for automated licence and compliance checks
QMSTR – Quartermaster – Toolchain and reporting framework under renewed development
ScanCode-Toolkit – Analysis of project artefacts for licences and credits
FASTEN Project / OSADL: License Compliance Verifier – Demonstrator using OSADL matrix and compatibility rules
EOSC-Synergy: SQAaaS (Software Quality Assurance as a Service) – Checks for the presence of a LICENSE file with an OSI-approved licence as a part of a more extensive quality analysis (including compliance with the OSI Open Source Definition)
MojoHaus License Maven Plugin – Introduction page, GitHub repository
Software Bill of Materials (SBOM) tools:
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
Integration - Ideally, compliance should be continuously monitored as a part of the CI/CD process/pipeline.
GÉANT resources:
Other:
Linux Foundation: Creating an Open Source Program – Guidance on establishing an OSPO
FOSSA: Building an Open Source Program Office (OSPO) – Blog post on setting up and managing an OSPO
CHANGELOG fileCLA (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
CONTRIBUTING File – File describing how to contribute to a project, including copyright and licence conditions
Copyright Holder – Legal entity or individual owning the exclusive rights to a software work
Derivative Licence – New licence applied to a derivative work, subject to compatibility and original licence terms
Documentation Licence – Licence covering non-code artefacts such as manuals, datasets, or diagrams (e.g. CC BY, CC BY-SA)
Dual and Multi-Licensing – Distribution under more than one licence, often combining open and proprietary terms; the user chooses which one to apply
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
NOTICE File – File accompanying software to acknowledge included components, copyrights, and licence attributions
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
Permissive Licence – Licence allowing broad reuse with minimal restrictions, permitting reuse in both open and proprietary software
README, LICENCE, NOTICE, CHANGELOG)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