Table of Contents

Summary

This document provides the necessary background information to understand the domain of Open Source licences (OSS), also known as Free and Open - Source licences (FOSS). It starts with an overview of the benefits of FOSSOSS, describes various types of free and open source licences and some related licencesones, and describes addresses other concerns and constraints related to licences. This is followed by some basic guidelines for the selection of a licence to be used in a project, including the relationship of the applied licence with sustainability and longevity, as well as key pointers on licence and IPR governance and tools that are available within the GÉANT context.

...

Open

...

source licences (

...

OSS)

...

Advantages of

...

OSS

The market is supposed expected to even balance out and equalise the total costs cost of ownership of for equivalent software products. StillHowever, vendors of proprietary software often claim that after some time the use of their products will be simpler and less costly than with FOSS. Some organisations do not want to invest in expertise and argue that although initial costs for OSS software may be lower, prolonged usage of proprietary software is simpler and maintenance fees are lower compared to the costs of using and ensuring support for OSS. Some organisations are hesitant to invest in the expertise and associated costs they often associate with the use and maintenance of FOSSusing and maintaining OSS, even when if the needed effort required is neglectableminimal. They often may want prefer to have an external organisation that they can hold accountable for software risks and problems. But the experience has shown that Generally, it is very hard challenging to hold a vendor of commercial software liable for it unless it software has been tailor-made for a single customer and very strict contractual obligations were put in placecommitments have been made. However, proprietary software is usually accompanied by multiple levels of support without incurring additional charges.

On the other hand, the characteristics of FOSS OSS make it a very an attractive option for many users and organisations. Also, many commercial developers of open-source software often provide It is not uncommon for proprietary software companies to contribute to open source software. For example, Microsoft is the largest contributor to OSS on GitHub. Additionally, many commercial developers of open source software often offer additional services as part of their business model. There are even third-party companies which that provide support for open - source software.

The open - source model differs greatly from the one used operation is very different from that of traditional licensed proprietary and commercial software by permitting because it promotes both distribution and modification. The first limitation is also eliminated in element is an obvious differentiator between freeware (free of charge) and shareware (free trial) software, at least for its binary form, but the possibility to modify the source code of OSS is crucial and has had a huge significant impact, which has brought leading to several substantial improvements over traditional proprietary licensing models.

• Availability and lower costs – For In cases of highly advanced or specialised needs, such as those related to research, new technologies and high loadloads, the market is not large enough for may lack a suitable commercial product to be that is available and sustainedsustainable. The immediate and cost-free availability of open source is also associated with software is often accompanied by the need to develop internal expertise, which is often something that but it should also align with the preferences of organisations and individuals want to do anyway or . Alternatively, they can choose to hire external support and maintenance. Many users – , particularly advanced ones in particular – want to be able , desire the ability to customise and adapt the software, and they are often happy willing to debug and maintain it. In research and education, the obligation to pay for softwarecost of commercial licences, overheads related or to their procurement and renewal of commercial licences, and related commitments are barriers that cannot be overcome by pose barriers for students, early researchers or and small research groups. Access to the source code may can also reduce their the learning curve and allow them to be more effective enhance developers' effectiveness with the technology. FurthermoreMoreover, the cost of highly specialised or tailor-made software is often unacceptable cost-prohibitive, even for large organisations, especially if when a working solution can be achieved by combining and customising even several freely available building blocks. These factors have led to the wide widespread adoption of open source in more advanced and specialised communities, the emergence of entirely new usage scenarios, and, along with the commodification and componentisation of computing resources and runtime environments, execution platforms and the introduction of large toolsets or architectures with many multiple components, such as those based on microservices.
• Innovation and flexibility – The easy Easy access to the source code enables empowers developers to add the features they need and incorporate novel ideas, algorithms and usage scenarios. They are not constrained by the organisational, commercial or strategic limitations of imposed by vendors of proprietary software, where the users would have to wait for the vendor to decide to provide and implement what they needwho may delay or decline to provide the required features. The more useful a new feature or solution is, the more developers and companies will are likely to join and contribute. The more programmers contribute to it, the Increased contributions lead to better, more useful and more valuable the result is going to beresults. This collaborative approach has been proven to work effective even if the when contributors are not required to share their derivative works. Furthermore, people who inherently need a specific improvement are more driven to provide a individuals with a genuine need for specific improvements are often more motivated to provide creative and innovative solution solutions than those who are just paid to produce something.
• Security and reliability through transparency – When the source code is available, many people can scrutinise or debug it. The security and functional flaws are more likely to be spotted and suboptimal solutions or vulnerabilities fixedThis facilitates the detection of functional issues, security vulnerabilities and suboptimal solutions and enables their prompt resolution. Contributors are aware that their code will be reviewed by other experts will be looking at and reviewing their code, and will therefore tend to stick , which encourages them to adhere to higher standards of quality. Every new Each reviewer can see what has been done before and what went wrong with it. If they try to fix it, they may be more incentivised to come up with a better solution than someone who had to adapt to strict deadlines and other limitations or priorities. Also, someone in the right context due to their combination of learn from previous attempts and identify past mistakes. The non-obligatory nature of commitment to the project allows contributors to be incentivised to find better solutions than developers bound by strict deadlines, commercial or contextual limitations. Additionally, individuals with the necessary skills, prior knowledge, experience or earlier dealing familiarity with a similar problem is problems are often in a better position equipped to detect and address an issue issues or bug bugs than the original author. Many open - source projects have dedicated reviewers who check evaluate modifications before they are included including them in the main codebase. They are not testers, but experts who These experts care about the code quality of the code and can work at their own pace. All these factors greatly improve software These factors significantly enhance the security and reliability , and this is the main reason why the great majority of services on the internet are nowadays running on Linux. With open source, when a vulnerability is of open source software. In the event of a vulnerability being identified in an active open - source project, the interested community members usually swarm in and quickly collaborate to promptly patch it. However, only those who keep up with the latest recommended versions, including the libraries they rely on, will can benefit from this dynamic activity.
• Longevity – Commercially licensed software can be retired by its vendor, who no longer supports it. The vendor may go out of business without selling its software to another company. In such situations, there is no way to update abandoned software, fix bugs, or adapt it to new uses or platforms. Support, patches and other related services are not no longer available anymore. Therefore, its usability can deteriorate quite rapidly and the user must decide when to invest in new software and migration migrate to it instead of living with the growing problems. In contrast, open - source software is free to evolve continuously as anyone can access the source code and contribute to it. Even after it has been abandoned for some time, anyone can revive, adapt, fix or repurpose it. Many useful and widely used FOSS OSS have wide, active and stable user communities, the members of which include individuals and including individuals, research groups , but also and large and small companies.

Types of FOSS licences

The best example of all the aforementioned qualities is Linux, which is the operating system of the cloud, with a market share of over 90 per cent of servers on the Internet. Linux is free and supports innovation and flexibility by constantly updating its core and functions practically on any kind of hardware. It inherits a multiuser and scalable design from UNIX and it is very reliable, running for multiple months and even years without the need to restart the system.

Types of OSS licences

