...

This work  is licensed under  CC BY-SA 4.0

Table of Contents

What’s New

The document has been significantly updated from March 2024 to August 2025 to provide enhanced guidance on software licensing within GÉANT. The following changes and additions have been made, with overall improvements including simplified language, reduced verbosity, and more practical guidance throughout, while only expanding the guide from 33 to 36 pages.

...

• The placement of information descriptions has been extended with requirements for including licence information in repository metadata, the GÉANT Software Catalogue, ecosystem-specific registries, and automatic extraction from project artefacts. Multi-licensing guidance is enhanced, explaining how to describe multi-licensed projects.
• Instructions for README files now emphasise their role in project communication, and outline licensing details, copyright statements, referencing direct dependencies, relevant tools and frameworks, and providing EU funding acknowledgements.
• The COPYRIGHT section has been streamlined to improve references to GÉANT project iterations, and update guidance on including the EU emblem in project materials.
• In addition to crediting contributors, the AUTHORS file should acknowledge funding using a simplified format, and reference the relevant work package or task.
• Coverage of the NOTICE file has been extended to include its purpose, list primary and secondary licences, identify exceptions, include component copyrights and disclaimers, credit third-party intellectual property, and fulfil specific Apache 2.0 licence requirements.
• The guidance on CHANGELOG files now emphasises maintaining structured, clearly formatted change documentation using consistent formats and automation tools.
• Copyright and Licence Notices in Source Code now discusses the pros and cons of including notices in source code headers, and outlines Mozilla licence requirements for new code.
• Finally, a new comprehensive checklist for preparing and validating project files has been introduced as a practical reference for ensuring compliance with licensing requirements.

1 Introduction

The primary objective of this guide is to explain the intricacies of licence selection, declaration, compliance, and related tasks, offering a step-by-step breakdown of licensing mechanics for software development teams.

...

For comprehensive information on licences, compatibility, and licence selection, consult the training and reference materials listed in the Resources section of this guide.

2 Essential Aspects and Elements of Software Licensing

This part of the guide covers the following topics:

• Significance of open source software (OSS) and licensing.
• OSS conditions.
• Compatibility of licences commonly used in GÉANT.
• GÉANT Intellectual Property Rights (IPR) Policy.
• Licence governance in GÉANT.
• Software composition analysis (SCA) service.
• Mend SCA tool.
• Software licence analysis (SLA) tool.
• Licensing process, decisions, and artefacts.
• Licences and tracking of documentation, data, and other works.

2.1 Open Source Software and Licensing

Key factors related to open source software (OSS) include the following:

...

These and other recommendations for various software project stakeholders are detailed in the GN5-1 Software Licence Selection and Management guide and Deliverable D9.4 Open Source and Licence Support Report.

2.2 OSS Conditions

Selecting a licence is not straightforward and is a task most developers prefer to avoid. While the GÉANT IPR Policy favours permissive licences and names examples such as MIT, BSD, and EUPL, the available options are often constrained by the licences of core components or the frameworks the software relies on. It is therefore sensible for developers to explore specific licences, their implications, and compatibility only when the constraints and candidate licences are known within the licensing process, supported by the licensing team and the GÉANT IPR Coordinator.

...

Figure 2.1: OSS conditions from Licensing Assistant – Find and Compare Software Licenses

2.3 Compatibility of Licences Frequently Used in GÉANT

We have compiled comprehensive information about OSS licences, some of which is also available through Mend, the tool used for SCA (described in Section 2.8). However, only a limited set of licences is frequently used in GÉANT, and only a few licences are common sources of compatibility issues. Figure 2.2 provides an orientational diagram describing the relationships and compatibility of these licences.

...

OSS licences are described in several documents produced by the licensing team. For more details, refer to Reference Information about OSS Licences and Tools, OSS Licences and Licence Selection, and Open Source Licences Used in GÉANT.

2.4 GÉANT IPR Policy

The GÉANT IPR Policy applies to intellectual property (IP) generated within the GÉANT project, including open source software. It provides recommendations and rules, which this document translates into practical and actionable instructions. The policy is available at IPR Policy. It aims to establish a framework for IP generated by the GÉANT project, applying to all GÉANT participants. It offers practical guidance on IPR and, most importantly, seeks to establish a cooperative approach to IP protection and fair use in GÉANT projects. The IPR Policy also upholds the principles of findability, accessibility, interoperability, and reusability (FAIR) for the use of GÉANT project IP. Upon approval by the General Assembly, it has been binding since January 2023.

