Ethics of Open Source Software Licensing
Introduction
In 2011 Marc Andreessen authored his now famous essay “Why Software Is Eating the World” which highlighted how software is pervasive in all aspects of our day-to-day lives and “every company needs to become a software company”. Today, the reality is that it is open source software that is eating the world.
Open source software development and associated licensing models were relatively niche and obscure have become ubiquitous across all areas of software development.
The ability to re-use components of code already created allows development teams to create more code, with more functionality, at greater velocity. It also promotes the adoption of transparent standards and makes applications more interoperable.
The early licensing models for open source were authored from an ethical viewpoint focussed on creating and maintaining software freedoms. There are two not for profit organisations that are viewed as the reference point for the definition open source software, the Free Software Foundation and the Open Source Initiative .
The Free Software Foundation was founded to support the free software movement and published what is known as the four freedoms with the fundamental principle that users of software should have the freedom to run, copy, distribute, study, change an improve the software they are using.
The Open Source Initiative was founded to promote the usage of open source software and is the custodian of the Open Source Definition (OSD) which is a document that determines whether a software license can be labelled with the open source certification mark. In other words a legitimate open source license conformant with the OSD. The open source definition includes requirements such as “no discrimination against persons or groups “and no discrimination against fields of endeavour”
However, there are many licenses that are classed as open source software licenses that fall outside the OSD and therefore not approved by the Open Source Initiative. For example, the JSON license has a sentence “The Software shall be used for Good, not Evil.” This is adding a restriction of use, therefore non-conformant with the OSD.
The Rise of Ethical Open Source Software Licenses
Recently there have attempts to introduce ethical terms into open source software licenses. One such license is the Hippocratic License [1] introduced by Coraline Ada Ehmke better known for her Contributor Covenant, . This is essentially a modified MIT license with added conditions:
The software may not be used by individuals, corporations, governments, or other groups for systems or activities that actively and knowingly endanger, harm, or otherwise threaten the physical, mental, economic, or general well-being of underprivileged individuals or groups in violation of the United Nations Universal Declaration of Human Rights (https://www.un.org/en/universal-declaration-human-rights/).
Again, due to the restrictions the license requires, it does not conform to the OSD. The PR generated by the introduction of this license, prompted the OSI to make the following statement:
Figure 1 Open Source Initiative Tweet
Bruce Perens who co-founded the OSI also published an article “Sorry, Ms. Ehmke, The “Hippocratic License” Can’t Work“ .
The motivation behind this license is a reaction to the use of technology by the US Immigration and Customs Enforcement agency ICE, and a broader movement the “No Tech for ICE”.
Another example of this genre of license is the Anti-996 License [2] published by Katt Gu and Suji Yan which requires any company using software under this license to comply with local labour laws as well as International Labour Organization standards.
The individual or the legal entity must strictly comply with all applicable laws, regulations, rules and standards of the jurisdiction relating to labor and employment where the individual is physically located or where the individual was born or naturalized; or where the legal entity is registered or is operating (whichever is stricter). In case that the jurisdiction has no such laws, regulations, rules and standards or its laws, regulations, rules and standards are unenforceable, the individual or the legal entity are required to comply with Core International Labor Standards.
The challenge with these types of licenses is they can be legally problematic due to the subjective fields of use restrictions and vague grant of rights.
Obligations of Open Source Software Licenses
With the volume and ease of availability of access to third-party software components, libraries, frameworks and packages from sites such as GitHub, NPM and Maven, it is not uncommon for modern software applications to be composed of up to 90% third-party open source software.
You can think of modern software development as a software supply chain. See figure 2.
Figure 2 open source software supply chain
However, although these third-party components which are freely available from multiple sources come with obligations. These obligations are defined by the terms of the license. A delivered code base will include multiple third-party components each with their own license(s) which results in multiple open source licenses to be complied with. Typically, obligations will include some or all the following:
Attribution and Notices. You may need to provide or retain copyright and license text in the source code and/or product documentation or user interface, so that downstream users know the origin of the software and their rights under the licenses.
Source code availability. You may need to provide source code for the open source software, for modifications you make, for combined or linked software.
Reciprocity. You may need to maintain modified versions or derivative works under the same license that governs the open source software component.
Other terms. The open source software license may restrict use of the copyright holder name or trademark, may require modified versions to use a different name to avoid confusion, or may terminate upon any breach.
Because of the multitude of licenses, variety of terms and the general lack of knowledge and guidance about licensing generates confusion which leads to decisions being made that could have a significant business risk to organisations such as IP infringement which could result in outcomes such as devaluing of a business and reputational damage.
Another challenge technology suppliers leveraging open source software is demonstrating to customers, prospective customers and partners that they can trust the open source software supply chain behind their solutions. This lack of demonstrable trust could lead to commercial restrictions such as loss of revenue for the suppliers.
Introducing the OpenChain Project
In 2013 the Linux Foundation started a project called the OpenChain Project led by Shane Coughlan to address
The OpenChain Project provides a framework to guide organisations in how to manage their open source software supply chain. Adoption of OpenChain can then be assessed either by self-assessment or interpedently. OpenChain should become part of the business as usual QA process for a software project, which will ensure obligations related open source licenses of components, libraries and packaged used to deliver a solution are met in the correct way.
Conformant organisations are able display their adherence and promote the fact they are OpenChain conformant.
Figure 3 OpenChain Project Structure
The high-level areas covered in the OpenChain specification are:
- Know your open source software responsibilities
- Implement an open source policy or guide
- Train relevant people of the policy
- Assign responsibility for achieving compliance
- Delegate responsibility for open source compliance
- Create an open source review board
- Review and approve open source software content
- Identify third-party open source software used and their attributes
- Implement Software Composition Analysis
- Deliver open source software content documentation and artifacts
- If sharing source code, ensure this is done correctly
- Ensure license and copyright attributions is implemented correctly
- Understand open source software community engagement
- Community contributing you your project
- Your developers contributing to open source projects
By adopting OpenChain organisations developing software solutions can not only demonstrate they have a structure for managing compliance but also they are respecting the intellectual property of the developers who have contributed software to the open source community and they are benefitting from.
OpenChain will also aid procurement professionals benchmarking solution when acquiring software solutions for their organisation.
OpenChain is in the process of being ratified as an ISO standard which will give it credibility globally as the definitive best practice for ensure compliance with open source software.
Risks of open-source code within Software Escrow agreements
The requirement for software escrow agreements is often included within software license or SaaS license agreements. This requirement obligates the developer to deposit their source code with a trusted source code escrow agent. In the event of a trigger situation, the deposited source code may be released to the beneficiary. In such a release circumstance, if the developer has misused open-source code and breached those licensing obligations, by default, the beneficiary may be exposed to such breaches even if they weren’t aware of the inclusion of open-source code within the code base. This could result in heavy legal issues for the beneficiary. To minimise the risk of breaching open-source licensing obligations, it is recommended for beneficiaries to request an open-source code audit to provide an insight into what code is actually used within an application and if there may be any potential licensing breaches.
Why consider an open-source code audit?
As mentioned above, it’s great to see that there are projects out there such as the OpenChain project, however there are still some instances when an organisation may want to consider instructing an expert open source auditing firm to perform an audit on their behalf to ensure good visibility into their open-source use.
The reasons to use an open-source code audit are as follows:
Investment – The opportunity to invest in a software or SaaS company may be tempting. Before investing you need to ensure that the IP of the company is owned by that company and does not contain open-source code which may negatively affect the value of the company.
Acquisition (M&A) – Open-source code audits are commonly used during an M&A process so the buyer gets an understanding of their potential legal exposure from licensing and exposure to potential vulnerabilities. For example, if open-source code with a GPL license exists within the code base, this will most likely be problematic.
Outsourced Developer – If you subcontract software development to a third-party developer, you may request assurances or warranties that the codebase does not contain any open-source code. In order to determine if the developer is keeping to their end of the agreement, it is essential to conduct an open-source code audit to verify compliance.
Security – The use of open-source code comes with security risks as the code is available to the public. Hackers can use this code to seek out and exploit vulnerabilities that may exist. Research has shown that 78% of audited codebases contained at least one open-source vulnerability, of which 54% were high-risk ones that hackers could exploit. The recent Log4j breach highlights the inherent risks of opensource code embedded within IT systems. According to cybersecurity experts, hackers can gain easy access to a company’s computer server, giving them entry into other parts of a network. It’s also very hard to find the vulnerability or see if a system has already been compromised. An open-source code audit and implementing a policy of maintaining a Software Bill of Materials (SBOM) will assist in identifying known vulnerabilities in a codebase containing open-source code.
Conclusion
Any discussion related to ethics are highly subjective. Open source software licensing crosses a broad spectrum with varying obligations that need to be considered. Some of those license obligations can even try to enforce a subjective ethical viewpoint.
Open source is generally perceived to be ethical because of the freedoms that it promotes. However, just because a solution is positioned as open source, does not necessarily mean it is ethical.
An important and often overlooked area of ethics related to open source is meeting the obligations of open source licensing and respecting the intellectual property of the developers and organisations that have contributed code for re-use.
The OpenChain project is a way for software companies to demonstrate that they respect IP and have a mechanism for managing this in their organisation. The OpenChain conformant badge can help acquirers of software solutions to identify suppliers who have taken opens source licensing seriously and have solutions they can trust to bring into their organisation.
Escrow London in joint partnership with Source Code Control perform audits of software code bases to detect and identify the existence of open-source code. The Escrow London/Source Code Control Open-Source team creates a detailed report identifying the open-source code and their corresponding licenses. For more information, please click here.
Written by Martin Callinan – Director, Source Code Control Limited, Escrow London’s Open Source Audit partner.
