The Licence Management Team (WP9 Task 2) provides expert software review and certification services within the GÉANT community. It ensures proper handling of licensing, dependencies, and legal aspects throughout the project lifecycle to improve security, quality, and compliance. The team supports internal, unpublished, and public software by issuing certificates that provide clarity, traceability, and assurance.
See Software Licence Management and Software Licensing Certificates. Then:
Use the templates and embedded instructions provided in Templates and Examples for Software Project Artefacts (for GÉANT participants).
See Software Licensing Certificates for descriptions and comparisons of available certificates.
Start with Open Source Licences Used in GÉANT, which provides an overview of common OSS licences, their requirements, compatibility, and patent terms.
For licence texts, obligations, use cases, and comparisons, consult:
For tailored advice, use the SLA service to identify the most suitable licence for your project.
This can be complex, as it depends on the licences of used dependencies. You may refer to the provided guides or seek help from the licensing team by requesting the SLA service. If there is a dependency with an incompatible licence, it may be necessary to remedy the situation by replacing, removing, or isolating the component.
A general recommendation is to use permissive licences (e.g. MIT, BSD, Apache 2.0) for GÉANT software unless stronger copyleft is specifically justified. To maximise software applicability, avoid copyleft licences (e.g. GPL, AGPL) unless necessary due to unavoidable dependencies and approved by the IPR Coordinator.
The above mentioned websites provide clear guidance on selecting an appropriate open source licence, with straightforward comparisons of popular licences and their requirements.
For a general discussion on OSS licences, refer to OSS Licences and Licence Selection. For details of common licences, see Open Source Licences Used in GÉANT.
Declaring an open source licence is essential for legal clarity, responsible reuse, and alignment with community and funder expectations. Without an explicit licence, code is legally treated as “all rights reserved”, meaning others cannot legally use, modify, or redistribute it – even if it is publicly visible on platforms like GitHub.
By attaching a well-defined OSS licence, you guarantee that the code meets the licence requirements and that others are empowered to reuse the work. This licence communicates the terms of use, protects the developer’s rights, and defines users’ obligations, such as attribution, disclaimers, and redistribution conditions. This is particularly important in collaborative environments and for publicly funded projects, where transparency, reuse, and compliance are core values.
Code without an explicit licence is automatically treated as “all rights reserved” under copyright law. Others have no legal permission to use, modify, or distribute it. By adding a licence, you clarify the terms under which the code can be used, while ensuring compliance with obligations like attribution, disclaimers, and redistribution conditions.
Licensing supports the FAIR principles – Findable, Accessible, Interoperable, and Reusable – widely adopted in research and open science. Reusability of digital objects, including software, depends on a clear usage licence. Without one, code cannot be reused in other projects, workflows, or datasets, undermining reproducibility and collaboration. Declaring a licence also improves Accessibility by removing legal ambiguity and supports Interoperability when integrating code across projects with different licences.
The GNU General Public License (GPL) is a strong copyleft licence with specific obligations. Any derivative works or redistributed versions must also be licensed under the GPL. If your software includes GPL-licensed code, you are legally required to make the full source code publicly available under the same licence. This aligns with open science goals of transparency and knowledge sharing but requires careful planning to ensure compliance, particularly in collaborative or commercial contexts.
The AGPL variant is network-protective, requiring full source code disclosure when software is used over a network.
LGPL v2 and v3 licensed components may be used in projects licensed under different terms.
GPL v2-only and GPL v3 are not mutually compatible; the same applies to their LGPL and AGPL variants.
No. Flags are context-dependent:
Contact the Licence Management Team for assessment.
Use a standard OSI-approved licence that fits your goals, such as MIT, Apache-2.0, GPL-3.0, or BSD.
LICENSE fileLICENSE or LICENSE.txt.COPYRIGHT file.READMEThis project is licensed under the MIT License – see the LICENSE file for details.”NOTICE or README.MIT in package.json or pyproject.toml).LICENSE example for the MIT licence:
MIT License Copyright © GÉANT Association 2025 (on behalf of the GÉANT project) Permission is hereby granted, free of charge, to any person obtaining a copy of this |
Full text continues – see https://opensource.org/licenses/MIT.
README.md snippet with a licence reference:
## Licence This project is licensed under the MIT License. See the [LICENSE](./LICENSE) file for details. |
GÉANT prefers UK English, so use “licence” for the noun but “license” for the verb. When it is part of the licence name, use it in its original, often capitalised, form “License”. This ensures compatibility with automated tools, as well as using LICENSE for the file name.
Whenever possible, include the full licence text from its official source, unmodified, to retain the original hash value, unless filling in required placeholders (e.g. copyright). Also, ensure the README and repository metadata state the applied licence or licences.
Yes, whenever possible, and from the earliest applicable licence version, as it increases the applicability and compatibility of your software.
When a project is offered under multiple software licences, the LICENSE file should:
Example:
This project is dual-licensed under the MIT License and the GNU General Public License v3.0 or later (GPLv3+). You may choose either licence to use this software under. * Use the MIT License as a permissive licence that allows proprietary derivative works. * Use the GPLv3+ to ensure derivative works remain under a copyleft licence. --- MIT License <Full text of the MIT licence> --- GNU General Public License v3.0 <Full text of the GPLv3 licence> |
Note that dual-licensing typically combines strong copyleft and proprietary licences, or GPL with Apache 2.0 or MIT, to offer permissive relicensing or ease integration with ecosystems incompatible with GPL.
Alternatively, reference separate licence files (e.g. LICENSE_MIT, LICENSE_GPL3) from the main LICENSE file:
This project is dual-licensed under the MIT License and the GNU General Public License v3.0 or later (GPLv3+). See `[LICENSE_MIT](./LICENSE_MIT)` and `[LICENSE_GPL3](./LICENSE_GPL3)` for the full texts. |
Provide supplementary information in the NOTICE file. In rare cases, such as OpenSSL dual-licensing, you may include it in the LICENSE file.
Use the format: “Copyright (c) <Year(s)> <Copyright Holder>”
For GÉANT projects, name GÉANT Association as the copyright holder. You are encouraged to include the specific funding phases during which the software was developed. Therefore, you may use either a specific format such as “GÉANT Association on behalf of GN4-2, GN4-3, GN5-1 and GN5-2,” or a broader statement such as “GÉANT Association on behalf of the GÉANT project.”
Verify that the years match the actual development period by checking your repository history or CHANGELOG. The copyright years should cover the entire development period, including any work done before transfer to the current holder.
Include this statement in at least the README and COPYRIGHT files.
Funding information is mandatory in the COPYRIGHT file if your code was developed using EC funds. It may also appear in README and NOTICE files and be accompanied by logos or links to sponsor or grant provider websites.
Host the EU funding logo as a static image in a controlled location within your project repository (e.g. under docs/assets/). Three optimised sizes are available, which you may choose depending on the file format and use. The smallest is sufficient for web use. These images have a white background for consistent display, but you may also use different background and text colours in line with EU rules.
Reference the locally preserved logo using Markdown:
 **The GÉANT project is funded by the Horizon Europe research and innovation programme.** |
