Open Source Software Compliance in Technology M&A

Open source software is not a fringe component of modern technology products. It is the foundation. Database engines, web frameworks, cryptographic libraries, container runtimes, network protocols, and user interface toolkits that power virtually every software product are built on open source components governed by a variety of license terms. Those license terms are legally binding contracts. A technology company that incorporates an open source component accepts the obligations of that component's license, and those obligations transfer to the acquirer in a technology M&A transaction.

This sub-article is part of the Technology and Software M&A Legal Guide. It addresses the full scope of open source software compliance in technology acquisitions: OSS license category overview, GPL virality and derivative work analysis, AGPL network copyleft, license compatibility, composition analysis tools, SBOM production, common audit findings, remediation options, policy and process diligence, inbound attribution obligations, outbound distribution triggers, OSS representations and warranties, escrow and closing conditions, and post-closing governance.

Acquisition Stars advises technology buyers, sellers, and investors on open source software compliance diligence, license risk assessment, remediation planning, and transaction structuring. Nothing in this article constitutes legal advice for any specific transaction.

OSS in Modern Software Stacks

The scale of open source software dependency in modern technology products is difficult to overstate. A typical web application built on a modern JavaScript framework may have hundreds of direct npm package dependencies and thousands of transitive dependencies pulled in through those direct dependencies. A Python data science application may draw on dozens of packages from PyPI. A containerized microservices architecture may incorporate independent open source components at the application layer, the container orchestration layer, the network layer, and the observability layer. Each of these components carries a license, and the obligations of those licenses are determined by the license text governing each component, not by the developer's awareness of or intent to comply with those obligations.

The diversity of OSS licenses creates significant compliance complexity. The Open Source Initiative has approved more than one hundred distinct open source licenses, each with different requirements for attribution, source code disclosure, patent grants, trademark usage, and modification disclosure. In practice, the large majority of OSS components used in commercial software products carry one of a smaller set of licenses: the MIT License, the Apache License version 2.0, the BSD licenses (2-clause and 3-clause), the GNU General Public License versions 2 and 3, the GNU Lesser General Public License versions 2.1 and 3, the GNU Affero General Public License version 3, the Mozilla Public License version 2.0, and the Eclipse Public License versions 1.0 and 2.0. Understanding the practical obligations of these licenses is the foundation of OSS compliance diligence.

OSS compliance failures in technology M&A fall into three categories. The first is copyleft contamination: the incorporation of copyleft-licensed code in a manner that extends the copyleft terms to proprietary code and creates an obligation to disclose and license the proprietary code. The second is attribution noncompliance: failure to include required copyright notices, license texts, change notices, or acknowledgment statements required by the applicable license. The third is security vulnerability exposure: use of OSS components with known, unpatched vulnerabilities that create operational security risk and potential contractual liability. Each category has distinct legal and remediation implications.

License Category Overview: Permissive, Weak Copyleft, Strong Copyleft, and Public Domain

OSS licenses fall into four broad functional categories based on the conditions they place on downstream use and distribution. Permissive licenses impose minimal conditions: attribution (reproduction of the copyright notice and license text in distributions) and, in some cases, a prohibition on using the licensor's name for endorsement. The MIT License, the 2-clause BSD License (the "Simplified BSD License"), the 3-clause BSD License (the "New BSD License"), and the Apache License version 2.0 are the most widely used permissive licenses. The Apache 2.0 license includes an express patent license grant from all contributors, which is commercially significant for acquirers relying on patent protection in their products.

Weak copyleft licenses impose copyleft conditions on modifications to the licensed component itself while permitting the component to be linked with proprietary code without extending the copyleft terms to the larger work. The GNU Lesser General Public License (LGPL) versions 2.1 and 3 and the Mozilla Public License (MPL) version 2.0 are the principal weak copyleft licenses in commercial use. Under the LGPL, if the target distributes a modified version of an LGPL-licensed library, the modifications must be provided under LGPL terms. But if the target uses an unmodified LGPL library as a component of a proprietary application, the proprietary application code is generally not subject to LGPL terms, provided the application is linked dynamically with the library and the user can relink the application with a modified version of the library. The Eclipse Public License version 2.0 operates similarly to the MPL, applying copyleft to modified versions of the licensed file while permitting combination with proprietary code in larger works.

