Visit our service review page to learn more about the Software Reviews#WhiteSourcescananalysis |
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.
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.
On the other hand, the characteristics of FOSS make it a very attractive option for many users and organisations. Also, many commercial developers of open-source software often provide additional services as part of their business model. There are even third-party companies which provide support for open-source software.
The open-source model differs greatly from the one used operation of traditional licensed proprietary and commercial software by permitting both distribution and modification. The first limitation is also eliminated in freeware (free of charge) and shareware (free trial) software, at least for its binary form, but the possibility to modify the source code is crucial and has a huge impact, which has brought several substantial improvements over traditional proprietary licensing models.
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.
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 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 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 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, is considered to not be a free software licence since it limits who can use a program or for what. 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 do not require any modification or even 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 through dynamic or static linking, network communication and different types of interfaces and connectors. Therefore, software licences differ from those used for other types of works as they are focused 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. 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 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'.
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.
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.
The user has no rights to use, share, modify or even compile the code. Having just access to source code is not the point of FOSS, but 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 or product is effectively under the strict control of its vendor. These hybrid licences are intentionally deceptive and confusing. Server Side Public License (SSPL) is a strong copyleft source available license that requires 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 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 a specific field of use. ELv2 (Elastic License v2) is a non-copyleft license prohibiting providing the products to others as a managed service, circumventing the license key functionality or removing or disabling features protected by license keys.
Open Source’s rule 6 (“no discrimination against fields of endeavour”) and 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 FOSS. 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 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 of external developers who have donated their time and energy by adding to projects while they still were open source. Also, these companies most often use code from other open-source projects to power their businesses.¶
When a provider is switching to a proprietary commercial license, it can choose the time, terms and cost. The future costs of software and even its future availability are unknowable, as with 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 license, be left with an unmaintained version, or fork the last open version of the software and carry the associated burden of maintenance forever.
Products subjected to this bait-and-switch move became popular because they had been marketed as being FOSS, as developers prefer to be able to control whatever runs in their programs, and fix it or to have other people fix it, although they are not affiliated with the original maker of the tool or component. Also, such platforms gain traction as they typically provide free and one-stop solutions, where expensive licenses for commercial alternatives tend to add up, and open-source substitutes are less integrated. Even the developers in big enterprises prefer using FOSS to going through the slow, bureaucratic and multi-layered approval and procurement procedures.
The only advantage of the prior FOSS status is the possibility to fork the prior 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 due to the resources needed and the necessary switch in branding, whereas people do not switch easily from one brand to another.
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.
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.
Highlight: What is important, under copyright law only the expression of ideas – not the ideas themselves – can be protected. As software is protected by copyright law, the diversity of FOSS licences with different requirements allows software developers to grant other users rights stated in the licence itself.
Patents are a much more complex form of intellectual property. An organization or individual who invented something substantial, novel and useful proves this in a regulated, expensive and time-consuming patent registration procedure. If this process is successful, a patent owner is granted the right that excludes others from making, using, selling, offering or making available the patented invention for the 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 it, 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 royalties and penalties and thus recover the costs of patent registration or purchasing and 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 patents-related uncertainty. A licence may state that it does not grant any rights to the contributors’ patents. Or it may explicitly grant 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 no software license would protect a licensee against a claim of infringement brought by a third-party patent holder, as licensors can only license works that belong to them. Since software patents are often too vague, abstract and ambiguous, they may be easily weaponised; they may 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 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.
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 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.
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.
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:
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.
For internal use
Sharing software with someone
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.
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:
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.
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.
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.
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.
Gather information (can be done with Mend)
Document (can be done with Mend)
Remediate
Create compliance artifacts (to ensure compliance)
Ideally, compliance should be continuously monitored as a part of the build process.
Commercial services
FOSS solutions
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.
Below you will find resources which may help you with your selection:
If you have further questions you can contact iprcoordinator@geant.org.