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 reuse components of code already created allows development teams to create more code, with more functionality, at a 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 non-profit organisations that are viewed as the reference point for the definition of 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 and 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.
Recently there have attempts to introduce ethical terms into open source software licenses. One such license is the Hippocratic License 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:
Bruce Perens who co-founded the OSI also published an article “Sorry, Ms. Ehmke, The “Hippocratic License” Can’t Work“.
Another example of this genre of a license is the Anti-996 License 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.
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 1.
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.
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.
The high-level areas covered in the OpenChain specification are:
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 ensuring compliance with open-source software.
Any discussion related to ethics is 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 acquire software solutions identify suppliers who taken open-source licensing seriously and have solutions they can trust to bring into their organisation.