Strong copyleft licenses require that any derivative work that is distributed be distributed under the same license terms and with source code. The GNU General Public License versions 2 and 3 are the canonical strong copyleft licenses. GPL v3 added provisions addressing patent termination, DRM, and tivoization (hardware restrictions on modified software) that were not present in GPL v2, and the two versions are not compatible in the sense that code under one cannot be combined with code under the other in a single distributed work. Public domain dedications, including the Creative Commons CC0 public domain dedication, impose no conditions on use or distribution. Works in the public domain through expiration of copyright terms or affirmative dedication can be incorporated into proprietary software without license compliance obligations, though attribution may still be a professional or contractual expectation.

GPL Virality and Derivative Work Analysis

The GPL's copyleft condition is described colloquially as "viral" because it propagates from the covered component to any derivative work that is distributed. Section 5 of GPL v2 and section 5 of GPL v3 both require that any work distributed by the licensee that contains or is derived from the GPL-licensed program must, as a whole, be licensed under the GPL and made available with complete corresponding source code. The critical legal question for any target that incorporates GPL-licensed code is whether the combination of the GPL component and the target's proprietary code constitutes a single work or a mere aggregation of separate programs. If it is a single derivative work, GPL terms extend to the entire combined work. If it is mere aggregation, the GPL component's terms do not extend to the proprietary code.

The GPL itself does not resolve this question definitively, but the Free Software Foundation's guidance and the weight of legal analysis support the following framework. Static linking of GPL-licensed code into a proprietary executable creates a derivative work for GPL purposes, triggering the obligation to license the entire combined executable under GPL terms. Dynamic linking through shared libraries is more contested: the FSF position is that dynamic linking can also create a derivative work, while a significant body of legal commentary takes the view that where proprietary code and GPL-licensed code are linked only at runtime through well-defined interfaces, the proprietary code may not be a derivative of the GPL code. Process separation, where the GPL component and proprietary code run as separate processes communicating through a network socket or IPC mechanism, provides the strongest argument for avoiding derivative work status, because the two programs are clearly separate works that happen to communicate rather than a single combined program.

GPL v3 added the concept of a "Corresponding Source" that must be provided with any object code distribution, defined broadly to include everything needed to generate, install, and run the object code plus any scripts to control those activities. This broader definition of required source extends GPL disclosure obligations to build systems, configuration scripts, and installation tooling in a way that GPL v2 did not explicitly address. For a technology acquisition where the target's build system or deployment scripts are themselves derived from GPL v3 code, the GPL v3 corresponding source obligation may reach those components.

AGPL Network Copyleft Trigger

The GNU Affero General Public License version 3 was created in 2007 to address a perceived gap in the GPL framework: under the GPL, a company that runs GPL-licensed software on a server and provides access to that software as a service over the internet does not distribute the software to users and therefore does not trigger GPL source disclosure obligations. The "SaaS loophole," as it is commonly called, allowed companies to leverage GPL-licensed code in their hosted services without providing source code, even though users were in practical terms receiving the benefit of the software without access to the source. AGPL section 13 closes this loophole by adding a "remote network interaction" trigger: if a modified version of an AGPL-covered program runs on a server that users interact with remotely over a network, the operator must offer those users access to the corresponding source code of the modified program.

The scope of AGPL section 13 in the SaaS context turns on whether users are "interacting with [the program] remotely through a computer network." For a SaaS application that users access through a web browser, the interaction is over a network and the AGPL trigger appears to apply. For a SaaS application where the AGPL-licensed component runs internally and its output is processed and presented by a proprietary layer before reaching the user, the analysis turns on whether the AGPL component itself is the thing with which users interact. A target that has deployed AGPL-licensed components (commonly encountered in database systems such as older versions of MongoDB, certain time-series databases, and graph databases) in its SaaS product must either comply with the AGPL source disclosure obligation by offering users access to the corresponding source, or obtain a commercial license from the AGPL component licensor.

