...

Instead of this page, please read the enhanced PDF version. Its textual improvements will soon be reflected in this Wiki, making it easier for you to comment or contribute.

Table of Contents

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.

This guide is divided into two main parts.

The first part, Essential Aspects and Elements of Software Licensing, provides software developers with crucial insights into software licence selection and related processes, highlighting the tasks they need to perform and the collaborative procedures required to engage with licensing support and related services. This part provides a straightforward overview of the elements necessary for efficient preparation, information gathering and conducting proper software licensing.

The second part, Complying with a Selected Licence, offers a detailed implementation description of how to implement the selected licence from a developer’s perspective, providing instructions facilitating the execution of the licensing process. It furnishes gives in-depth information alongside simple but critical guidance on creating essential licensing artefacts.

Notably, 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 at this guide’s endin 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):

• Our work increasingly relies on OSS. Developers, National Research and Education Networks (NRENs) and GÉANT widely and increasingly use, adapt, create and endorse OSS.
• In a

These are the key concerns related to the use of OSS:

• Our work increasingly relies on Open Source Software (OSS). Developers, NRENs and GÉANT largely and increasingly use, adapt, create and endorse OSS.
• In a broader context, the ICT and R&E communities value OSS for its cost-effectiveness, transparency, collaboration, customisability, vendor independence, longevity, security, educational value, compatibility, ethical and philosophical values, accessibility and more (detailed below).
• OSS licences ensure the licensed software remains free, prevent appropriation and help avoid abandonment.
• Declaring a software licence makes it easier to select what other code and libraries can be incorporated into the project and how others can use, adapt and contribute to the software.
• Licensing considerations are critical when there is a distribution or sharing of software, as OSS licences come with specific conditions.
• Declaring a licence and licence compliance are also essential for legal reasons and software usability, ensuring better transparency and collaboration.
• Adhering to the requirements of applied licences (including those of dependencies) enhances the transparency of the software project within the wider community.

Open source software holds significant importance is important in various domains, including technology, research and education, business and government. It plays a crucial role in promoting affordability, transparency, collaboration, and technology 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.

1. Cost-Effectiveeffective – Open source software is often free to use, significantly reducing software acquisition and licensing costs for individuals, businesses and organisations. This cost-effectiveness is especially critical for smaller businesses, educational institutions and governments with budget constraints.
2. Transparency – Open source software 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 transparency is particularly important for software used in critical applications, such as cybersecurity and healthcare.
3. Community Collaborationcollaboration – Open source projects typically have large and diverse communities of developers and users who collaborate to improve the software. This collaborative approach results in rapid bug fixes, updates and feature enhancements. It also fosters innovation and the sharing of knowledge.
4. Customisation – Users of open source software have the freedom to modify and customise the code to suit their specific needs. This flexibility allows businesses and individuals to adapt software to their unique requirements, giving them a competitive edge.
5. Vendor Independenceindependence – With proprietary software, users are often locked into a single vendor’s ecosystem. Open source software reduces vendor lock-in, as users have access to the source code and can switch service providers or modify the software as needed.
6. Longevity – Proprietary software may be discontinued by the vendor, leaving users without support or updates. Open source software tends to have longer lifespans, as the community can take over maintenance and development if the original project loses momentum.
7. Security – While open source software is not immune to vulnerabilities, its transparency allows a global community to continually audit the code for security flaws. When vulnerabilities are discovered, they can be fixed quickly. In contrast, the security of proprietary software depends solely on the vendor’s resources and priorities.
8. Education and Learninglearning – Open source software encourages learning and skill development. Students and aspiring developers can study, modify, and contribute to open source projects, gaining practical experience and exposure to real-world software development.
9. Compatibility – Open standards and open source software often go hand in hand, promoting compatibility and interoperability between different software and systems and reducing barriers to data exchange and collaboration.
10. Ethical and Philosophical Valuesphilosophical values – The open source movement is rooted in values such as transparency, collaboration, and the idea that software should be a public good. Many individuals and organisations choose open source software to align with these values and principles.
11. Global Accessibilityaccessibility – Open source software is accessible to users worldwide, regardless of location or economic status. This accessibility promotes digital inclusion and levels the playing field for all users.

