Table of Contents

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 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 offers a detailed implementation of the selected licence from a developer’s perspective, providing instructions facilitating the execution of the licensing process. It furnishes in-depth information alongside simple but critical guidance on creating essential licensing artefacts.

Notably, this document does not delve into the specifics of individual OSS licences, 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 end.

Essential Aspects and Elements of Software Licensing

Significance of Open Source Software (OSS) and Licensing

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 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-Effective – 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 Collaboration – 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 Independence – 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 Learning – 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 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 Accessibility – 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 general OSS-related concerns, there are some requirements and recommendations applicable in the GÉANT context, some of which are implied by its IPR Policy (also see GÉANT Resources – Intellectual Property):

• Every GÉANT software project should select and apply a suitable OSS licence that fits your needs and those of the user community.
• Starting the licensing process early makes 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 GÉANT or received support from it and who authored the produced software.
• Assess the used components and software by applying common software quality and trustworthiness checklists to use reliable components and produce reliable software. Examples: 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 analysis services (SLA and SCA) that conduct related reviews and audits designed to establish open source licences and ensure licence compliance.
• Identifying and addressing vulnerabilities in your software 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.

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 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 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 to code sharing and modification (where copyleft licences are more stringent), relicensing (also referred to as sublicensing, which may be desired to be prohibited or allowed), and the way patents are handled (waived, protected or ignored). 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 Assistant tool (JLA - Find and compare software license), which greatly facilitates the selection of the most appropriate licence aligned with the developers’ strategy and user community when choices exist.

Figure 1: OSS Conditions from Joinup – JLA - Find and compare software licenses

Compatibility of Frequent Licences in GÉANT

We have compiled comprehensive information about OSS licences, some of which is also available via Mend, the tool used for SCA. However, there is a limited set of licences that are frequently used in GÉANT or are common sources of compatibility issues. Here is 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: Relationships between software frequent licences in GÉANT projects

OSS licences are detailed in several documents produced by the licensing team. For additional details, please refer to the Reference information about OSS licences, OSS licences and licence selection and !!GSD: Important licences for licence selection guides.

GÉANT IPR Policy

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

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

Lack of complying 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 (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.

• All 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 guides developed by the software licensing team are listed in “Further Reading”, while training and infoshare presentations are in “Training Materials.”

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 WP9 Task 2 activity Open Source Licensing Support (OSLS), or simply software licensing. It:

• 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 (IPR).

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

• Software Composition Analysis (SCA) – Technical and practical assistance for software development teams with managing software components and their software licences.
• Software 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, namely SonarQube Setup Assistance and Extended Source Code Review. 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 and SLA services are requested by submitting a software review request to the 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 licences and licence selection guide first. Since the SLA service requires the software development team’s involvement in licence selection, it is recommended to read this before requesting this service. It also helps with interpreting the Software Composition Analysis results. If you are 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 directly go to the !!GSD: Important licences for licence selection guide instead.

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 and the resultant reports and decisions yield valuable insights for assessing software solutions and services based on them during their evaluation at GÉANT Project-Level Management gates.

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 the development team used or contributed to the platform by assessing its overall status of licensing and security of its components. This is a side effect of the analysis of the GÉANT’s development team, as it transitively includes an analysis of involved components and licences.

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, 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 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”) 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 in interpreting it, although the software development team should be able to interpret this report.

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.

SCA summary is available at Software Reviews, with additional details at Client Guide for Software Composition Analysis (SCA).

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 designed for in-house use by the customer and does not offer direct consultancy by legal experts. Mend is capable of detecting software components, identifying their open source licences and uncovering vulnerabilities. It can seamlessly integrate with your development environment and build a pipeline to detect open source libraries with security or compliance issues. Mend can report severe software bugs, problematic licences, new versions and available fixes. Mend 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 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 team sets up and maintains the Mend configuration, including the list of approved and rejected libraries provided by the software team.

