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

Compare with Current View Page History

« Previous Version 2 Current »

Software Licensing Guides Series

Table of Contents

Overall Process and Guidance

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

Use the templates and embedded instructions from Templates and Examples for Software Project Artefacts (for ).

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

Refer to Software Licensing Certificates - old.

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 the relevant descriptions at Software Licence Management and Software Licensing Certificates - old. Then:

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 the most common OSS licences, their requirements, compatibility, and patent terms.

Licence texts, obligations, use cases, and comparisons:

For tailored advice, use the SLA service to select the most suitable licence for your project.

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 compatible; the same applies to LGPL and AGPL variants. However, your software may use LGPL v2 and v3 licensed components.

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 do I declare an open source licence?

  • Choose a licence (the SLA service may help)
  • Create a LICENSE or LICENSE.txt file and paste the full licence text
  • Add your name or organisation and the year, if required (MIT, BSD, and ISC licences include placeholders)
  • Create a COPYRIGHT file
  • Reference the licence in your README. Example:
    "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 a suitable file (such as README)
  • Use SPDX identifiers if applicable (e.g. add "MIT" in package.json, pyproject.toml, etc.)
  • Declare the applied licence in the code repository metadata

Example for the MIT licence:

  • Start the LICENSE file with:
Copyright © GÉANT Association 2025 (on behalf of the GÉANT project)
## Licence
This project is licensed under the MIT License. See the [LICENSE](./LICENSE) file for details.You use the noun 'licence'. How should a licence file be named – “LICENSE” or “LICENCE”?Use LICENSE (US spelling) to ensure compatibility with automated tools.General Artefact Concerns

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.

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. It is best practice. If not created early, it becomes difficult to construct later.

Multi-Repository Projects

Should all repositories in a large multipart project include artefacts?

Yes. At a minimum:

  • LICENSE must be in each repository
  • README can be brief, linking to the main repository’s README
  • COPYRIGHT must be in each repository (can be identical or note differences)

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 is not sufficient.

Is a COPYRIGHT file required in every repository?

Yes. Even if identical, the COPYRIGHT file should be present in all repositories.

It should include the GÉANT copyright statement, disclaimer, IP ownership claim, and acknowledgement of EU funding with logo.

Is a NOTICE file required in every repository?

No. Only Apache requires preserving existing NOTICE. Even then, you may:

  • Place dependency information in each repository’s README
  • Include the Apache boilerplate in the README or COPYRIGHT file

This avoids creating a NOTICE file for every repository.

You may also create identical or uniform NOTICE files by factoring out most variability into the README and CHANGELOG. Such NOTICE file may, for example, state:

This software includes no modified third-party components.
Project evolution and changes are documented in the CHANGELOG file.

However, custom NOTICE files allow inclusion of:

  • Licensing options, secondary licences, exceptions, or additional permissions
  • Disclaimer
  • Authors and contributors
  • Third-party components and tools used
  • Trademark information
  • Patent claims or notices
  • Special acknowledgements or attributions

  • Prior notices required by third-party components and their licences

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 all such dependencies, and rerun the SCA scan
    • Address each remaining vulnerability
    • Isolate or replace the component
    • Document your findings and actions
  • Contact the Licence Management Team for further advice if needed

  • No labels