In addition to the these general OSS-related concernsfactors, there are some 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 your the needs of the software development team and those of the user community.
• Starting Start the licensing process early makes , 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 use reliable ensure the components used and produce software produced are reliable software. 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 licensing license analysis services (SCA and SLA and SCA) services that conduct related reviews and audits designed to establish open source licences help determine the OSS licence appropriate for the software and ensure licence compliance. Identifying and addressing vulnerabilities in your the software that may be detected by the SCA improves its quality and benefits to 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.

For example, a developer might have to use the Apache licence if the framework they are using or relying on supports it. Alternatively, if there are unavoidable GPL or AGPL dependencies, they may opt for a compatible and licence, which is often the most restrictive of the licences involved. Conversely, in cases where there are no preexisting limitations, as with an unconstrained new project or when all essential components use permissive licences, the development team can choose one or several candidate licences based on their key features related with regard to code sharing and modification (where copyleft licences are more stringent), relicensing (also referred to as sublicensing, which the team may be desired wish to be prohibited prohibit or allowedallow), and the way patents are handled (waived, protected or ignored). (For further information about software selection, see Section 2.8 Software Licence Analysis (SLA) Service.) Various licence conditions are often classified as:

• Rights/permissions – what you can do.
• Requirements/obligations – related to behaviour and the provision of compliance artefacts such as copyright, disclaimer, licence text, notices, relevant source code, build and installation instructions, etc.
• Restrictions/limitations – limits of use or what you must not do.
• Other characteristics – typical uses, classification, compatibility, legal features, origin, community, endorsement and more.

These features are further differentiated in various models, one of which is provided through the EU Join-Up Licence EC’s Joinup Licensing Assistant tool (JLA - – Find and compare software licenselicenses [JLA]), which, when choices exist, greatly facilitates the selection of the most appropriate licence aligned with the developers’ strategy and user community when choices exist.

Figure 2.1: OSS Conditions from 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. Here is . 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.

Figure 2.2: Relationships between software frequent OSS licences frequently used in GÉANT projects

OSS licences are detailed described in several documents produced by the licensing team. For additional details, please refer to the following guides: Reference information about OSS licences, OSS licences and licence selection and 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 guides].

2.4 GÉANT IPR Policy

