You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Current »

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.

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.

Why should I include a licence when publishing code in a public repository?

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.

What are the legal implications of not including a licence?

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.

How does licensing relate to the FAIR principles?

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.

What should I know about the GPL licence?

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. 

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?

  1. Choose a licence

    • Use a standard OSI-approved licence that fits your goals, such as MIT, Apache-2.0, GPL-3.0, or BSD.

    • The SLA service can assist.
    • Tools like choosealicense.com can guide your selection. 
  2. Create a LICENSE file
    • Name the file exactly LICENSE or LICENSE.txt.
    • Copy and paste the full licence text.
    • Add the copyright statement, if required (MIT, BSD, and ISC licences include placeholders).
  3. Create a COPYRIGHT file.
  4. Reference the licence in README
    • Add a short note, e.g.
      “This project is licensed under the MIT License – see the LICENSE file for details.”
  5. Optionally add licence headers at the top of source code files
    • It should contain a copyright statement and licence reference.
  6. Follow additional requirements
    • Apache requires boilerplate text (provided with the licence text) in NOTICE or README.
  7. Use SPDX licence identifiers, if applicable
    • For integration with package managers (e.g., npm, PyPI), include the licence in metadata files, usinf SPDX identifiers where applicable (e.g. MIT in package.json or pyproject.toml).
    • Declare the licence in repository metadata.

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.

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

Where should I provide supplementary licensing information?

Provide supplementary information in the NOTICE file. In rare cases, such as OpenSSL dual-licensing, 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.

Project Artefacts

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.

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?

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.

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

Managing Secrets, External Assets, and Intellectual Property

How should configuration values and secrets be managed?

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.

Should I commit binaries, compiled code, or generated files?

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.

How do I include third-party or proprietary resources correctly?

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.

How do I document patents relevant to the project?

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.

How do I handle trademarks used in the project?

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.

How should trade secrets be addressed?

Do not include them. Instead:

  • Keep proprietary logic or secret algorithms in private repositories and expose them via APIs or plugin interfaces.
  • Avoid committing commented-out proprietary code or internal notes.
  • If the open source release is an Open Core subset, clearly state in the README which modules are excluded.

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 by replacing or isolating affected components.
  • Document findings and actions.
  • Contact the Licence Management Team if further assistance is required.

  • No labels