Swapnil Bhartiya | 21 March 2018
The key to open source compliance is knowing what’s in your code, right down to the exact versions of the components, says Ibrahim Haddad.
Companies across all industries use, participate in, and contribute to open source projects, and open source compliance is an integral part of the use and development of any open source software. It’s particularly important to get compliance right when your company is considering a merger or acquisition. The key, according to Ibrahim Haddad, is knowing what’s in your code, right down to the exact versions of the open source components.
Ibrahim Haddad
Haddad often writes about compliance with the aim of simplifying what can be a complex and daunting process. Recently, Haddad, who is Vice President of R&D and Head of the Open Source Group at Samsung Research America, wrote Open Source Audits in Merger and Acquisition Transactions, a free ebook from The Linux Foundation. In the book, Haddad provides a practical guide to open source audits in merger and acquisition (M&A) transactions and offers tips for improving general open source compliance preparedness. We reached out to Haddad to understand more about the importance of compliance and audits in the open source world.
The Linux Foundation: A common perception is that using open source software means you do not have to worry about negotiating licenses, fees, and other complications associated with proprietary software. So, why should enterprises care about compliance?
Ibrahim Haddad: It is true that open source software has to a large extent simplified the process of software procurement. The traditional procurement model for proprietary software has always been heavy on the front end, as it involves trial and evaluation, negotiation related to possible customizations, licensing terms, fees, and several other factors. With open source, it is still true that you should evaluate the software, compare it to other possible alternatives, and evaluate if the license of that software is in line with how you plan to use it.
However, this is generally the extent of the initial effort. Once you ship a product, you then must demonstrate that you have respected the terms of the licenses attached to the open source components. That may mean providing a written office, publishing all copyright, attribution and license notices, and/or making available source code including any modifications you have introduced. Obligations will vary based upon the terms of the open source license and how the code is used.
Companies must make open source compliance an engineering priority, as it is the best way to display their fulfillment of the license obligations. If a company is unable to demonstrate compliance and is unwilling to become compliant when challenged, the owners of the copyright on the open source software may decide to revoke the license. The company could easily end up in a very difficult space where they may need to recall products and re-engineer around the code.
The Linux Foundation: In my opinion, there are two primary aspects of Open Source — consumption and contribution. What role does compliance play in these cases?
Haddad: I agree that the two primary aspects of open source are using and contributing. An enterprise can choose open source components and deploy them in their software stack. An enterprise can also decide that certain open source components are strategic to their products and contribute to these components, inject new dynamics in the projects, and steer them in a technical direction that is favorable to their products.
In the first case, compliance is a critical aspect of the “usage” model. A product or software stack that incorporates open source and is being made commercially available must demonstrate open source compliance. This is essential, and no enterprise should risk their profitability with incomplete compliance.
In my mind, contributing involves a different type of compliance than what is implied through the “usage” model. My recommendation and actual practice for code contribution is to follow an internal process that includes:
- Scan source code intended for contribution to identify its origin and license.
- Ensure you have the rights to contribute it under the project’s license.
- Get your company’s approval for that contribution – and in the case of CLA, also getting approval to sign the CLA on behalf of your company before making the contribution.
I will explain my logic for these three steps:
On 1: It is necessary to identify all the code planned for contribution, and any licenses upon it. This step will also help you identify any possible incompatibilities between the licenses of the contribution and the target project. If the code you plan to contribute and the target project have incompatible licenses, or if you discover the code was copied from somewhere else, then you will need resolve the issue before your code submission.
On 2: This step ensures that you are not accidentally open sourcing third-party proprietary code. This can be a problem in big internal projects with legacy code.
On 3: In most companies, ongoing contributions require approval following whatever internal process that has been set in place. That process should also address who can sign and submit a CLA as an individual contributor (employee of company X), or on behalf all contributors from company X.
Following these steps, you will be able to significantly minimize legal or compliance risks resulting from using or contributing to open source projects.
The Linux Foundation: If you do serve external customers, but you are not shipping any code, then you are simply offering a service. Do you have to be compliant in that case also?
Haddad: I would like to highlight two use cases here. The first is using open source software in your company for internal purposes: IT, testing, evaluation, etc. In such cases, there are no compliance requirements because it is never distributed.
The second case involves offering online (or web) services to clients using software that incorporates open source software. In that specific case, some licenses such as the GNU Affero General Public License (AGPL) do require companies to comply with the license obligations, even if the software itself never changes hands.
Therefore, regardless of how you use the open source software, I am a strong believer in the value of going through a compliance process to identify open source code, applicable licenses and usage models. I believe that good compliance practices are also good engineering practices.
The Linux Foundation: What was the motivation behind writing Open Source Audits in M&A Transactions? Who is the main audience of the book?
Haddad: I mainly had three motivations for writing this book:
- The first motivation was the lack of documentation around the open source audit process that must take place prior to a merger or an acquisition. If you search online for documentation on this topic, you will not find much outside of the advertisements from various compliance services providers.
- The second motivation is saving time. I get many inquiries about this process and having such a document is great to share when I am asked about it. In addition, I thought that if I am able to produce a document that highlights the process and explains it, maybe this will encourage others to write about it and share their experiences and recommended practices.
- The third motivation was related to innovation in the compliance space that was not getting the attention it deserves. For example, the “Blind Audit” model from FOSSID AB where your compliance service provider can complete the audit without having access or even looking at the source code. This level of privacy and security is highly desirable.
The target audience of the book is anyone interested or involved in ensuring open source compliance. Although the ebook focuses on the specific process during an M&A transaction, it offers various recommendations on how to be compliant. These recommendations apply to any company that uses open source. Therefore, if you are an engineer, legal counsel, someone who works in software procurement, or anyone who is involved in open source in their organization, then you will get something out of reading the book.
The Linux Foundation: Compliance can be a challenge when you use a lot of open source projects with many license mixes. What practices would you suggest to companies to help them with their compliance efforts?
Haddad: I think we have come a long way in the open source compliance domain. Back in the early 2000s, open source compliance was really misunderstood, in large part because it was a developing domain. Today, open source compliance is well understood and most companies have a good enough understanding of the licenses and what needs to be done to stay in compliance. My view is that the top challenges are related to scale and building compliance into the software supply chain.
Of the two challenges I just mentioned, scale is the hardest, and it covers multiple dimensions. One is scaling at the project level, when you are dealing with hundreds of open source components and potentially thousands of open source snippets. The other dimension is scaling to address the complexities of a product with an arbitrary number of licenses involved. The way to deal with that is twofold: process and automation. In November 2016, The Linux Foundation published an ebook entirely dedicated to this topic: Open Source Compliance in the Enterprise. It offers a guide for how best to use open source code in products and services and participate in open source communities in a responsible way.
The second challenge is building trust in the software supply chain, and there are several initiatives that are geared for that purposes. The most prominent projects are OpenChain and SPDX, both hosted at The Linux Foundation. The SPDX initiative has created a standard method to communicate software components, licenses and copyright information associated with the software. In addition, the OpenChain project is offering a systematic approach for companies to build their compliance efforts and be in conformance of various levels of compliance. They are also offering a training curriculum that companies can adopt and customize for their internal use.
For organizations that rely heavily on open source for their products/software stacks, it is essential for them to participate in these efforts. When you look at the errors that lead to non-compliance, we’ve notice that large companies have significantly improved their internal compliance practices. However, many compliance issues are still being propagated via the software supply chain, from upstream suppliers whose compliance practices are not as rigorous. The final product integrator is responsible for compliance obligations even if they did not create the code they distribute, so this is a relevant issue throughout the entire supply chain. Both SPDX and OpenChain help minimize the compliance gap and ensure proper compliance when software changes hands.
The Linux Foundation: What would be your top recommendations for companies who are major consumers of open source software but are not well versed in ensuring compliance?
Haddad: I have one recommendation: know what is in your code, right down to the exact versions of the open source components. This statement sounds simple but it involves setting up a compliance policy and process, investing in tooling and automation, training employees, and assigning someone (or a small team) to oversee the overall effort.
Also remember that open source compliance is an ongoing process, not a destination. Maintaining good compliance practices enables companies to be prepared for a possible acquisition, sale, or product or service release. For this reason, companies are highly encouraged to invest in building and improving upon their open source compliance programs.
There are also many resources available, so please check them out:
- Open Source Compliance in the Enterprise is a practical guide for enterprises on how to best use open source in products and services in a legal and responsible way.
- Practical GPL Compliance is a guide for startups, small businesses, and engineers, particularly focused on complying with the versions of the GNU General Public License (GPL).
- OpenChain Curriculum is designed to help organizations meet the training and process requirements of the OpenChain Specification. It can also be used for general open source training.
- The Linux Foundation offers a free open source compliance course for developers.