...

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 , and provides essential information for developers seeking to address licensing issues independently. Additional templates and links to example files with GÉANT-approved content will be provided as they become available from software projects.

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 that a copy of the licence be included, 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 the 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 a 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 declaration of 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 the licence (or all offered licences) 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 the inclusion of 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 [Dillinger Dillinger] or StackEdit [StackEditStackEdit].

The following sections address these compliance requirements in more detail, covering:

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

3.3!!     Copyright and Licence Notices in Source Code

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

/*

...

Copyright

...

(c)

...

<Year>

...

<Copyright

...

Holder>

...

 *

...

This

...

code

...

is

...

released

...

under

...

<Licence

...

Name>.

...

See

...

file

...

LICENSE

...

or

...

visit

...

<Licence

...

URL>

...

 *

...

for

...

full

...

licence

...

details.

...

 */

3.2 Placement of Information

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

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 file, and sometimes within the LICENSE file if there is a placeholder for this in the licence text or it is otherwise required by itthe licence, 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 file. COPYRIGHT, NOTICE or CONTRIBUTORS files sometimes acknowledge the project team and individual contributors and authors. It is better to adhere to the AUTHORS file, unless this information is already provided elsewhere in the existing software.

Funding information may be mentioned in the README, COPYRIGHT and AUTHORS files. 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 Acknowledgement 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 own licences. They should include a separate LICENSE file in each subfolder containing a module with a different licence than from that of the main project and provide any necessary attribution or copyright notices for that module. It is crucial to provide this information for subprojects or folders if it differs from what is stated in the main project or the root folder. If their other important information is also different, it should be provided in their respective folders in the same manner as for the main project.

3.1 Project Licence

...

Options

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

• 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 onlyonly”, ” 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 of 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 the following text to README 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 a 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 stating “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 the imposition of 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 up a space for providing additional restricting clauses, but one licensors 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.

3.4 Complying with Licences of Used Code

In addition to meeting your project's 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 The essential actions are as follows:

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

3.5 README File

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

The README file 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 intranetinternet.
• 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 [Make_a_READMEMake a README]. After providing a sample markdown, it offers a more detailed section titled “Suggestions for a good README”.

3.6 COPYRIGHT File

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

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 root folder or in the 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 whether 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," 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-1 Project, a project that has received funding from the Horizon Europe research and innovation programme under Grant Agreement No. 101055563 101100680 (GN5-1).

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 “Copyright (c) <Year> <Copyright Holder>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 If the software was developed during several iterations of the project, all of them shall be mentioned, for example: ”GÉANT “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 such as 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” the application’s “About” page, screen or window, etc.), following the guidelines from the GÉANT IPR Policy . Here is their summary[GN_IPRPolicy GÉANT IPR Policy], which may be summarised as follows:

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

...

Figure 3.1 presents an example of the use of the EU emblem with the

...

appropriate text about GÉANT and its funding:

Figure 3.1: The EU emblem with the text about GÉANT and its funding text

(use Use the above image or download and adapt and resize a hi-res image from here[EC_DownloadsEC Downloads].)

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.

• No. 691567

!! Comment on using GN5 FPA Grant Agreement No. 101055563 (GN5)

3.7 Acknowledgements in AUTHORS, NOTICE and README

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

An AUTHORS (or CONTRIBUTORS) file is a straightforward way to acknowledge and credit individual contributors and reference the GÉANT activity Work Package or task 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 file 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 interfaceinterface”. ” 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 the COPYRIGHT file. Their lines may also start with time period references, such as ‘2021.’ and ‘2020-“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 the README file 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 <Dependency 1 Name>
      - Version: [Dependency <Dependency 1 Version Number]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 <Dependency 2 Version Number]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 <Dependency 3 Version Number]Number>
      - URL: <Dependency 3 URL>
      - Licence: <Dependency 3 Licence>
      - Copyright (c) <Library < Dependency 3 Year Range> <Library < Dependency 3 Copyright Holder>

We thank all

...

open source developers who contributed

...

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 . Some licences require preserving the content from existing NOTICE files of dependencies. If a NOTICE file is not requiredunnecessary, you may opt to provide this information in a dedicated section of the README file 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.

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

3.8 CHANGELOG File

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

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’ “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“Added:’”, ‘Changed“Changed:’”, ‘Fixed“Fixed:’”, ‘Deprecated“Deprecated:’”, ‘Removed“Removed:’ ” and ‘Security“Security:’ ” for security-related changes. Changes descriptions Descriptions of changes 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, such as that shown in the following markdown example:

## [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

...