Written by
Martin Callinan – Director, Source Code Control Limited
June 2020
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.
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 an 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 acquires of software solutions identify suppliers who taken opens source licensing seriously and have solutions they can trust to bring into their organisation.
[1] The term ‘Hippocratic’ is derived from the Hippocratic Oath, the most widely known of Greek medical texts. The Hippocratic Oath in literal terms requires a new physician to swear upon several healing gods that he will uphold a number of professional ethical standards.
[2] The term “996 ICU” refers to working 996 (9am to 9pm 6 days a week) hours at the expense of one’s health (ending up in the Intensive Care Unit of the hospital)