The Importance of Technical Diligence on Source Code During Asset Acquisitions

by Carolina Säve and Robert Sweeney

Intellectual property is increasingly becoming a highlight of many asset deals, yet often buyers and sellers fail to account for the unique diligence and logistical considerations that arise when software-related IP is at issue. This article addresses software-related IP considerations in transactions and why it is essential to be aware and proactive to minimize associated risk.

At the outset of any software asset deal, buyers need sufficient insight into the source code that underlies the asset to quickly identify issues that could adversely impact deal value. The parties’ initial non-disclosure agreement should contain sufficiently strict confidentiality measures, need-to-know access limitations, and provisions that allow the buyer’s technical representative to review the related source code. Such a review can be facilitated in a number of ways, including without limitation, providing a copy of the relevant code to buyer, utilizing a secure source code virtual data room, or conducting an independent third-party review. The goal of providing source code access, which benefits both seller and buyer, is to provide a fair and honest assessment of the asset to avoid disputes post-closing (e.g., inadequate functionality or inability to integrate new software into the buyer’s other software offerings).

During technical diligence, among other things, the buyer should identify any dependencies necessary for proper software code functionality. In the context of source code, dependencies generally refer to the situation where one software component relies on another component to function. Such dependencies can be generally bucketed into three groups: (1) seller-owned proprietary dependencies, (2) third-party dependencies, and (3) open source software dependencies.

Handling Seller-Owned Proprietary Dependencies

When the software asset relies on a seller-owned dependency, a more intensive decision-making process is implicated. Oftentimes, sellers create software “ecosystems” whereby various programs are tied together and rely on one another to function. If this is the case, buyers face three options: long-term continued reliance on the dependency, replacement of the dependency, or temporary reliance on the dependency while replacement code is developed.

At one end of the spectrum is continued reliance on the dependency, which necessitates a perpetual license from the seller, ideally coupled with a copy of the dependency’s source code to ensure access to and continued functionality of the purchased software asset without needing to rely on seller for such access. Sellers, however, are often reluctant to grant such benevolent licenses because the retained code is often still material and valuable to the seller’s business. Even when sellers grant perpetual licenses, the grant is typically restricted in other ways that impact the usefulness of the code going forward (e.g., prohibitions on modification, distribution, sublicensing, fields of use, etc.). In any event, a difficult and costly negotiation often ensues when a perpetual license is requested.

At the other end of the spectrum is fully replacing the seller-dependency. While favorable for purposes of a “clean break,” a full replacement of such a dependency will result in a delay between purchase of the software asset and its deployment, as creation of a proprietary substitute or integration of a third-party’s alternative is time consuming and cost intensive.

Accordingly, sellers and buyers commonly take a “middle of the road” approach, whereby the parties enter into a transition services agreement (TSA). A properly drafted TSA typically contains a time-limited license of the seller-retained asset in favor of the buyer that permits the buyer to continue to use, deploy, modify, and sublicense its rights to the necessary contractors while it develops a permanent substitute solution. Typically, a TSA also provides for technical assistance services from seller personnel to ensure the soon-deprecated dependency is adequately supported during the interim period. Additionally, robust non-disclosure and non-use provisions are necessary to ensure source code trade secrets remain confidential. Though non-exhaustive, these particular provisions can provide a software asset buyer adequate time to develop a dependency replacement.

Addressing Third-Party Dependencies

A third-party dependency generally refers to code, necessary for the purchased software asset to function, that is licensed to the seller from an unrelated entity. When such a dependency is present, it is vital to identify the agreement terms governing the seller’s rights to the dependency and whether the agreement is assignable. If the third-party agreement can be freely assigned, the agreement will simply be added to the pool of assets subject to the asset purchase agreement. However, some agreements impose assignment consent requirements.  A third-party licensor that is a competitor to the buyer may not provide consent or reasonable license terms, rendering it difficult, if not impossible, for the buyer to deploy its newly purchased asset. Even non-competing licensors may impose commercially unreasonable terms on the buyer, understanding and capitalizing on the fact that the licensor’s code is critical to the viability of the upcoming asset sale. Therefore, early identification of third-party dependencies is valuable, if not critical, for assessing the worth and feasibility of deploying newly acquired software assets.

Managing Open Source Dependencies

Open source software (OSS) generally refers to source code made publicly available for free through one of many licenses that have varying restrictions on use and distribution. Developers turn to OSS for quick solutions during development and maintenance, saving company resources. OSS dependencies are pervasive and present in nearly all code bases. Though a resource-efficient approach to code development, OSS usage comes with certain risks—namely security issues and licensing issues that may not become important until a potential acquisition. To address these issues and to be in accordance with high-quality software development practices, sophisticated sellers maintain up-to-date software bills of materials (SBOM) that list all OSS dependencies. Ideally, an SBOM includes for each OSS module the applicable license, how and where the code is used, and whether the code was modified or “distributed” by the seller. A detailed OSS SBOM review is imperative to identify any OSS licensed under more restrictive licenses that require free distribution of proprietary code, and confirm absence of OSS with vulnerabilities that can be exploited by bad actors. Completing an OSS dependency review early in a transactional process allows time either to replace problematic OSS or to drop out of the deal if needed.

High Level Takeaways

• Software asset purchases require an early, technical diligence review to identify source code dependencies to (i) avoid delays caused by dependency remediation; (ii) potentially adjust deal structure and closing deliverables; and (iii) negotiate potential purchase price adjustment.

• Dependencies can be categorized into three buckets: seller-retained dependencies, third-party dependencies, and open source dependencies. Each raises different issues that need to be addressed and remediated.

Carolina Säve, Of Counsel at Mintz, is a registered patent attorney who focuses on strategic counseling in the mechanical, electrical, and computer science arts, including AI-related tech.

Robert Sweeney, Associate at Mintz, is an attorney who focuses his practice on IP litigation, licensing, and transactions in the software, medical device, and energy sectors.