...

The WP9 Task 2 software licensing team provides related services, support, and guidance. Relevant materials developed by the team are listed in Section 4.3 Further Reading, while training and infoshare presentations are listed in Section 4.2.

2.5 Licence Governance in GÉANT

The goal of licence governance in GÉANT is to ensure compliance with GÉANT’s IPR Policy while respecting the licences of dependencies and domain community standards. It is led by the IPR Coordinator and supported by WP9 Task 2 Open Source and Licence Support (OSLS), or simply software licensing. The OSLS team:

...

The analyses, especially when conducted for a module that is an add-on for an externally developed open source platform, can also benefit the broader software platform community by assessing its overall licensing status and component security. This is a side effect of analysing software produced by GÉANT development teams, as it includes assessing involved components and licences.

2.6 Importance of Declaring a Licence in Code Repositories and FAIR Compliance

Declaring an open source licence when publishing code in a public repository is essential for legal clarity, responsible reuse, and alignment with community and funder expectations. Legally, code shared without an explicit licence defaults to “all rights reserved”, prohibiting others from using, modifying, or redistributing it – even when publicly accessible. Applying a well-defined licence ensures compliance with legal requirements while empowering others to reuse the work. Specifying a licence communicates the terms of use, protecting both the developer’s rights and users’ obligations (including attribution requirements, disclaimers, and redistribution conditions). This becomes particularly crucial in collaborative environments and for publicly funded projects, where compliance, reuse potential, and transparency are essential values.

Licensing also plays a pivotal role in upholding the FAIR principles (Findable, Accessible, Interoperable, and Reusable), widely endorsed in research and open science. The Reusability of digital assets, including software, hinges on a clear licence. Without one, code cannot be integrated into other projects, workflows, or datasets, undermining reproducibility and collaboration. A declared licence further supports Accessibility by resolving legal ambiguity and enhances Interoperability, particularly when integrating projects with differing licensing terms.

Special Considerations for the GPL

Among open source licences, the GNU General Public License (GPL) family imposes distinct obligations. As copyleft licences, they require derivative works or redistributed versions to adopt the same GPL terms. Distributing software that incorporates GPL-licensed code legally obligates you to release the source code publicly under identical conditions. While this aligns with open science ideals of transparency and shared knowledge, compliance demands deliberate planning – especially in collaborative or commercial settings.

2.7 Software Composition Analysis (SCA) Service

This service assists development teams by setting up a project within an SCA tool and providing insights into external components. It is suitable for both one-time software analysis and continuous monitoring, identifying third-party components, their licences, and potential IPR infringements or security vulnerabilities. The service can be combined with other software review services or performed independently. Repeated analyses can determine how changes in software and dependencies affect licence compliance and identify new or pending vulnerabilities. For ongoing monitoring, the analysis setup can be integrated into the project’s continuous integration platform.

...

A summary of the SCA service is available in Software Reviews, with more details in the Client Guide for Software Composition Analysis (SCA).

2.8 Mend SCA Tool

Mend is an online tool provided by GÉANT for open source licence and security compliance. It is designed for in-house use by customers and does not offer direct legal consultancy. Mend detects software components, their licences, and vulnerabilities. It integrates seamlessly with development environments, building a pipeline to detect open source libraries with security or compliance issues. Mend reports severe bugs, problematic licences, new versions, and available fixes. It simplifies the management of open source libraries and helps detect and resolve compliance and security issues.

...

It should be noted that other tools are available for software composition and licence analysis; some are listed in Other Software Composition Analysis (SCA, Software Inventory) Tools.

2.9 Software Licence Analysis (SLA) Service

Selecting the appropriate licence for distributing and using software is critical, as it defines the terms for sharing, modifying, and distributing the software. This process considers project objectives, developer preferences, the desired level of collaboration, the software’s ecosystem (including related products, their licences, and users’ expectations), and the constraints imposed by the licences of dependencies and other background and sideground IP. Choosing a licence also involves assessing the effort needed to resolve licence compatibility issues and ensuring compliance with legal, regulatory, and funding requirements. The chosen licence plays a key role in fostering a collaborative and transparent development environment, providing clarity on how others can use and contribute to the open source project.

...

A summary of the SLA service is available in Software Reviews.

2.10 Licensing Process, Decisions, and Artefacts

The typical steps for managing licences are:

...

