|
Visit our service review page to learn more about the related Software Reviews Services. |
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 OSS, describes various types of free and open source licences and some related ones, and addresses other concerns and constraints related to licences. This is followed by 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 available within the GÉANT context.
The market is expected to balance out the total cost of ownership for equivalent software products. However, vendors of proprietary software often 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 using and maintaining OSS, even if the effort required is minimal. They often prefer to have an external organisation that they can hold accountable for software risks and problems. Generally, it is challenging to hold a vendor of commercial software liable unless software has been tailor-made for a single customer and very strict contractual commitments 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 OSS make it an attractive option for many users and organisations. 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 that provide support for open source software.
The open source model is very different from that of traditional licensed proprietary and commercial software because it promotes both distribution and modification. The first element is an obvious differentiator between freeware (free of charge) and shareware (free trial) software, but the possibility to modify the source code of OSS is crucial and has had a significant impact, leading to several improvements over traditional proprietary licensing models.
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.
Open source licences are licences that allow software to be freely used, modified and shared [https://opensource.org/licenses]. Although there are many "free software" and "open source software" licences recognised by the Free Software Foundation (FSF) and approved by the Open Source Initiative (OSI), 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 other components, resulting in the presence of many software licences. To be approved as open by OSI, software licences must meet certain criteria [https://opensource.org/osd]. But even open licences differ in terms of the rights and limitations they include, often regarding derivative works, such as modification of the original code or its use 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 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 any uses of a software library.
The open source rules are designed so that those who receive copies of software must themselves be able to redistribute the original and make derivative works from the original, 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 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.
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 military purposes, it is considered not to be a free software licence since it limits who can use a program and for what purpose. The OSI does not allow discrimination against persons, groups or fields of endeavour in using 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 use other software in many ways 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, interfaces invoked through dynamic or static linking or network communication, or connectors. Therefore, software licences differ from those used for other types of 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. 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 changes to existing files. The term 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".
Highlight: It is important to fulfil the requirements of the chosen OSS licence and ensure that there is also licence compatibility. If you do not fulfil the licence requirements, you are breaching licensing conditions, which might lead to significant financial loss.
There are also non-OSS restrictive licences that are often presented or perceived as being similar to OSS but 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 licences (or shared source licences) are proprietary licences that allow for source code to be viewed and, 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 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 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' licences are similar to source-available licences. They are presented as open, but under closer scrutiny, it becomes clear that licensed software 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 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 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 towards a specific field of use. The Elastic License version 2 (ELv2) is a non-copyleft licence that prohibits providing the products to others as a managed service, circumventing the licence key functionality or removing or disabling features protected by licence keys.
The OSI's Open Source Definition rule 6 (“no discrimination against fields of endeavour”) and 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 OSS. 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 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 contributions of external developers who have donated their time and energy by adding to projects while they were still open source. Additionally, these companies often use code from other open source projects to power their businesses.
When a provider switches to a proprietary commercial licence, they can choose the time, terms and cost. The future costs of software and even its future availability are unknowable, 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 licence, be left with an unmaintained version or fork the last open version of software and bear the associated burden of maintenance forever.
Products subjected to this bait-and-switch move became popular because they had been marketed as OSS, as developers prefer to be able to control whatever runs in their programs and fix it or have other people fix it, even if they are not affiliated with the original maker of the tool or component. Such platforms gain traction as they typically provide free and comprehensive solutions, where expensive licences for commercial alternatives tend to add up and open source substitutes are less integrated. Even developers in large enterprises prefer using OSS over going through slow, bureaucratic and multi-layered approval and procurement procedures.
The only advantage of the prior OSS status is the possibility to fork the previous version, but even this opportunity may effectively close after some time if the community sticks with the vendor and its proprietary changes. Forks are also challenging due to the resources needed and the necessary switch in branding since people do not switch easily from one brand to another.
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 software is controlled by a single entity, as demonstrated in the cases of Elasticsearch and MongoDB. This is why it is crucial to carefully choose software that is guaranteed or, at least, most likely to remain OSS.
Copyright is a form of intellectual property that allows the legal creator of an original work to license that work to the extent governed by copyright law. Declaring copyright on a work does not require any registration or official notice; it simply requires clearly and visibly stating the copyright and defining its subject. The copyright can also be easily transferred to another party, typically through a contract or statement. Since open source licences already open up the work to anyone under clear conditions, copyrights as such are not a problem, but the exact details of these conditions are. The licensing concern related to copyright is whether the licence states it and how the text of the 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.
Highlights:
Patents are a much more complex form of intellectual property. An organisation or individual who invents something substantial, novel and useful proves this through a regulated, expensive and time-consuming patent registration procedure. If this process is successful, a patent owner is granted the right to exclude others from making, using, selling, offering or making available the patented invention for a predefined period, such as 20 years, during which the patent may be subject to maintenance fees. A patent may provide the holder with associated royalties in terms of monetary compensation for its 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 maximise royalties and penalties, thus recovering the costs of patent registration or 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 patent-related uncertainty. A licence may state that it does not grant any rights to the contributors' patents or explicitly grant 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. However, no software licence would protect a licensee against a claim of infringement brought by a third-party patent holder since licensors can only license works that belong to them. Since software patents are often vague, abstract or ambiguous, they can be easily weaponised and may even protect 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 OSS licence waives any patent-related obligations, that patent may later be narrowed or cancelled through litigation by a holder of a rival patent. If this happens, even the licensee who has fully complied with the terms of the original licence and the licensor's patent may become liable for infringement of a competing patent if 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 patent. 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:
Copyleft licences, in principle, prevent the code from being incorporated into or 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 sublicensing, the contributed code can be relicensed at the discretion of the guardian.
Software relicensing is done for commercial reasons or to improve licence compatibility. In the first case, the change is typically towards 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.
Relicensing 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:
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. Furthermore, all contributors do not need to have previously signed a permissive licence or contributor agreement. Licences with an "or later" option are a concise form of multi-licensing in which all subsequent versions of the said licence are accepted in advance, including those that do not currently exist.
For internal use
Sharing software with others
For a service, the provider is generally protected as long as they use any OSS except those licensed under the following options:
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:
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:
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.
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.
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:
Gather information (can be done with Mend)
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
Create compliance artefacts (to ensure compliance)
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:
Ideally, compliance should be continuously monitored as a part of the build process.
Commercial services:
OSS solutions:
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.
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:
It also ensures that the Markdown files are compliant with the markdownlint rules.
If you have further questions, you can contact iprcoordinator@geant.org.