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 Complying with a Selected Licence part has been improved to offer clearer, more actionable guidance across documentation files. Coverage is expanded on when software licensing is required, how licence choice is influenced by project dependencies, and possible exceptions for Software as a Service (SaaS). Guidance is provided on using GÉANT software licensing templates and AI assistance to create licence and copyright documentation.

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

This guide is divided into two main parts:

1. The first part, Essential Aspects and Elements of Software Licensing, provides developers with key insights into software licence selection and management, outlining the tasks they must perform, and the procedures required to engage with services that support licensing. This part provides a straightforward overview of the elements necessary for efficient preparation, information gathering, and software licensing.
2. The second part, Complying with a Selected Licence, explains how to implement the selected licence from a developer’s perspective, providing instructions that ease the licensing process. It gives in-depth information, along with simple but vital guidance on creating essential licensing artefacts.

This document does not detail individual open source software (OSS) licences, software composition analysis (SCA) tool usage, licence compatibility, or the remediation of licence conflicts. This is intentional, as developers may not need to deal in depth with these complex tasks, because they can rely on support from the software licensing team. When such details are necessary, they are covered in separate guides provided by the software licensing team.

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:

• Our work increasingly relies on OSS. Developers, National Research and Education Networks (NRENs), and GÉANT use, adapt, create, and endorse OSS.
• The ICT and R&E communities value OSS for its cost-effectiveness, transparency, collaboration, customisability, vendor independence, longevity, security, educational value, compatibility, ethical and societal values, accessibility, and more (detailed below).
• OSS licences ensure software remains free, prevent appropriation, and reduce the risk of abandonment.
• Declaring a software licence simplifies the selection of code and libraries for use in a project, and facilitates usage, adaptation, and contribution by other developers.
• Licensing is critical when distributing or sharing software, as OSS licences have specific conditions.
• Licence declaration and compliance are essential for legal and usability reasons, increasing transparency, and fostering collaboration.
• Adhering to applicable licences (including those of dependencies) enhances the visibility and credibility of a software project within the wider community.

OSS is extensively used in technology products, services, business, governments, research, and education. It provides and supports affordability, transparency, collaboration, and technical innovation. It empowers individuals and organisations to take control of their software solutions, adapt them to their needs, and contribute to a global community of developers and users. Key benefits include:

1. Cost-effectiveness – OSS is often free to use, significantly reducing software acquisition and licensing costs for individuals, businesses, and organisations. This is especially critical for smaller businesses, educational institutions, and governments with budget constraints.
2. Transparency – OSS is built on open and transparent development processes. Anyone can review the source code to understand how the software works, enhancing trust and security. This is particularly important for software used in critical applications, such as cybersecurity and healthcare.
3. Community collaboration – OSS projects often have large and diverse communities of developers and users who collaborate to improve the software. This leads to rapid bug fixes, updates, and feature enhancements, fostering innovation and knowledge sharing.
4. Customisation – Users can modify and customise the code to meet specific needs. This flexibility allows businesses and individuals to adapt software to their unique requirements, offering them a competitive advantage.
5. Vendor independence – Unlike proprietary software, where users are often locked into a vendor’s ecosystem, OSS offers greater freedom and flexibility, as users have access to the source code and can switch providers or modify software as needed, including integration with other products.
6. Longevity – While proprietary software may be discontinued by the vendor, leaving users without support, OSS tends to have a longer lifespan. Communities can continue maintaining and developing the software if the original team slows down or abandons it.
7. Security – Although OSS is not immune to vulnerabilities, its transparency allows a global community to audit the code continually. When vulnerabilities are discovered, they can be fixed quickly. Proprietary software security, on the other hand, depends on the vendor’s resources and priorities.
8. Education and learning – OSS encourages learning and skill development. Students and aspiring developers can study, modify, and contribute to OSS projects, gaining practical experience in real-world software development.
9. Compatibility – Open standards and OSS promote compatibility and interoperability between different software, reducing barriers to data exchange and collaboration.
10. Ethical values – The OSS movement is rooted in values such as transparency, collaboration, and the belief that software should be a public good. Many individuals and organisations align with these values.
11. Global accessibility – OSS is accessible to users worldwide, regardless of location or economic status, promoting digital inclusion and levelling the playing field.