Continuous licence management is carried out by the development team based on their SCA-SLA experience, with advice from the licensing team. The licensing team may adjust project configuration in Mend and configure it for the chosen allowed or prohibited licences. While the development team should perform further monitoring and adjustments after successful licensing, it is recommended to repeat the SCA-SLA process after significant changes to ensure the project remains compliant.

Preparation

• Decide on the software name, grouping of subprojects, and the use of available contributions.
• New projects may require a proof of concept or prototype to identify and validate key components.
• Gather pre-existing information and documentation for components, models, assets, and relevant specifications and standards.
• Consolidate project components into a single repository project, or clarify their relationships if they should remain separate.
• Address authorship and copyright matters internally.
• Ensure the software project is hosted on GÉANT GitLab (Community Edition hosting most projects, Ultimate Edition hosting selected projects) or GitHub.
• Register the software project in the GÉANT Software Catalogue.

...

The software may include non-original artefacts or assets with different licences. These assets, which may not be detected by SCA tools, should be documented with their origin, copyright, and licence information as soon as they are added to the project. Methods for documenting them are covered in Section 2.11 Licences and Tracking of Documentation, Data, and Other Works. Failing to document them promptly can complicate their identification and tracking in the future.

One Project or Several Projects?

When handling multiple projects, it is essential to determine which dependencies should be included in the SCA analysis. This may depend on the relationship between components and their respective responsibilities. For instance, a project may be a subproject of the same team or a module within a larger project overseen by an external group or entity. Both the subproject and the main project may need to be analysed together with their source code and dependencies, even if stored in separate repositories.

...

The licensing team can also advise on grouping features or products within the project and software branding from a technical and licensing perspective. For advice on product or service development, please contact the GÉANT Marcomms Team at marcomms@geant.org.

Information Gathering and Documenting

Collect and document copyrights, licence findings, and decisions:

...

For more information about the licence selection process and related recommendations, refer to the OSS Licences and Licence Selection guide and the white paper OSS Licences in GN4-3 and GN5-1 GÉANT Project: Current State and Recommendations.

Remediation

This stage focuses on resolving licence conflicts and fulfilling obligations, which may require varying levels of effort from developers, ranging from minor adjustments to significant changes, such as removing or replacing dependencies, developing alternatives, or refactoring code. In some instances, further remediation may be required after subsequent SCA scans.

...

• Selecting a more appropriate licence for the product or project compatible with dependencies.
• Implementing quick fixes, such as:
  • Updating or replacing vulnerable open source components.
  • Updating outdated open source libraries where possible.
  • Investigating unclear component licences or seeking clarification or relicensing from authors.
  • Purchasing necessary proprietary software licences.
  • Choosing among dual-licence options for components.
• Identifying any remaining incompatible licences.
• Deciding on actions for components with such licences:
  • Removing non-essential components.
  • Replacing them with available alternatives.
  • Moving them to the server side (providing functionality via a central service).
  • Developing alternatives to meet the required functionality.
• Accepting certain risks.
• Internally documenting dependencies, their licences, features they provide, decisions made, and remediation actions undertaken.
• If necessary, repeat the SCA and the remediation steps listed above.

Creating Licence-Related Artefacts

To ensure OSS licence compliance, several key artefacts are required. The details of these artefacts are covered in Section 2.12.

...

• Document dependencies, their licences, notices, and copyright information.
  • List the licences of directly included dependencies in a dedicated file or project documentation, typically in the NOTICE file, along with each component’s copyright and links to its licence text. The file may also include disclaimers and details on the project’s licence, tools used, and IP used. The README can summarise this information in a more concise form.
  • In the AUTHORS file, you may credit individual contributors, acknowledge funding, and reference the GÉANT work package or project task.
  • For source code components in subfolders, store their licences, copyright, and notices within those folders.
• Document licence adherence, contribution, and updating.
  • Provide guidance for users and contributors on adhering to licensing requirements in the README, CONTRIBUTING, or CODE_OF_CONDUCT file. Examples include guidelines from FileSender and Atom.
  • Outline contribution and copyright guidelines, even if external contributions are not expected.
