This work  is licensed under  CC BY-SA 4.0

...

...

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.

...

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.

...

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.

...

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.

...

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

...

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.

...

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.

...

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

...

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.

...

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:

...

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

...

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