In the GÉANT context, specific requirements and recommendations are guided by its IPR Policy (also see GÉANT Resources – Intellectual Property):

1. Establish clear naming and branding, and define how the project should be packaged into products and repositories. Ideally, OSS should be hosted in a public versioned repository, with GÉANT GitLab as the preferred platform (Community Edition hosting most projects, Ultimate Edition hosting selected projects). The relationship between packages and their components will likely influence the licensing decisions.
2. Every GÉANT software project should select and apply an OSS licence that meets the needs of both the development team and the user community.
3. Start the licensing process early to streamline licensing and compliance.
4. The chosen licence must be compatible with all used components’ licences, to eliminate IPR and licensing risks for GÉANT.
5. It is preferable to place the OSS source code in a public and versioned code repository, with a clear licence indication.
6. Copyright information must acknowledge GÉANT’s involvement and support, underscoring that the work was conducted within the GÉANT project or received support from it. The authors of the produced software should also be identified.
7. Assess components and software by using common software quality and trustworthiness checklists to ensure quality and reliability. Examples include TinyMCE – Open Source Software Evaluation Checklist, Red Hat – Checklist for Measuring the Health of an Open Source Project, and EURISE Network Technical Reference – Software Quality Checklist.
8. Use GÉANT software composition and licence analysis (SCA and SLA) services to conduct the related reviews and audits, designed to determine the appropriate OSS licence and ensure compliance. Identifying and addressing software vulnerabilities through SCA improves quality and benefits the broader community.
9. Set up contribution, communication, and governance workflows to ensure compliance with the software’s licence.
10. Adhere to the standards of the domain community in software development, licensing, software metadata, documentation, registration in relevant community registries, citation, and promotion.
11. If applicable, enable and advise on the citation and referencing of software in scientific papers, presentations, and tutorials, ensuring clear and persistent references.

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.

...

Various licence conditions are often classified as:

• Rights/permissions – what you are allowed to do.
• Requirements/obligations – mandatory compliance artefacts, such as copyright, disclaimers, licence text, notices, relevant source code, build and installation instructions, etc.
• Restrictions/limitations – what you are prohibited from doing.
• Other characteristics – typical uses, classification, compatibility, legal features, origin, community, endorsement, and more.

These features are further outlined in models such as the EC’s Licensing Assistant tool, which, when options exist, greatly facilitates the selection of the most suitable licence aligned with the developers’ strategy and user community.

...

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.

...

To summarise the IPR Policy:

• All OSS licences (OSI and FSF) are permitted.
• The IPR Policy strongly recommends the use of permissive licences.
• Copyleft licences (weak, strong, or network-protective) can be applied as needed, in consultation with the IPR Coordinator.
• The IPR Coordinator provides final recommendations and maintains the GÉANT IP Register.

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:

• Assists those wishing to understand and manage OSS licences, master the tools provided, and apply them.
• Provides knowledge and support to solution designers, developers, and skilled promoters on licences and IPR.

The licensing team offers technical and implementation support on open source software and licence management through two services:

• Software composition analysis (SCA) – Technical and practical assistance for development teams in managing software components and their licences.
• Software licence analysis (SLA) – Assistance for software teams in aligning project and licensing decisions with the GÉANT IPR Policy and the guidance provided by the IPR Coordinator.

These services complement other software review services provided by WP9 Task 2 Software Governance and Support, such as SonarQube Setup Assistance and Extended Source Code Review. Through SCA and SLA services, the licensing team ensures key licensing concerns are addressed by:

• Assessing the licences of components and prior IP.
• Selecting an open source licence that meets the project’s needs.
• Ensuring the selected licence is compatible with the components’ licences.
• Ensuring compliance with the chosen licence.

The licensing team helps GÉANT software teams with IPR and licensing issues by implementing robust processes for managing dependencies and licences and achieving compliance with the GÉANT IPR Policy. It provides access to expert tools for analysing and managing open source licences. The OSLS has collaborated with many GÉANT software teams to assess their licensing situations and decisions, offering recommendations to support reliable and effective IPR management in line with the GÉANT IPR Policy.

...

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.

The SCA is currently based on Mend (described in more detail in Section 2.8), which identifies third-party components in projects and gathers information about their licences and security vulnerabilities. Mend uses a comprehensive database to address two critical aspects:

• Analysing components and their licences to reduce the risk of IPR infringement, which could have significant financial consequences, by supporting licence compatibility and compliance.
• Reporting security vulnerabilities, which complements SonarQube and extended code reviews.

The licensing team sets up the project in the Mend SCA tool, which generates reports on software composition and potential deviations from established policies. The visibility of reports and the created Mend project can be configured during the project setup or adjusted after results are obtained. The primary report, the “Risk Report”, details the software composition, including components, their licences, and related risks and vulnerabilities.

...

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.

...

Each Mend dashboard segment leads to detailed pages and reports with charts and tables. The dashboard presents the following information:

• Product Alerts – shows information about library (component) alerts generated for a product. The New Versions category indicates alerts for scanned libraries that are outdated. When such a library is detected, a new alert is generated, specifying the out-of-date library and its latest version.
• Security and Quality – displays the number of libraries with vulnerabilities by severity, the score of the most vulnerable library, the number of libraries with newer versions and vulnerabilities, and the count of “buggy” libraries.
• Libraries – provides detailed data on libraries, including name, licence, and per-product or per-project occurrences.
• Licence Analysis – gives an overview of licences used by product or project components, and the number of different licence types.

Administrators can customise system settings, manage user permissions, and configure integration with third-party components.

...

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:

1. Gather information (can be done using Mend).
2. Document (can be partially done using Mend).
3. Remediate.
4. Create licence-related artefacts (to ensure compliance).

These steps are preceded by preparatory activities and decisions, and should be followed by ongoing measures to ensure continuous licence management. Detailed information on the preparatory steps, the process itself, and long-term licence management activities within GÉANT is provided in the following sections. For further information, refer to GÉANT’s Open Source Licensing and Compliance training and GN5-1 Deliverable D9.4 Open Source and Licence Support Report.

...

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.

All components of a closely interconnected software development project should reside in a single repository, ideally on GÉANT GitLab. However, some developers may opt for GitHub or mirror their GitLab project there to gain increased visibility, collaboration opportunities, redundancy, and access to additional features and integrations. Additionally, while development and complex pipelines can remain within the private GÉANT GitLab environment, the final outputs can be publicly shared on GitHub.

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:

• Specify the current licence of your product (a packaged bundle of components) or project (a separate programme or component), if one is already in place.
• Record the copyrights for the contributions used.
• Request software composition analysis (SCA) and software licence analysis (SLA) via GÉANT Jira.
• Scan the project codebase, producing an inventory of components and their licences through the SCA service (the service will set up the SCA project, scan the codebase, and deliver an SCA report).
• Interpret the SCA outputs and findings.
• If ambiguities or complex situations arise or advanced support is needed, proceed with the SLA service for additional assistance.
• Further analyse and document dependencies and licences.
• Based on the SCA report and any additional security or vulnerability reviews, review and update the inventory of components, identifying:
  • Vulnerable open source components that should be removed or replaced.
  • Outdated open source libraries that need updating.
  • Confirmed licences for the components used (in-licences).
