Open Source Audits in Merger and Acquisition (M&A) Transactions
Provides an overview and practical guide to open source audits in merger and acquisition (M&A) transactions.
This document is a translation of Open Source Audits in Merger and Acquisition Transactions: The Basics You Must Know (by Ibrahim Haddad, Ph.D., 2018), published by the Linux Foundation. The original author has not reviewed this translation. The original can be viewed at the original PDF.
In an era where software sits at the center of every deal, open source due diligence has become standard practice in mergers and acquisitions (M&A). This book covers how open source audits are conducted in M&A transactions, and what the acquirer and the target company each need to prepare.
1 - Chapter 1. Introduction
Introduces an overview of the open source audit process in M&A transactions.
This document is a translation of Open Source Audits in Merger and Acquisition Transactions (by Ibrahim Haddad, 2018), published by the Linux Foundation. The original author has not reviewed this translation. The original can be viewed at the original PDF.
We live in a software-defined era. Nearly everything we do is in some way planned, shaped, analyzed, and managed by software. Under that vast software umbrella, open source software stands foremost. Companies across every industry are rushing to use, participate in, and contribute to open source in order to capture the various benefits open source projects offer. Those benefits range widely, from tapping external engineering resources that shorten time to market, to faster innovation.
This trend applies equally to corporate transactions, since nearly every technology acquisition involves software in some form. The software due diligence process, in which the acquirer comprehensively reviews the target company’s software and compliance practices, has now become standard procedure in every merger and acquisition (M&A). Open source software is commonly encountered in this process, and it presents verification challenges different from those of proprietary software.
This material looks at an overview of the open source audit process conducted in merger and acquisition (M&A) transactions.
2 - Chapter 2. Common Open Source Usage Scenarios
Summarizes the ways open source enters a codebase: incorporation, linking, and modification.
Before diving into the open source due diligence process, it helps to understand the various paths through which open source software enters the target company’s development process. This applies whether the company put open source software into its codebase knowingly or unknowingly. As with a traffic ticket, not knowing about an obligation is no excuse. It is therefore wise to understand the various ways in which software from multiple sources is used. The most common usage scenarios for open source software are incorporation, linking, and modification.
Modifying an open source component, or injecting open source code into a proprietary or third-party component, can affect how an audit service provider detects and reports that code. When working with an open source audit provider, it often helps to understand how their detection methods capture open source code.
2.1 Incorporation
A developer may use a complete open source component, or copy a portion of a component (sometimes called a snippet) into their software product. This situation can be permissible, and depending on the license of the incorporated open source code and the license of the software component it is copied into, there may be no license risk at all. In other cases, however, incorporation causes problems when the license of the copied open source code is incompatible with the license of the proprietary codebase (Figure 1).
Open source licenses carry various obligations that can affect a company’s legal liability and the proprietary nature of its own code. All incorporation therefore needs to be tracked, disclosed, and approved internally, following the same process used to track and approve third-party licensed software.
Figure 1. Incorporation: putting open source code (green) inside a different body of code (blue) (source: Linux Foundation, 2018)
Source code audits are designed to find open source that has been incorporated into a codebase without being disclosed, to prevent unpleasant surprises after an acquisition. Undisclosed incorporation becomes more likely when the target company has not received sufficient open source compliance training, or has relied on outsourced staff or interns who leave no long-term records.
Incorporation scenarios often go unnoticed when a person looks through the source code directly, but a source code scanning tool with the ability to find and match snippets can readily surface them.
2.2 Linking
Linking is a common scenario that arises, for example, when using an open source library. In this scenario, a developer links an open source software component with their own software component (Figure 2). Various terms refer to this scenario: static/dynamic linking, combining, packaging, and creating interdependencies. Libraries are usually included at the top of a file, and linked code tends to reside in a separately named directory or file, which makes linking relatively easy to detect when scanning source code visually.
Figure 2. Linking: connecting open source code (green) to a different body of code (blue) while keeping them separate (source: Linux Foundation, 2018)
Linking differs from incorporation in that the source code is kept separate rather than being copied into a single combined form. The linking interaction occurs when the code is compiled into a single executable binary (static linking), or when the main program runs and calls the linked program (dynamic linking).
2.3 Modification
Modification is the scenario in which a developer changes an open source software component (Figure 3). The following actions fall into this category.
- Adding or injecting new code into an open source software component.
- Modifying, optimizing, or changing an open source software component.
- Deleting or removing code.
Figure 3. Modification: a developer adding, changing, or deleting code in open source code (green) (source: Linux Foundation, 2018)
It is important to know that some development tools can perform some of these actions without the user noticing. For example, a developer may use a tool that automates a specific part of the development process. Examples include graphics frameworks that provide user interface templates, game development platforms that provide physics engines, and software development kits (SDKs) that provide cloud service connectors. To deliver these services, a tool usually injects part of its own code into the developer’s output when the code is built. The license of code injected by a development tool in this way must always be verified, especially because the resulting output is often statically linked.
3 - Chapter 3. Open Source Audits
Explains why open source audits are performed, the criteria for deciding whether to commission one, and the inputs and outputs of the audit process.
Every merger and acquisition (M&A) transaction differs, but the need to verify the impact of acquiring open source obligations remains constant across every deal. An open source audit is performed to understand how deeply the target uses and depends on open source software. It also provides insight into compliance issues, and further allows a look into the engineering practices of the target company.
Open source licenses can impose constraints on how software is redistributed. These constraints may be incompatible with the acquirer’s business, so they need to be uncovered early. Examples of how open source software affects the acquired asset include the following.
Open source licenses typically impose obligations that must be fulfilled when distributing code. One example is the GNU General Public License (GNU GPL), which requires that derivative works or combined works also be provided under the same license. Other licenses require that specific notices be included in documentation, or place constraints on how a product may be promoted.
Failing to meet open source license obligations can lead to litigation, costly redesigns, product recalls, and reputational damage.
3.2 Should You Commission an Open Source Audit?
A frequently asked question is whether an open source audit is even necessary. The answer depends on the company, the purpose of the acquisition, and the size of the source code. For example, in a smaller acquisition, some companies choose only to review the open source bill of materials (BoM) provided by the target (assuming one is provided) and discuss open source practices with the target’s engineering leadership. Even when the purpose of the acquisition is talent acquisition, an audit can uncover undisclosed liabilities arising from past license obligations of an already-released product.
The audit process has one primary input and one primary output (Figure 4). The input to the process is the entire software stack subject to the ongoing merger and acquisition (M&A) transaction. This includes proprietary software, open source, and 3rd party software. The primary output at the end of the process is a detailed open source software bill of materials, which lists the following.
- All open source software used as components, their origin, and the identified license
- All open source snippets used in proprietary or 3rd party software, their source component, and the identified license
Figure 4. Inputs and outputs of the due diligence process. The full software stack, consisting of proprietary software, 3rd party software, and open source software, is taken as input, and after source code scanning and identification, an open source software bill of materials (BoM) is produced as output (source: Linux Foundation, 2018)
4 - Chapter 4. Estimating Audit Scope
Explains the code size and characteristics an auditor must understand to produce an audit estimate, and how urgency affects cost.
The size, scope, and cost of an audit vary by transaction, and generally increase as the size and complexity of the source code grow. To provide an estimate (cost and duration) for an open source audit, the auditor needs to gain some understanding of the codebase’s size and characteristics, as well as the project’s urgency.
The first questions an auditor asks relate to code metrics: the size of the source codebase, the number of lines of source code, and the number of files to be audited. The auditor also asks whether the codebase consists solely of source code, or whether it also includes binary files, configuration files, documentation, and other file types. Knowing the file extensions subject to audit can also be helpful to the auditor.
Mature companies generally keep records of the open source components and versions used in their products and projects. This information greatly helps the auditor gauge the expected workload.
Because discussions of audit cost occur early in the process based on size and scope, the acquirer may not have access to all the information described above. At a minimum, the auditor needs to know the number of files to be scanned before proceeding, and any additional information helps refine the estimate further. Once the auditor has gathered enough information to understand the scope of work, urgency also needs to be determined, since it significantly affects the cost of the audit.
5 - Chapter 5. Audit Methods
Explains the procedures and trade-offs of three audit methods: traditional audits, blind audits, and do-it-yourself (DIY) audits.
When performing an open source audit, certain capabilities of a tool provide real value to the acquiring company. One of the most important is the ability to find open source code snippets mixed into the target company’s proprietary code, and vice versa. Another is the ability to automatically filter false positives from audit results, minimizing the amount of manual work required.
There are three audit methods.
- Traditional audit. The auditor has full access to all code and performs the audit remotely or on site.
- Blind audit. The auditor performs the work remotely without ever seeing the source code.
- Do-it-yourself (DIY) audit. The target company or acquiring company uses a tool to perform most of the actual audit work themselves, with the option for the audit firm to randomly verify the results.
5.1 The Traditional Audit Method
This method is called traditional because it is the original way of scanning source code for open source compliance. In a traditional audit, a compliance auditor from a third-party audit firm accesses the source remotely through a cloud system, or by visiting the site directly, and then performs a source code scan.
Figure 5. The traditional audit procedure in a merger and acquisition (M&A) transaction (source: Linux Foundation, 2018)
Figure 5 shows the audit procedure under the traditional audit method. Note that this procedure can vary slightly by service provider. A typical traditional audit procedure follows these steps.
- The auditor sends questions to the acquiring company to better understand the work.
- The acquiring company answers, helping the audit firm better grasp the scope and audit parameters.
- The auditor provides a quote based on the answers.
- The quote is agreed upon. Next, the parties sign a service agreement, a statement of work, a non-disclosure agreement, and so on. (The “Start” in Figures 5, 6, and 7 assumes the point at which all agreements have been signed, i.e., when the audit procedure actually begins.)
- The auditor is granted access to the target’s code, either through a secure cloud upload or by visiting the company for an on-site audit.
- The auditor scans the target’s source code, cleans up false positives, and evaluates the results.
- The auditor generates a report and delivers it to the client.
- The results are reviewed with the auditor and questions are answered, either by call or in person.
Most audit service providers adopt this method in common. You can get multiple bids for the same audit work and pick the one that best fits your requirements. Following this model requires the target company either to transfer the code to the auditor, or to allow the auditor to visit its office and complete the work on site.
5.2 Blind Audits
The blind audit method was pioneered by FOSSID AB, headquartered in Stockholm, to address the confidentiality requirements of M&A transactions. (Here, FOSSID AB refers to the company, and FOSSID refers to the tool itself.)
This company uses its own proprietary technology to perform audits and generate reports without ever seeing the source code. Figure 6 shows the blind audit procedure used by FOSSID AB, designed to keep source code confidential in M&A transactions. One key advantage of a blind audit is that the auditor can complete the review without accessing the source code. Furthermore, with enough care from the acquiring company, it can also provide a high level of confidentiality by keeping the auditor unaware of the target’s identity. As far as the author is aware, no other company offering open source compliance services provides this audit method.
Figure 6. The blind audit procedure using FOSSID. The target company collects and sends only the digital signature of the software using a fingerprint collection tool, and FOSSID AB audits it by matching that signature against an open source database, without ever accessing the source code (source: Linux Foundation, 2018)
5.3 DIY Audits
A do-it-yourself (DIY) audit gives the acquiring company or the target company time-limited access to a compliance cloud tool so they can run the scan themselves. This allows the audit to be performed internally with full access to the knowledge base and all reporting functions. This approach is particularly attractive to companies with in-house staff experienced enough to interpret scan results and propose remediation procedures. For a company that goes through M&A procedures several times a year, it can quickly become the more cost-effective approach. The audit tool service provider can further secure the integrity of the audit by performing an independent certification to verify the results.
Figure 7 shows this audit method using FOSSID AB’s tool. This approach has several advantages. Because it uses internal resources and does not depend on the availability of a third-party auditor, the audit can begin immediately when needed. This approach can shorten the schedule and reduce external cost factors. Because the audit is performed by someone with direct access to the code, all compliance issues can be handled immediately and fixes applied right away. Finally, the audit tool provider can verify the audit to ensure accuracy and completeness. As part of its DIY service, FOSSID AB randomly verifies X percent (X is determined as part of the quote agreement) of the files the target company decides to audit.
Figure 7. The do-it-yourself (DIY) audit procedure using FOSSID. The target company performs the scan and audit itself on a time-limited instance of a dedicated web app, FOSSID AB independently verifies a portion of the audited files, and all data is deleted once the period ends (source: Linux Foundation, 2018)
6 - Chapter 6. Notes on the Final Report
Notes that final reports may contain a lot of noise, requiring time to filter out real issues, and that SPDX-format reports must be requested to be received.
Many audit tools can be configured to highlight potential issues. Careful review of the results may reveal that a good number of them are not real problems, but you should be prepared for a substantial amount of noise mixed in. This noise stems from things such as residual code that remains in the code tree but is not actually used. Initial reports can therefore be lengthy, and you should be prepared to invest time in filtering the report to find the real issues.
Note that reports conforming to the Software Package Data Exchange (SPDX) format are typically provided only upon request. If you want to receive a report in that format from your audit service provider, you therefore need to request it separately.
7 - Chapter 7. Security and Version Control
Explains that vulnerabilities in open source projects are disclosed alongside the fix process, and that although security and version control are not part of compliance due diligence, scan service providers may address them separately.
It is generally accepted that software ages like milk, not wine. And security vulnerabilities are a concern in all code, whether open source or not. However, in open source projects, these vulnerabilities are publicly exposed alongside the process of fixing them. This exposure can occur either before or after a fix is applied, and older open source code may harbor vulnerabilities that are actively exploited in the wild. Security and version control are not part of the open source compliance due diligence process, but companies that provide source code scanning services sometimes also offer a service that maps identified open source components against known open source security vulnerabilities.
8 - Chapter 8. Pre- and Post-Acquisition Remediation
Covers the options for resolving compliance issues revealed by the audit, and how the cost of each option can be used in valuing the target company.
By this point, the acquirer should have a clear understanding of how the target company uses and manages open source software, and how successfully it has met its open source license obligations. The acquirer and the target need to negotiate remediation for open source compliance issues based on this information. If issues are found in the audit, there are a few options for resolving them as part of the ongoing transaction. The first option is simply to remove the problematic code. If the open source software only plays a supplementary role to proprietary code, it can be removed entirely. Another option is to design around the problematic component, or to rewrite the code using cleanroom techniques.
If that area of code is essential or has already been distributed, the only remaining option is to bring the code into compliance. The cost of each option can be used when valuing the target. Whichever option is chosen, it is important to identify the individuals who were involved in introducing the open source code and involve them in the remediation work. They may have additional documentation or knowledge useful for resolving the issue.
9 - Chapter 9. Preparing for an Audit as a Target Company
Covers how a target company can prepare in advance for an open source audit through its regular compliance activities.
Passing an open source compliance audit is not difficult, provided you are prepared. But if you only start preparing after an acquiring company has shown interest, passing becomes difficult. These activities need to proceed alongside everyday business and development activities. The goal is to track every open source component the company uses and to honor the open source license obligations that arise from using those components. These same measures also help greatly when a company becomes the subject of a corporate transaction, because they reduce the risk of unexpected problems.
9.1 Know What Is in Your Code
Knowing what is in your code is the golden rule of compliance. You need to maintain a complete software inventory of every software component, including its origin and license information. This includes software components the organization built itself, open source components, and components originating from third parties. Most important is having a process to identify and track open source components. A complex compliance program is not always necessary, but five basic elements are required: policy, process, people, training, and tools.
9.1.1 Policy and Process
An open source compliance policy is a set of rules governing the management of open source software, covering both use and contribution. Process is the detailed specification of how the company implements these rules day to day. Compliance policies and processes govern various aspects of open source software, including use, contribution, auditing, and distribution.
Figure 8. An example of an end-to-end open source compliance process, going through the stages of identification, audit, resolution, review, approval, registration, documentation, verification, and disclosure (source: Linux Foundation, 2018)
Figure 8 shows an example compliance process. It represents the various stages each software component goes through as part of due diligence while building a product or software stack.
- Identify all incoming source code.
- Audit the source code.
- Resolve issues found in the audit.
- Complete the appropriate review.
- Obtain approval for the open source usage.
- Register the open source in the software inventory.
- Update product documentation to reflect the open source usage.
- Verify all steps prior to distribution.
- Distribute the source code and perform final verification related to distribution.
The output of this process is an open source Bill of Materials (BOM). This BOM can be published together with a written offer that fulfills the legal obligations for the components it contains, along with the relevant copyright, license, and attribution notices. For a detailed discussion of the open source compliance process, refer to the free e-book Open Source Compliance in the Enterprise, published by the Linux Foundation.
9.1.2 People
At a large company, the open source compliance team is a multidisciplinary group made up of several members whose mission is to ensure open source compliance. The core team, often called the Open Source Review Board (OSRB), consists of representatives from engineering and product teams, one or more legal counsel, and a compliance officer. The extended team consists of a variety of members across departments such as documentation, supply chain, corporate development, IT, and localization, who contribute to compliance efforts on an ongoing basis. At a small company or startup, however, it can be as simple as a single engineering manager supported by legal counsel. Every company is different.
9.1.3 Training
Training is an essential component of a compliance program, helping employees clearly understand the policies governing open source software usage. The goal of providing open source and compliance training is to raise awareness of open source policy and strategy, and to build a shared understanding of the issues and facts of open source licensing. It should also address the business and legal risks that arise from including open source software in a product or software portfolio.
Both formal and informal training methods can be used. Formal methods include instructor-led training courses that require employees to pass a knowledge test to complete the course. Informal methods include webinars, brown bag seminars, and presentations delivered as part of new employee orientation sessions.
Open source compliance teams frequently use tools to automate source code audits, find open source code, and identify its licenses. These tools include compliance project management tools, software inventory tools, and source code and license identification tools.
9.2 Comply with Your Obligations
Whether intentionally or not, if you have shipped a product that includes open source software, you must comply with the various licenses governing those software components. This is why knowing what is in your code matters: having a complete Bill of Materials makes compliance far easier.
Complying is not a simple task, and it varies by product depending on the licenses and code structure involved. Broadly speaking, complying means the following.
- Track every use of open source software.
- Produce a finalized open source Bill of Materials for all software included in the shipping product image.
- Fulfill the obligations of the open source licenses.
- Repeat this process every time a software update is distributed.
- Respond to compliance inquiries promptly and seriously.
9.3 Use the Latest Release for Security
One benefit of a comprehensive compliance program is that it becomes easier to find and replace products containing unsafe versions of open source components. Most source code scanning tools now offer the ability to flag disclosed security vulnerabilities in outdated software components. One important consideration when upgrading an open source component is to always confirm that the component retains the same license as the previous version, since open source projects have occasionally changed licenses at a major release.
Companies are encouraged to engage with open source project communities to avoid situations where they end up using a version with a security vulnerability. Actively participating in every open source project you use is neither reasonable nor feasible, so some level of prioritization is needed to identify the most important components. The level of engagement can range from subscribing to mailing lists and joining technical discussions, to contributing bug fixes and small features, to making major contributions. At minimum, it is beneficial for a company’s developers working on a particular open source project to subscribe to and monitor that project’s mailing list to receive reports on security vulnerabilities and available fixes.
9.4 Measure Your Compliance Efforts
The easiest and most effective first step any organization can take, regardless of size, is to participate in the OpenChain Project and achieve “OpenChain Conformant” status. This is done by answering a series of questions, either online or manually. The questions used for OpenChain conformance help confirm that an organization has established a process or policy for open source software compliance. OpenChain is an industry standard similar to ISO 9001. It leaves the precise implementation of process and policy to each individual organization and focuses on the “big picture.” OpenChain conformance demonstrates that an open source compliance process or policy exists, and that additional details can be shared when a supplier or customer requests them. OpenChain is designed to build trust between organizations across global supply chains.
The Linux Foundation’s Self-Assessment Checklist is a broad checklist that covers compliance best practices as well as the elements a compliance program needs in order to succeed. Companies can use this internal self-assessment checklist to evaluate their compliance against compliance best practices.
10 - Chapter 10. Preparing for an Audit as the Acquirer
Covers the decisions the acquirer must make before commissioning an audit, and the additional obligations after receiving the audit results.
As the acquirer, you need to take action and make decisions before commissioning an audit, and there are additional obligations after receiving the results.
10.1 Choose the Audit Model and Auditor That Fit Your Needs
As discussed earlier, three main audit methods are available, and you need to decide which one best fits your specific situation.
10.2 Understand What Matters to You
A source code audit report can provide a substantial amount of information depending on the complexity of the code scanned. It is important to identify which licenses and use cases are considered significant.
10.3 Ask the Right Questions
An open source audit report provides a great deal of information about the target company’s source code and its associated licenses. However, clarifying or confirming compliance-related concerns requires further investigation into a number of other data points. This section summarizes what matters and offers a set of questions as a starting point for framing the questions to raise with the target company.
- Has the target company used code under a license that could jeopardize the target’s or the acquirer’s intellectual property (IP)?
- Are there any code snippets of unknown origin or unknown license?
- Are the target company’s open source compliance practices sufficiently mature and comprehensive?
- Does the target company track known vulnerabilities in its own open source components?
- When distributing its products, does the target company provide all the materials needed to satisfy open source license obligations (written offers, all required notices, and source code where applicable)?
- Does the target company’s compliance process keep pace with its development speed, so that it can meet product release schedules?
- Does the target company have a process in place to respond to source code requests in a timely manner?
10.4 Identify Items to Resolve Before Deal Execution
In some cases, an open source audit may reveal instances of licenses or compliance practices that are unacceptable to the acquirer. In such cases, the acquirer can request that these instances be mitigated as a condition of closing. For example, the target company may use a code component provided under License A, while the acquirer has a strict policy prohibiting the use of any source code licensed under License A. In such situations, both sides need to discuss the matter and find a possible resolution.
10.5 Develop a Post-Acquisition Compliance Improvement Plan
Developing a compliance improvement plan is especially important when the acquirer is a large company acquiring a small startup that will continue to operate as a subsidiary. In such situations, the acquirer often helps the target company establish formal compliance policies and processes, provides training on its own practices, and offers ongoing guidance and support.
11 - Chapter 11. Recommended Compliance-Related Development Practices
Summarizes development practices that reduce compliance issues, and mistakes that must be avoided.
Detailed recommendations on how to establish development practices that support open source license compliance activities are already available in a number of publications. This chapter briefly touches on the most important of these practices. Following them can eliminate a substantial share of commonly occurring compliance issues.
11.1 Recommended Practices
- Request approval for using open source software before committing code to a product repository.
- Request approval before linking proprietary code to an open source library or vice versa, unless the license of that library code has already been pre-approved under company policy.
- For every file you modify, update a changelog with a one-line description of the date of change, the author, and the change applied.
- Document the interface between the code you write and the open source software. This helps others understand the interaction and clarify compliance-related concerns.
- Save the web page describing the license of a source code package as a PDF, to record the state of the project at the time of download.
- Keep an unmodified copy of the package, along with its license information, in a backup location.
- When upgrading an open source software component, verify that the license has not changed. Licenses can change between versions.
- Verify that the license of a source code package matches what is described on the project’s website. If there is a discrepancy, contact the project to clarify it.
11.2 Mistakes to Avoid
- Do not remove or alter existing license or copyright information. All such information must be kept intact.
- Do not rename open source components.
- Do not copy and paste open source code into proprietary or 3rd party source code, or vice versa, without prior approval.
- Do not commit open source or 3rd party source code to an internal product source tree without prior approval.
- Do not merge or mix source code that came in under different licenses without proper approval.
- Do not discuss compliance practices with individuals outside the company.
12 - Chapter 12. Conclusion
Summarizes what the target company and the acquirer each need to prepare in order for open source due diligence to proceed smoothly.
Open source due diligence is generally just one item on a long list of tasks that need to be completed successfully in a merger and acquisition (M&A) transaction. Even so, given the central role of software and the potential intellectual property (IP) risks involved, it remains an important aspect of the overall due diligence process. Open source due diligence may seem like a lengthy process, but it is often completed quickly when both sides are prepared and work with a responsive compliance service provider.
So how can you prepare?
If you are the target company, you can maintain proper open source compliance practices by incorporating the following items into your development and business processes.
- Identify the origin and license of all internal and external software.
- Track open source software (components and code snippets) throughout the development process.
- Perform source code review on new or updated code that goes into a build.
- Fulfill license obligations when releasing products or updating software.
- Provide open source compliance training to employees.
If you are the acquirer, you need to know what to look for and have the capability to resolve issues quickly.
- Decide with the target company on the appropriate audit method to use and the 3rd party to whom the audit will be entrusted. Note that some providers lack blind testing capability, some do not support a do-it-yourself (DIY) approach, and others lack the ability to detect code snippets.
- If possible, obtain multiple quotes for the audit and learn more about the audit service providers. This step is not just about cost; it is about securing the accurate deliverables that will help resolve your concerns. Make sure you have the internal expertise to compare each quote on an equal footing, and confirm that the quote covers all of the following audit parameters.
- Audit method, inputs and outputs
- Key points of contact at the target company and the acquirer for promptly discussing issues that arise
- Schedule and process, especially if on-site visits are involved
- Confidentiality parameters
- Code vulnerability and version control analysis
- Cost, both standard procedure and expedited processing
Open source compliance is an ongoing process. Maintaining good open source compliance practices prepares you for any situation involving a change in the ownership or management of software, such as a potential acquisition, divestiture, or product or service launch. For this reason, companies are strongly encouraged to invest in building and improving their open source compliance programs.