July brought a flurry of activity to our various offices and reminded me of an often overlooked but very important piece of M&A diligence. By now most of us are well-versed in the basic steps of conducting IP due diligence in M&A deals. Any company can quickly generate a list of its patent, trademark and copyright registrations, and most have little trouble locating the license agreements they have signed with third parties. Frequently, however, targets and acquirers assign little relevance to, or completely fail to document, unsigned licenses for free source code that is included in the target’s software offerings. Yes, we are talking about open source software, and far too many companies fail to recognize the importance of detailed disclosure of open source use until too late in the diligence process. Both targets and acquirers should prepare for and commence open source diligence early in the M&A timeline.
If you are an acquisition target, are interested in becoming one, or frankly if you are using open source at all, you can never start the open source documentation process too early. There is no need to wait until the term sheet is signed. The first step is creating and following an open source software policy for your organization. This policy should include both a central means of documenting your use of open source software and a mechanism for approving/disapproving each proposed use of open source. You will need to know and document the identity of the open source software being used, the version, the applicable open source license, whether your developers have modified it, whether you’ve distributed it, and how it interacts with your proprietary code and with other third party software. Remember that open source software packages frequently require dependencies to be downloaded and installed; you will need to track your use of those too. If you have not been keeping track of your open source use to date, or if you believe there are gaps in your records, consider having an open source audit performed on your code base. While they sometimes disclose false positives, these audits are a great tool for getting the whole picture of your company’s open source use.
If your company is an acquirer, begin asking for open source information early in the diligence process. The target’s disclosures in response to the open source representations in the merger or purchase agreement should not be the first time you have a chance to review documentation of its use of open source. Develop a good open source diligence questionnaire and send it to the target along with your first set of diligence questions. You will want to know the identity of any open source software used in the development of the target’s software products, the specific version used, the license applicable to that version, whether the target modified the open source software, whether the target distributed the open source software, and how each piece of open source software interacts with the target’s proprietary code and with other third party software. Carefully investigate the open source software they’ve identified. Does it require dependencies that are licensed under a different open source library? Are included libraries licensed under a different license? Do not be afraid to request additional information if the target fails to provide the detail you’ve requested. The days of adequately responding to an open source questionnaire with a simple list of [software package] | [license] have been over for some time. If the target is not able to give you what you need, or if the target’s software is the focal point of the transaction, strongly consider undertaking an open source software audit of the target’s code base.
Open source software diligence requires advanced planning, proper procedures and timely disclosures of information. It often is not a quick or simple process, but the time spent prior to or during diligence is an important step in identifying and remedying open source issues before they become major post-closing problems for both parties.