• Prepare and apply a Contributor License Agreement (CLA) if necessary.
  • If the selected licence requires a CLA, establish one to define contribution terms and ensure mutual understanding.
  • Some licences offer suitable CLA forms.
  • Clearly outline the CLA process in the README and detail it in the CONTRIBUTING file to ensure legal clarity for all involved.
  • Place the CLA in a file named CONTRIBUTOR_LICENSE_AGREEMENT, CLA, or within broader contribution guidelines in the CONTRIBUTING file.
  • Creating a Developer Certificate of Origin (DCO) is a lightweight alternative to a CLA. By adding a “Signed-off-by: Name <Email Address>” in their Git commit, contributors self-certify that they agree to the DCO’s terms, affirming they are either the original authors or have the right to submit the code, which can be used in the project under its licence.
• Establish a licence notification mechanism – If the licence or contribution policy may change, implement a notification mechanism for contributors and users. This could include prompts during builds, repository notifications, or updates via project notification channels. A pop-up with licence and copyright change information is also an option.
• Once licence artefacts are complete, they should be assessed by the SLA team and the IPR Coordinator.
• Complete the SLA/SCA Evaluation and Feedback Survey.

Continuous Licence Management

The aim of continuous licence management is to integrate licence oversight into the regular software development lifecycle.

...

GÉANT software best practice BP-B.6: Manage Sideground IPR recommends addressing pre-existing and external IP early and periodically repeating the process.

2.11 Licences and Tracking of Documentation, Data, and Other Works

Software-related artefacts and assets distributed with software or stored in its repository generally adhere to the same open source licence. These may include data, technical documentation, configurations, and user manuals. For separate tutorials, presentations, training materials, or promotional materials which are not software artefacts, it is advisable to use the Creative Commons Attribution (CC BY) or Attribution-NonCommercial (CC BY-NC) licences. The GNU Free Documentation License (GFDL) is also noteworthy. While data is sometimes licensed under OSS licences, datasets are more commonly licensed under Creative Commons and Open Data Commons.

...

Original assets distributed with the software should be kept under the same licence and do not need to be individually tracked.

2.12 Project Licence Options

The applied licence may allow additional conditions or permissions to be added, clarifying how others can use, modify, and distribute the software. If the licence offers such options, they are explained in the licence text. Common software licence options that code owners may explicitly state include:

...

It should be noted that SCA tools cannot interpret options, additional rights, or conditions introduced in free text.

3 Complying with a Selected Licence

This section guides developers through the process after selecting a licence. It covers preparing necessary files, performing compliance checks, and reviewing adherence with the licensing team. It also provides essential information for developers seeking to address licensing issues independently. Links to GÉANT-approved example files will be provided as they become available from software projects.

...

REMEMBER: using AI prompts can create copyright issues, always creatively transform prompts and verify AI tools generated content.

3.1 Placement of Information

The README file serves as the primary entry point for users and is highlighted by platforms like GitHub, which displays its content when the project’s root folder is opened. It should summarise key information, including copyright and licence. Hyperlinks can direct users to other files and external resources, such as the full licence text, project website, or funding information. Online platforms like GitLab, GitHub, and the GÉANT Software Catalogue manage and display information such as the licence via their user interface. In some cases, registration in specialised registries, like research software registries or the WordPress plugin directory, may also be necessary. These platforms often extract relevant information automatically from files like README or COPYRIGHT, and present it in the project profile or metadata.

...

Modules in subfolders may have their own licences. Each subfolder with a different licence from the main project should include a separate LICENSE file, along with necessary attribution or copyright notices. This information is crucial for subprojects or folders differing from the main project. Other important information for subprojects should be provided in their respective folders, similar to the main project. The README, COPYRIGHT, and NOTICE files of unmodified components should remain unchanged.

3.2 Compliance with Licences of Used Code

In addition to adhering to your project’s licence requirements, it is essential to meet the obligations of licences governing dependencies or reused code, including copyright and patent rules. This requires ongoing attention throughout development. Key actions include:

...

• Including the original copyright notice.
• Providing a copy of the Apache licence.
• Describing significant changes made to the original code.
• Maintaining a NOTICE file with attribution notes (original or added ones).

3.3 README File

The README file should contain basic information about the software, including the licence and copyright, typically in one short line each. It should also mention the origin or motivation for the development, credit GÉANT, and refer to COPYRIGHT, LICENSE, and other files for details.

...

A helpful README template is available at Make a README, which provides exemplary markdown and detailed recommendations in the section Suggestions for a good README.

3.4 COPYRIGHT File

Software is protected by copyright law. Various OSS licences impose specific requirements under which software developers grant other users specific rights while retaining copyright. Therefore, developers must clearly indicate the copyright.

...

