Software Licensing Guides Series

Table of Contents

Overall Process and Guidance

What is the Licence Management Team?

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.

How do I contact the Licence Management Team or request software licensing services or certificates?

See Software Licence Management and Software Licensing Certificates. Then:

Where can I find templates and examples for software project artefacts?

Use the templates and embedded instructions provided in Templates and Examples for Software Project Artefacts (for GÉANT participants).

What certificates can I apply for as part of the licensing process? Is there a comparison of available certificates?

See Software Licensing Certificates for descriptions and comparisons of available certificates.

Understanding Open Source Licences

How can I learn what each OSS licence means and what it requires?

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.

Under which licence should my project be licensed?

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.

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.

What should I know about the GPL licences?

The GNU General Public License (GPL) is a strong copyleft licence. If your software incorporates GPL-licensed components, the full source code must be made available under the same licence. GPL v2-only and GPL v3 are not mutually compatible; the same applies to their LGPL and AGPL variants. However, LGPL v2 and v3 licensed components may be used.

Are all GPL or restrictive licences flagged by Mend SCA always critical?

No. Flags are context-dependent:

  • Components may be multi-licensed
  • Not all uses involve distribution
  • Severity depends on usage and risk

Contact the Licence Management Team for assessment.

Declaring an Open Source Licence

How to declare an open source licence?

  • Choose a licence (the SLA service can assist).
  • Create a LICENSE or LICENSE.txt file and paste the full licence text.
  • Add the copyright statement, if required (MIT, BSD, and ISC licences include placeholders).
  • Create a COPYRIGHT file.
  • Reference the licence in your README (e.g. “This project is licensed under the MIT License – see the LICENSE file for details.”).
  • Follow additional requirements (e.g. Apache requires boilerplate text in NOTICE or README).
  • Use SPDX identifiers where applicable (e.g. “MIT” in package.json, pyproject.toml).
  • Declare the licence in repository metadata.

Example for the MIT licence:

  • Start the LICENSE file with:
    “Copyright © GÉANT Association 2025 (on behalf of the GÉANT project)”.
  • Paste the remainder of the MIT text.
  • Include the copyright statement and the following in README.md:

## Licence
This project is licensed under the MIT License. See the [LICENSE](./LICENSE) file for details.

Why and when to use “licence” instead of “license”, and how should a licence file be named – “LICENSE” or “LICENCE”?

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.

How should I format the LICENSE file?

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.

Should I use the “or later” licensing option?

Yes, whenever possible, and from the earliest applicable licence version, as it increases the applicability and compatibility of your software.

How do I handle multi-licensing in the LICENSE file?

When a project is offered under multiple software licences, the LICENSE file should:

  • List all applicable licences clearly, specifying that the user may choose one
  • Explain the applicable conditions, including any limitations or consequences
  • Include or reference the full text of each licence

Example:

This project is dual-licensed under the MIT Licence and the GNU General Public Licence v3.0 or later (GPLv3+).
You may choose either licence to use this software under.
* Use the MIT Licence 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.

Where should I provide supplementary licensing information?

Provide supplementary information in the NOTICE file. In rare cases, such as OpenSSL, you may include it in the LICENSE file.

How should I format the copyright statement?

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.

Where and how must I include EU funding information and the EU logo?

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:

![Co-funded by the EU](docs/assets/EU_logo.png)
**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:

  • For GN5 only: “The GÉANT project is funded by the Horizon Europe research and innovation programme.”
  • For GN3 and/or GN4: “The GÉANT project is funded by the Horizon 2020 research and innovation programme.”
  • For GN3 and/or GN4 and GN5: “The GÉANT project is funded by the Horizon 2020 and Horizon Europe research and innovation programmes.”

Is a NOTICE file required?

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:

  • Primary repository location for traceability and provenance
  • Licensing options, secondary licences, exceptions, rights preserved, or additional permissions
  • Disclaimer
  • Authors and contributors
  • Third-party components and tools used
  • Trademark information
  • Patent claims, rights, or notices
  • Special acknowledgements or attributions
  • Prior notices required by third-party components and their licences

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.

Which licences require documenting modifications?

  • Apache 2.0 – requires notices in modified files
  • MPL v2.0 – requires documentation of changes
  • EPL v2.0 – requires identification of changes

Most OSS licences (except MIT and BSD) expect modifications to be described, typically in a NOTICE file.

Project Artefacts

Is the CHANGELOG mandatory?

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.

Do I need to reconstruct the entire CHANGELOG for an existing 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.

Who should be listed in the AUTHORS file?

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.

Multi-Repository Projects

Should READMEs be unique per repository?

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.

How should artefacts of sub-repositories be managed?

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

Where should the licensing and copyright statements appear?

Include a clear licensing declaration and a short copyright statement in the README of each repository. Having a LICENCE file alone is insufficient.

Is a COPYRIGHT file required in multi-repository projects?

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.

Is a per-part NOTICE file required in multi-repository projects?

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

Inbound Contributions

Which files regulate inbound contributions?

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 GÉANT 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.

Managing Vulnerabilities

How can I efficiently address critical vulnerabilities reported by an SCA tool?

  • Check if a newer version of the component resolves the issue.
  • Update dependencies and rerun the SCA scan.
  • Address remaining vulnerabilities.
  • Isolate or replace the affected component.
  • Document findings and actions.
  • Contact the Licence Management Team if further assistance is required.

  • No labels