...

...

1 Introduction

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

...

Note that this document does not delve into the specifics of individual open source software (OSS) licences, software composition analysis (SCA) tool usage, licence compatibility and the remediation of licence conflicts. This is intentional, recognising that some developers may not need to grapple with these complex and resource-intensive matters, while many others could be shielded from these issues through the support of the software licensing team and their services. In cases where such details are required, they are covered in separate guides provided by the software licensing team. For comprehensive information about individual licences, licence compatibility and the nuances of licence selection, please 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 frequently 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 Significance of Open Source Software and Licensing

These are the key factors related to the use of open source software (OSS):

...

In addition to these general OSS-related factors, there are several requirements and recommendations applicable in the GÉANT context, some of which are implied by its IPR Policy [GN_IPRPolicyIPR Policy] (also see GÉANT Resources – Intellectual Property [GN_Resources_IPGÉANT Resources – Intellectual Property]):

• Every GÉANT software project should select and apply a suitable OSS licence that fits the needs of the software development team and those of the user community.
• Start the licensing process early, to make it easier to set up a licence and maintain compliance.
• The chosen licence must be compatible with licences of all used components so that the IPR and licensing risks on GÉANT are eliminated.
• It is preferable to place the OSS source code in a public and versioned code repository with a clear indication of the used licence.
• Copyright information must indicate GÉANT’s involvement and support. This information underscores that work was conducted within the GÉANT project or received support from it and identifies who authored the produced software.
• Assess the used components and software by applying common software quality and trustworthiness checklists, to ensure the components used and software produced are reliable. Examples: TinyMCE – Open source software evaluation checklist [TinyMCE_OSSEC], Red Hat – Checklist for measuring the health of an open source project [RedHat_COSP TinyMCE – Open source software evaluation checklist], EURISE Network Technical Reference – Software quality checklist [EURISE_SQC TinyMCE – Open source software evaluation checklist, Red Hat – Checklist for measuring the health of an open source project, EURISE Network Technical Reference – Software Quality Checklist].
• Use software composition and license analysis (SCA and SLA) services that conduct related reviews and audits designed to help determine the OSS licence appropriate for the software and ensure licence compliance. Identifying and addressing vulnerabilities in the software that may be detected by the SCA improves its quality and benefits the broader community your team contributes to.
• Set up contribution, communication and governance workflows that ensure compliance with the software’s licence.
• Adhere to the standards of the domain community in software development, licensing, provision of metadata about software, documentation, registration in relevant community registries, citation and promotion of software.
• If applicable, enable and advise on the citation and referencing of software in scientific papers, presentations, tutorials, etc., ensuring that these references are unambiguous and permanent.

2.2 OSS Conditions

Selecting the licence is not straightforward, and it is a task most developers would prefer to avoid. While the GÉANT IPR Policy [GN_IPRPolicyIPR Policy] favours permissive licences and even names some, such as MIT, BSD and EUPL, the actual choices available are limited by the licences of the core components of the software or the frameworks it utilises. Therefore, it becomes meaningful for developers to delve into specific licences, their implications and compatibility only when the constraints are known and when it becomes necessary within the licensing process, with the assistance of the licensing team and the GÉANT IPR Coordinator.

...

