...

IntroductionIntroduction

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.

...

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

...

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.

...

It should be noted that other tools can be used in software composition and licence analysis; some are listed in our Reference information about OSS licences.(!!To GSD, does the anchor work, create one using a macro?)

Software Licence Analysis (SLA) Service

...

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

One or Several Projects?

...

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

...

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

...

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

...

Licences and

...

Tracking of Documentation, Data and Other Works

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

...

If the data is dynamically fetched from external services and APIs during software initialisation or used regularly as contextual or supporting information, it must be prominently referenced in the README or NOTICE file and project documentation. Examples include maps, environmental and sensory information and the presentation of data from external sources. Furthermore, software may persist, aggregate, or otherwise process data obtained from its users and other services. This includes user-created or shared collaborative content, usage information, logs or data items harvested from other services, personal data from authentication services, information about network resources, topologies or traffic and datasets for training machine learning models. Software documentation should state the use of such data by the application and provide instructions for admins 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., 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 (!!LINK TO security code review team). This is complemented by infrastructure-level support from GÉANT Security.

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

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

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

Complying with a Selected Licence

...

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)

...

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

...