The GÉANT IPR policy Policy applies to IP generated within the ProjectGÉANT project, including Open Source Software (OSS)open source software. It also provides related recommendations and rules which are made concrete in this the present document concretised through practical and actionable instructions. The policy is available here: Intellectual Property Rights (IPR) Policy Version 4.2. This at [GN_IPRPolicyIPR Policy]. The IPR Policy seeks to establish a framework for the Intellectual Property intellectual property (IP) generated by the ProjectGÉANT project. It applies to all project participants of the GN5 Project -n project and any other EC-funded GÉANT projects and provides practical and useful guidance in the area of IPR. Most importantly, this 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. This The IPR Policy also aims to apply FAIR (the principles of findability, accessibility, interoperability , and reusability (FAIR) principles in the use of the Project project IP. This The IPR Policy has been binding from the moment of its approval by the General Assembly and as of the start of the GN5 Project -1 project (January 2023). 

What is important for you from a software development perspective is that there is a Software Composition Analysis software composition analysis (SCA) tool that allows for a software scan to check and ensure verify the licences of used components and determine which licence shall be used.

Lack of complying Failure to comply with OSS licence terms can have significant legal and monetary consequences, hence due diligence is required. The IPR Policy emphasises the importance of IP protection, introduces the GÉANT IP Register where project results will be documented, and highlights the significance and necessity of having the code scanned with a Software Composition Analysis (an SCA ) tool to ensure licence compliance and compatibility. It also highlights the role of the IPR Coordinator in supporting project participants with the licence selection process.

To summarise the IPR Policy:

• All OSS licences [OSI_LicencesAll OSS licences] are allowed.
• The IPR Policy strongly recommends the selection of permissive licences.
• Copyleft licences (weak, strong or network protective) can be applied as necessary, in consultation with the IPR Coordinator.
• The IPR Coordinator provides the final recommendations and maintains the GÉANT IP Register.

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

2.5 Licence Governance in GÉANT

The goal of licence governance in the GÉANT Project 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 Licensing and Licence Support (OSLS), or simply software licensing. ItThe OSLS team:

• Helps those who prefer to invest in understanding and managing OSS licences, master the provided tools, and apply them.
• Offers knowledge and support to solution designers, developers and skilled promoters on licences and Intellectual Property Rights intellectual property rights (IPR).

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

• Software Composition Analysis composition analysis (SCA) – Technical and practical assistance for software development teams with managing software components and their software licences.
• Software Licence Analysis licence analysis (SLA) – Assistance to software teams in aligning their 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, namely SonarQube Setup Assistance and Extended Source Code Review [Wiki_SWReviewsSoftware review services]. Through SCA and SLA services, the licensing team ensures the handling of key licensing concerns by:

• Assessing the situation with licences of components and prior IP.
• Selecting an open source licence for the software project’s needs.
• Making sure the selected licence is compatible with the components’ licences.
• Ensuring compliance with the chosen licence.

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

GÉANT development and maintenance teams can contact the OSLS through the GÉANT Slack channel or via email. CA SCA and SLA services are requested by submitting a software review request to the GÉANT Jira Software Tools Help Desk [Jira_RSWR GÉANT Jira Software Tools Help Desk], which also serves to track the progress of the work on them. Several iterations of analysis and licence and dependency adjustments may be required to reach a satisfactory IPR status. The IPR Coordinator can be reached when assistance with licensing decisions is needed.

Our guides help with the licensing and services. For more information about OSS licences, read the FOSS OSS licences and licence selection guide first [Wiki_OSSL&LS OSS licences and licence selection]. Since the SLA service requires the software development team’s involvement in licence selection, it is recommended to that you read this guide before requesting this the service. It also helps with interpreting the Software Composition Analysis software composition analysis results. If However, if you are already generally familiar with OSS licences or just want to get summaries of licences that are frequently present in GÉANT software projects or are typical of licence compatibility problems, you may go directly go to the Important licences for licence selection guide instead [Wiki_ImportantLicencesImportant licences for licence selection].

SCA and SLA present a valuable opportunity to elevate and align a software project with both GÉANT’s and external expectations, encompassing licensing and policies. The analysis, selection , and validation of software licences can greatly enhance the projects and bolster their credibility within GÉANT and beyond.

Engaging in software licensing offers a chance to meticulously evaluate the project’s components, review their licences and consider aspects related to authorship, ownership, external relations and expectations, and associated documentation artefacts. This concerted effort contributes to standardising various projects in these respects. Licensing reviews engage individuals who were not the original developers to assess and validate the software project, injecting a significant impetus for its developers to critically evaluate and consolidate their work.

Furthermore, this activity entails registering and publishing software using GÉANT’s internal software development tools and aligning them with established practices and expectations within GÉANT. The successful completion of licensing and the formalisation of the licence stand as positive indicators for the project within GÉANT. This holds particular significance for smaller and relatively autonomous developments, such as those undertaken within the GÉANT Trust and Identity Incubator, as it can enhance visibility and overall improvement in the practices and visibility of the originating activity. Moreover, addressing issues through licensing analysis and the resultant reports and decisions yield valuable insights for assessing software solutions and the services based on them during their evaluation at GÉANT Project-Level Management gatesProduct Lifecycle Management (PLM) gates [PLM !!].

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 platforms platform the development team used or contributed to the platform , by assessing its the overall status of its licensing and the security of its components. This is a side effect of the analysis of the software produced by GÉANT’s software development teamteams, 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.

The SCA is currently based on Mend (described in more detail in Section 2.7), which is used to identify third-party components in projects and gather information about their licences and security vulnerabilities. Mend employs a comprehensive database to assist in two critical aspects:

• The analysis of components and their licences helps reduce risks associated with IPR infringements, which could have significant financial consequences, by achieving licence compatibility and compliance.
• The security of OSS is another important issue. Mend reports vulnerabilities through the a report that complements SonarQube and extended code reviews.

The licensing team sets up the project in the Mend SCA tool, which generates reports on the software composition and potential deviations from established policies.

The visibility of produced reports and the created Mend project can be established while the software project is being set up, but it can also be adjusted after the results of the analysis have been obtained or even at the end of the review.

The primary report (“Risk report”Report”) is on the software composition with its components, their licences and related risks and vulnerabilities.

The designated leader or expert from the software development team receives this report and supports provides support in interpreting it, although the software development team should be able to interpret this report themselves.

The licensing team helps with this report if needed, and the developers can ask for additional feedback on the reported and other risks related to licences and IPR infringements.

A summary of the SCA summary service is available at in Software Reviews [Wiki_SWReviews Software Reviews], with additional details at 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 . It is [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 is capable of detecting can detect software components, identifying identify their open source licences and uncovering uncover vulnerabilities. It can seamlessly integrate with your the development environment and build , building a pipeline to detect open source libraries with security or compliance issues. Mend can report reports severe software bugs, problematic licences, new versions and available fixes. Mend 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 and matches , 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.

The Mend tool, offered by WP9 Task 2, streamlines the process of verifying software IPR compliance and partially automates it. Through all this, Mend provides visibility and control over the risks associated with open source. The licences licensing team sets up and maintains the Mend configuration, including the list of approved and rejected libraries provided by the software development team.

A short overview of Mend usage is available in the Mend short guide for end users [Wiki_MendGuideMend short guide for end users].

Mend can analyse projects in several ways. The provided code may be locally stored and a Mend scan can be manually triggered whenever the developer development team needs to assess the effects of a recent code change (details in Adding project to Mend (Scan Flow) [Wiki_MendAP Adding project to Mend (Scan Flow)]). Scanning of GÉANT software can be conducted by performing one integral Unified Agent (UA) project scan or multiple per-product scans. Currently, there is no versioning in Mend, so each software version is scanned as a separate Mend project.

Mend scans directories to find software components and identify vulnerable libraries, licensing conflicts or risks. It After scanning the source code it displays the results in the Mend web application after scanning the source code. By default, it checks the digital signatures of used components in the Mend database to detect and describe open source or commercial components in the product. Mend is a platform that enables users to connect to a GÉANT product (without having to review the code) and assess its compliance with a predefined IPR policy. The verification Verification is accomplished by scanning the project, which populates the Mend web application dashboard with data about the project and enables the creation of reports on compliance with the help of Mend’s backend database.

The web-based GUI provides numerous options and panels for reviewing and analysing scans of open source software in an organisation’s products and projects. Scans of the organisation’s products can be found in the Mend web application. Each scanned product or project is displayed on the corresponding page displaying summary information about a specific product or project and offers offering various dashboard options, providing a comprehensive view of the organisation’s open source status. The product/project page provides access to all contained projects and libraries used by the product/project.

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

• Product Alerts section – displays valuable information about library (component) alerts generated for a product. The New Versions category shows the number of alerts triggered for scanned libraries that are out - of - date (i.e., not the latest version). Whenever an out-of-date library is found, a new alert is generated and displayed in the Alerts report. The alert indicates the out-of-date library and its new version.
• Security and Quality – displays the number of libraries containing vulnerabilities, sorted by severity, the score of the most vulnerable library, the count of libraries with newer versions and vulnerabilities, and the count of ‘buggy’ “buggy” libraries.
• Libraries section – presents detailed information about the product libraries (components), including library name, library licence, and per-product or per-project occurrences of libraries.
• Licence Analysis – provides data on the distribution of licences used by product or project components. It displays the number of different licence types.

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

Additional and detailed information on licences is available in reports, which are available from the Report menu. The Risk Report contains useful information for analysis and it is the most detailed in terms of content. It is a tool that provides a view of all aspects of libraries, their licences, security and quality. The report contains several panels and tables displaying risk-related information. There is security Security and licence analysis data with similar reviews is also presented in other parts of Mend, such as the Product Dashboard.

The displayed information is based on an internal database of libraries, their obsolete versions and vulnerabilities, licences and licence conflicts. Since this database is continually updated, the produced reports can change over time even if a scan has not been performed in the meantime.

Mend information on OSS licence licences includes licence type, copyright, handling of patents and royalties, linking requirements, and compliance with free and open source software norms. The Mend’s experts have conducted an analysis of many licence types and defined risk scores to help developers easily assess risks associated with a particular licence. The primary score is the copyright Copyright risk score calculated based on several factors (Risk Score Attribution [Mend_RSA Risk Score Attribution]). Its purpose is to quantify, on a linear scale, the degree of loss of exclusive control over the code using a library or source code governed by that licence. The copyright Copyright risk score is, therefore, more suitable for commercial organisations wanting to quantify or audit the level of exclusivity over their software assets and associated risks than it is for a software project willing to share, or interested in sharing, the code they developed. Since low values of this score, associated with the colour green colour, generally correspond to permissive licences, while high values, associated with red, correspond to strong copyleft licences, it can be used to quickly identify and assess the present licences. Licences are also quantified in terms of copyleft (no, partial, full) and linking (non-viral, dynamic, viral). There is also “Patent & Royalty Risk Score” a Patent and Royalty risk score and a related attribute that indicates whether the software under the described licence is royalty-free (yes, conditional, no).

Mend can integrate with development environments and with build tools. It can be incorporated into a Continuous Integration continuous integration (CI) pipeline, triggering scans with each commit in host repositories such as GitHub [GitHub GitHub], GÉANT GitLab [GN_GitLab GitLab] and Bitbucket [GN_Bitbucket BitBucket]. GÉANT already used Bamboouses Bamboo [GN_BambooBamboo] as the CI/CD software between the host repository and Mend (details in Automated Mend scans with Bamboo [Wiki_MendASB Automated Mend scans with Bamboo]).

Mend’s functionality, originally tailored for commercial organisations and projects, is gradually moving towards licence compatibility checks more suitable for use within OSS projects. However, developers and project leaders still need to familiarise themselves with it and with licence peculiarities and limitations.

Mend does not provide full and entirely accurate licence detection. It is possible to manually correct licences of individual components at the organisational level. This helps with some libraries that do not have licence information or do not have a licence version specified. Sometimes, only suspect licences are indicated and they must be verified. Multilicences Multi-licences and allowed relicensing are not always reliably handled and not all allowed licences are always listed. Also, there is no support for software versioning or differential reports.

All this prevents a fully automated licence control and alerts. However, although an effort to interpret and improve the Mend analysis is sometimes needed, its use is much more efficient than manual analysis. Besides, even after it completes its composition analysis work, some decision-making and remediation after its composition analysis are needed.

This is why the service described in the next described service, SLA, which was specifically designed for thissection, software licence analysis (SLA), is needed. Since licence selection is based on developers’ preferences and the effort needed to remediate the problems with components and their licences. Mend provides a licence compatibility analysis which indicates the (likelyMend provides a licence compatibility analysis which indicates the (likely) compatibility of other components with the selected one. However, this is far from an automatic licence selection, which will probably always require human decision-making and trade-offs.

It should be noted that other tools can be used in software composition and licence analysis; some are listed in our Reference information about OSS licences.

...

an automatic licence selection, which will probably always require human decision-making and trade-offs.

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.

The SLA service is a technical consultancy service providing a comprehensive understanding of third-party libraries within a software project and their licences. This understanding is crucial for selecting appropriate software and ensuring compatibility among all licences involved. The service is highly recommended for software development teams seeking to validate third-party licences, establish or review their software’s licence, verify compliance with it and the GÉANT IPR Policy, or assess the implications of potential changes in the project licence, the effects of major changes in their software or changes in licences of used libraries or frameworks.

It provides a deeper insight into third-party library licences and their relationship with the project. A prior Software Composition Analysis software composition analysis (SCA) is a prerequisite. The service relies on the results obtained from SCA but also conducts manual checks of detected libraries as needed.

The service includes customising the licence settings of the SCA tool, project licence selection with analysis of the relationship between the project licence and those of its dependencies, and checking alignment with licence requirements and the rules and recommendations of the GÉANT IPR Policy, both requiring verification of related documentation artefacts. If the SCA tool is used with continuous integration, the service team works with the customer to customise related settings.

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

2.9 Licensing Process, Decisions and Artefacts

The typical steps for licence management described during the GÉANT’s Open Source Licensing and Compliance workshop include:

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

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 Detailed preparation for the process and elements of the above steps in GÉANT are provided in the next section.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 the 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.

All components of closely interconnected software development should reside in one project repository, preferably GÉANT GitLab. Although some developers may choose GitHub or opt to mirror their GitLab project on GitHub to obtain permanent URLs for accessing the latest release and its assets, such functionality has been available in GitLab since version 14.9 (GitLab_ReleaseFieldsGitLab: Release fields)). Furthermore, permanent links to assets from specific releases, including those from private releases, have been accessible since GitLab version 15.9. Users can access private release assets using a Personal Access Token. Nevertheless, for certain users, the dual use of both GitLab and GitHub projects remains a viable option. In this approach, the actual development work and intricate pipelines are concealed within the more private space of GÉANT GitLab, with only the final outcome visible on GitHub for public viewing.

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 the ”Section 2.10 Licences and Tracking of Documentation, Data and Other Works” section. Failing to promptly 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 with a SCA tool. This decision may also depend on the relationship between components and their respective responsibilities. For example, if 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 rationale for this extended analysis is twofold. In the first scenario, by undertaking an integrated analysis of the larger project and its subprojects, a more comprehensive and holistic understanding of the whole project and its constituent parts can be achieved. In the second scenario, where the main responsibilities and governance lie with the larger project to which the developers contribute with their part, an integrated view of the entire broader undertaking is essential for the contributing team, as they should know whether the licence governance of the larger project is solid. This is particularly significant since although the wider audience and possible suitor will perceive the contributed component or extension as part of someone else’s project, but which that does not fully protect contributors from a potential licensing dispute. To reassure the contributor, it is prudent to analyse the larger work in the same systematic manner as the contributed part.

Developers should indicate to the licensing team that one of the above situations is the case and which other components they think should be included in the analysis. This may be further facilitated through the use of adequate settings within the project’s build tool configuration. For example, dependencies with Maven’s default scope declaration ‘compile’ “compile” are available in all build tasks and propagated to all dependent projects, when their dependencies are transitively included in the Mend analysis. Dependencies with ‘provided’“provided”, ‘runtime’ “runtime” and ‘test’ “test” scopes should be provided by the execution environment, at runtime, or during testing. They are not considered an integral part of the project but as external libraries that need to be used and are, therefore, not transitively analysed.

We 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 done 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 licence licences, and decisions:

• Note the current licence of your ‘product’ product (entire bundle of created components) or ‘project’ project (one program or standalone component), if set.
• Request Software Composition Analysis software composition analysis (SCA) and Software Licence Analysis software licence analysis (SLA) through GÉANT Jira [Jira_RSWRGÉANT Jira].
• Scan your the project codebase, producing an inventory of used components and their licences with the SCA service.
• Interpret SCA outputs.
• Additionally, analyse and document dependencies and licences with the SLA service.
• As a part of (or based on the outputs of) SCA, SLA and, potentially, dedicated security and vulnerability reviews of your software, review and update the inventory of used components. Identify:
  • Vulnerable open source components that should be removed or replaced.
  • Outdated open source libraries that should be updated.
  • Confirmed licences of used components (in-licences).
• The above review may also include clarifying these ambiguities or doubts:
  • A tool may not be able to properly identify a licence – some licences are reported as suspect or ambiguous.
  • Information about the applied licence may be false, unclear or contradictory.
  • Some licences may be recognised under several names.
  • Some (permissive) licences (BSD, Artistic
…
• • , etc.) have unnumbered variants or are sometimes edited by authors.
  • Applicability of
‘or later’
• • “or later” may be unclear or even wrongly declared by editing the original licence text.
• Document gathered analysis and review information through reports, UI and data exports.
• Consult on the report findings with the licensing team IPR Coordinator, who will assist with determining which licence shall be applied.
• The response will be sent by the IPR Coordinator with guidance regarding the applicable licences.
• Select an appropriate licence – There is a dedicated overview document, Important licences for licence selection [Wiki_ImportantLicencesImportant licences for licence selection], about OSS licences and their relationships. Reading it helps improve the awareness of OSS licences and selection, but the final decision must be made with the IPR Coordinator after the SCA scan.
• Document decisions that were made – Some licences may be additionally refined during remediation and decision-making, but you should also record licensing selection arguments, detected issues and how they were (or will be) addressed. The IPR Coordinator’s arguments and clearance should also be recorded.

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 phasestep, the goal is to identify and resolve licence conflicts and obligations. Their resolution can be trivial but also extremely complex, and may include the removal or replacement of dependencies and functionalities, the development of Resolving these conflicts may involve trivial or highly complex actions, such as removing or replacing dependencies, developing substitutes, or refactoring of existing code.

In some circumstancescases, additional remediation after the repeated SCA scan might be needednecessary. The process may , therefore, include one or several of the following:

• Choose a product/project licence (out-subsuming licence) compatible with key dependencies.
• Perform the 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 need needs to be performed to ensure OSS licence compliance. Some details related to the key artefacts listed below are included in the “Complying Section 3 Complying with a Selected Licence” sectionLicence.

• 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 their its official text. Some licences require including the inclusion of copyright information in it.
  • When a LICENSE file is present, header comments in source code files (with licence and copyright info 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 if 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 at 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 (CLAsCLA) 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.

• 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 seamlessly integrating dependencies and licence checks into CI/CD toolchains. Use the Mend service provided by
GEANT
• • GÉANT or other available tools [Wiki_OtherSCATools] that identify dependencies and their licences or verify licence compliance. This ensures
early catching of
• • that accidental licence violations are caught early.
  • Some tools such as License Maven Plugin [LMPLicense Maven Plugin] can generate a file with lists of dependencies and their licences, download dependencies’ licence files, check, update or remove licence headers in source files and update (or create) the main project licence file.
  • Verify and scrutinise the outputs of employed tools, bearing in mind that they are not foolproof.
• Establish continuous monitoring and compliance checks.
  • Stay updated on changes to the chosen OSS licence.
  • Review the potential impact of any licence updates on your project.
  • Establish processes for continuous compliance checks to ensure that licensing obligations are consistently met by repeating SCA and SLA as needed for new dependencies or licences.
• Perform regular audits of licensinglicence-related artefacts.
  • Conduct regular audits of the project’s
licensing
• • licence-related artefacts to ensure they remain accurate and up
-
• • to
-
• • date.
  • Promptly address any discrepancies to uphold legal clarity and compliance. Any delay is likely to complicate their resolution.
• Seek legal advice when necessary – For complex licensing situations, seek advice from the IPR Coordinator, who can help ensure proper interpretation and compliance with legal aspects.

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

2.10 Licences and Tracking of Documentation, Data and Other Works

Software-related artifacts 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 Non-Commercial License 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.

Software should acknowledge its use of external data by clearly documenting and attributing data sources in its documentation or within the software. This acknowledgment acknowledgement should ensure transparency and adherence to licensing or usage terms linked to the external data. Consequently, the software's software’s licence may be impacted if the data comes with specific licensing requirements or restrictions. In such cases, the software must adhere to the terms of the external data licence. This is particularly relevant if data obtained from another source is hardcoded in software, integrated into software data structures, part of its knowledge base, or incorporated into software configuration or database bootstrap scripts. This applies to all data provided with the software, used to configure settings or define parameters, or essential for the software's software’s operation. Such data should be listed among the software's software’s references and included in the software's software’s licensing analysis. If the data used in this way is proprietary or licensed under an open data or OSS licence, compliance with licence requirements is imperative, and the used data should be mentioned, at least, in the NOTICE file. However, if the data is reference or lookup information in public and widespread use, such as a list of country codes from international standardsthe International Organisation for Standardisation, it should be acknowledged in software documentation and project artifacts artefacts but typically does not need inclusion in the analysis of licences. Even if the use of such data is not explicitly credited, its presence and source should be mentioned in the documentation to explain how this information can be updated.

...

If the data is dynamically fetched from external services and APIs during software initialisation or used regularly as contextual or supporting information, it must be prominently referenced in the README or NOTICE file and project documentation. Examples include maps, environmental and sensory information and the presentation of data from external sources. Furthermore, software may persist, aggregate, or otherwise process data obtained from its users and other services. This includes user-created or shared collaborative content, usage information, logs or data items harvested from other services, personal data from authentication services, information about network resources, topologies or traffic, and datasets for training machine learning models. Software documentation should state the use of such data by the application and provide instructions for admins administrators or users on how to subscribe to external sources or access them, as registration with third-party services is often necessary. Ideally, the software should allow integration with multiple alternative services according to customer preferences, thereby decoupling the software from specific data and services. Users must be informed that they can opt for various data sources.

Processing of external or user-created data may require explicit user consent, be allowed by the terms of use for the service from which data is coming from, or be subject to arrangements between the provider or controller of the system based on the software and those who manage the external source. These arrangements are not the primary concern for software developers and they do not affect software licensing. Still, they should be reasonably achievable with the software. Developers should ensure that software and data are secure, design software for personal data protection, and provide features supporting data-related arrangements, such as obtaining user consent, cookies management, and the display of the privacy notice, terms of use, service policy or data retention policy. On the other hand, virtually all OSS licences include disclaimers of warranties and liability, so software authors cannot be legally liable for malfunctions, damages or misuse suffered or caused by users of OSS software. GÉANT offers security-focused code reviews using automated code analysis and expert assessments [Wiki_SWReviews !!], coupled with related training ([Wiki_SCT !!LINK TO security code review team)]. This is complemented by infrastructure-level support from GÉANT Security [GN_Security GÉANT Security].

The use or modification of some other types of externally developed work can significantly impact software licensing, especially if this work includes elements such as database models, architectural designs, development and execution frameworks, and code generated by tools. If the work is under a specific licence, the software incorporating it must adhere to the licence terms, considering requirements like such as attribution, restrictions on commercial use, or obligations for derivative works. Furthermore, if the software integrates an external database model, framework, or generated content in such a way that the new work is extensively influenced or permeated by the used prior work, the licensing terms of that work may extend to the entire software project. This is especially true if copyleft OSS licences, and non-OSS licences like such as Creative Commons licences with NC (non-commercialNonCommercial), ND (no derivativesNoDerivatives) and SA (share-alikeShareAlike) clauses, are applied. For instance, if development is based on someone else's else’s database model, the used model will likely need modifications, extensions and optimisations, making the allowance for modifications (derivatives) crucial. Therefore, it is essential to review the licences and terms of any such work before significant development begins. These works typically come with copyrights, which should be documented (e.g., in a NOTICE file) and directly included in the code repository, particularly if original or modified artifacts artefacts are present, preferably in a dedicated folder.

Given that many of the above-described works are unlikely to be detected with SCA tools, clear documentation and communication of their use and licences in software documentation are imperative as soon as they are adopted. This also applies to non-original software-related artefacts (assets, configuration files, scripts, technical documentation and user guides). If they are distributed with software, they should be kept in its source code repository and under the same licence as the piece of software they originally came with. If many such works are included, they should be annotated with easy-to-aggregate and searchable provenance and licensing details in the software repository, stated in the project’s Software Bill of Materials (SBOM) [Mend_SBOM Software Bill of Materials (SBOM)], or marked with easily extractable metadata and comments. The included details should encompass the place of use, origin, copyright and licence. Omitting to do so upon including these assets can complicate their identification and tracing at a later stage. This particularly applies to non-original graphical or UI assets, such as images, vector graphics, JavaScript code or GUI layouts that do not directly belong to external components and are not placed within them.

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. Here provided is 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.

...

Here is an example of the use of the EU emblem with the apropritate text about GÉANT and its funding:

Figure 3: The EU emblem with the about GÉANT and funding text (use the above image or download and adapt and resize a hi-res image from here)

...