Figure 2.1: OSS conditions from JLA – Find and compare software licenses [JLA Joinup – JLA - 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 via Mend, the tool used for SCA (described in Section 2.7). However, there is a limited set of licences that are frequently used in GÉANT or are common sources of compatibility issues. Figure 2.2 presents an orientational diagram describing the relationships and compatibility of these licences. Please note that there are two distinct interpretations of licence compatibility. A less restrictive, more commonly used and symmetrical type of compatibility indicates that components with two distinct licences can be used in the same project, which may be achieved by relicensing one or both of them or by selecting a third licence for the encompassing product. A more restrictive and direct, yet asymmetrical, interpretation determines whether a component under one licence may be used in software under another licence. Although the first interpretation is dependent on the second, various types of “use” by the produced software exist and sometimes can be altered by modifying the system architecture to allow the integration of a problematic component without needing to change the licence of the created software.

...

OSS licences are described in several documents produced by the licensing team. For additional details, please refer to the following guides: Reference information about OSS licences and tools [Wiki_OSSL_RefInfoReference information about OSS licences, OSS licences and licence selection], OSS licences and licence selection [Wiki_OSSL&LS OSS licences and licence selection] and Important licences for licence selection [Wiki_ImportantLicencesImportant licences for licence selection].

2.4 GÉANT IPR Policy

The GÉANT IPR Policy applies to IP generated within the GÉANT project, including open source software. It also provides related recommendations and rules which are made concrete in the present document through practical and actionable instructions. The policy is available at [GN_IPRPolicyIPR Policy]. The IPR Policy seeks to establish a framework for the intellectual property (IP) generated by the GÉANT project. It applies to all project participants of the GN5-n project and any other EC-funded GÉANT projects and provides practical and useful guidance in the area of IPR. Most importantly, the IPR Policy aims to establish a cooperation modus operandi and proper protection as well as fair use with regard to any IP created by GÉANT projects. The IPR Policy also aims to apply the principles of findability, accessibility, interoperability and reusability (FAIR) in the use of the project IP. The IPR Policy has been binding from the moment of its approval by the General Assembly and as of the start of the GN5-1 project (January 2023).

...

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

2.5 Licence Governance in GÉANT

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

...

The performed analyses, when conducted for a module that is an add-on for an externally developed open source platform, may also benefit the broader community of the software platform the development team used or contributed to, by assessing the overall status of its licensing and the security of its components. This is a side effect of the analysis of software produced by GÉANT’s software development teams, as it transitively includes an analysis of involved components and licences.

2.6 Software Composition Analysis (SCA) Service

This service assists software development teams by establishing a project within an SCA tool and providing valuable insights into external components. It is suitable for one-time software analysis but also continuous monitoring, identifying third-party components used and their licences, and offering information about potential IPR infringements and security vulnerabilities. The service can be used in combination with other software review services or performed exclusively. Repeated analyses can determine how changes in software and dependencies impact licence compliance and identify new or pending vulnerabilities. For ongoing monitoring, the produced analysis setup can be integrated into the project’s continuous integration platform.

...

A summary of the SCA service is available in Software Reviews [Wiki_SWReviews Software Reviews], with additional details in the Client Guide for Software Composition Analysis (SCA) [Wiki_CGSCA Client Guide for Software Composition Analysis (SCA)].

2.7 Mend SCA Tool

Mend is an online tool provided through a service purchased by GÉANT for open source licence and security compliance [Mend_SCA Mend short guide for end users]. It is designed for in-house use by the customer and does not offer direct consultancy by legal experts. Mend can detect software components, identify their open source licences and uncover vulnerabilities. It can seamlessly integrate with the development environment, building a pipeline to detect open source libraries with security or compliance issues. Mend reports severe software bugs, problematic licences, new versions and available fixes. It simplifies the management of open source libraries and the detection and remediation of compliance and security issues. It builds an inventory of software components by detecting declared dependencies, matching them with a rich database providing licence information, warnings about outdated or risky open source libraries, and details of associated security vulnerabilities and issues. The provided licence information includes licence type, risk level, handling of patents, summary descriptions, and excerpts from original licence texts, etc.

...

It should be noted that other tools can be used in software composition and licence analysis; some are listed in Other software composition analysis (SCA, software inventory) tools [Wiki_OtherSCAToolsReference information about OSS licences].

2.8 Software Licence Analysis (SLA) Service

Software licence selection involves choosing the appropriate licence for distributing and using the software. This decision is crucial as it defines the terms under which the software can be shared, modified and distributed. The selection process considers the project’s goals, the developers’ preferences, the desired level of collaboration, and the constraints imposed by licences of dependencies and other sideground IP. As touched on in Section 2.2, the most restrictive licence is often the only one compatible with all those present. However, this is not necessarily the case, as when permissive licences have been used. Furthermore, at times, a licence that is compatible with the most, or with all, may not even be among those that are present. Selection of a subsuming licence should also consider the effort needed to remediate detected licence compatibility problems, involve assessing the impact on the software's ecosystem, and ensure compliance with legal, regulatory and funding requirements. The chosen licence plays a pivotal role in fostering a collaborative and transparent development environment while providing clarity on how others can use and contribute to the open source project. All of the above illustrates the complexity of licence selection, and explains why the SLA service was designed and is needed.

...

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

2.9 Licensing Process, Decisions and Artefacts

The typical steps for licence management include:

...

These are preceded by a number of preparatory activities and decisions, and should be followed by measures that ensure long-term, continuous licence management. Details of the preparation required for the process, the above steps, and ongoing licence management activities in GÉANT are provided in the following sections. (For further information about the four steps, see GÉANT’s Open Source Licensing and Compliance training [OSLC_TrainingOpen Source Licensing and Compliance].)

Preparation

• Decide on the software name, grouping of subprojects and use of available contributions.
• New projects might require a proof of concept or prototype to identify and validate key components.
• Gather preexisting information and documentation.
• Consolidate the project’s components in repositories into a single project or clarify their relationships if it is more advantageous for them to remain separate.
• Make sure your software is on GÉANT GitLab [GN_GitLabGÉANT GitLab ] or GitHub [GitHub GitHub].
• Register the software project in the GÉANT Software Catalogue [GN_SC GÉANT Software Catalogue].
• Internally address authorship and copyright matters.

...

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

One or Several Projects?

When handling multiple projects, it is crucial to determine and specify which dependencies should be incorporated into the SCA analysis. This decision may also depend on the relationship between components and their respective responsibilities. For example, whether one project serves as a subproject managed by the same team or may be intended to function as a module within a larger project overseen by different developers. If so, there may be a need to comprehensively analyse both projects, including their dependencies and, potentially, their source code, even if it is kept in separate repositories.

...

The licensing team can also provide ideas about grouping features or products within the project and branding for the software. This will be done strictly from a practical technical and licensing perspective. If you need a more authoritative consultation on the product or service that you are developing, please contact the GÉANT Marcomms Team at marcomms@geant.org.

Information Gathering and Documenting

Document copyrights, findings about licences, and decisions:

...

For additional details about the licence selection process and related recommendations, refer to the OSS licences and licence selection guide [Wiki_OSSL&LSOSS licences and licence selection guide] and OSS Licences in GN4-3 and GN5-1 GÉANT Project: Current State and Recommendations white paper [Wiki_OSSLWPGÉANT OSS licences whitepaper].

Remediation

During this step, the goal is to identify and resolve licence conflicts and obligations. Resolving these conflicts may involve trivial or highly complex actions, such as removing or replacing dependencies, developing substitutes, or refactoring existing code.

...

• Choose a product/project licence (subsuming licence) compatible with key dependencies.
• Perform initial easy-to-achieve improvements:
  • Remedy vulnerable open source components.
  • Update outdated open source libraries (where possible).
  • Ask component authors to clarify their licence or to relicense.
  • Pay for the required proprietarily licensed software.
  • Choose among dual licences of components.
• Identify remaining incompatible licences.
• Decide what to do with components that use these licences:
  • Remove (component and corresponding functionality) if not necessary.
  • Replace with an existing equivalent.
  • Move to server-side (central service).
  • Write your replacement.
• Accept some risks.
• Internally document dependencies, their licences, responsibilities, decisions made and performed remediations.
• If needed, repeat the SCA and the above-listed steps.

Creating Licence-Related Artefacts

A series of steps needs to be performed to ensure OSS licence compliance. Some details related to the key artefacts listed below are included in Section 3 Complying with a Selected Licence.

• Provide a LICENSE file.
  • Clearly state the chosen OSS licence for the project by including a suitable LICENSE file in the root directory of the project repository.
  • Ensure the licence text precisely aligns with its official text. Some licences require the inclusion of copyright information.
  • When a LICENSE file is present, header comments in source code files (with licence and copyright information and disclaimers) are unnecessary, except in special circumstances.
• Declare the licence in project documentation, website and repository UI.
  • Review and update project documentation to reflect the chosen OSS licence.
  • Utilise any available repository UI features to declare the project’s licence.
• Declare the project’s licence in the GÉANT Software Catalogue and IP Register.
  • The Software Catalogue has introduced a feature to declare the licence on the project home page.
  • The IPR Coordinator maintains the GÉANT IP Register.
• Provide a copyright notice.
  • Add a copyright notice for the project work in a COPYRIGHT file.
  • Include copyright information for components developed by others in compliance with their licence requirements by including 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, detailing the licences for used components where necessary.
  • Provide instructions for access to the full licence text if not provided in the LICENSE file.
  • Briefly explain the implications of the licence for both users and contributors.
  • If licensing badges are available, add a licensing badge to the README file to visually communicate the project’s licensing information and make it easily recognisable.
• Document code modifications as required for the licence.
  • Providing a history of changes may be required by the applied licence.
  • If the modified software has a CHANGELOG file or similar, extend it with a description of changes using the same format.
  • To learn whether documenting modifications to code in a CHANGELOG file or elsewhere is required, check the licence text or licence summaries such as those in Important licences for licence selection [Wiki_ImportantLicences Important licences for licence selection].
• Declare the use of licence options if available for the chosen licence.
  • Some licences provide options that should be explicitly stated if they are applied.
  • Options may include accepting later or future versions of the licence or relicensing to specific licences endorsed by the original licence.
• Document dependencies, their licences, notices and copyright information.
  • Document the licences of directly included dependencies in a dedicated dependencies file or within the project documentation.
  • Include copyright information for these dependencies and links to official licence texts.
  • For source code components in subfolders, store their licences, copyright and notices files there.
• Document licence adherence, contribution and updating.
  • Provide clear guidance for users and contributors on adhering to licensing requirements in a README, CONTRIBUTING or CODE_OF_CONDUCT file. Examples of this are the guidelines provided by FileSender [FileSender_Contribfilesender/CONTRIBUTE.md] and Atom [Atom_Contribatom/CONTRIBUTING.md].
  • Provide contribution and copyright instructions and rules, even if external contributors are not expected.
• Prepare and apply a Contributor License Agreement (CLA) if necessary.
  • If the chosen licence necessitates a CLA, establish it to define terms for contributions and ensure understanding and adherence.
  • For some licences, suitable CLA forms are available, and the appropriate one needs to be selected.
  • Clearly communicate (in a README or CONTRIBUTING file) the process for contributors to sign CLAs, ensuring legal clarity for all involved parties.
  • A CLA is placed in a file named CONTRIBUTOR_LICENSE_AGREEMENT, CLA or as a part of the broader contribution guidelines in the CONTRIBUTING file.
• Establish a licence notification mechanism – Implement a notification mechanism to alert contributors and users about the project’s licensing terms and their updates. This can include prompts during the build process, clear notifications in the project repository, use of the project’s general notification channels, and providing licence and copyright information through the application UI.

Continuous Licence Management

The goal of long-term, continuous licence management is to integrate licence management into the regular software development lifecycle.

...

GÉANT software best practice BP-B.6: Manage sideground IPR [GN_BP_B6BP-B.6: Manage sideground IPR] recommends dealing early with the preexisting and external IP and repeating the process periodically.

2.10 Licences and Tracking of Documentation, Data and Other Works

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

...

The original assets distributed with software are best kept under the same licence when they do not have to be individually tracked.

3 Complying with a Selected Licence

This is the primary section for developers after selecting a licence. It facilitates preparatory work and internal compliance checks before reviewing licence adherence with the licensing team, and provides essential information for developers seeking to address licensing issues independently. Additional templates and links to example files with GÉANT-approved content will be provided as they become available from software projects.

...

• Project licence options.
• Placement of information.
• Copyright and licence notices in source code.
• Complying with licences of used code.
• README file.
• COPYRIGHT file.
• Acknowledgements in AUTHORS, NOTICE and README files.
• CHANGELOG file.

3.1 Project Licence Options

The applied licence may offer the option to apply additional conditions or permissions. These additional statements help clarify how others can use, modify and distribute the software. If the licence used offers some licensing options, these options and their declaration are explained in the licence text. Some common software licence options that code owners may explicitly state include:

...

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

3.2 Placement of Information

The README file is the primary starting point and is, therefore, emphasised by GitHub. It includes a description of the software along with licensing information. Hyperlinks in README files can connect users to external resources such as the full licence text, project website or funding details. In online platforms such as GitLab, GitHub or the GÉANT Software Catalogue, relevant information may be linked in the project’s profile or description.

...

Modules located in subfolders may have their own licences. They should include a separate LICENSE file in each subfolder containing a module with a different licence from that of the main project and provide any necessary attribution or copyright notices for that module. It is crucial to provide this information for subprojects or folders if it differs from what is stated in the main project or the root folder. If their other important information is also different, it should be provided in their respective folders in the same manner as for the main project.

3.3 Copyright and Licence Notices in Source Code

A simple copyright line and a licence indicator may be placed in the header of every source file, as shown in the example below; replace the text in angle brackets with the appropriate information. While not mandatory, these notices can be useful if you anticipate that individual project files may be accessed, reused or modified independently, and you are concerned that users or modifiers might overlook or not receive the project-level copyright and licence information.

/* Copyright (c) <Year> <Copyright Holder>
 * This code is released under <Licence Name>. See file LICENSE or visit <Licence URL>
 * for full licence details.
 */

3.4 Complying with Licences of Used Code

In addition to meeting your project’s licence requirements, it is imperative to address the obligations imposed by licences governing dependencies or reused code, encompassing associated copyright and patent rules. This necessitates continuous attention throughout the development process. The essential actions are as follows:

...

• Include the original copyright notice.
• Provide a copy of the Apache licence.
• Describe any significant changes made to the original code.
• Maintain a NOTICE file with attribution notes (either the original or a new one with your additions).

3.5 README File

The README file should include basic information about the software. It should clearly and concisely state the licence and copyright, typically in one short line each. It should also state the origin of the development, give credit to GÉANT and refer to COPYRIGHT and LICENSE files for further details.

...

A useful README template is available at Make a README [Make_a_READMEMake a README]. After providing a sample markdown, it offers a more detailed section titled “Suggestions for a good README”.

3.6 COPYRIGHT File

Software is protected by copyright law. Various OSS licences have different requirements under which software developers grant other users specific rights while retaining copyright. Developers must clearly indicate copyright in addition to the licence.

...

Contact the IPR Coordinator if you have any questions about specific copyright. Licence text must be prepared for every software you are developing, and the selected licence will depend on the licences used for components, while the copyright statement might vary depending on the institutions involved.

3.7 Acknowledgements in AUTHORS, NOTICE and README

An open source project typically results from the collective efforts of various developers or teams who have made valuable contributions. It is essential to acknowledge their contributions and efforts.

...

It is your responsibility to review and comply with the respective licences and attribution requirements for these components, as stated in their respective files or documentation, as the project’s dependencies evolve. Acknowledging contributions, dependencies and tools is not only a gesture of appreciation but also a way to foster a collaborative and supportive open source community.

3.8 CHANGELOG File

Some licences require a history of software changes to be maintained and provided. It is commonly in a file named CHANGELOG, CHANGES or HISTORY, placed in the root directory of the project. Some licences have explicit naming requirements or even requirements on the content of entries. The history should provide a chronological summary of new features, significant changes, additions, bug fixes and other modifications, serving as a record of changes made to a software project over the project’s releases and time. This helps users and contributors understand what is new and different in each release and understand the evolution of a software project. It also assists with troubleshooting and identifying potential upgrade issues. One common approach is to generate the history of changes by concatenating release notes, the creation of which may also be facilitated with a tool using commit messages.

...

The project’s documentation should explain how users and contributors can check the file for release notes.

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 [OSLC_Traininghttps://e-academy.geant.org/moodle/course/view.php?id=214]
• Webinar: License Dependencies Analysis with WhiteSource [LDAwithWS_Webinarhttps://e-academy.geant.org/moodle/course/view.php?id=220]
• Training course: Introduction to Open Source Licensing and Compliance 2023 [IntroOSLC_Traininghttps://e-academy.geant.org/moodle/course/view.php?id=478]
• Infoshare: Software Licences Management in GÉANT [SWLMinGN_Infoshare Infoshare: Software Licences Management in GÉANT]

4.3 Further Reading

• GÉANT IPR Policy [GN_IPRPolicy https://about.geant.org/wp-content/uploads/2022/06/GEANT-_IPR_Policy_2022.pdf]
• OSS licences and licence selection [Wiki_OSSL&LS OSS licences and licence selection] – an introductory guide
• OSS Licences in GN4-3 and GN5-1 GÉANT Project: Current State and Recommendations [Wiki_OSSLWP Open Source Software Licences in GN4-3 and GN5-1 GÉANT Project: Current State and Recommendations] – project-oriented white paper for GÉANT participants. A guide on licence selection with an appendix describing the OSS licences most frequently used by analysed projects
• Software licence selection and management in GÉANT [Wiki_SWLS&MCopy of Software Licence Selection and Management in GÉANT] – a maintained online version of this guide.
• Important licences for licence selection [Wiki_ImportantLicences Important licences for licence selection] – descriptions and compatibility of most frequently used licences in GÉANT
• Reference information about OSS licences and tools [Wiki_OSSL_RefInfo 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 [GN_BP_B6 GÉANT software best practice BP-B.6: Manage sideground IPR]
• OSI Approved Licenses [OSI_Licences https://opensource.org/licenses/]

4.4 Services

• GÉANT Software Licence Management (homepage) [Wiki_SWLM GÉANT Software Licence Management (homepage)]
• Jira requests for SCA and SLA [Jira_RSWR https://jira.software.geant.org/servicedesk/customer/portal/2/create/55]
• Software Reviews [Wiki_SWReviews Software Reviews – GÉANT Software Development Support] – GÉANT Software Development Support
• GÉANT Mend, with login via GÉANT SSO, special permissions may apply [GN_Mend https://app-eu.whitesourcesoftware.com]
• Accessing Mend and visibility levels [Wiki_MendAccess Accessing Mend and visibility levels] – visibility of Mend scan results
• Mend short guide for end users [Wiki_MendGuide Mend short guide for end users] – also explains the interpretation of Mend reports
• The Risk Report [Mend_TRR https://docs.mend.io/bundle/sca_user_guide/page/the_risk_report.html] – short Mend report guide for end users
• GÉANT GitLab [GN_GitLab https://gitlab.software.geant.org]
• GÉANT Software Catalogue [GN_SC https://sc.geant.org]

References

Glossary

...