...

Summary

This document provides the necessary background information to understand the domain of Free and Open-Source licences (FOSS). It starts with an overview of the benefits of FOSS, describes various types of free and open and some related licences, and describes 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.

Free and Open-Source licences (FOSS)

Benefits of FOSS

The market is supposed to even out and equalise the total costs of ownership of equivalent software products. Still, 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 costs they often associate with the use and maintenance of FOSS, even when the needed effort is neglectable. They often may want to have an external organisation they can hold accountable for software risks and problems. But the experience has shown that it is very hard to hold a vendor of commercial software liable for it unless it has been tailor-made for a single customer and very strict contractual obligations were put in place.

...

• Availability and lower costs – For highly advanced or specialised needs such as those related to research, new technologies and high load, the market is not large enough for a suitable commercial product to be available and sustained. The immediate and cost-free availability of open source is also associated with the need to develop internal expertise, which is often something that organisations and individuals want to do anyway or hire external support and maintenance. Many users – advanced ones in particular – want to be able to customise and adapt the software and are often happy to debug and maintain it. In research and education, the obligation to pay for software, overheads related or procurement and renewal of commercial licences, and related commitments are barriers that cannot be overcome by students, early researchers or small research groups. Access to the source code may also reduce their learning curve and allow them to be more effective with the technology. Furthermore, the cost of highly specialised or tailor-made software is often unacceptable even for large organisations, especially if a working solution can be achieved by combining and customising even several freely available building blocks. These factors have led to the wide 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 resources and runtime environments, the introduction of large toolsets or architectures with many components, such as those based on microservices.
• Innovation and flexibility – The easy access to the source code enables 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 vendors of proprietary software, where the users would have to wait for the vendor to decide to provide and implement what they need. The more useful a new feature or solution is, the more developers and companies will join and contribute. The more programmers contribute to it, the better, more useful and more valuable the result is going to be. This has been proven to work even if the contributors are not required to share their derivative works. Furthermore, people who inherently need a specific improvement are more driven to provide a creative and innovative solution 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 fixed. Contributors are aware that other experts will be looking at and reviewing their code, and will therefore tend to stick to higher standards of quality. Every new 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 prior knowledge, experience or earlier dealing with a similar problem is often in a better position to detect and address an issue or bug than the original author. Many open-source projects have dedicated reviewers who check modifications before they are included in the main codebase. They are not testers, but experts who care about the quality of the code and can work at their own pace. All these factors greatly improve software 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 identified in an active open-source project, the interested community members usually swarm in and quickly patch it. However, only those who keep up with the latest recommended versions, including the libraries they rely on, will 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 available anymore. Therefore, its usability can deteriorate quite rapidly and the user must decide when to invest in new software and migration 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 have wide, active and stable user communities, the members of which include individuals and research groups, but also large and small companies.

Types of FOSS licences

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 software" and "open-source software" licences that are recognised by Free Software Foundation (FSF) and approved by Open Source Initiative (OSI), there are just a few licences that are popular, widely used, or have strong communities. However, a single software project may include several components, which include transitively other components, which may result in the presence of many software licences. To be approved as open by OSI, software licences must meet some criteria [https://opensource.org/osd]. But even open licences differ in terms of the rights and limitations they include, which are often on derivative works, such as modification of the original code or its use from the new code. About half of 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 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.

...

Highlight: It is important to fulfil the requirements of chosen FOSS licence and ensure that there is also licence compatibility. If you did 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 restrictive licences which are often presented or perceived as being similar to FOSS, but which introduce limitations that prevent them from being open-source according to the Open Source Initiative (OSI) and free to the Free Software Foundation. Source available licenses (or shared source licences) are proprietary licenses 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 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 only grant rights to developers of Microsoft Windows-based software, while Ms-RSL allows viewing the source code for reference and debugging.

...

All this 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 why it is so important to carefully choose software that is guaranteed or at least most likely to remain FOSS.

Copyrights, patents and warranties

A copyright is a form of intellectual property which allows a legal creator of an original work to license that work to the extent governed by copyright law. Declaring copyright on some work does not require any registration or official notice but just to clearly and visibly declare the copyright and define its subject. The copyright can be also easily transferred to another subject, typically through a contract or statement. Since open-software licences by definition already open up the work to anyone under clear conditions, copyrights as such are not a problem, but the actual details of these conditions. The licensing concern related to copyright is whether the licence states it and how the text of the license 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.

...

Even if a patent holder has licensed that patent for use in open-source software or the applied FOSS licence waives any patents-related obligations, that patent may 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 and the licensor’s patent may become liable for infringement of a competing patent if it continues 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 patent. As this can become expensive, licensees may embark on such an endeavour only if their business would be seriously affected by the requirements of the competing patent holder.

Other constraints and rights

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.

...

• Describe 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 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 usage.
• 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 licences.
  

Contributor agreements

Copyleft licenses, in principle, prevent the code from being incorporated into or re-licenced 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-licensing, the contributed code can be relicensed at the discretion of the guardian.

Relicensing

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

...

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 permissive licence or contributor agreements signed by all contributors. “Or later” styled licences are a concisely expressed form of multi-licensing in which all subsequent versions of the mentioned licence are accepted in advance, including those which currently still do not exist.

Governance of FOSS licences in general

Use of FOSS licenses 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.

...

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:

...

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.

...

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)

...

Create compliance artifacts (to ensure compliance)

Software composition analysis – inventory tools

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

...

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:

...