In today’s world of BYOD (Bring Your Own Device), cloud computing and the Internet of Things (IoT), individuals touch open source software (OSS) on a daily basis, and it’s not uncommon for competing businesses to find themselves working collaboratively in an era “collabor-etition” or “co-opetition”. Given the ubiquity of open source, there is an inevitable need for companies to have processes in place with respect to its utilization and/or distribution. The development of a comprehensive OSS strategy and policy is fundamental to practicing and maintaining good business hygiene, while understanding and manage legal, intellectual property (IP), and security risks.
Companies’ use of OSS is at an all time high. OSS is no longer on the margins of software development, but now plays a critical role in a majority of businesses. A recent Gartner report stated, “The widespread use of open source technology in mission-critical IT portfolios means that IT leaders must establish effective governance processes.”
What is an Open Source Audit?
When a company first recognizes its use and possible distribution of OSS, an important initial step is to perform an open source audit. An open source audit is a systematic examination of a company’s software, checking to identify what OSS sits within its overall code base. A number of commercial enterprises, including Black Duck Software, offer audit services that check your code base against their vast open source code databases to discover and review all know and hidden OSS.
The resulting audit report, sometimes referred to as a due diligence report, will include both a complete list of identified OSS components and their associated licenses. It’s important to know how each component is used within your organization, since the act of distributing certain open source components can have a significant impact depending on the applicable licensing terms.
Truly useful audit reports will also identify where specific software uses may present known licensing conflicts or IP issues. Once these potential issues have been identified, you can begin to examine what each issues means to your business and how to fix them from a legal or technical perspective to avoid on-going problems.
Remediation Requires Legal and Technical Teams
Legal teams should assess the actual licenses in use to ensure no false positives have been identified in the report, and that all potentially problematic conflicts and exposures are remediated (with the help of technical teams). Doing this effectively requires both an understanding of how the code is being used and detailed knowledge of OSS licenses.
There are two principal self-appointed, authorities who approve OSS licenses: the Free Software Foundation (FSF) and the Open Source Initiative (OSI), respectively. The OSI has approved slightly more licenses as meeting the criteria of “open,” than the FSF has deemed as “free”. There are currently 70 open source licenses approved by the OSI. Licensing expertise and an understanding of the practical application and interactions of your code is critical to the legal aspect of an audit review.
However, technical input is also crucial to reviewing open source use and providing potential fixes. As Gartner pointed out in its 2014 report, “OSS governance efforts that do not include developers as critical members of the decision generally result in a decision-making process that doesn’t work.” Changes required to resolve identified issues can not only have a technical and legal impact, but also a commercial one. Therefore, the best analysis of issues and potential solutions will come from your business, legal and technical teams working together.
When are Audits Required?
Often an audit is requested by a third-party as the result of a potential investment, IPO, sale or merger. In these circumstances, it is commonplace for warranty statements to be requested in respect to an organizations’ use of open source code and OSS license compliance.
The reality is that any organization using significant volumes of software or, more importantly, distributing software, ought to have knowledge of its code use and its associated license commitments regardless of third-party triggers. A thorough understanding of your company’s use and distribution of software, as well as an ongoing compliance process, should be part of an overall open source governance program.
Warranties around open source are a hot topic and the fact that an audit has occurred or proper governance has been put in place may not resolve all of the issues which arise from warranty and indemnity requests, although it helps.
If an audit is undertaken to meet a third-party’s requirements on an investment, merger, or floatation, a warranty with respect to the ownership or rights to use may be requested by the investor or purchaser. A purchaser or investor will want to know exactly what they are buying or taking a stake in. What obligations and liabilities they will be taking on?
By its very nature and pace of development, determining the origin of OSS components can be difficult. Therefore, most audit providers will not offer an absolute warranty, indemnity, or guarantee that the code audit is 100% correct. However, most can offer some level of protection or a letter of assurance which will assist in the terms of a warranty. An exhaustive code audit by a reputable third-party, coupled with a formal OSS policy and governance processes, should provide a suitable level of comfort to potential investors and acquirers.
Audit reports can also provide reassurance to customers and/or third-parties to whom code is provided through your company’s software or services. Depending on circumstances, it may be appropriate to provide third-parties with a code Bill of Materials (BOM) to set out the code that is being provided.
Of course, beyond commercial audit services there are also a number of freely available tools which can check your code base, such as the Binary Analysis Tool (BAT), the Open Source License Checker, and FOSSology (which is the best known of the three). If your engineering teams are sophisticated enough, these free tools may provide a base level of comfort without the cost of a commercially provided audit. However, usage of these tools will also come with no reassurance and may not provide an acceptable level of comfort to third-parties seeking warranties with respect to the content of the code.
Key Steps to a Successful Open Source Audit
To summarize, the following are key steps your company should take when performing an open source code audit:
- Establish an internal audit team including legal (if not available, seek external legal counsel), technical, and commercial representatives.
- Review potential audit providers. The size of the provider’s code database, their costing methodology, their audit report format, and warranties or assurances offered should all be top considerations.
- Appoint a third-party audit provider and, if necessary, an external legal expert.
- Consider how your business uses and intends to use OSS, what your open source strategy is, and whether any licenses are inappropriate in particular circumstances.
- Upon receiving the audit report, review identified issues from a technical and legal perspective. This may take a period of time and ongoing co-operation.
- Evaluate current processes and determine what your company’s OSS best practices will be in terms of adoption, use, and distribution.
- Legal and technical teams should come to an agreement on necessary fixes and undertake fixes as a consequence of audit.
- Draft an OSS policy and establish a process for ongoing code management and monitoring.
- Institute regular audits to ensure that policies are being followed and code remains compliant.
- Regularly review and update your OSS policy to stay aligned with development processes and business goals.
A successful audit should provide assure your internal teams, third-parties, and customers that your code is legally and technically compliant. And once you have a proper open source policy and governance program in place, you’ll be able to ensure that it stays compliant.