AGPL findings are among the most commercially significant OSS diligence findings in SaaS company acquisitions because the remediation options are more constrained than for GPL. Dynamic linking and process separation arguments that may defeat GPL derivative work analysis do not eliminate the AGPL network interaction trigger, which is activated by user access over a network rather than by distribution. The practical remediation options are commercial re-licensing (where available), component replacement with a permissively licensed or commercially licensed alternative, or prospective compliance with the source disclosure obligation. Where the AGPL component is deeply integrated into the target's architecture, replacement may be a multi-month engineering project that affects the transaction timeline and structure.

License Compatibility Matrix

License compatibility determines whether two open source components with different licenses can be combined in a single work that is then distributed. Compatibility is relevant when the target's product combines components under different copyleft licenses, because combining components under incompatible copyleft licenses creates a situation where the obligations of each license cannot simultaneously be satisfied. GPL v2 and GPL v3 are not compatible in this sense: a work that combines GPL v2-only code with GPL v3 code cannot be lawfully distributed, because distributing under GPL v3 would be outside the permissions granted by the GPL v2 license, and distributing under GPL v2 would be outside the permissions granted by the GPL v3 license. The FSF addresses some compatibility issues by drafting later versions to be compatible with earlier versions where possible, but the GPL v2-only designation (used by the Linux kernel and many other widely deployed projects) creates genuine incompatibility with GPL v3 components.

The Apache License version 2.0 is compatible with GPL v3 but not with GPL v2, because the Apache 2.0 patent termination provision is considered an additional restriction under GPL v2 section 6. This compatibility structure means that a product combining Apache 2.0-licensed and GPL v2-only licensed components faces a compatibility problem if the combined work is distributed. In practice, many technology companies have built products with this combination without awareness of the incompatibility, because both licenses are permissive relative to commercial software and the constraint arises only when distributing the combined work. Diligence should identify any components with GPL v2-only designations and assess whether those components are combined in a distributed work with Apache 2.0-licensed code.

The LGPL and MPL occupy intermediate positions on the compatibility spectrum. LGPL v2.1 code can be combined with GPL v2 or GPL v3 code in a combined work that is distributed under GPL terms. LGPL v3 code can be combined with GPL v3 code similarly. MPL v2.0 is compatible with the GPL and LGPL licenses and contains an explicit "Exhibit B" incompatibility flag that can be set by licensors to make the MPL code incompatible with secondary licenses, but MPL code without this flag set is generally compatible with the GPL family. The Eclipse Public License v2.0 includes a secondary license compatibility provision that allows EPL-licensed code to be combined with GPL v2 or GPL v3 code under specific conditions, addressing a compatibility gap in EPL v1.0.

OSS Audit Tools: Black Duck, FOSSA, Snyk, Scantist, and Mend

Automated software composition analysis tools are the standard mechanism for identifying OSS components in a target's codebase at the scale required for M&A diligence. These tools scan source code, binary files, package manifests, dependency lock files, and build scripts to identify open source components and match them against databases of known OSS projects, versions, and licenses. The major commercial tools in this category are Black Duck (Synopsys), FOSSA, Snyk, Scantist, and Mend (formerly WhiteSource). Each tool has different strengths in terms of detection methodology, license database coverage, vulnerability database integration, and reporting format.

Black Duck is among the most widely used tools for M&A diligence because of its comprehensive KB (knowledge base) of open source components and its ability to perform binary scanning as well as source scanning. Binary scanning allows Black Duck to identify OSS components in compiled executables and container images even where the source code is not available for review, which is relevant for acquired companies that distribute compiled products or that have deployed dependencies in container images. FOSSA is frequently used by engineering teams as an ongoing compliance tool and produces SBOM output in industry-standard formats (SPDX, CycloneDX) that can be used as the baseline for M&A diligence. Snyk is primarily oriented toward security vulnerability identification and integrates deeply with development pipelines, producing combined license and vulnerability reporting that is useful for assessing the overlap between license compliance gaps and security exposure.