A short overview of Mend usage is available in the Mend 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 team needs to assess the effects of a recent code change (details in Adding project to Mend (Scan Flow)). Scanning of GÉANT software can be conducted by performing one integral 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 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 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 various dashboard options, providing a comprehensive view of the organisation’s open source status. The product page provides access to all contained projects and libraries used by the 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’ 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 and licence analysis data with similar reviews 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 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 is the copyright risk score calculated based on several factors (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 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 or interested in sharing the code they developed. Since low values of this score, associated with 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” 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 build tools. It can be incorporated into a Continuous Integration (CI) pipeline, triggering scans with each commit in host repositories such as GitHub, GÉANT GitLab and BitBucket. GÉANT already used Bamboo as the CI/CD software between the host repository and Mend (details in 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 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 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 work, some decision-making and remediation after its composition analysis are needed.

This is why the next described service, SLA, which was specifically designed for this, 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 (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 licence analysis; some are listed in our Reference information about OSS licences.(!!To GSD, does the anchor work, create one using a macro?)

Software Licence Analysis (SLA) Service

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 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 (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 SLA service's summary is available in Software Reviews.

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)

Detailed preparation for the process and elements of the above steps in GÉANT are provided in the next section.

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 or GitHub.
• Register the software project in the 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: 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.

Software-related artefacts (technical documentation, configuration, and user guides) distributed with software should be kept in its source code repository and will likely be under the same licence as the software. Keep separate tutorials, presentations or standalone training or promotional materials elsewhere, and they may be licensed under the CC BY-NC or CC BY licence. 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, should be annotated with provenance and licensing details in the software repository, the project’s Software Bill of Materials (SBOM) or through easily extractable metadata and comments. Proper documenting  of their copyright and licence of is crucial, and omitting to do it upon including these assets can complicate their identification and tracing at a later stage.

One or Several Projects?

When handling multiple projects, it is crucial to determine and specify which dependencies should be incorporated into the analysis with a SCA tool. This decision may also depend on the relationship between components and their respective responsibilities. For example, if 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 main responsibilities and governance 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 the wider audience and possible suitor will perceive the contributed component or extension as part of someone else’s project, but which 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’ 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’, ‘runtime’ and ‘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 can also provide ideas about grouping features or products within the project and branding for the software. This will be 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.

Information Gathering and Documenting

Document copyrights, findings about licence and decisions:

• Note the current licence of your ‘product’ (entire bundle of created components) or ‘project’ (one program or standalone component), if set.
• Request Software Composition Analysis (SCA) and Software Licence Analysis (SLA) through GÉANT Jira.
• Scan your 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 …) have unnumbered variants or are sometimes edited by authors.
• Applicability of ‘or later’ may be unclear or even wrongly declared by editing the original licence text.
• Document gathered 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 !!GSD: Important 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 and GÉANT OSS licences whitepaper.

Remediation

During this phase, 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 substitutes, or refactoring of existing code.

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

• Choose a product/project licence (out-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 to be performed to ensure OSS licence compliance. Some details related to the key artefacts listed below are included in the “Complying with a Selected Licence” section.

• Provide 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 official text. Some licences require including copyright information in it.
  • When a LICENSE file is present, header comments in source code files (with licence and copyright info 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 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 documenting modifications to code in a CHANGELOG file or elsewhere is required, check the licence text or licence summaries such as those in !!GSD: 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 filesender/CONTRIBUTE.md and atom/CONTRIBUTING.md
  • Provide contribution and copyright instructions and rules, even if external contributors are not expected.
• Prepare and apply a Contributor License Agreement (CLAs) 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 README or CONTRIBUTING) 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 CONTRIBUTING.
• 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 application UI.

Continual Licence Management

The goal of long-term licence management is to integrate 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 Mend service provided by GEANT or other available tools that identify dependencies and their licences or verify licence compliance. This ensures early catching of accidental licence violations.
• Some tools such as License 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 licensing-related artefacts.
• Conduct regular audits of the project’s licensing-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 BP-B.6: Manage sideground IPR recommends early dealing with the preexisting and external IP and repeating it periodically.

Documentation and Data Licences and Use

Software-related artifacts distributed with the software or stored in its source code repository typically adhere to the same open source licence. This includes data, technical documentation, configurations and user manuals. For separate tutorials, presentations, training and promotional materials, it is advisable to use the Creative Commons Attribution Non-Commercial License (CC BY-NC). Another noteworthy licence is the GNU Free Documentation License (GFDL). While data is occasionally licensed under OSS licences, more commonly used are 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 should ensure transparency and adherence to licensing or usage terms linked to the external data. Consequently, the 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 operation. Such data should be listed among the software's references and included in the 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 standards, it should be acknowledged in software documentation and project artifacts 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.

The above also applies to data contained in external code libraries or modules.

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 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 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 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 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, coupled with related training. This is complemented by infrastructure-level support from GÉANT Security.

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.

Developers are obligated to adhere to the requirements of the chosen OSS licence and ensure licence compatibility. Failure to comply constitutes a breach, potentially leading to legal challenges and significant financial loss.

Even if the software and its dependencies are aligned with the chosen licence, this licence must be clearly stated in the documentation, including the README file. Most licences require including a copy of the licence, which is typically placed in the LICENSE file in the root folder. Some licences may require only their name or URL in documentation, but having the licence text in a dedicated file is standard. A clear and explicit statement of the specific licensing is necessary, beyond just including a licence text. For instance, the GPL family of licences articulates this requirement in the “How to Apply These Terms to Your New Programs” section at the end of their text. Simply including the licence text in the LICENSE file is insufficient; a distinct statement affirming the applied licence is required.

While licence and copyright information usually do not need to be in every source file header, the applied licence and funding should be clearly declared and strategically placed so that anyone interested could easily find and see them. If the software has its website or webpage, the licences should also be stated there. The source code repository used may also have a mechanism for specifying the used licence. GitHub and GitLab provide features that allow declaring the licence by using the repository’s user interface. GitHub is able to automatically recognise the used licence from the LICENSE file in the root folder.

Software authors may specify alternative licences for a project, offering it under a dual licence or multiple licences. However, when such software is used in another project, only one of its available licences is applied when considering compatibility with the licence of the main project. Also, the component’s licence must be compatible with (all offered) licence of the main project.

The minimal set of typical documenting files in a software project usually includes README for project information, LICENSE for licensing details and CONTRIBUTING for contribution guidelines. The applied licence may require including CHANGELOG or CHANGES for tracking project changes. These files may optionally use markdown when their names end with the .md extension. If so, you can edit them using an online markdown editor or checker such as Dillinger or StackEdit.

Copyright and Licence Notices in Source Code

A simple copyright line and a licence indicator may be placed at the header of every source file. While not mandatory, this 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.
 */

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 GÉANT Software Catalogue relevant information may be linked in the project’s profile or description.

It is essential to create or to review and update the copyright statement. Typically, a COPYRIGHT file should indicate that the software is copyrighted by GÉANT, NRENs or other organisations. The copyright holder should also be specified within the README, and sometimes within the LICENSE file if there is a placeholder for this in the licence text or it is otherwise required by it, or in copyright notices within headers of source files.

Contributors are acknowledged in the AUTHORS file, providing a list of individuals or entities who have contributed to the software and who may be grouped by type (e.g., code, documentation, testing). The source code repository, if regularly used, tracks contributions and may provide information for the AUTHORS. COPYRIGHT, NOTICE or CONTRIBUTORS files sometimes acknowledge the project team and individual contributors and authors. It is better to adhere to the AUTHORS, unless this information is already provided elsewhere in the existing software.

Funding information may be mentioned in the README, COPYRIGHT and AUTHORS. It may include logos or links to websites of sponsors or grant providers. It should be transparently disclosed if funding influences project direction or goals, which is certainly the case for the developments in GÉANT. The information about EC funding is obligatory if the code was developed with the money provided by the EC. Acknowledgment of funders might also be included in the detailed documentation.

Contribution guidelines are documented in the README or CONTRIBUTING file. These guidelines specify how new contributors can engage with the project, submit changes (including committing, branching, testing and releasing), and adhere to the project’s coding standards and licensing requirements. They may link to templates, coding style profiles or guidelines and specific instructions for different kinds of contributions.

Software, its licence, associated background IP and sideground IP should be recorded in the GÉANT IP Register. This is done by the licensing team and the IPR Coordinator.

Modules located in subfolders may have their licences. They should include a separate LICENSE file in each subfolder containing a module with a different licence than 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.

Project Licence Options 

The applied licence may allow choosing 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:

• Permitting users to choose between the original licence version or any later version – One option is to permit users to choose between the original licence version or any later version approved by the licensor. Allowing such multiversioning relicensing can be interpreted as licence-endorsed open-ended multilicensing. For example, a clear statement indicating the code’s specific GPL licence is required and is typically found in the README file. The GPL phrase “This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version” allows the choice of the referenced version or any later version. Simplifying it to “This software is licensed under GNU General Public License version 3 or any later version” is acceptable. If the licence notice statement ends with “version 3” or “version 3 only,” then only GPL 3.0 can be applied. If the version number is not mentioned, the recipient can choose any published version of the licence. The notice can even specify that a proxy can decide which future versions of the GNU General Public License can be used, but this option is rarely used. For LGPL, this notice should mention “GNU Lesser General Public License” instead of “GNU General Public License”.
• Relicensing under a different licence – Some licences allow relicensing the software under a different licence endorsed by the original licence or even a licence chosen by the licensor. For EPL 2.0 licensed software, its notice or file headers should state “This program and the accompanying materials are made available under the terms of the Eclipse Public License 2.0 which is available at https://www.eclipse.org/legal/epl-2.0/.” With this, software is to be used with EPL 2.0 only. But a Secondary License can be introduced, where recipients can choose to comply with either the EPL or the Secondary License. Adding this text introduces GPL 2.0 with Classpath-exception as the Secondary License: “This Source Code may also be made available under the following Secondary Licenses when the conditions for such availability set forth in the Eclipse Public License, v. 2.0 are satisfied: The GNU General Public License (GPL), version 2 with Classpath-exception.” Any other licence that grants the recipients the rights that are at least as broad as those granted under the EPL can be declared as Secondary License. Adding the latter clause is effectively relicensing, and all copyright holders must agree to the licence change. When MPL 2.0 is used, the notice must state “This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at https://mozilla.org/MPL/2.0/.” By default, MPL 2.0 offers most GPL licences as Secondary Licenses. However, the licensor may prohibit this by providing “This Source Code Form is ‘Incompatible With Secondary Licenses,’ as defined by the Mozilla Public License, v. 2.0.”
• Extending certain rights beyond standard terms – In some cases, it is possible to extend certain rights beyond the standard terms of the original licence, such as allowing commercial use without open sourcing modifications, providing a patent grant and permitting the distribution of proprietary versions. Any extension of rights should be clearly articulated and explicitly state that these extensions work in conjunction with the original licence without replacing or modifying its conditions. For example, the notice suggested for Apache 2.0 states that software is on an “AS IS” basis. However, additional warranties can be agreed in writing.
• Placing limitations on certain uses or modifications – Some licences may allow or not prohibit imposing additional conditions such as restricting non-commercial use, requiring the availability of modified source code and ensuring compatibility with the original version. It is crucial to note that adding limitations should be done carefully and explicitly and ensuring that these limitations work alongside the original licence. The original Apache 2.0 notice opens a space for providing additional restricting clauses, but one should avoid introducing restrictions that contradict or undermine the fundamental principles of open source licensing, such as the ability for users to freely use, modify and distribute the software.
• Choosing the jurisdiction under which the licence is governed – With EUPL, the licensor can choose the jurisdiction under which the licence is governed. This allows them to specify the legal framework to be applied, which can be helpful when dealing with legal matters.

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

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. Here are the essential actions:

• Extend README, COPYRIGHT and NOTICE files to explicitly declare and credit the use of dependencies or other utilised code, clearly stating the application of their licence options.
• Retain all preexisting licence and copyright-related files and notices to ensure comprehensive documentation and compliance with their respective licences.
• Properly attribute and document any modifications made to reused code, updating the history of modifications and the list of contributors as necessary.
• Stay informed about licence updates and changes for used code, as they can impact compliance requirements and necessitate adjustments.

Eclipse or Mozilla-licensed dependencies (direct or transitive) require explicit reference within the project's documentation.

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

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

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.

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

• Purpose or intent, which authors may sometimes omit as it may appear self-evident to them.
• Scope, supported settings, requirements or constraints of the application which may not be apparent to a reader encountering the project on the intranet.
• Installation and configuration.
• Usage.
• Roadmap and known issues.
• Community contributions.
• Acknowledgements, dependencies and used tools.
• Software licence and licences of differently licensed components.

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

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.

Copyright management within the project is expressed through the copyright statement. Copyright is sometimes embedded in the LICENSE file. For some short licences such as MIT, BSD and their variants, the copyright notice is an integral part of the LICENSE file and is provided at the beginning of the LICENSE file, although a place for this may be reserved elsewhere in the licence text. In some cases, the copyright information is placed in a separate COPYRIGHT file to maintain the LICENSE file’s integrity.

Not all software developed within the GÉANT project correctly indicates copyright. This issue needs addressing during work on software licensing. While core copyright information can be provided on the project website, in the project’s LICENSE file (if this is a convention for the applied licence) and in the README file, creating a dedicated COPYRIGHT file with more comprehensive details is advisable for software created or modified within GÉANT.

The COPYRIGHT file should be placed in the project or component’s root folder if it differs from the rest of the project. It should include a reference to the GÉANT project and specify the years in which the work was carried out. It should state that the software is copyrighted by GÉANT and other contributing organisations. In addition to copyrighting new code to GÉANT, indicate if any code within was reused, adapted or relied upon from elsewhere. If the work includes contributions from NRENs that were created independently of GÉANT or direct insertions or adaptations of code from other projects, copyrights of the original copyright holders should be indicated or preserved if they were already present.

If you are creating a COPYRIGHT file in markdown format, which is not necessary if the copyright information is short and simple, you may use Dillinger, StackEdit or another online markdown editor or checker.

An example of a COPYRIGHT file with a disclaimer that can be tailored to your needs is provided here:

Copyright (c) 2023-2024 GÉANT Association on behalf of the GN5-1 project

THE SOFTWARE IS PROVIDED "AS IS," WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES, OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT, OR OTHERWISE, ARISING FROM, OUT OF, OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Project IP was generated and/or developed during the GÉANT GN5 Project, a project that has received funding from the Horizon Europe research and innovation programme under Grant Agreement No. 101055563 (GN5).

The Partner that developed the Project IP remains the sole owner of the Project IP developed during the Project. However, GÉANT Vereniging (Association), registered with the Chamber of Commerce in Amsterdam with registration number 40535155, and operating in the UK as a branch of GÉANT Vereniging (Association), registered office: Hoekenrode 3, 1102BR Amsterdam, The Netherlands, UK branch address: City House, 126-130 Hills Road, Cambridge CB2 1PQ, UK, has the free-of-charge, non-exclusive, perpetual, irrevocable, worldwide right to exploit the Project IP, including any Background and Sideground IP, and any IPR attached to the respective IP, including the right to sublicense the Project IP through multiple levels of sublicences and/or other licensing arrangements and to release to third parties the Project IP, including Public Disclosure in accordance with this IPR Policy.

The COPYRIGHT file commences with a copyright statement. The first line contains ”Copyright (c) <Year> <Copyright Holder>,” where <Year> indicates the year or range of years when the copyright for the software was established or updated, and <Copyright Holder> is the name or organisation. In the case of GÉANT Association, include a reference to the project phase during which the licensed software was developed. In case that the software was developed during several iterations of the project, all of them shall be mentioned, for example: ”GÉANT Association on behalf of GN4-2, GN4-3 and GN5-1).”

If there are additional agreed copyright statements confirmed by the IPR Coordinator, such as those independently developed by other partners like NRENs, they should be added in lines following the GÉANT Association copyright.

The above template includes a disclaimer of warranty and a limitation of liability clause. If the software is not open source and you retain all rights provided by copyright law, you may use “All rights reserved” instead. Even if you skip this statement, the work is automatically protected by copyright; another person cannot reproduce, distribute or adapt any part of the work without your permission.

Whenever your code was developed with EC funding, the EU emblem shall be included. The EU emblem should be added to information about funding whenever feasible (in README.md, project documentation, application's ”About” page, screen or window, etc.), following the guidelines from the GÉANT IPR Policy. Here is their summary:

• The minimum emblem height is 1 cm.
• “European Union” shall be used in conjunction with the name of the programme or fund and spelt out in full.
• Use one of the listed non-serif fonts without any font effects.
• The text should not interfere with the emblem in any way.
• The text should be proportionate to the size of the emblem.
• The text should be in the same blue colour as the EU flag, black or white, depending on the background.
• Along with the EU emblem, information about the funding shall be provided.

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)

For the prior projects, the text is:

• GN4-3 project is funded from the Horizon 2020 research and innovation programme under Grant Agreement No. 856726
  GN4-2 project is funded from the Horizon 2020 research and innovation programme under Grant Agreement No. 731122
  GN4-1 project is funded from the Horizon 2020 research and innovation programme under Grant Agreement No. 691567

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.

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.

An AUTHORS (or CONTRIBUTORS) file is a straightforward way to acknowledge and credit individual contributors and reference the GÉANT activity or task of the project team. This file is placed in the project’s source code root.

This file can also acknowledge funding as required by the contract or programme. If detailed information about individual contributors is not provided, funding credits can be moved to the COPYRIGHT file. Some of the information from COPYRIGHT and AUTHORS may also be summarised in the README and on the project’s standalone website, as instructed by the GÉANT Marcomms Team. However, there is no need to provide funding credits for software descriptions within GÉANT-branded websites or within its internal collaboration platforms.

Below is a markdown template for an AUTHORS file:

<Project Name> has been created by the <GNx-y> WP<x> Task <y> <Recognisable Task Name>.

## Developers
- [<Author 1 Name>] (<Author 1 Contact>): <Author 1 Role>
- [<Author 2 Name>] (<Author 2 Contact>): <Author 2 Role>

## Relevant Contributors
- [<Contributor 1 Name>] (<Contributor 1 Contact>): <Contributor 1 Role>
- [<Contributor 2 Name>] (<Contributor 2 Contact>): <Contributor 2 Role>

## Funding
- [GN5-1](https://geant.org/gn5-1/) is funded from the European Union’s GN5 FPA partnership framework agreement, Horizon Europe research and innovation programme under Grant Agreement No. 101100680 (GN5-1).
- [GN4-3](https://geant.org/projects/) is funded from the European Union’s Horizon 2020 research and innovation programme under Grant Agreement No. 856726.
- [GN4-2](https://geant.org/projects/) is funded from the European Union’s Horizon 2020 research and innovation programme under Grant Agreement No. 731122.
- [GN4-1](https://geant.org/projects/) is funded from the European Union’s Horizon 2020 research and innovation programme under Grant Agreement No. 691567.

<Project Name> should be replaced with the name of the software project. If you want to indicate the project’s GÉANT origin, the file may optionally start with the line provided at the beginning of the template.

When individuals are listed, their names may be accompanied by optional email addresses or other relevant contact information (e.g., a reference to a catalogue or repository, or ORCID iD) and descriptions of their notable contributions or roles in the project, if desired. These descriptions should be brief, such as “Implemented the core functionality of the project” and “Designed the project’s user interface.” This not only gives credit to those who have worked on the project but also helps other contributors find each other, which can foster collaboration. The contributors section may also include individuals involved in related activities who did not directly author the code if their contributions were significant. Developers and contributors should be clearly distinguished from the holder(s) of copyright stated in COPYRIGHT. Their lines may also start with time period references, such as ‘2021.’ and ‘2020-today:’.

Make sure to keep this section up to date as new contributors join the project or make significant contributions.

If your project is part of a larger ecosystem or relies on third-party libraries, it is a good practice to acknowledge these dependencies in your documentation as well, either in README or in a separate NOTICE file. Also, the licence that you use may require that you create a NOTICE file or you may be modifying a project with an existing one, into which you should add your entries. Mention all the libraries and frameworks that your project uses and provide links to their respective websites or repositories. README, COPYRIGHT and NOTICE files of unmodified components should remain undisturbed.

Below is a markdown template for a NOTICE file listing relevant third-party components, their licences, URLs and copyright information:

# <Project Name> - NOTICE File

This project includes third-party software components subject to open source licences. Please read and comply with the licensing terms and attribution requirements of these components, as listed:

1. <Dependency 1 Name>
   - Version: [Dependency 1 Version Number]
   - URL: <Dependency 1 URL>
   - Licence: <Dependency 1 Licence>
   - Copyright (c) <Dependency 1 Year Range> <Dependency 1 Copyright Holder>

2. <Dependency 2 Name>
   - Version: [Dependency 2 Version Number]
   - URL: <Dependency 2 URL>
   - Licence: <Dependency 2 Licence>
   - Copyright (c) <Dependency 2 Year Range> <Dependency 2 Copyright Holder>

3. <Dependency 3 Name>
   - Version: [Dependency 3 Version Number]
   - URL: <Dependency 3 URL>
   - Licence: <Dependency 3 Licence>
   - Copyright (c) <Library 3 Year Range> <Library 3 Copyright Holder>

We thank all the open source developers who contributed to these dependencies.

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. The actual content and format of a NOTICE file may vary depending on the specific project and its and dependencies’ licensing requirements, as some licences require preserving the content from existing NOTICE files of dependencies. If a NOTICE file is not required, you may opt to provide this information in a dedicated section of README in a more concise form, also including the information about the tools used, as given in this markdown example:

## Dependencies

This project relies on the following third-party libraries and tools:

- [Library A](https://librarya.com) - Used for data processing.
- [Framework B](https://frameworkb.io) - Provides essential functionalities for the project.
- [Tool C](https://toolc.org) - Assisted in automating tasks.

Scanning a project with Mend is useful for checking dependencies to avoid forgetting significant ones. However, transitive dependencies listed in Mend reports should not be included in the above lists.

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.

CHANGELOG File

Some licences require maintaining and providing a history of software changes. 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 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.

Entries should be organised chronologically, with the newest changes at the top. Each entry typically corresponds to a single release. Include release or version numbers or tags (e.g., “1.2.3”) and indicate release (or change) dates. For unreleased changes, consider using ‘Unreleased’ as the version until a release occurs. Summarise changes in bullet points or brief paragraphs, optionally grouping them by type (e.g., features, bug fixes, improvements). Alternatively, bullets may have indicative prefixes, such as ‘Added:’, ‘Changed:’, ‘Fixed:’, ‘Deprecated:’, ‘Removed:’ and ‘Security:’ for security-related changes. Changes descriptions may reference the relevant commit IDs and code files for detailed information. Highlight important changes by visually emphasising significant updates.

The information from commits into the source code repository should be used to track changes systematically. Having a practice of frequent commits, development in branches, and meaningful clear and concise commit messages helps in this, but the information from the repository is often too specific. It is also important to tag releases with version numbers for easy identification. Other valuable sources of information about changes, the content of which can be readily transferred to the history, are release notes and lists of features and modifications planned for a release, developer tasks and fixed issues. The history should remain meaningful throughout the software lifecycle, so it is useful to mention why a change is made or include the context or background for the change. Features such as pull requests and code reviews can offer an additional context.

Use a consistent and clear format for each entry. This is an exemplary markdown:

## [1.2.3] - 2024-01-01

### Added
- Newly added feature 1
- Newly added feature 2

### Changed
- Updated existing feature or its implementation
### Fixed
- Bug fix 1
- Bug fix 2

Markdown for linking to specific commits or issues related to each change facilitates access to additional information.

- New feature 1 (#123)
- Bug fix 1 ([commit hash])

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

Resources

Contact

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

Training Materials

• Open Source Licensing and Compliance: https://e-academy.geant.org/moodle/course/view.php?id=214
• Webinar: License Dependencies Analysis with WhiteSource: https://e-academy.geant.org/moodle/course/view.php?id=220
• Introduction to Open Source Licensing and Compliance 2023: https://e-academy.geant.org/moodle/course/view.php?id=478
• Infoshare: Software Licences Management in GÉANT
  

Further Reading

• GÉANT IPR Policy: https://about.geant.org/wp-content/uploads/2022/06/GEANT-_IPR_Policy_2022.pdf
• OSS licences and licence selection – an introductory guide
• Project-oriented whitepaper for GÉANT participants – a guide on licence selection with an appendix describing the most frequently OSS licences used from analysed projects
• !!GSD: Important licences for licence selection – descriptions and compatibility of most frequent licences in GÉANT
  
• Reference information about OSS licences and tools – a comprehensive catalogue of thematically organised resources and pointers
• Open Source Software Licences in GÉANT – whitepaper on licensing in GN4-3 and GN5-1, with recommendations and info about licences in analysed projects

• GÉANT software best practice BP-B.6: Manage sideground IPR

• OSI Approved Licenses: https://opensource.org/licenses/

Services

• GÉANT Software Licence Management (homepage)
• Jira requests for SCA and SLA: https://jira.software.geant.org/servicedesk/customer/portal/2/create/55
• Software Reviews – GÉANT Software Development Support
• GÉANT Mend, with login via GÉANT SSO, special permissions may apply: https://app-eu.whitesourcesoftware.com

• Accessing Mend and visibility levels – visibility of Mend scan results

• Mend short guide for end users – also explains the interpretation of Mend reports
• The Risk Report – Short Mend report guide for end users: https://docs.mend.io/bundle/sca_user_guide/page/the_risk_report.html
• GÉANT GitLab: https://gitlab.software.geant.org
• GÉANT Software Catalogue: https://sc.geant.org