Just like food, the software solutions you consume are also made up of different ingredients. These include third-party software (supplied by vendors outside your organisation) along with other open source software components and libraries that collectively form the ingredients of the software application. Organisations must adopt a compliance strategy to avoid the risks associated with releasing a product that does not comply with the underlying licences.
Lack of awareness about open source software compliance and software security risks can result in various compliance related issues.
Before it is consumed by an end user, the product team and stakeholders should understand their software’s composition. Unless you are aware of the potential risks your software may have, you cannot remediate that risk. To understand the risk associated with open source software, it is essential to know how it enters your supply chain.
What is open source software and how does it enter your supply chain?
Open source software is computer software that is released under a licence in which the copyright holder grants users the right to use, study, modify, and distribute the software and its source code to anyone and for any purpose.
Modern applications such as mobiles, the cloud and IoT connected devices may comprise up to 90 per cent of open source, according to a report by Forrester. Open source components are malleable in nature because one can copy, redistribute, and even make changes to the software, for any purpose. This makes it favourable for the developing team to incorporate this software into its code.
Another important aspect with regard to open source compliance risks is the software dependencies. Dependencies are components and libraries that are required for the application to run, and are pulled into the application at build time.
These are categorised into two types — direct dependencies and transitive dependencies. Direct dependencies are the libraries your code directly calls and utilises. Transitive dependencies are the libraries or other software that the direct dependencies depend on.
These dependencies have their own governing licence, which could be different from the parent open source library. It is important to track the dependencies in your software because you are still obligated to comply with the terms of the licence, even if the dependency is direct or transitive.
Open source licence risks and compliance
Each open source software library is governed by an open source licence. These licences can be categorised into different risk levels: permissive, weak copyleft, strong copyleft, and source available, which in turn have obligations, attributions and varying severity of risks associated with them. Figure 2 shows the different licence types and their associated obligations.
Open source software licences obligate the developer or organisation developing software to comply with the terms of the licence. Some of the obligations include keeping the licence information and copyright notices intact, providing attribution notices that identify the copyright holder, identifying modifications made to the software, etc, and in some cases to make the source code of the overall application available to users of the application. Non-compliance with the licence obligations can impact the business in many ways.
- Licence infringement consequences: Development teams could lose the right to use the component or library, which could result in a product recall, fixing or re-writing the code patch.
- Loss of intellectual property (IP): Open source licence compliance can result in a requirement to release the source code of your IP to users of the application.
- Reputation loss: Press articles and media coverage can jeopardise a company’s reputation.
- Cost consequences: Remediation processes like removing or replacing an open source component can often be expensive and time-consuming.
The reality of licence violations
Non-compliance with open source software in the past has given rise to many disputes, which have made quite an impact on an organisation’s reputation and client base.
Artifex vs Siemens Product Lifecycle Management Software Inc.: Artifex Software filed a lawsuit against Siemens Product Lifecycle Management Software Inc. in 2019 for unauthorised copying and distribution of one of the former’s products called ‘Ghostscipt’.
Ghostscript (a dual-licensed component) is a well-known interpreter for the PostScript language and PDF files. Artifex released Ghostscript under a commercial licence or free of charge under the terms of the GNU Affero General Public License (AGPL). The company alleged that Siemens had been using Ghostscipt in one of its software products known as ‘Solid Edge’ without adhering to the licence obligations of AGPL or purchasing the commercial licence.Siemens dismissed the suit.
According to Miles Jones, president of Artifex Software, “Artifex has long offered such
companies a straightforward choice: Comply with the terms of the AGPL, sign a commercial licence agreement with Artifex, or do not distribute Ghostscript. Siemens has refused each of these options, which is why we filed our lawsuit. We take our obligation to protect our intellectual property seriously.”
Software Freedom Conservancy vs Vizio Inc.: In a recent open source licence non-compliance case, Software Freedom Conservancy (SFC) filed a lawsuit against Vizio Inc. for what it called repeated failures to fulfill even the basic requirements of the General Public License (GPL).
SFC is a non-profit organisation focused on ethical technology. The lawsuit was filed against Vizio’s television products built on its SmartCast operating system, which is based on Linux. Since Linux is licensed under GPLv2, SFC alleges that Vizio has incorporated a GPL component into its TV’s software and has failed to comply to the requirements of GPL.
As a user of GPL licensed components, Vizio is obliged to provide end users the freedom to run, study, share, and modify the software along with a copy of the source code of its TV software. However, SFC alleges that Vizio has not been complying with any of the licence obligations and continues to use the component in its software.
Another aspect that makes this lawsuit unique is that SFC is not suing Vizio on behalf of a copyright holder of a particular open source component. Instead, it has lodged the complaint as a consumer of the product.
“That’s what makes this litigation unique and historic in terms of defending consumer rights,” says Karen M. Sandler, SFC’s executive director.
If SFC prevails, this case will give a significant boost to consumer rights, wherein not only the copyright holders of any open source component but the consumers also have the right for open source licence enforcement.
Establishing a compliance strategy
Identifying and tracking open source components and licences does not get the job done. In order to fully comply with the open source licence obligations, a compliance strategy needs to be implemented.
This compliance strategy should cover processes, policies and guidelines around onboarding the open source components, and educating team members on the obligations associated with open source licences.
The teams may include, but not be limited to, developers, product teams, stakeholders, legal teams, etc.
Delivering training to the employees: Training may include policy and guidelines set in place, which are required to be fulfilled before onboarding any open source component into the solution.
Regular training will help developers understand better the licensing basics and the importance of attribution concerns arising from using open source licences and sharing the source code if appropriate.
The compliance policies and processes may help in governing the various aspects of using, contributing, auditing, and distribution of open source software.
Software composition analysis: Software composition analysis (SCA) automates the process of gaining visibility into the components of a code base. SCA tools help in scanning an organisation’s source code. These tools help to create an inventory, commonly known as software bill of materials (SBOM).
There are several SCA tools in the market that aim at identifying whether there is any licensing information or security threats present within the code.
OSRB (Open Source Review Board): Another significant component of a compliance strategy is the OSRB (Open Source Review Board), which comprises a team of reviewers consisting of representatives from legal, engineering, and product teams; it helps to set the open source compliance strategy in place.
This board helps with any matters that relate to the use of open source components and determining the process of onboarding any open source component in the organisation. The OSRB reviews all the requests to incorporate open source code in products/services, evaluates these requests and approves/denies them based on technical and legal considerations.
Organisations such as the Linux Foundation have implemented this practice to ease the compliance process.
OpenChain standard
To safeguard your software’s code against any potential risks, quality compliance is the need of the hour. In order to build trust around open source usage in the software supply chain and to ensure smooth product delivery, the OpenChain Project has introduced the ISO/IEC 5230 OpenChain standard. Started by the Linux Foundation and led by Shane Coughlan (general manager, OpenChain Project at the Linux Foundation), it has standardised a process for open source licence compliance. The standard defines clear guidelines that must be followed in order to achieve a conformant solution. Adopting these guidelines will help organisations develop a strong sense of confidence in their software bill of materials (SBOM). A recent bill passed in the United States mandates that the SBOM must contain details of components and vulnerabilities associated with the shipped product or solution.
Microsoft announced its conformance to the OpenChain specification in 2019. Many renowned organisations like Toyota, Cisco, and Uber have adopted the ISO/IEC 5230 and OpenChain standard as part of their compliance programmes. The ISO standard provides a benchmark framework, which ensures compliance related issues are reduced. It helps suppliers build trust in their software solution before releasing it into the market.
