Software due diligence is a process completed during a merger or acquisition of a software company that analyzes all aspects of the target company, its operation and its product prior to investment or purchase by another company. It is a key step in building trust between the companies, as it is used to determine how much a target company is really worth, how much it can produce, and if the organization is actually equipped to deliver on its promises.
Due diligence allows the software company buyer to gather information about a potential target, allowing them to plan for integration. Gathering information about the target can help to determine how the products and people of the company will fit into the buying organization, and what sort of integration costs or issues there may be. It also identifies and attempts to eliminate risks for both parties, as these risks can put the deal in jeopardy if uncovered during the transaction, or can decrease investment efficiency and hurt business plans for the buyer if discovered after the transaction is completed.
Software due diligence is meant to ensure both parties know everything they need to before signing a contract together.
During Software Due Diligence
During software M&A, it is in the best interests of both parties to close the deal as quickly as possible, as nearly 20% of global M&A deals are withdrawn or terminated. The time taken to complete the deal can be a serious contributing factor to whether or not the deal is completed, as dragging out the M&A and due diligence processes can test a buying company’s patience.
Buyers don’t want to waste time and resources on an unnecessarily drawn out process if they don’t need to. Furthermore, if the process takes an extended period of time, fortunes may have changed for the potential buyer in this time, and they may no longer be in a financial position to be purchasing another company.
Failed software M&A transactions can have an incredibly harmful impact on the reputation of the selling company, as they will make future companies that may be interested in M&A think twice about investing in or acquiring a company that failed to close the deal previously.
What caused the deal to fall through?
Were there glaring issues that led to the other company withdrawing their interest?
These questions can create doubt in the minds of future buyers or investors. On top of this, if a software acquisition deal falls through, sellers will often have wasted large amounts of valuable time and resources trying to get materials for M&A and due diligence prepared.
When conducting software due diligence, buyers should try to use as many resources as possible before asking the target company for proprietary information. A combination of several resources can provide much of the necessary information and can be used to perform a range of due diligence tasks. Good resources to use are articles about the target on news sites, analyst reports, business data on the target’s website, videos of the CEO’s technical product strategy, technical staff profiles on LinkedIn and developers’ contributions on public open source projects. These resources can reveal a lot of information about the acquisition target’s staff, their company architecture and their development processes, allowing buyers to either start planning how to integrate the target into their company, or to withdraw from the deal.
Once the information from these resources has been gathered, and assuming the deal is continuing to move forward, trying to gather details about the target’s proprietary information is the next step for buyers. This information can include the target’s internal processes, architecture and real code, but this information may be difficult to access. Even if a buyer approaches a target company with a letter of intent and non-disclosure agreements, targets will often hesitate to share too many architecture or code details. This is due to the fact that if the deal falls through, potential sellers don’t want their methods and/or code to be used by a prospective buyer, who can then become a new rival in the industry.
If granted access to proprietary information, particularly source code, buyers must try to get as much information as possible, including details about bugs, design problems, security vulnerabilities and missing or conflicting open source licenses. Bugs and design problems can present serious issues, as inefficient code design can be a nightmare for developers to work with, and can be time consuming to fix. Security vulnerabilities can cause headaches as they are hard to find, but are vital to identify and deal with to protect software from attacks. When it comes to open source licenses, if OSS use is out of license compliance, this can be possibly the most insidious problem to find of all, as it can lead to legal issues and potential loss of IP and can reduce the value of the sale.
How Software Company Sellers can Prepare for Software Due Diligence
To ensure that the M&A and due diligence processes go smoothly, it is imperative for sellers to prepare properly. Being proactive and staying organized are the two best things a seller can do, as this can speed up the software due diligence process and ensure that deals are completed in a timely fashion. One of the best ways to stay organized is to keep an updated database of open source specifications and use.
Keeping a list of open source components in use can not only identify what components are in use, but can also identify where they are and provide details about security vulnerabilities, quality issues and license issues. This list can be created and maintained manually or it can be automated. The manual method usually involves a spreadsheet updated by developers whenever they add or remove components, but this can be highly inaccurate if developers forget to update the list or simply neglect to do so due to laziness. An automated solution can scan a codebase with automated tools, automatically discovering all open source components and recording their details within minutes. Automated software to monitor open source components is not only far more accurate, but is also far faster than recording this information manually.
Once information about open source use is organized, sellers must ensure all of their licenses are in compliance. This involves checking what all licenses require the user to do, and ensuring your company meets the requirements. Companies acquiring software companies want to make acquisitions without legal implications, and want to start with a “clean slate”, so ensuring they aren’t buying a company or its code with OSS license issues is a top priority for buyers.
Sellers must also identify any vulnerable code and outdated components and fix these issues if possible. The seller’s code can have software vulnerabilities and flaws without them being aware, and if the buying company finds out about these issues before the seller does, they won’t want to purchase code that can be easily hacked or exploited. Manually tracking all vulnerabilities is nearly impossible, as thousands of vulnerabilities are published online monthly. Automated tools can scan software with information from the National Institute of Standards and Technology (NIST) database and immediately alert users when weaknesses are found. Organizing information about OSS use, OSS licenses and vulnerable or outdated components will expedite the due diligence process, and will reflect well on the selling company when due diligence is conducted.
Finally, sellers will often want to give disclosures, similar to those given when selling a house. Instead of giving disclosures about cracks in the foundation, software sellers should give high-level disclosures about company policies, process documentation, BOMs of open source components and security breaches. Buyers will normally follow up by inquiring about development processes, debugging procedures and different use cases, and if they proceed with the deal, they’ll often want to perform their own analysis of the code to find any quality, security and license compliance issues.
Dealing with Software Due Diligence Issues
Issues of some sort will arise in almost every M&A deal, particularly based on information found during due diligence.
Thankfully, there are many avenues for dealing with these issues. The first and simplest method is for a seller to agree to fix a found issue by a certain deadline as a condition of sale. If an agreement can’t be reached this easily, a seller can provide a warranty in the event that a buyer identifies a risk that the seller deems a non-issue. This can resolve disputes by holding the seller accountable in the event of a risk becoming an issue, but without forcing them to fix the problem or pay any sort of compensation up front. A final solution can be for the seller to set aside a certain percentage of the deal’s value as insurance for a finite time. If future issues arise, the buyer can draw from this money as needed, and the percentage can increase if major unexpected issues appear.
Use a Third Party to Decrease Software Due Diligence Risk
Using a third party to conduct software due diligence is often a wise choice for both parties. When performing their own due diligence on a target company, buyers can become “contaminated” by too much confidential information. Looking directly at code and other proprietary content can lead to legal issues in the future if the deal falls through. If they’ve shown the buyer too much of their proprietary content, sellers may be very concerned that potential buyers will steal their IP and become new rivals. If the potential buyers later come out with any sort of similar software to that of the target, even without intent to steal the software, they’ll likely be accused of IP theft.
Particularly when dealing with sensitive content like architecture and code, using a third party can both insulate buyers from contamination and accusations of IP theft, while also granting sellers peace of mind. In the same scenario of the deal falling through during due diligence, the buyer will not have directly seen the code or IP of the target, and therefore can’t steal the IP or be accused of doing so. Additionally, third parties can have teams of varying expertise, objective views, and the ability to compare hundreds of companies to the target company, meaning that they’re more prepared to conduct a thorough due diligence process than either the buyer or the seller.
Software due diligence is a vital part of every merger and acquisition. To ensure it goes as smoothly and quickly as possible, sellers must prioritize organization, particularly when it comes to open source use. Keeping within license restrictions and staying up to date on vulnerabilities and new updates for open source components can be a difficult task when conducted manually.
Automating OSS organization makes the software due diligence process far easier, and can put sellers’ minds at ease during due diligence.
Sellers can use OSS security analyzing software like SOOS to facilitate organization, increase awareness of open source issues, and speed up the entire M&A process.