Open source licences are licences that allow software to be freely used, modified and shared [https://opensource.Open source licences are licences that allow the software to be freely used, modified, and shared [https://opensource.org/licenses]. Although there are many "Free free software" and "open - source software" licences that are recognised by the Free Software Foundation (FSF) and approved by the Open Source Initiative (OSI), there are just a few licences that are popular, widely used, or have only about a dozen are used by the most popular software with strong communities. However, a single software project may include several components, which transitively include transitively other components, which may result resulting in the presence of many software licences. To be approved as open by OSI, software licences must meet some certain criteria [https://opensource.org/osd]. But even open licences differ in terms of the rights and limitations they include, which are often on regarding derivative works, such as modification of the original code or its use from the in new code. About half of the licences require disclosure of both the existing and new code to external users or when distributing the software, but they do not require this for private use. It should be noted that a few of them also consider access over the network as the to be a use that implies the right to receive the source code. They also specify whether modifications or the code using the licensed code must be released under the same licence or a similar licence may be used. The scope of this may be limited to modifications of existing files, additions or even any uses of a software library.

The open - source rules are designed so that those who receive copies of the software must themselves be able to redistribute the original and make derivative works from the original, at the same time while also allowing others to do the same. Some licences prevent open - source code from “getting closed” and require that users and contributors to the code propagate put up with uphold open - source values by sharing their modifications or additions (derivative works) on the same terms as the original. This means that those who receive copies of these works must be able to redistribute the original and make derivatives ad infinitum.

As opposed In contrast to Creative Commons CC - ND and CC - NC licences, an open - source software licence must allow modifications or commercial uses to be considered truly open. If the licence prohibits the licensed material and derivatives from being used for commercial or (for example) military purposes, it is considered not to not be a free software licence since it limits who can use a program or and for what purpose. The OSI does not allow discrimination against persons, groups , or fields of endeavour in using the software, so it can be used for any purpose, including any business.

Most licences require the licence text as well as the copyright notice to be included with the licensed material. Some also require documenting the changes made to the licensed material.¶

Pieces of software may modify or extend fragments of already existing software, which is similar to the creation of “derivatives” in CC licences. To preserve the integrity and ensure maintenance of the original work, open - source licences often require derivative works to be distributed on the same terms under which the licensee was permitted access to the original work, such as the source code that was used (incorporated, copied or potentially modified) and the use of the resulting components, such as software libraries. While CC - ND licences condition sharing and reuse as long as the content is left unchanged, a piece of software may other software may use other software in many ways which that do not require any modification or even the actual inclusion of the used software. A piece of software may depend on other software by relying on its definitions, contained specifications, and interfaces , or by invoking it invoked through dynamic or static linking , or network communication and different types of interfaces and connectors, or connectors. Therefore, software licences differ from those used for other types of works as they are focused work. They focus on different ways software may be used, and, when a specific type of use occurs, how it affects the licensing of other software that is using it , and the scope of that impact. These terms include all conditions and obligations defined by the licence of used software. If demands are low, the licence is called permissive, as opposed to restrictive, or, more correctly, copyleft Open source licences guarantee the freedom to use, modify, and redistribute software. The main difference between permissive and copyleft licences lies in derivative work. Copyleft licences require the licensing of produced code under the same licence, while permissive ones do not have that kind of restriction. If the scope is narrow, it does not extend to all extensions of the used work or the entire software that uses the licensed material. Instead, it is limited to requiring the availability of modifications of the original work or the changed changes to existing files. The term that is used in this case is '"weak copyleft'". If the scope is broad, the licence of the used component and related conditions must be applied to all software that uses it. This is called '"strong copyleft'".

• Public domain licences offer the most permissive model. Anyone can modify and use the software without any restrictions. But even if a component is While a public domain licence offers the fullest degree of freedom to build upon and reuse software licensed in this manner, it is not always possible to waive all rights under some countries' laws and regulations. In such cases, the CC0 licence can replace the public domain for all practical purposes. But even if a component is free and comes without any legal strings attached, one should always make sure it is secure before adding it to the codebase.
• Permissive licences contain impose minimal requirements about on how the software can may be modified or redistributed. Users do not have to republish any the changes they make and typically usually only have to give preserve the licence text and attribution to the original authors. They may provide a disclaimer and, often, require describing with some licences, need to describe changes. This type of licence is used by almost two-thirds of open - source software in circulation [https://www.synopsys.com/blogs/software-security/top-open-source-licenses/]. Permissive licences are popular due to the flexibility they offer to those who use such licensed software and the low IPR risk. These licences include the MIT (the most popular one, short and simple), Apache 2.0 (requires notice of changes, grants licence a license to patents unless litigating and mentions preservation of trademark rights), BSD (some versions require including the disclaimer), and ISC (along with its OpenBSD variant, which is a further simplification of MIT and BSD). The Artistic License (used for Perl and available in several variants of versions 1.0 and 2.0) is permissive, but it also includes compensation for damage. These licences are used by almost two-thirds of the OSS in circulation and account for the vast majority of external dependencies used in GÉANT projects.

• 
  

  Copyleft licences (Copyleft licences, also known as reciprocal licences or restrictive, protective , and even viral licences, ) allow the modification of the code and the distribution of new works based on it , as long as provided the requirements for redistribution under the same conditions are met. The intent is to ensure that rights that the user or modifier has benefited from are preserved in derivative works by disallowing the contributors to appropriate their changes and come in an asymmetric position to upstream contributors. This typically means that anyone who changes the code also has to release their modifications newly produced code must be under the same or a compatible licence and, therefore, available to users to modify or use for other purposes. Copyleft licenses licences are often considered to be riskier in commercial settings, as they can limit the potential business value or threaten jeopardise the secrecy of intellectual property. All copyleft licences are used by more than one-third of open - source software. They are less present in GÉANT projects, but even a single usage may have serious impact on licensing options available to a software project.
  
  • Weak copyleft licences have a library or file scope. Examples are
  • Weak copyleft licences have a library or file scope. Examples are the LGPL (Lesser GNU General Public License; version 2.1 cleans text of 2.0 and allows dynamic linking without enforcing copyleft; version 3.0 grants the use of patents, it is not compatible with LGPL 2.0 but is with Apache 2.0 and the end-user must be able to install a modified version – it prohibits closed devices, DRM or hardware encryption or patents retaliation), EPL (Eclipse Public License 1.0 and 2.0), MPL (Mozilla Public License 1.0, 1.1 and 2.0 – it is simple, allows static linking and has licence variants with additional terms), Ms-PL (Microsoft Public License), Ms-RL (Microsoft Reciprocal License), and CDDL (Common Development and Distribution License 1.0 and 1.1) require releasing the modified code only, thus allowing the use of open - source libraries in proprietary software. MPL, Ms-RL and CDDL require this only for the modifications of to existing files. Libraries under LGPL, EPL and Ms-RL allow proprietary licences for the code that is using them, but the original licence also extends to new files in a modified library.
  • On the other hand, strong copyleft licences often require releasing the entire project or product under the a licence that is the same or similar to the one that of the used work. Among the copyleft software, the use of strong copyleft licences significantly prevails. These licences intend to keep everyone on the same page and disallow ‘free ride’ a "free ride" which is still possible with permissive and weak copyleft licenseslicences. By introducing these restrictions, the creators of strong copyleft licences wanted to expand the presence of open - source software, ensure the sustainability of the open - source software ecosystem and strengthen the open - source - software movement. The most common and widely used licence is the GPL (GNU General Public License; version 2.0 is more often used; version 3.0 grants the use of patents, ; it is compatible with Apache 2.0 and ; the end-user must be able to install modified software).
  • AGPL (Affero General Public License 3.0) is similar to the GPL, but it is also network protective. Use over a network is considered a distribution, thus requiring modified code to be available to external users. It is becoming increasingly popular , as it closes the ‘ASP"ASP/SaaS loophole’ loophole" of the GPL, which allow the allows software under the GPL to be exploited without disclosure, as SaaS software by its nature is not distributed to users. The AGPL is, as stated in its preamble, “specifically designed to ensure cooperation with the community in the case of network server software”software.”

Highlight: It is important to fulfil the requirements of the chosen FOSS OSS licence and ensure that there is also licence compatibility. If you did do not fulfil the licence requirements, you are breaching licensing conditions, which might lead to significant financial loss. 

Source-available and

...

'fauxpen' licences

There are also non-FOSS OSS restrictive licences which that are often presented or perceived as being similar to FOSS, OSS but which introduce limitations that prevent them from being open - source according to the Open Source Initiative (OSI) and free according to the Free Software Foundation. Source available licenses licences (or shared source licences) are proprietary licenses licences that allow for source code to be viewed and only , in some cases, modified and redistributed. They make the code available for viewing to facilitate scenarios such as inspection, understanding of functioning, debugging, integration or testing of external components. Examples of such restrictive licences are the Business Source License (BSL), Microsoft Limited Public License (Ms-LPL), Microsoft Limited Reciprocal License (Ms-LRL), and Microsoft Reference Source License (Ms-RSL). Some of those these licences only grant rights to developers of Microsoft Windows-based software, while Ms-RSL allows viewing the source code for reference and debugging.

The user has no rights to use, share, modify or even compile the code. Having just access to the source code is not the point of FOSS, but essence of OSS; it is having the full freedom to use it, including for commercial or disreputable purposes, as long as the same freedom is preserved for those who use or even possibly pay for the code in question.

‘Fauxpen’ 'Fauxpen' licences are similar to source-available licences. They are presented as open, but under closer scrutiny, it becomes clear that licensed software or product is effectively under the strict control of its vendor. These hybrid licences are intentionally deceptive and confusing. The Server Side Public License (SSPL) is a strong copyleft source available license that requires licence. It claims similarity with AGPL v3.0, except for article 13. While this article in AGPL requires the modified source code of programs used remotely to be made available to users, SSPL requires the public release of the source code of service management layers when providing a service. This restricts cloud providers from offering SSPL-licensed software to third parties as a service as this since it requires them to release under the SSPL the entirety of their source code, APIs and other software required for a user to run an instance of their service. SSPL also makes it impossible to use the Linux kernel, which is under the incompatible GPLv2-only licence. SSPL is therefore discriminatory toward towards a specific field of use. ELv2 (The Elastic License v2version 2 (ELv2) is a non-copyleft license prohibiting licence that prohibits providing the products to others as a managed service, circumventing the license licence key functionality or removing or disabling features protected by license licence keys.

Open Source’s The OSI's Open Source Definition rule 6 (“no discrimination against fields of endeavour”) and FSF’s the FSF's freedom zero : (“the freedom to run the program as you wish, for any purpose”) clearly indicate that 'fauxpen' and source-available licences are not FOSSOSS. Providers of software who switch to such licences effectively transition projects that started as open source into proprietary licences and admit that their business models are inconsistent with open source. They claim that they to want to protect their work from unfair exploitation by cloud providers and other free riders who would use their software without backing its creation and maintenance. At the same time, they appropriate the contribution contributions of external developers who have donated their time and energy by adding to projects while they were still were open source. AlsoAdditionally, these companies most often use code from other open - source projects to power their businesses.¶

When a provider is switching switches to a proprietary commercial licenselicence, it they can choose the time, terms and cost. The future costs of software and even its future availability are unknowable, as with similar to any other proprietary software. When previously open software is embedded in or changed into a proprietary product, its users have to agree to the terms of a proprietary licenselicence, be left with an unmaintained version , or fork the last open version of the software and carry bear the associated burden of maintenance forever.

Products subjected to this bait-and-switch move became popular because they had been marketed as being FOSSOSS, as developers prefer to be able to control whatever runs in their programs , and fix it or to have other people fix it, although even if they are not affiliated with the original maker of the tool or component. Also, such Such platforms gain traction as they typically provide free and one-stop comprehensive solutions, where expensive licenses licences for commercial alternatives tend to add up , and open - source substitutes are less integrated. Even the developers in big large enterprises prefer using FOSS to OSS over going through the slow, bureaucratic and multi-layered approval and procurement procedures.

The only advantage of the prior FOSS OSS status is the possibility to fork the prior previous version, but even this window of opportunity may effectively close after some time if the community sticks with the vendor and its proprietary changes. Forks are also hard challenging due to the resources needed and the necessary switch in branding , whereas since people do not switch easily from one brand to another.

All this Highlight: The emergence of 'fauxpen' source licensing implies that access to updates of software under permissive licences and those with the ' sublicense ' option may be volatile in the long run if the software is controlled by a single entity, as demonstrated in the cases of Elasticsearch and MongoDB. This is why it is so important crucial to carefully choose software that is guaranteed or, at least, most likely to remain FOSSOSS.

Copyrights, patents and warranties

A copyright Copyright is a form of intellectual property which that allows a the legal creator of an original work to license that work to the extent governed by copyright law. Declaring copyright on some a work does not require any registration or official notice but just to ; it simply requires clearly and visibly declare stating the copyright and define defining its subject. The copyright can also be also easily transferred to another subjectparty, typically through a contract or statement. Since open -software source licences by definition already open up the work to anyone under clear conditions, copyrights as such are not a problem, but the actual exact details of these conditions are. The licensing concern related to copyright is whether the licence states it and how the text of the license licence and copyright notice (with the original copyright and attribution marks) should be included with the licensed material and presented. For example, the inclusion of the copyright may be required only for the source code or may also include binaries.Highlight: What is important, under

Highlights:

• Under copyright law, only the expression of ideas – not the ideas themselves – can be protected.

...

• Written works, software and art are protected by copyright. Patents protect specific inventions, that is, technical solutions providing exact instructions for solving a problem.
• Since software is protected by copyright law, the

...

• wide variety of

...

• OSS licences with different requirements allows software developers to grant specific rights to other users

...

• as stated in the chosen licence while still retaining their copyright-protected rights. Therefore, it is crucial for developers to clearly state the copyright along with the licence.

licence itself.Patents are a much more complex form of intellectual property. An organization organisation or individual who invented invents something substantial, novel and useful proves this in through a regulated, expensive and time-consuming patent registration procedure. If this process is successful, a patent owner is granted the right that excludes to exclude others from making, using, selling, offering or making available the patented invention for the a predefined period, such as 20 years, during which the patent may be subject to maintenance fees. A patent may provide the holder with the associated royalties in terms of monetary compensation for using itits use, while its infringements are internationally enforceable and punishable in courts. Patent owners try to extend the boundaries of their patent and, at the same time, scan for infringements to maximize the maximise royalties and penalties and , thus recover recovering the costs of patent registration or purchasing and purchase, as well as maintenance, scanning and litigation. Therefore, there is always a risk of possible and even unknowing infringement of a patent by the licensor of software and, subsequently, their licensees.

Some licences describe the handling of potentially applicable patents and royalties, which removes at least some of the patentspatent-related uncertainty. A licence may state that it does not grant any rights to the contributors’ patents. Or it may contributors' patents or explicitly grant contributors’ the contributors' patent rights. Both models eliminate some uncertainties, but they do not resolve the patenting issue. The latter approach is an attempt to prevent the appropriation of innovation and software through patents. But However, no software license licence would protect a licensee against a claim of infringement brought by a third-party patent holder , as since licensors can only license works that belong to them. Since software patents are often too vague, abstract and or ambiguous, they may can be easily weaponised ; they and may even protect even concepts or methods of interacting with a system. Neither the licensor nor the licensee may be aware of such a patent, so a patent troll or a competitor with an applicable patent may appear at almost any moment.

Even if a patent holder has licensed that patent for use in open - source software or the applied FOSS OSS licence waives any patentspatent-related obligations, that patent may later be later narrowed or cancelled through litigation by a holder of a rival patent. If this happens, even the software licensee who has fully complied with the terms of the original license licence and the licensor’s licensor's patent may become liable for infringement of a competing patent if it continues they continue to use the affected software. Since the patent narrowing or cancellation would affect not only the holder of the original patent but also its licensees, licensees may want to participate in protecting the licensor’s licensor's patent. As this This can become expensive, and licensees may embark on such an endeavour only if their business would be seriously affected by the requirements of the competing patent holder.

...

Most licences require the licence text, as well as the copyright notice, to be included with the licensed material. Some also require documenting the changes made to the licensed material.

Some licences:

• Describe the circumstances in which the source code must be made available.
• State whether the changes must be documented.
• Describe the allowance or prohibition of using contributors' names, trademarks or logos.
• Declare whether they include a limitation of liability. Some clearly state that there is no warranty and that the software creator cannot be charged held liable for damages. They explicitly assert that they do not offer any warranties or guarantees for using the code, so that the author cannot be held liable if the code does not work well in some usageinstances.
• Are peculiar in what they consider software usage , or even constrain types of use (e.g., by prohibiting commercial, over-the-network or military usage), which disqualifies them from being considered real FOSS OSS licences.
  

Contributor agreements

Copyleft licenseslicences, in principle, prevent the code from being incorporated into or re-licenced relicensed to proprietary code. However, a licence change may still be possible with a loophole opened by contributor agreements. Terms that are typically used are Contributor License Agreement, Copyright Transfer Agreement or Copyright Assignment Agreement. These agreements are used by organisations that are guardians of software to own or use contributions. They may include a transfer of copyright. However, when these agreements include the transfer of unrestricted republishing rights (regardless of copyright transfer), allow distribution without restriction or explicitly permit relicensing and even sub-licensingsublicensing, the contributed code can be relicensed at the discretion of the guardian.

Relicensing and multi-licensing

Software relicensing is done for commercial reasons , or to improve licence compatibility. In the first case, the change is typically toward towards a proprietary licence that is often blurred as a ’fauxpen’ 'fauxpen' or source-available licence. The result of such relicensing is the elimination of some previous uses or users.

Relicensing is for better licence compatibility is conducted if the current licence is incompatible with those of other jointly used components so that a greater combined work could be licensed somehow.

Relicensing is possible:

• Due to the prior use of a permissive FOSS OSS licence or another licence that allows sublicensing;.
• If it is allowed to the guardian organization organisation by contributors through contributor or copyright agreements, by which they grant the organisation the right to sublicense or relicense, that is, redistribute the work under a different license;licence.
• If it is decided by the owner of the proprietary code so decides.

Adding an alternative licence is not relicensing, as the old licence remains fully valid for those who decide to stick to it. Multi-licensing is, therefore, a better way to improve licence compatibility than relicensing. Also, it does not require a prior Furthermore, all contributors do not need to have previously signed a permissive licence or contributor agreements signed by all contributors. “Or later” styled licences are a concisely expressed agreement. Licences with an "or later" option are a concise form of multi-licensing in which all subsequent versions of the mentioned said licence are accepted in advance, including those which currently still that do not currently exist.

Governance of

...

OSS licences in general

Use of

...

OSS licences depending on project intent

For internal use

• One can use any FOSS and not worry about licences – they have their code and are not giving it to anyone, which is OK with all FOSS licences.
• The code is kept private, but internal use is very limited – the use of software may easily evolve into sharing or use in commercial contexts that directly involve other parties.
• What when the creators later decide to offer software to others? Without considering the licences of used components. They may end up with components with incompatible licences, unable to choose one for the product/project. Therefore is important to:
  • Start early to consider licences and overall attitude towards FOSS licences.
  • Learn about licences of used components and determine which licences are acceptable within the project.
  • Determine the potential future licence if the way software is used is changed.

Sharing software with someone

• With permissive licences of components, the modifiers do not have to make any source code available.
• With copyleft components, access to some or all source code must be allowed.
  
• When sharing, the same or compatible licence for changed code or even the entire project must be used.
  
• With several strong copyleft components, the creators may not be able to pick up a licence that is compatible with all of them.
• Licence compatibility has become a major and very actual issue in the wider software community.
  
• One should think twice about the software under a permissive licence that is effectively controlled by a single entity, especially if the software may be used in a service. Some modifiers or their customers may therefore prefer copyleft so that would be protected from licence changes.

For a service, the provider is safe if using any FOSS except one under AGPL (but even that as well as long as it does not mind letting the users get its code or do not want to use it from cloud providers, which may be forbidden from offering a service based on such software. The same applies to ‘fauxpen’ licences such as SSPL or ELv2.

Licence impact on community, quality, longevity and sustainability

Projects often follow a natural cycle of creation, a burst of intense activity, a long phase of steady use and productivity, and fading as it is replaced by new projects covering the same space but with a more advanced technology base; this happens through the slow or fast migration of the community. Factors that affect software sustainability and longevity are often analysed [https://opensource.com/life/14/1/evaluate-sustainability-open-source-project, https://repositum.tuwien.at/handle/20.500.12708/2820]. The longer the project is alive, the more likely it will exist. The activity of the community (number of contributions and active contributors) and the quality of its core members are more significant than the size of the user base for the sustainability of the software. An analysis of the Ohloh data [now at https://www.openhub.net/] about a large number of FOSS projects [https://redmonk.com/dberkholz/2013/04/22/the-size-of-open-source-communities-and-its-impact-upon-activity-licensing-and-hosting/] indicates that:

• The larger the project is, the more like it is to work out the licensing issues and specify a licence. The portion of projects without a specified licence decreases with the number of monthly committers – they start at about 50% for a single committer, decrease to 40% for five, and stabilise at about 20% for projects with more than contributors.
• Permissively licenced projects are evenly distributed regardless of their size. They start at 20% for up to 10 monthly contributors, peak at about 25% for 20-30 contributors, and then return to the baseline.
• The use of copyleft licences coincides with the size of the active community. It starts with about 20%, increases to about 35% after 10 committers, and ends up at about 40% for projects with many contributors.

Highlight: The lack of a clear licence is an indication that the developers find licensing unimportant, confusing or too time-consuming for their purpose. Such projects do not tend to last long and establish a large community.

The utility of software is maximised if the widest possible set of users can appropriate its benefits. But FOSS, like many other parts of the digital infrastructure, suffers from a free-rider problem: “Resources are offered for free, and everybody (whether individual developer or large software company) uses them, so nobody is incentivised to contribute back, figuring that somebody else will step in.” [https://www.fordfoundation.org/work/learning/research-reports/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/]. A free rider has a competitive advantage, since it did not have to invest in the original development, and can invest in developing additional benefits and services instead. While a free-rider does not exclude others from using the code, which is not an exclusive resource, it may exhaust the original creator’s access to users. Users turn into customers; customers are an exhaustible common resource as they tend to stick to one provider. Customers contribute to provider income in various ways defined by its business model. Although most people perceive free riding as deeply unfair, it is still better to have someone using the creator’s open-source software than somebody else’s. The presence of a free-rider makes it more likely that others will also use this software and some of them will contribute back. Therefore, software free-riders, including competitors who capitalise on others’ work may have a positive overall effect as they act as mediators towards other contributors and customers. A large user community brings the contributors and paying customers and even brings the sponsors who otherwise would not show up. Still, for this to happen it is necessary to prevent the competing free-riders from suffocating the primary contributors. This means that the original contributor’s offering (beyond just software) must be made somewhat exclusive to incentivise users and customers to join.

• Permissively licences software may start small, stay that way, or increase in terms of activity, but seem to be somewhat limited by the optionality of returning to the community by those who modify it.
• Weak copyleft licences are suitable for libraries and other components the popularity and utility of which would be significantly affected by expansive licensing rules of strong copyleft licences.
• Strong copyleft licences are suitable for large or stand-alone projects such as operating systems and specialised or productivity tools.

There is a growing number of companies whose business model is based on FOSS. This is model is called commercial open-source software. Their commercial offerings usually take the form of proprietary or closed-source IP, which may include a combination of premium features and hosted services that offer performance, scalability, availability, productivity, and security assurances. This is known as the ‘open core business model’. Some of them also offer professional services, including maintenance and support assurances.

The obligation to keep all modifications under the same or compatible copyleft licence works exceptionally well in projects such as the Linux kernel. This is particularly the case when the licence does not preclude the use of software to run other software under other types of licences. Therefore, the use of a copyleft licence may be a great benefit to the software, especially if it does not reduce its use in normal usage scenarios. This is why weak copyleft licences such as LGPL were designed for and they are applied when it is more important to enlarge the number of contributors (as with research software) than to boost its popularity by maximally liberal terms of use or to keep the competitive advantage by keeping the code proprietary. Furthermore, a combination of (often copyleft) open-source with additional proprietary add-on components or services on top is an often applied approach that balances openness with sustainability.

If a large enough member of the community has a sufficient influence on the platform, it may decide to fork it under a ‘fauxpen’ proprietary licence that significantly constrains its use, at the same redirecting most of the current users to the fork and taking full control over the new developments in it. The inadequacy of the original business model or the appearance of competing offerors is the reason for some makers of open source products, which have been seen as its custodians by the communities, to make this move. Of course, this is possible only with permissive licences that typically allow appropriation through relicensing. The appropriator does not even have to be the primary contributor to software, but the one most users refer to, for example by providing support or popular commercial add-ons. A similar outcome may be caused by the extensive use of software as a part of a cloud offering, where the cloud provider effectively distributes and monetises open-source software without meaningfully contributing back to it or by providing proprietary add-ons, which are typically limited to facilitating access to the platform within its cloud offering. The original ‘open core business model’ provider may then move to a network protective or ‘fauxpen’ licence. However, some projects with permissive licences, such as the Apache web server, have an extremely long lifespan and a huge community.

It is not possible to empirically determine whether software longevity benefits more from copyleft or permissive licences, as this more depends on other circumstances. The choice of a licence supporting sustainability and longevity of software primarily depends on the attitude of the developers and community, as well as the primary usage scenarios. Of course, such a choice may not be available at all due to the requirements imposed by the organisation, funder or dependencies. Interestingly, when this choice is available, it may be more dependent on intrinsic motivations and view about fairness than extrinsic motivations such as the expectation of reputation or economic gain [https://opensource.com/law/13/8/motivation-free-software-licensing]. On the other hand, if the developers invest in interoperability and open standards, this may greatly help project adoption regardless of the licence.

Multi-licensing under permissive and copyleft or copyleft and proprietary terms is also a viable solution, as it increases licensing compatibility when the software when is to be combined with other components into new products. At the same time, it allows for a larger user base and, at least to some extent, stimulates future contributions.

The user base is also not to be neglected, and it greatly contributes to the sustainability of permissive FOSS. Users drive the functionality, identify the bugs, and shape the direction of a project to meet their needs. This may result in slick products that ‘just work’ without much configuration and customisation, as long as the target audience is large enough and there are other factors that contribute to the product ecosystem. Still, it is often very hard to determine the size and engagement of the user community. What is often much easier to assess (when choosing), but hard to incite (when developing), is the wider ecosystem around a project established by the engagement of other providers which may offer support, consultancy, customisation, hosting, or bundling with their products or services.

Besides often emphasised doubts about the FOSS business models, some authors [Lanier, You are not a gadget] dispute open source and open content expropriation of intellectual production as a form of "Digital Maoism" which stifles small-scale entrepreneurship and destroyed opportunities for the middle class to finance content creation, resulting in the concentration of wealth in a few corporations and individuals, who insert themselves as content and service concentrators. However, instead of FOSS, this criticism should be rather directed to the centralisation of distribution and advertising platforms and the model of “free services” paid for through reselling of personal data, user profiles and targeted marketing. The large concentrators depend on FOSS like anyone else, but their core components are always proprietary. On the other hand, big tech companies frequently create or appropriate FOSS platforms and tools for consumers and developers to tie the customers to their ecosystems and technologies. Typical examples are some very popular application development tools, run-time environments, non-SQL data storage and processing platforms and AI platforms which are typically conveniently tied to companies’ cloud offerings. Therefore, whenever a big tech company offers a sleek FOSS component or platform, developers should think twice if they want to become ‘products’ again and be recruited into the company’s camp.

Despite FOSS’s success, scaling and sustaining open-source projects remain challenging.

Licence selection and attaining compliance

Copyleft licences ensure licensing stability, while permissive software can be forked and relicensed by a major contributor or a company providing popular free or commercial services or products based on this software. Such an organisation can also strongly influence software evolution and usage patterns.

• Available options may be mandated or recommended by the institution, project management or funder.
• The constraints of other involved parties and coauthors must be respected.
  
• The constraints imposed by original authors and licences of dependencies must be respected.
• There may be some typical and established software licensing practices of the community.

Personal preferences and attitudes of software authors, who should also consider desirable public messages and non-mandating institutional, project-level or funder preferences on software licensing and open source.

The choice is typically quite simple. The existing constraints most often mandate the type of licence. If these institutional or other policies prohibit the use of copyleft licences, this also means that the software must not use components under such licences. But if this is allowed and such components are needed and useful, then a compatible copyleft licence is to be used.

The opportunity for a relatively free choice exists in a situation where all important used components come with either permissive or weak copyleft licences. But if components with weak copyleft licences are modified, the modification must retain the original or use a compatible licence.

Highlight: Permissive (non-copyleft) open source licences, such as MIT license, BSD-based licences or Apache License 2.0, are strongly encouraged for GÉANT software projects. Permissive licenses guarantee the freedoms to use, modify, and redistribute the code. As software under strong copyleft cannot be integrated into software under permissive licences, strong copyleft licences shall be avoided - such a licence may be approved by the GÉANT IPR Coordinator if it does not impede the adoption or reuse of software in the target community and it is mandated by a wider collaboration or it is necessary due to the licence of a critical component without a viable alternative. Software-related artifacts (technical documentation, configuration and user guides..) that are distributed with software or kept in its source code repository should be under the same licence as software. For separate tutorials, presentations or standalone training or promotional materials, the CC BY-NC or CC BY licence is recommended.

Typical steps

Gather information (can be done with Mend)

• Note the licence of the ‘product’ (entire bundle of created components) or ‘project’ (one program or stand-alone component), if set
• Create an open-source inventory of used components
• Detect vulnerable open-source components (to remove or replace)
• Identify outdated open-source libraries (to replace?)
• Identify licences of used components (in-licences)
• Clarify ambiguities or doubts, such as those on the use or modification of libraries
  
• A tool may not be able to properly identify a licence – in Mend, some are 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’ licences may be unclear or even edited in the licence text
• Document gathered information – Mend does the above through reports, UI and data exports
• Document your decisions – some may be refined during remediation

Document (can be done with Mend)

Remediate

• Choose a product/project licence (out-licence) compatible with key dependencies
• Initial 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
• Enforce open source licence compliance (e.g., provide all required compliance artifacts)
• Accept some risks

Create compliance artifacts (to ensure compliance)

Software composition analysis – inventory tools

Ideally, compliance should be continuously monitored as a part of the build process.

Commercial services

• WhiteSource (now Mend, used in GÉANT)
• Black Duck (the most commercial solution)
• JFrog Xray (add-on for Artifactory)
• GitLab Ultimate licence compliance feature – https://docs.gitlab.com/ee/user/compliance/license_compliance/
• …

FOSS solutions

• FOSSology, https://www.fossology.org/
• QMSTR (Quartermaster), toolchain and reports – it was stalled, now back to progress, https://qmstr.org/
• Scancode-Toolkit, https://github.com/nexB/scancode-toolkit
• License Compliance Verifier (LCV), Demonstrator based on a subset of the compatibility rules from the Open Source Automation Development Lab (OSADL) matrix, https://github.com/fasten-project/fasten/wiki/License-compliance…

Highlight: Each GÉANT software project shall be analysed with the GÉANT-endorsed Software Composition Analysis tool in order to ensure licence compliance and licence compatibility.

Licence selection tools

Below you will find resources which may help you with your selection:

• Choose an open-source license – Provides an excellent overview of why you might choose various types of open-source licences, https://choosealicense.com/. Permissive licenses are those which do not include the “Same License” condition at https://choosealicense.com/licenses/.
• Joinup Licensing Assistant – Find and compare software licenses, https://joinup.ec.europa.eu/collection/eupl/solution/joinup-licensing-assistant/jla-find-and-compare-software-licenses
• Creative Commons (CC) licence chooser, https://creativecommons.org/choose/, https://chooser-beta.creativecommons.org/.
• https://opensource.guide/ provides general resources and guides for getting started in open-source software. It also includes an excellent overview of the legal side of open-source software, https://opensource.guide/legal/.

• When using OSS solely for internal use, there is generally no immediate concern about licences since the code is not being shared with others. In this scenario, any OSS can be utilised without worrying about the licences of the components. As long as the code remains within the organisation and is not distributed to external parties, all OSS licences permit such internal usage.
• However, it is important to recognise the limited nature of internal use. The use of software may evolve over time, potentially involving sharing or commercial arrangements with other parties. Therefore, it is important to consider licences early on if there is a possibility of offering software to others in the future. In such cases, it is necessary to gain an understanding of the licences associated with the components used and determine which licences align with the project's requirements. It is also wise to anticipate potential changes in software usage and consider the appropriate licence for such scenarios in advance.
• If the creators ultimately decide to offer software to others, they may encounter components with incompatible licences, making it challenging to select a suitable licence for the product or project. Hence, it is of utmost importance to:
  • Initiate the consideration of licences and establish an overall approach towards OSS licences early in the development process.
  • Acquire knowledge about the licences of the utilised components and determine which licences are acceptable within the project's scope.
  • Determine a potential future licence in case the way software is used changes.

Sharing software with others

• When utilising components with permissive licences, there is no obligation for the modifiers to make the source code available.
• However, if an open source component with a strong copyleft licence is used, any software created using that component must also be released as open source.
• When sharing software, it is necessary to use the same or compatible licence for the modified code or even the entire project.
  
• In cases where multiple strong copyleft components are involved, it may be challenging for the creators to find a licence that is compatible with all of them.
• Licence compatibility has emerged as a significant and current issue within the broader software community.
• It is prudent to carefully consider software under a permissive licence that is effectively controlled by a single entity, especially if the software may be used in a service. In such cases, some modifiers or their customers may prefer copyleft licences to ensure protection against licence changes.

For a service, the provider is generally protected as long as they use any OSS except those licensed under the following options:

• AGPL requires component/software developers to share their source code with users when it is accessed via a network connection, including the cloud.
• 'Fauxpen' licences, like SSPL or ELv2, require service providers to make Service Source Code available in its entirety. This includes "management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software, and hosting software.”

Licence impact on community, quality, longevity and sustainability

Projects often go through a natural cycle of creation, intense activity, steady use and productivity, and eventually fade as they are replaced by newer projects with advanced technology. This transition occurs as the community gradually or rapidly migrates from one software to another. The factors that impact software sustainability and longevity are often analysed [https://opensource.com/life/14/1/evaluate-sustainability-open-source-project, https://repositum.tuwien.at/handle/20.500.12708/2820]. The longer a project evolves, the more likely it is to continue existing. The activity of the community, including the number of contributions and active contributors, as well as the quality of its core members, is more significant than the size of the user base when it comes to software sustainability. An analysis of a large number of open source projects [https://redmonk.com/dberkholz/2013/04/22/the-size-of-open-source-communities-and-its-impact-upon-activity-licensing-and-hosting/] indicates the following:

• Larger projects are more likely to address licensing issues and specify a licence. The portion of projects without a specified licence decreases with the number of monthly committers. It is at around 50% for a single committer, decreases to 40% for five committers, and stabilises at around 20% for projects with many contributors.
• Permissively licensed projects are evenly distributed regardless of their size. They start at 20% for up to 10 monthly contributors, peak at about 25% for 20-30 contributors, and then return to the baseline.
• The use of copyleft licences increases with the size of the active community. It starts at about 20%, grows to about 35% after 10 contributors, and reaches about 40% for projects with many contributors.

Highlight: The absence of a clear licence indicates that developers find licensing unimportant, confusing, or time-consuming. It indicates a lack of appreciation for their own work and the work of other contributors. Such projects often do not last long or establish a large community.

The utility of software is maximised when a wide range of users can benefit from it. However, OSS, like many other parts of the digital infrastructure, faces a free rider problem: “Resources are offered for free, and everybody (whether an individual developer or a large software company) uses them, so nobody is incentivised to contribute back, figuring that somebody else will step in.” [https://www.fordfoundation.org/work/learning/research-reports/roads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure/]. Free riders have a competitive advantage since they did not invest in the original development, and can focus on developing additional benefits and services instead. While free riders do not exclude others from using the code, which is a non-exclusive common resource, they may deplete the original creator's access to users. Users turn into customers, who become an exhaustible common resource as they tend to stick to one provider. Customers contribute to the provider's income through various means defined by their business model. Although free riding is often seen as unfair, it is still preferable to have someone use the creator's software rather than someone else's. The presence of free riders makes it more likely that others will use software and some of them will contribute back. Therefore, software free riders, including competitors who capitalise on others' work, may have a positive overall effect as they act as mediators towards other contributors and customers. A large user community attracts contributors, paying customers and even sponsors who may not have shown up otherwise. However, it is important to prevent competing free riders from suffocating the primary contributors. This can be achieved by making the original contributor's offering somewhat exclusive to incentivise users and customers to collaborate with them. Merely providing baseline software may not be sufficient; additional value and benefits should be offered. Therefore, the original contributors should go beyond simply providing the software itself. They can offer enhanced features, premium services, customisation options, specialised support, or other unique advantages that differentiate their offering from competitors. By providing added value, they create a stronger incentive for users and customers to choose their solution over alternative options.

There is a growing number of companies whose business models are based on open source software. This model is known as commercial open source software. These companies typically offer additional proprietary or closed-source IP as part of their commercial offerings, which may include premium features and hosted services that provide performance, scalability, availability, productivity and security assurances. This approach is referred to as the "open core business model." Some companies also offer professional services, including maintenance and support assurances.

The typical patterns of use of various types of licences are:

• Permissively licensed software may start small, remain that way, or increase in terms of activity, but its growth seems to be somewhat limited by the optionality of returning modifications to the community.
• Weak copyleft licences are suitable for libraries and other components whose popularity and utility would be significantly affected by the expansive licensing rules of strong copyleft licences. The use of weak copyleft licences for such products may therefore provide a fine balance between broad applicability and the obligation to return to the community.
  
• Strong copyleft licences are suitable for large or stand-alone products such as operating systems and specialised or productivity tools.

The obligation to keep all modifications under the same or compatible copyleft licence works exceptionally well in projects such as the Linux kernel. This is particularly true when the licence does not preclude the use of software to run other software under different types of licences. Therefore, the use of a copyleft licence can be greatly beneficial to software, especially if it does not hinder its usage. Weak copyleft licences such as the LGPL were designed for such cases, where it is more important to expand the number of contributors (as in research software) than to maximise popularity through liberal terms of use or to maintain a competitive advantage by keeping the code proprietary. Additionally, combining (often copyleft) open source with proprietary add-ons or services is a commonly used approach that balances openness with sustainability.

If a sufficiently influential member of the community has enough influence on a platform, they may decide to fork it under a 'fauxpen' proprietary licence that significantly constrains its use, redirecting most current users to the fork and taking full control over new developments in it. The inadequacy of the original business model or the emergence of competing offers may drive some open source product makers, who were seen as custodians by the corresponding communities, to make this move. This is possible with permissive licences that typically allow appropriation through relicensing. The appropriator does not even have to be the primary contributor to software but rather the one to whom most users refer for support or popular add-ons. A similar outcome may be caused by the extensive use of software as a part of another company's cloud offering, where the cloud provider effectively distributes and monetises open source software without meaningfully contributing back to it or by providing proprietary add-ons, which are typically limited to facilitating access to the platform within its cloud offering. The original "open core business model" provider may then shift to a network protective or 'fauxpen' licence. However, some projects with permissive licences, such as the Apache web server, have an extremely long lifespan and a huge community.

It is not possible to empirically determine whether copyleft or permissive licences contribute more to software longevity, as it depends on other circumstances. The choice of a licence that supports sustainability and longevity primarily depends on the attitude of the developers and the community, as well as the primary usage scenarios. Of course, sometimes this choice may not be available due to requirements imposed by the organisation, funder or dependencies. Interestingly, when the choice is available, it may depend more on intrinsic motivations and views about fairness than on extrinsic motivations like reputation or economic gain [https://opensource.com/law/13/8/motivation-free-software-licensing]. On the other hand, investing in interoperability and open standards can greatly aid project adoption, regardless of the licence.

Multi-licensing by combining permissive and copyleft or copyleft and proprietary terms, is also a viable solution as it increases licensing compatibility when software is to be combined with other components into new products. It allows for a larger user base and stimulates future contributions to some extent.

The user base should not be overlooked, as it greatly contributes to the sustainability of permissive OSS. Users drive functionality, identify bugs and shape the project's direction to meet their needs. This can result in polished products that "just work"' with minimal configuration and customisation (since everyone is sharing the same expectations and conventions), as long as the target audience is large enough and there are other supporting factors contributing to the product ecosystem. However, assessing the size and engagement of the user community is often challenging. What is often easier to evaluate when choosing software, but difficult to foster when developing it, is the wider ecosystem around a project. This ecosystem can only be established through the engagement of other providers who offer support, consulting, customisation, hosting or bundling of software with their products or services.

Besides the frequently emphasised doubts about OSS business models, some authors [Lanier, "You are not a gadget"] dispute open source and open content expropriation of intellectual production as a form of "Digital Maoism" that stifles small-scale entrepreneurship and destroys opportunities for the middle class to profit from content creation, resulting in the concentration of wealth in a few corporations and individuals who position themselves as content and service concentrators. However, this criticism should be directed more towards the centralisation of distribution and advertising platforms and the model of “free services” paid for by selling personal data and user profiles or using them for targeted marketing. Large concentrators depend on OSS like anyone else, but their core components are always proprietary. On the other hand, big tech companies frequently create or appropriate OSS platforms and tools for consumers and developers to lock customers into their ecosystems and technologies. Examples include some very popular application development tools, runtime environments, non-SQL data storage and processing platforms and AI platforms that are conveniently tied to companies' cloud offerings. Therefore, when a big tech company offers a habit-inducing OSS component or free platform, developers should consider whether they want to become 'products' again and be absorbed into the company's ecosystem.

Scaling and sustaining open source projects remain challenging despite the general success and ubiquity of OSS.

Licence selection and achieving compliance

Copyleft licences provide licensing stability, while permissive licences allow forking and relicensing by major contributors or companies offering popular free or commercial services or products based on software. Such organisations can significantly influence software evolution and usage patterns.

• The available licensing options may be mandated or recommended by the institution, project management or funder.
• The constraints imposed by other involved parties and co-authors must be respected.
  
• The constraints imposed by the original authors and licences of dependencies must be respected.
• The community may have established software licensing practices or expectations that can serve as guidance.

Software authors should also consider their personal preferences and attitudes while taking into account desirable public messages and non-mandating preferences on software licensing and open source from institutions, projects or funders.

The choice of licence is often straightforward. Existing constraints frequently dictate the type of licence required. If institutional or other policies prohibit the use of copyleft licences, software should not incorporate components under such licences. However, if copyleft components are allowed and necessary, a compatible copyleft licence should be used.

In situations where all significant components come with permissive or weak copyleft licences, there is more freedom to choose. However, if modifications are made to components with weak copyleft licences, the modified code must retain the original licence or use a compatible one.

Highlights:

• Permissive (non-copyleft) open source licences like the MIT licence, BSD-based licences or Apache License 2.0 are strongly encouraged for GÉANT software projects. These licences ensure the freedom to use, modify and redistribute the code.
• Strong copyleft licences should generally be avoided for GÉANT software projects unless mandated or necessary due to wider collaboration or critical components. It is therefore preferable to use components with permissive licences. Approval from the GÉANT IPR Coordinator may be obtained if the use of a strong copyleft licence does not hinder the adoption or reuse of software within the target community.
• Software-related artefacts such as technical documentation, configuration and user guides, distributed with software or stored in its source code repository, should be licensed under the same licence as software. Separate tutorials, presentations, training materials or promotional materials may use licences like CC BY-NC or CC BY.

Typical steps in the licence selection process

Gather information (can be done with Mend)

• Note the licence of the software project, product, the product bundle of individual components, if set.
• Create an open source inventory of used components.
• Detect security vulnerable open source components (to remove or replace).
• Identify outdated open source libraries (to replace?).
• Identify licences of used components (in-licences).
• Clarify licensing ambiguities or doubts, such as those on the use or modification of libraries.
• A tool may not be able to properly identify a licence; in Mend, some are suspect or ambiguous.
• Information about a component's (or even your project's) licence may be false, unclear or contradictory.
• Some licences may be recognised under several names.
• Some (permissive) licences (BSD, Artistic, etc.) have unnumbered variants or are sometimes edited by authors.
• The applicability of "or later" licensing option may be unclear or even directly edited in the original licence text.

Document

• Document gathered information – Mend does the above through reports, UI, and data exports.

  • Can be done with Mend or another suitable SCA tool, some details must be manually refined.

• Document your decisions – some may be refined during remediation.

Remediate

• Choose a product or project licence (out-licence) compatible with key dependencies.
• Make initial 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 proprietary licensed software.
• Choose among the available licences for dual- and multi-licensed components.
• Identify the remaining incompatible licences:
  • Decide what to do with components that use these licences.
  • Remove a component or corresponding functionality if not necessary.
  • Replace a component with an existing equivalent.
  • Move a component or functionality to the server side (central service).
  • Write your replacement.
• Enforce open source licence compliance (e.g., provide all required compliance artefacts).
• Accept some risks.

Create compliance artefacts (to ensure compliance)

Manage sideground IPR best practice

The BP-B.6: Manage sideground IPR best practice aims to achieve compliance with the GÉANT IPR Policy and ensure compatibility of the project's software licence with third-party components. It outlines the overall process of software composition and licence analysis, as well as licence selection, which are interconnected and support each other. This practice applies to projects that use external libraries, components, source code or other dependencies provided by third parties, regardless of whether they are open-source (OSS) or proprietary licensed.

This best practice provides a simple outline of the actions that software teams need to take. These include scanning their projects for dependencies, licences and vulnerabilities using Software Composition Analysis (SCA) tools, analysing the results, remediating any detected issues, setting a LICENSE file in projects, declaring the licence in their source code and repositories and tracking and maintaining licence conformance through internal checks and appropriate tools. All these actions should align with the declared licence, the GÉANT IPR Policy and with the support of WP9 Task 2 Open Source Licensing Support and the GÉANT IPR Coordinator.

To comply with this best practice, please follow the steps below:

1. Familiarise yourself with the licences of the libraries and other software included in your product.
   1. Ensure the team has a basic understanding and awareness of intellectual property rights (IPR) and the GÉANT IPR Policy. Use the available materials mentioned in this document and seek support from the GÉANT IPR Coordinator (iprcoordinator@geant.org).
   2. Identify, analyse and document the libraries used by applying a dedicated tool.
2. Verify that the licences comply with the restrictions imposed by GÉANT and the licence compatibility requirements.
   1. Determine the general IPR orientation, such as permissive or copyleft licences and then select a specific tentative licence for the project/product (e.g., MIT or GPL3+).
   2. Review and document the current licences using a Software Composition Analysis (SCA) tool or by visiting the licensors' websites. Correct or refine the information in the tool or document and check their requirements and compatibility.
   3. Ensure compliance with the requirements stated in the applicable licences and the rules and recommendations of the GÉANT IPR Policy. Document the licence, include a copyright notice and publish code changes in the source code repository and on the software project website.
3. Establish a system to track existing licences, adjustments and compliance.
   1. Promptly re-evaluate licence compliance if there are changes in the used libraries, licences or rules (as defined in policy or knowledge base).
   2. Detect, document and effectively communicate any changes.

Software composition analysis – inventory tools

Ideally, compliance should be continuously monitored as a part of the build process.

Commercial services:

• WhiteSource (now Mend, used in GÉANT)
• Black Duck (the most commercial solution)
• JFrog Xray (add-on for Artifactory)
• GitLab Ultimate licence compliance feature, https://docs.gitlab.com/ee/user/compliance/license_compliance/

OSS solutions:

• FOSSology, https://www.fossology.org/
• QMSTR (Quartermaster), toolchain and reports – it was stalled, now back to progress, https://qmstr.org/
• Scancode-Toolkit, https://github.com/nexB/scancode-toolkit
• License Compliance Verifier (LCV), Demonstrator based on a subset of the compatibility rules from the Open Source Automation Development Lab (OSADL) matrix, https://github.com/fasten-project/fasten/wiki/License-compliance…

Highlight: Each GÉANT software project shall be analysed with the GÉANT-endorsed Software Composition Analysis tool to ensure licence compliance and licence compatibility.

Licence selection tools

• Choose an open-source license – Provides an excellent overview of why you might choose various types of open source licences, https://choosealicense.com/. Permissive licences are those that do not include the “Same license” condition at https://choosealicense.com/licenses/.
• Joinup Licensing Assistant – Find and compare software licences, https://joinup.ec.europa.eu/collection/eupl/solution/joinup-licensing-assistant/jla-find-and-compare-software-licenses
• Creative Commons (CC) licence chooser, https://creativecommons.org/choose/, https://chooser-beta.creativecommons.org/.
• https://opensource.guide/ provides general resources and guides for getting started in open source software. It also includes an excellent overview of the legal side of open source software, https://opensource.guide/legal/.

Other recommendations

The SQAaaS tool (Software Quality Assurance as a Service) [https://sqaaas.eosc-synergy.eu/] checks for the presence of a LICENSE file with an OSI-approved licence (although just compliance with the OSI Open Source Definition is required). Moreover, it checks, among others, the existence of:

• LICENSE.txt file
• CITATION.cff file
• CODE_OF_CONDUCT.md file
• CHANGELOG.md file
• CONTRIBUTING.md file
• Release tags follow Semantic Versioning (e.g., '1.2.3' is compliant, 'v1.2.3' is not)

It also ensures that the Markdown files are compliant with the markdownlint rules.

If you have further questions, If you have further questions you can contact iprcoordinator@geant.org.