Figure 3.1 presents an example of the EU emblem with a reference to GÉANT:

Figure 3.1: The EU emblem with text about GÉANT and its funding

...

The EU emblem and funding statement must be prominently displayed in the COPYRIGHT and README files, as well as in all public or participant-facing communication materials, such as printed or digital products or websites. The same is recommended for NOTICE and AUTHORS, if present.

3.5 AUTHORS File

Open source projects typically result from the collaborative efforts of various developers or teams, and it is important to acknowledge their contributions.

...

After funding information, add other acknowledgements as needed. If the project is part of a larger ecosystem or depends on third-party libraries, it is good practice to acknowledge these dependencies either in the README or a separate NOTICE file.

3.6 NOTICE File

The project licence may require a NOTICE file, or you may be modifying a project with an existing one, in which case you should add your entries. Mention all the libraries and frameworks your project uses, and provide links to their respective websites or repositories. Declare and credit any other IP used, along with its licence and licence options.

...

It is your responsibility to review and comply with the respective licences and attribution requirements for these components, as project dependencies and licence conditions evolve. Acknowledging contributions, dependencies, and tools fosters a collaborative open source community.

3.7 CHANGELOG File

A well-maintained CHANGELOG enables users and developers to track a project’s development history, making it easier to follow updates and modifications. It also aids in troubleshooting and identifying potential issues during upgrades. Even if not required by the licences, documenting the history of changes in the CHANGELOG is considered good practice.

...

The project’s documentation should explain that users and contributors can access the CHANGELOG file for release notes, and possibly other artefacts such as the project roadmap.

3.8 Copyright and Licence Notices in Source Code

Placing copyright and licence notices in source code file headers ensures proper attribution and compliance with licence requirements, and may improve transparency for contributors. However, this practice is declining due to redundancy with centralised LICENSE files, maintenance complexity, interaction with version control systems and automation tools when the information is updated, as well as the preference for cleaner and more readable code.

...

Rare exceptions where a copyright header is required are generally tied to projects’ licensing policies rather than licence requirements. For instance, Mozilla’s source repositories require appropriate header text for new code.

3.9 Checklist for Preparing and Validating Project Files

This checklist provides key steps for preparing and validating project files, based on prior instructions and common issues:

...

Refer to Templates and Examples for Software Project Artefacts for guidance. A more detailed checklist is available with further instructions.

4 Resources

4.1 Contact

• IPR Coordinator email: iprcoordinator@geant.org
• WP9 Task 2 Open Source and Licence Support (OSLS, software licensing)
  • Slack: #sw-licences at https://geant-project.slack.com workspace
  • Email: sw-licences@software.geant.org
• GÉANT Marcomms Team email: marcomms@geant.org

4.2 Training Materials

• Training course: Open Source Licensing and Compliance
• Webinar: License Dependencies Analysis with WhiteSource
• Training course: Introduction to Open Source Licensing and Compliance 2023
• Infoshare: Software Licences Management in GÉANT

4.3 Further Reading

• GÉANT IPR Policy
• OSS Licences and Licence Selection guide and the white paper OSS Licences in GN4-3 and GN5-1 GÉANT Project: Current State and Recommendations. – introductory guide
• OSS Licences in GN4-3 and GN5-1 GÉANT Project: Current State and Recommendations – project-oriented white paper for GÉANT participants, providing guidance on licence selection, with an appendix describing the OSS licences most frequently used by analysed projects
• Software Licence Selection and Management in GÉANT – maintained online version of this guide
• Open Source Licences Used in GÉANT – descriptions and compatibility of commonly used licences in GÉANT
• Templates and Examples for Software Project Artefacts – per-artefact Markdown templates, and links to examples from various projects
• Reference Information about OSS Licences and Tools – a comprehensive catalogue of thematically organised resources and pointers
• GÉANT software best practice BP-B.6: Manage sideground IPR
• OSI Approved Licenses

4.4 Services

• GÉANT Software Licence Management (homepage)
• Jira requests for SCA and SLA
• Software Reviews – GÉANT Software Development Support
• GÉANT Mend (login via GÉANT SSO; special permissions may apply)
• Accessing Mend and visibility levels – on the visibility of Mend scan results
• Mend short guide for end users – includes interpretation of Mend reports
• The Risk Report – short end-user guide on Mend risk report
• GÉANT (Community Edition hosting most projects, Ultimate Edition hosting selected projects)
• GÉANT Software Catalogue

Glossary