...

Instead of this page, please read the enhanced PDF version. Its textual improvements will soon be reflected in this Wiki, making it easier for you to comment or contributeA PDF snapshot of this document from March 2024 is also available. Information provided on this page is up-to-date.

Table of Contents

...

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

...

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

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

...

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

Preparation

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

...

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

One or Several Projects?

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

...

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

...

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

3

...

Complying with a Selected Licence

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

...

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

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

3.

...

1 Project Licence Options

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

• 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 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 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 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 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 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 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.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 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 the 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. 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 from that of the main project and provide any necessary attribution or copyright notices for that module. It is crucial to provide this information for subprojects or folders if it differs from what is stated in the main project or the root folder. If their other important information is also different, it should be provided in their respective folders in the same manner as for the main project.

3.3 Copyright and Licence Notices in Source Code

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

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

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

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

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

...

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, the application’s “About” page, screen or window, etc.), following the guidelines from the GÉANT IPR Policy [GN_IPRPolicy GÉANT IPR Policy], which may be summarised as follows:

...

Figure 3.1 presents an example of the use of the EU emblem with the appropriate text about GÉANT and its funding:

...

• 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

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

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.

...

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

4 Resources

4.1     1 Contact

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

4.2     2 Training Materials

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

...

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

4.4     Services

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

References

Glossary