Written by Victoria Lee
Given the ever more urgent demand for innovation, it is rare for software development to not incorporate third-party components. In most cases, it is easier and faster to buy rather than build. In the case of open source software, the buy decision is made even easier because the software seems to come at no monetary cost.
There is, however, a cost to using open source software, in the form of compliance with the applicable open source license. Investors in software companies and acquirers of companies where software is a key asset also recognize the existence of this non-monetary cost. Indeed, failure to comply may well bring with it further costs. As a result, these days, only rarely will an investor or acquirer fail to carry out a dedicated due diligence process that focuses on open source usage and compliance.
Once an incidence of non-compliance is identified in the course of diligence, the next step is typically a discussion about the appropriate corrective action. Typically, one of two paths may be taken at this point: either remove the open source code that resulted in the non-compliance, or, when a commercial license for the same software component is available, pay for the commercial license.
Such remediation steps are necessarily prospective solutions: the remediation does not eliminate the technical legal non-compliance that already took place. In most cases, the remediation has usually been acceptable as a business matter because open source enforcement has generally focused on enforcing compliance rather than seeking monetary damages. However, in today’s business climate, enforcement is growing, and it is focusing on monetary damages. Even when non-compliance is corrected, that prior legal non-compliance has the potential to lead to liability. Given that, it probably makes sense for investors/acquirers and companies/sellers who identify non-compliance to revisit their traditional approach.
Companies taking money from investors and sellers about to embark on an exit should consider including a disclosure against the obligatory non-infringement warranty when actual or potential non-compliance with an open source license is found. Of course, it may be possible to rely on the language we all see in schedules of exceptions and disclosure schedules that provide for a disclosure in one section to also apply to another when it is “reasonably apparent” from the disclosure. But, given the current state of enforcement, it is quite possible that, even after corrective action is taken, the open source non-compliance may result in an infringement claim for the prior non-compliance.
Enforcers of copyleft open source license (eg, GPLv2 or AGPL), rather than a permissive license (eg, MIT, BSD or Apache), pose the greatest risk of an infringement claim. In the case of an acquisition where there is an indemnity and escrow, one point of negotiation could be that such disclosure should be for information purposes only. Additionally, a buyer may want to consider having a special indemnity as a remedy for any infringement claim that may arise from the open source non-compliance (as well as any other remediation steps that may be demanded, such as release of the proprietary code).
The use of open source may accelerate the pace of development and innovation, but it is certainly not free. Increasingly, those pondering an investment or an exit understand that it may actually come at a cost, at a time when it is least desirable.