• The review may also clarify ambiguities or doubts:
  • The SCA tool may not properly identify a licence or may report some licences as suspect or ambiguous.
  • Information about a licence may be false, unclear, or contradictory.
  • Some licences may be recognised by multiple names.
  • Some permissive licences (BSD, Artistic, etc.) have unnumbered variants or are sometimes edited by software authors.
  • The applicability of “or later” clauses may be unclear or wrongly declared by editing the original licence text.
• Document all findings through reports, UI displays, and data exports.
• Consult the licensing team and the IPR Coordinator, who will help determine the appropriate licence to apply. Tools like JLA or choosealicense.com can help you in this process.
• Select an appropriate licence – The document Open Source Licences Used in GÉANT provides insights into OSS licences and their relationships. Reading it improves understanding of OSS licences and helps in selection, but the final decision must be made with the IPR Coordinator after the SCA scan.
• Document decisions – Some licences may be further refined during remediation and decision-making, but you should record the reasoning behind licence selection, detected issues, and how they were or will be addressed. The IPR Coordinator’s reasoning and approval should also be documented.

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.

Remediation actions may include:

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

• Provide a LICENSE file
  • Clearly state the selected OSS licence by placing a LICENSE file in the root directory.
  • Ensure the licence text matches the official version exactly. MIT, BSD, and ISC require copyright information to be included in the LICENSE file.
  • When a LICENSE file is present, header comments in source code files (with licence, copyright, and disclaimers) are generally unnecessary, except in special circumstances.
• Declare licence options if available and used.
  • Some licences offer options that must be explicitly stated.
  • Options may include accepting later versions of the licence or relicensing under specific licences endorsed by the original licence.
  • Licence options are typically declared in the README file.
• Declare the licence in project documentation, on the website, and in the repository UI.
  • Update project documentation to reflect the selected OSS licence.
  • Use any available repository UI features to declare the licence.
  • If integrating with other systems or package managers (e.g., npm or PyPI), you may need to specify the licence using its SPDX identifier in the project’s metadata file (e.g., package.json or pyproject.toml)
• Document the project licence in the GÉANT Software Catalogue and IP Register.
  • The Software Catalogue allows for declaring the licence on the project home page.
  • The IPR Coordinator manages the GÉANT IP Register.
• Provide a copyright notice.
  • Add a copyright notice for the project in a COPYRIGHT file, including funding information.
  • Include copyright information for third-party components in compliance with their licences, listing each component’s name, year, and copyright holder.
• Produce a README file containing licence and copyright information.
  • Include project licensing information in the README file, specifying the licences of used components if necessary.
  • Provide instructions for accessing the full licence text if not provided in the LICENSE file.
  • Briefly explain the licence’s implications for users and contributors.
  • If licensing badges are available, add one to the README file to clearly communicate the project’s licensing information.
• Document code modifications as required by the licence.
  • A history of changes may need to be documented, depending on the applied licence.
  • If the modified software or component has a CHANGELOG file or equivalent, extend it with details of your changes, preserving its format.
  • Check the licence text or summaries, such as those in Open Source Licences Used in GÉANT to determine whether documenting code modifications is necessary.

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

• Integrate licence-related checks into the build process.
  • Incorporate SCA and other licence-related tools into the build process. This can be at least partially automated by integrating dependency and licence checks into CI/CD toolchains. The Mend service provided by GÉANT or other tools can identify dependencies and their licences or verify compliance. Setting up an “allowed licences” policy in Mend ensures licence violations are detected early.
  • Some tools, such as the License Maven Plugin, can generate a list of dependencies and their licences, download licence files, check, update, or remove licence headers in source files, and update (or create) the main project licence file.
  • Verify and review tool outputs, as they are not foolproof.
• Establish continuous monitoring and compliance checks.
  • Stay informed about changes to the chosen OSS licence.
  • Review the potential impact of any licence updates on your project.
  • Establish processes for continuous compliance checks, repeating SCA and SLA as needed for new dependencies or licences, to ensure licensing obligations are met.