The text beneath the logo is the funding statement. Ensure it covers all relevant EU funding instruments or project phases throughout the development period. Adapt it according to the GÉANT project iteration to cover the development and copyright statement period:
No. Only the Apache licence requires preserving the existing NOTICE and including information for modified files.
In projects under BSD or MIT, where copyright notifications are embedded within the LICENCE file, this does not need to be duplicated in NOTICE.
A NOTICE file is suitable for the following information, which also helps keep the README lighter and reduces the need for other related files:
Include only relevant parts that clarify the actual licensing situation, beyond what is already implied by the licence.
A typical disclaimer is: “This software is provided ‘as is’, without any warranties or guarantees.”
List directly used components. For each, include the name, URL, used version, copyright, licence name or SPDX identifier, and a link to the licence text. Ensure their versions match those actually used in the project. There is no need to list transitive dependencies. If some are detected by your SCA tool as incompatible dependencies, comment on them (e.g. as false positives) in internal documentation.
If the NOTICE file is otherwise unnecessary, but direct dependencies must still be declared, direct dependencies, you may place a simplified dependency list in the README, which may include only the name, link, and purpose.
For general-purpose components (e.g. PostgreSQL, Docker, Elasticsearch, Apache HTTPD), you may describe them collectively as part of a “platform stack” rather than listing them as third-party dependencies, especially if multiple versions or compatible equivalents may be used.
You may also list tools used. A tool is any system used to create, check, or manage code, configurations, or data during development or operation, but not part of the software runtime. Include tools that were used regularly or had a significant impact on development. Optional or sporadically used tools can be omitted. If tool versions are relevant, ensure they match those actually used.
Most OSS licences (except MIT and BSD) expect modifications to be described, typically in a NOTICE file.
No, but it is best practice to maintain one. It provides valuable public information and becomes difficult to reconstruct if not created early in the project.
No. You can start the CHANGELOG from the current point. It is acceptable to state that prior changes are not listed:
## [1.12.3] – 2025-06-17 - Changelog initiated; prior changes not listed. |
CHANGELOG content may be reconstructed from repository versions and commits. Optionally, each version may include a short summary paragraph providing a high-level description of the release before the itemised changes. Such a summary may also be used where detailed items cannot be reconstructed.
If you maintain the AUTHORS file, list all developers and key contributors, including those from relevant GÉANT activities and tasks, detailing their roles and contributions. Important non-developer contributors to conceptualisation, documentation, testing, or deployment can be listed in an optional “Other Contributors” section. The list of authors may not be exhaustive, but limited to the core team.
In addition to author names, consider including contact links such as email, ORCID, or repository IDs, roles, and institutions. If there are many contributors, note that the full list is available in Git history.
Provide WP and Task codes and names where applicable. The list of authors may be preceded by a statement such as “<Project Name> was developed by the GÉANT <GNx-y> WP<a> Task <b> (<Task Name>).” Include all relevant contributing project phases, activities, and tasks. Since codes may change across project iterations, include both names and codes of work packages and tasks.
Yes. Each sub-repository README should describe its purpose and link to the main repository (and potentially other project parts). It may be brief, containing part-specific information, a link to the main repository’s README, and links to other sub-repositories. This helps users understand the structure and navigate the project effectively.
If all repositories are in the same repository which supports project grouping (such as GitLab), group them together.
Each repository must contain its own full LICENSE and COPYRIGHT files, even if identical to those in the main repository. The main repository should also include full copyright and licence information for all sub-repositories.
Other files do not need to be duplicated or include significant overlaps.
Other common files in sub-repositories may be generic and point to the corresponding files in the main repository instead of duplicating content. Their form may be:
# <Project Name> *Component* – <NOTICE, AUTHORS, CHANGELOG, etc.> This is a sub-repository of the <Project Name>. The full <NOTICE, AUTHORS, etc.> for the entire project<, with the list of authors and contributors,> is maintained in the [<Main Repository Name>](<Main Repository File URL>). |
To keep these files identical across repositories, you may omit component names from titles.
You may also opt to provide sub-repository-specific content (such as authors) if it significantly differs between parts.
The NOTICE file, if it exists, may have the above form, referring to the main repository’s NOTICE for shared information, and, like the README, providing information about sub-repositories with navigational links. Alternatively, it could provide unique information for the sub-repository.
You may maintain a single, project-wide CHANGELOG unless sub-projects have independent release cycles.
Include a clear licensing declaration and a short copyright statement in the README of each repository. Having a LICENCE file alone is insufficient.
Yes. Even if identical, the COPYRIGHT file must be present in all repositories.
It should include the GÉANT copyright statement, disclaimer, IP ownership claim, and acknowledgement of EU funding with the logo.
No. This depends on the specifics of each part. Only the Apache licence requires preserving the existing NOTICE and including information for modified files.
Per-part NOTICE and README files should be unique to each sub-repository, reflecting its dependencies and purpose, and providing navigational links to all involved repositories. Sub-repositories should be listed similarly to components, and both files should indicate where the project is hosted, including the primary repository address and the purpose and location of sub-repositories, ensuring uniformity in the NOTICE section where components are listed.
For projects not under Apache, identical or uniform NOTICE files may be created by moving most variability to the README and CHANGELOG. For example, a NOTICE file could state: “This software includes no modified third-party components. Project evolution and history of changes are documented in the CHANGELOG.md file.”
Files that describe inbound contributions include:
README – provides general guidance for users and contributors on adhering to licensing requirements.
CONTRIBUTING – details contribution and copyright guidelines, explains the CLA or DCO process, and ensures legal clarity for all contributions.
CODE_OF_CONDUCT – may include guidance on contributor behaviour and adherence to licensing policies.
CONTRIBUTOR_LICENSE_AGREEMENT or CLA – contains the formal Contributor Licence Agreement, if required. For projects using a Developer Certificate of Origin (DCO), self-certification is recorded in Git commit messages rather than a separate file.
Alternatively, the CLA may also be incorporated within the CONTRIBUTING file.
In many GÉANT projects involving only internal participants, files regulating external contributions are unnecessary. If external contributions are accepted, include a clear statement of origin. Projects under copyleft licences often use a CLA or DCO process to manage contributions safely and ensure compliance.
Never commit credentials, API keys, passwords, or production settings to public repositories. Provide a config.example or .env.example file with placeholders. Load real values from environment variables or a secret management system. Add actual configuration files (.env, config.json) to .gitignore.
If a secret is committed, treat it as compromised, revoke it immediately, and rewrite Git history using tools such as git-filter-repo.
No. Repositories should contain source code only. Committing binaries increases repository size and makes diffs unreadable. Do not include executables (.exe, .bin, .so, .dll), build artefacts (/build, /dist), archives (.zip, .jar, .apk,.war, .tar, .gz), and likely secrets (.p12, .key, .jks). Generate these artefacts via CI/CD and publish them as release assets, for example through GitHub Releases or GitLab Package Registry, or , if your build needs some, configure your it to retrieve them from external locations. To prevent accidental commits, list all such files explicitly in .gitignore.
Only bundle external resources when unavoidable. Prefer package managers to fetch dependencies during the build. If bundling is required, confirm that the third-party licence permits redistribution and is compatible with your project’s licence. Preserve original LICENSE files and copyright headers. Where required, include full licence reference or texts in the NOTICE file and list each component, its origin URL, and its licence in the README or NOTICE.
For licences with an express patent grant, such as Apache 2.0 or GPL 3.0, the licence text is usually sufficient. If your organisation owns relevant patents, list them in the NOTICE file to clarify the scope of the grant. Mention known third-party patents in the README or NOTICE without offering legal interpretation or creating custom legal disclaimers.
Open source licences cover code, not branding. Add a “Trademark Notice” section to the README or NOTICE file stating that project names, logos, and icons are trademarks of their respective owners. Clarify that the software licence does not grant trademark rights, except for nominative use to describe the software, with appropriate use of trademark symbols ( ™ or ®), and that use does not imply endorsement by the trademark holder.
Do not include them. Instead:
README which modules are excluded.