The selection of the appropriate scan tool for a specific diligence engagement depends on the target's technology stack, the format of the codebase (source-available versus binary-only), the acquirer's existing tool infrastructure, and the depth of analysis required. In practice, many M&A OSS diligence engagements use multiple tools in combination, because no single tool achieves complete detection coverage across all component types and all programming language ecosystems. The results from multiple tools are then reconciled to produce a comprehensive SBOM that serves as the basis for legal analysis.

Composition Analysis and SBOM

Software composition analysis (SCA) is the technical process of identifying every component in a software product, including direct dependencies (packages explicitly declared in the project's dependency manifest) and transitive dependencies (packages pulled in by direct dependencies). Transitive dependency analysis is critical because the license obligations of a transitive dependency are as binding as those of a direct dependency: if a direct dependency under a permissive license itself depends on a GPL-licensed package, the GPL-licensed package's terms apply to the full dependency tree regardless of the fact that the target never explicitly chose to include it.

The output of SCA in M&A diligence is a software bill of materials: a structured list of every component identified in the target's software, with each component's name, version, supplier, license, and known vulnerability status. The SBOM may be formatted according to the SPDX standard (the Linux Foundation's Software Package Data Exchange specification), the CycloneDX standard (maintained by the OWASP Foundation), or a proprietary tool format. SPDX and CycloneDX are both recognized by CISA and NIST as preferred SBOM formats under U.S. government guidance. For targets that sell software to the U.S. federal government, SBOM production in a recognized format is now a compliance obligation under Executive Order 14028 and subsequent CISA guidance.

The SBOM produced in diligence should cover the target's complete software portfolio: the main product codebase, internal tools and utilities, development tooling that is distributed with or required to build the product, container images, and any third-party components that are embedded in or bundled with the target's products. An SBOM limited to the main application and excluding development dependencies, build tooling, and container infrastructure may undercount the target's total OSS exposure. The completeness of the SBOM is itself a representation that should be addressed in the purchase agreement, because an SBOM that omits material components provides incomplete protection to the acquirer.

Common Audit Findings: Missing Attribution, Copyleft Contamination, and Unresolved Vulnerabilities

Attribution noncompliance is the most frequently found OSS compliance issue in technology M&A diligence, and in many cases it is also the most straightforward to remediate. Permissive licenses such as MIT, BSD, and Apache 2.0 require that the copyright notice and license text for each included component be reproduced in the distributed product, typically in a notices file, a credits file, or an about screen accessible to users. A target that has incorporated hundreds of permissive-licensed components without maintaining a current notices file has an attribution compliance gap for every component that lacks the required attribution. Remediation requires generating a current notices file from the SBOM and including it in all future distributions. For past distributions without proper attribution, the legal exposure is typically limited to breach of license terms, which may not carry significant damages risk but could theoretically result in loss of the license rights if the licensor elects to enforce.

Copyleft contamination findings require more careful analysis. Not every instance of a copyleft-licensed component in a target's codebase represents a contamination problem. A GPL-licensed utility that runs as a standalone process and is never combined in a single executable with proprietary code, a LGPL-licensed library that is dynamically linked and unmodified, and an AGPL-licensed tool that is used only internally without user-facing network access each represent different risk profiles despite all being "copyleft" licenses. The severity of a copyleft finding depends on the specific license, the technical mechanism of incorporation, whether the combined work is distributed externally, and whether any distribution has actually occurred in a way that would have triggered the source disclosure obligation.

Security vulnerability findings are assessed separately from license compliance findings but are often produced by the same SCA tools. Known vulnerabilities in OSS components are catalogued in the NIST National Vulnerability Database (NVD) and assigned Common Vulnerabilities and Exposures (CVE) identifiers with severity scores under the Common Vulnerability Scoring System (CVSS). A target with high-severity or critical CVEs in active components of its production software has an operational security risk that is independent of its license compliance posture. In M&A transactions, unresolved critical CVEs in production software may constitute a breach of the representations on security practices, require disclosure in the purchase agreement schedules, or be the subject of a closing condition requiring remediation to specified criteria before closing.

Remediation Options: Replacement, Re-licensing, Dual Licensing, and Carve-Out

Component replacement is the most straightforward remediation for copyleft contamination: substitute the copyleft-licensed component with a permissively licensed or commercially licensed alternative that performs the same function, update the codebase to use the replacement, verify that the replacement does not introduce new OSS compliance issues, and eliminate the copyleft dependency entirely. The feasibility of replacement depends on the availability of a suitable alternative, the depth of integration of the copyleft component into the target's architecture, and the engineering resources required to execute the substitution. For components that are peripheral to the target's core functionality and for which permissive alternatives exist, replacement before closing is often the preferred path. For components that are deeply integrated or for which no functional equivalent exists under a permissive license, replacement may require months of engineering work.

Commercial re-licensing through a dual licensing arrangement is available for many widely used copyleft-licensed OSS projects. Under a dual licensing model, the project licensor offers the software under two parallel licenses: the open source copyleft license (available to all users who comply with the copyleft terms) and a commercial license (available for a fee to users who cannot or do not wish to comply with the copyleft terms). Companies that have adopted dual licensing models include MySQL (GPL v2 and commercial), Qt (GPL/LGPL and commercial), and various database and infrastructure projects. A target that relies on a dual-licensed component under its GPL terms without satisfying the GPL's source disclosure obligation can potentially remediate the compliance gap by obtaining a commercial license retroactively, though the commercial licensor's willingness to grant a retroactive license and the pricing of that license are matters of negotiation.

Architectural carve-out involves restructuring the target's software architecture to eliminate or isolate the copyleft dependency such that the copyleft component is no longer combined with proprietary code in a way that triggers copyleft obligations. This may involve converting a statically linked dependency to a dynamically linked one, extracting the copyleft component to a separate process that communicates with the proprietary code only through a network or IPC interface, or introducing a clean API boundary between the copyleft component and the proprietary code. The carve-out approach does not eliminate the copyleft component from the product but restructures the relationship between the component and the proprietary code to support an argument that the combined work is not a derivative work subject to the copyleft terms. The strength of this argument depends on the specific license and the technical facts of the implementation.

Policy and Process Diligence: OSS Approval Workflows and Contribution Policies

Beyond the technical findings from composition analysis, OSS diligence should assess the target's internal policies and processes governing OSS use. A company with a mature OSS governance program will have an OSS approval workflow that requires engineering teams to obtain approval before introducing new OSS dependencies into the codebase, a process for evaluating the license terms of proposed new dependencies against the company's license policy, and documented records of approved dependencies. The existence and rigor of this process is predictive of the completeness and accuracy of the SBOM produced in diligence and of the likelihood that new compliance issues will emerge post-closing.

An OSS approval workflow typically assigns dependencies to one of several approval tiers based on license type: permissive-licensed components may be auto-approved, weak copyleft-licensed components may require engineering review to confirm proper isolation, strong copyleft-licensed components may require legal review and explicit approval, and certain licenses (such as AGPL or copyleft licenses with additional commercial restrictions) may be categorically prohibited. Companies that have implemented this tiered approval structure and can document the historical approval records for their dependency inventory provide a higher-quality starting point for diligence than companies that have not systematically tracked OSS introductions.

OSS contribution policies govern whether and how the target's engineers contribute code to external open source projects. A contribution to an external OSS project may constitute a license grant from the target to the OSS project community, and depending on the project's contributor license agreement (CLA) requirements, that license may be broad enough to include rights that the target's own IP assignment agreements give to the company. A target whose engineers have contributed code to external projects without a corporate contribution policy and without confirming that contributions were consistent with the company's IP ownership obligations may have inadvertently licensed proprietary technology to the OSS community or created ambiguity about ownership of contributed inventions.

Inbound Attribution Obligations and Outbound Distribution Triggers

Attribution obligations under permissive licenses require affirmative action by the target to comply: the copyright notice and license text for each attributed component must be included in every distribution of the software. For a software company that distributes products to thousands of customers through installer packages, the attribution obligation applies to each distribution. Many companies satisfy this obligation through a single notices file bundled with the installer, but the notices file must accurately reflect all components included in the current version of the software and must be updated with each new version that adds or removes OSS components. A target that has distributed versions of its product without accurate attribution faces potential license termination for those versions and reputational risk if the noncompliance is identified by component licensors or OSS community members.

Outbound distribution triggers determine whether a copyleft license's source disclosure condition has been activated. For the GPL, the trigger is distribution of the object code or source code to third parties outside the organization. Internal use of GPL-licensed software within a single organization, including all of its subsidiaries and affiliates, does not trigger the distribution obligation. For the AGPL, the trigger is user interaction with the program over a network. For the LGPL, the trigger for the library-modification copyleft is distribution of a modified version of the library. Characterizing all product deployments and service architectures against these trigger definitions is essential to determining which components require remediation and which can remain in the product without disclosure action.

The SaaS delivery model eliminates GPL distribution triggers for most use cases because the software runs on the provider's servers and is accessed by users over a network without the binary being delivered to users. This creates the counterintuitive result that a SaaS company may incorporate GPL-licensed code in its platform without triggering the GPL's source disclosure obligation, while a company that distributes the same software as a downloadable application must comply with GPL source disclosure for that distribution. The AGPL exception to this pattern means that the SaaS model must be assessed separately for each copyleft license rather than applying a blanket rule.

OSS Representations and Warranties, Escrow and Closing Conditions, and Post-Closing Governance

OSS-specific representations in technology acquisition agreements address the completeness of the SBOM, the target's compliance with material OSS license obligations, the absence of copyleft contamination requiring source disclosure of proprietary code, the existence and maintenance of an OSS approval policy, and the accuracy of the representation that no AGPL or similarly broad copyleft license has been incorporated into the target's products in a way that triggers network copyleft obligations. Each representation should be scoped to materiality, because achieving complete technical accuracy on OSS compliance across a complex software product requires more precision than a representation can practically carry without a highly detailed disclosure schedule.

The indemnification framework for OSS representations should reflect the potential cost of remediation if a representation turns out to be inaccurate post-closing. Copyleft contamination of proprietary code that requires source disclosure could, in the most severe cases, require the acquirer to open-source code that it purchased as a proprietary asset, eliminating a material portion of the transaction's value. More commonly, the remediation cost involves engineering time for component replacement, commercial license fees for dual-licensed components, and legal fees associated with negotiating remediation. Where known OSS compliance gaps are identified in diligence, the parties may agree to a closing condition requiring remediation of specified findings, a holdback of a portion of the purchase price pending remediation completion, or a purchase price reduction reflecting the cost of required remediation work.

Post-closing OSS governance is an area where acquirers commonly underinvest relative to the risk it controls. The SBOM produced in diligence provides the baseline for ongoing OSS governance, but it becomes stale immediately as the engineering team adds new dependencies or updates existing ones. An effective post-closing OSS governance program integrates SCA tooling into the development pipeline, applies an OSS license policy to all new dependency introductions, maintains a current SBOM, conducts periodic reviews of existing dependencies for new vulnerabilities and license changes, and trains engineering teams on OSS compliance obligations. Establishing this governance structure in the first 90 days post-closing, before the acquired engineering team is fully integrated into the acquirer's development environment, captures the moment when OSS practices can most easily be reset and standardized.

Frequently Asked Questions