• Perform regular audits of licence-related artefacts.
  • Conduct regular audits to ensure the project’s licence-related artefacts are accurate and up to date.
  • Promptly resolve any discrepancies to maintain legal clarity and compliance. Delays are likely to complicate resolution.
• Seek legal advice when necessary – In complex licensing situations, seek advice from the IPR Coordinator to ensure proper interpretation and compliance.

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:

• Permitting users to choose between the original licence version or any later version – This allows users to choose between the original licence version or any later version approved by the licensor. Such relicensing can be interpreted as licence-endorsed open-ended multi-licensing. For example, a statement specifying that a particular GPL licence version is required is typically placed in the README file. You can use the whole phrase offered by the GPL: “This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version”, or simplify it to “This software is licensed under GNU General Public License version 3 or any later version”. If the licence notice ends with “version 3” or “version 3 only”, only GPL 3.0 applies. If no version is specified, the recipient can choose any published version of the licence. The notice can even specify that a proxy can decide which future versions of the GPL can be used, although this option is rarely used. The same applies to LGPL, with “GNU Lesser General Public License” replacing “GNU General Public License.”
• Relicensing under a different licence – Some licences allow relicensing under a secondary licence endorsed by the original one or chosen by the licensor. For example, the EPL 2.0 notice that states “This program and the accompanying materials are made available under the terms of the Eclipse Public License 2.0, which is available at https://www.eclipse.org/legal/epl-2.0/.” means the software can only be used with EPL 2.0. However, a Secondary License may be introduced, allowing recipients to comply with either the EPL or the Secondary License, such as GPL 2.0 with Classpath-exception: “This Source Code may also be made available under the following Secondary Licenses when the conditions for such availability set forth in the Eclipse Public License, v. 2.0 are satisfied: The GNU General Public License (GPL), version 2 with Classpath-exception.” Any licence granting rights at least as broad as those under the EPL can be declared as a Secondary License. Adding the latter clause is effectively relicensing, and all copyright holders must agree to such a licence change. For MPL 2.0, its licence notice: “This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at https://mozilla.org/MPL/2.0/.” allows most GPL licences as Secondary Licenses, unless the licensor prohibits this by adding “This Source Code Form is ‘Incompatible With Secondary Licenses’, as defined by the Mozilla Public License, v. 2.0”.
• Extending certain rights beyond standard terms – Certain rights may be extended beyond the standard terms of the original licence, such as allowing commercial use without open sourcing modifications, providing a patent grant, or permitting the distribution of proprietary versions. These extensions should be clearly articulated, specifying that they supplement the original licence without replacing or altering its conditions. For example, Apache 2.0 states that the software is by default provided “AS IS,” but additional warranties can be agreed upon in writing.
• Placing limitations on certain uses or modifications – Some licences may allow the addition of conditions, such as restricting non-commercial use, requiring modified source code availability, or ensuring compatibility with the original version. Any limitations should be added carefully, ensuring their compatibility with the original licence. For example, Apache 2.0 allows additional restrictive clauses, but licensors should avoid introducing restrictions that contradict or undermine open source principles.
• Choosing the jurisdiction governing the licence – With the EUPL, the licensor can choose the jurisdiction under which the licence is governed, specifying the applicable legal framework.

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:

• Extending README, COPYRIGHT, and NOTICE files to explicitly declare and credit dependencies or reused code, clearly stating their licences.
• Retaining existing licence and copyright files and notices to ensure full original documentation and compliance with respective licences.
• Attributing and documenting any modifications to reused code, updating modification history and the contributor list as necessary.
• Staying informed about updates to licences for used code, as they may impact compliance requirements and require adjustments.

Eclipse- and Mozilla-licensed dependencies (direct or transitive) require explicit reference in project documentation.

Using code under Apache 2.0 with a different licence for your project involves specific obligations:

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

The README file should provide guidance and instructions related to the software, covering:

• Purpose or intent, which authors may sometimes omit as it may seem obvious to them, and key features.
• Scope, supported settings and environments, requirements or constraints of the application, which may not be apparent to new users.
• Installation and configuration.
• Usage.
• Documentation.
• Roadmap and known issues.
• Community contributions.
• Funding, acknowledgements, dependencies, and tools used.
• Software licence and copyright.

The licence notice and details on licence options (such as “or later”), also possibly included in the NOTICE file, should be mentioned in the README. Markdown examples for stating the licence are:

...

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.

...

If you are creating a COPYRIGHT file in markdown format, Dillinger, StackEdit, or other online markdown editors can be helpful. However, this is unnecessary if the copyright information is short and simple.

An example of a COPYRIGHT.md file with a disclaimer that can be adapted to your needs is provided below:

...

In addition to the COPYRIGHT file, the EU emblem and funding statement must be prominently displayed in the README, project documentation, the application’s “About” page or pop-up, 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. Their use must follow the guidelines outlined in the GÉANT IPR Policy, summarised as follows:

• Minimum emblem height is 1 cm.
• It must include the phrase “Co-funded by the European Union”.
• Alongside the EU emblem, funding information must be provided.
• The EU emblem should be used in conjunction with the name of the programme or fund.
  • For the GN5 project: “The GÉANT project is funded by the Horizon Europe research and innovation programme.”
  • For GN3 and GN4: “The GÉANT project is funded by the Horizon 2020 research and innovation programme.”
  • For developments spanning multiple programmes: “Horizon 2020 and Horizon Europe research and innovation programmes.”
  • Including the project phase, such as “GÉANT project (GN5-2)” is recommended for clarity and traceability.
  • The “Project IP was generated” paragraph in the COPYRIGHT file may need to be updated accordingly, e.g., to “GÉANT (GN4) project” and “Horizon 2020 research and innovation programme.”
• Use a non-serif font without effects.
• The text should be proportionate to the emblem’s size.
• The text should be in EU blue, black, or white, depending on the background.
• Ensure the text does not overlap with the emblem.

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:

• README
  • After the title with the software name, optionally list key attributes in bullet points.
  • Use subtitles to structure the content.
  • Briefly describe software purpose, motivation, usage context, and prerequisites.
  • Provide brief installation, configuration, and usage instructions. Screenshots are encouraged. Include key notes on user management, integration, and security.
  • Clearly state the licence in one line, noting if options like “or later” apply. Reference the LICENSE file or official licence URL.
  • Include copyright in a single line or paragraph, and refer to the COPYRIGHT file.
  • Mention the software’s origin or motivation.
  • Credit GÉANT and relevant parties, such as NRENs or external partners.
  • Include the EU logo and required text.
  • To keep the file short, refer to other files or documentation for further details.
• LICENSE
  • Confirm the licence with the GÉANT IPR Coordinator after ensuring component compatibility.
  • Copy the full licence text from the official source. Some licences include copyright placeholders to be filled.
• COPYRIGHT
  • Verify copyright and IPR details with the GÉANT IPR Coordinator.
  • Include the EU logo and required text. Host the logo as a static image in a controlled location.
• AUTHORS (Optional)
  • List authors and contributors, including contact details (email, ORCID, or repository ID). Optionally include their institutions and roles.
  • Optionally credit the GÉANT project phase, work package, or task while keeping copyright holders in the COPYRIGHT file.
• NOTICE (Optional)
  • Not necessary if all licence-mandated information is in the README.
  • Acknowledge third-party libraries, listing components, their licences, URLs, and copyrights.
  • Optionally mention tools used in the project.
  • Include mandatory notices for third-party components when required (e.g., for Apache 2.0 licensed components).
• CHANGELOG (Recommended, often mandatory)
  • Maintain a concise history of changes. This is a requirement for many licences and is good practice.
  • Use a standard format.
  • For the first version, simply note it as the initial public or production release.

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