Open Source Software Compliance in Technology M&A

Open source components can appear in the product, build environment and deployed infrastructure. Establish which code and rights the transaction will transfer and which conditions govern continuing use. Allocate historical issues according to the acquisition structure and transaction documents rather than assuming every obligation or liability transfers automatically.

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 on technology acquisition diligence, transaction documents and risk allocation. Bring the unresolved code or license question, engineering evidence and transaction stage to the engagement assessment. Use qualified technical and license advice for the actual implementation.

OSS in Modern Software Stacks

A dependency inventory needs to cover what the target actually builds, deploys and delivers. Review direct packages, transitive dependencies, container contents and build inputs within the agreed scope. Record where evidence is incomplete. A package count alone establishes neither compliance nor the legal reach of a component's terms.

Read the license text for each identified component and version, including any notices or additional permissions. Common families include permissive licenses, component-level copyleft and broader copyleft terms. Family labels help organize review; the exact text and the actual use determine the conditions the team needs to address.

OSS compliance failures in technology M&A fall into three categories. One issue is a mismatch between proprietary distribution plans and the conditions governing a covered copyleft work. Determine the affected code and permissions before selecting a compliance or remediation route. 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.

For licenses described as weak copyleft, inspect the specific version and covered-work definitions. LGPL, MPL and EPL impose different conditions. Ask counsel which component, files, contributions or combined work are covered, and ask engineering to document the actual modifications, linking and delivery. A family label alone establishes no permission to combine the component with proprietary code.

For strong copyleft components, assess whether the target has created or conveyed a covered combined or modified work and what conditions apply. GPLv2-only and GPLv3 differ; a grant permitting a later version can change the available licensing route. Public-domain status and dedications also need their own rights analysis, including any relevant patent, trademark or contractual issues.

GPL Virality and Derivative Work Analysis

Trace the actual covered work and the relevant activity before describing GPL reach. GPL version 2, sections 2 and 3 address modified-work distribution and source requirements. GPL version 3 uses its own definitions and conditions. Ask counsel to distinguish aggregation from a covered combination using engineering evidence rather than the label viral.

Document how the components communicate, whether they are linked, what is packaged together and what recipients receive. The GNU GPL FAQ on aggregation and combined programs explains the license steward's interpretation. Counsel should evaluate the actual mechanics and applicable law; a linking label or interface choice supplies no automatic legal result.

Check the source materials required by the applicable license version. GPLv2 section 3 expressly includes scripts controlling compilation and installation in its source description. GPLv3 defines Corresponding Source and contains additional conditions. Ask engineering to demonstrate that the actual source package and build materials satisfy the route used for the distributed work.

AGPL Network Copyleft Trigger

Read the exact license version and the deployed code together. GNU AGPL version 3, section 13 addresses a modified version of the program and remote interaction through a computer network. Its conditions and the definition of Corresponding Source require analysis of the actual work. The presence of a package name in a software inventory alone cannot establish that all proprietary application code must be disclosed.

Ask engineering to identify the component, license version, modifications, interfaces, deployment and users who interact with it. Have counsel map those facts to the applicable license obligations and any commercial license already held. Preserve the component source, notices, modification history and architecture record used for the assessment. A browser-based service description alone leaves the scope of the covered work unresolved.

For an unresolved finding, compare documented compliance, an available commercial license, component replacement and transaction-specific allocation of the remaining risk. Assign engineering and legal owners, prerequisites, evidence of completion and a decision deadline. Record which proposed remedy has actually been tested. A separation or replacement proposal needs review against the final architecture and license; a proposed change supplies no automatic clearance for signing or closing.

License Compatibility Matrix

Compatibility review starts with the exact grants and the proposed combination. Distinguish GPLv2-only from a grant permitting later versions. Identify which work will be conveyed and whether the relevant conditions can be satisfied together. Record any unresolved conflict before promising that proprietary source can remain closed.

When reviewing an Apache 2.0 component alongside GPL code, identify the exact GPL version and the nature of the combination. The GNU license list discussion of Apache 2.0 distinguishes compatibility with GPLv3 from GPLv2. Have counsel apply that distinction to the actual work rather than assuming that separate permissive and copyleft components are automatically compatible.

For LGPL, MPL and other licenses with component-level or secondary-license provisions, inspect the version, notices and any elections or incompatibility designation. Ask counsel which files and modifications are covered and whether the proposed combination satisfies the applicable conditions. Keep that conclusion tied to the actual component evidence.

OSS Audit Tools: Black Duck, FOSSA, and Snyk

Software composition analysis tools help identify components and candidate licenses in the supplied material. Define whether the scan covers source, binaries, packages, containers and build outputs. Treat the findings as evidence to validate, including unidentified code and potential false matches. A scan supplies no substitute for deciding which legal conditions apply.

Black Duck provides software composition analysis that can help identify third-party components in materials supplied for diligence. FOSSA provides dependency and license-analysis workflows that can help organize an inventory. Snyk provides developer security and dependency analysis that can help connect vulnerability and license findings. Verify the selected product's current scan methods, supported inputs and reporting capabilities with its vendor before defining the engagement scope.

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) seeks to identify dependencies and their relationships in the reviewed software. Include transitive components in the inventory, then examine how each is used, modified and delivered. Presence in a dependency tree alone establishes no automatic GPL obligation for every other component in that tree.

A software bill of materials (SBOM) records identified components and associated information such as versions and licenses. Agree the needed fields, format and scope with the buyer and engineering team. For government customers, inspect the actual agency and contract requirements. NIST software supply-chain guidance addresses procurement context; federal sales alone establish no universal SBOM delivery rule for every supplier.

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

Inspect the notices required by each applicable license and compare them with the actual distributed versions. Ask engineering to show the notice file, license texts and packaging used for each relevant release. Counsel should assess any historical gap, possible termination or cure conditions and the effect of the proposed correction. Updating the next release alone establishes no resolution of past noncompliance.

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.

A commercial license may be an option where the relevant rights holder offers one. Confirm who controls the necessary rights, the exact component and version, permitted uses and whether past activity is covered. Negotiate any needed historical release or cure explicitly; buying a prospective license supplies no automatic retroactive clearance.

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. A carve-out leaves the component in place while changing its relationship with proprietary code. Counsel and engineering should evaluate the final architecture against the applicable license before accepting the proposed separation as a remedy. 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. Compare the policy and historical approval records with the scan results and release history. Ask engineering to explain discrepancies and document the process actually followed.

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

Check the actual attribution, notice and redistribution conditions for the component versions included in each release. Keep the notices package aligned with what engineering delivers. Record historical versions with missing materials and have counsel determine the available correction or cure route. The particular license terms control the required steps and potential consequences.

For GPL-covered software, identify the actual distribution or conveyance and applicable license version. Map recipients, including customers, contractors and separate legal entities within a corporate group. Have counsel determine the obligations for each activity and covered work. For AGPLv3, assess section 13 against the actual modified program and remote interaction, together with the other applicable license provisions. 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.

Trace the actual delivery model: server execution, browser downloads, client applications, containers and transfers between legal entities can involve different facts. GPLv3 distinguishes mere remote interaction without transfer of a copy in its conveying definition. Assess each applicable license against the actual implementation, including AGPLv3 section 13 where relevant. Preserve the architecture and transfer record supporting the conclusion and test any proposed remediation before accepting it as complete.

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. An unresolved license issue can constrain continued distribution. Assess whether documented compliance, an available commercial license, replacement or another validated change can address the finding. Allocate historical exposure separately from the proposed future implementation. 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.

Assign post-closing owners and deadlines before closing. Use the diligence inventory as a baseline, then define how new dependencies, updates and distribution changes enter review. Integrate the agreed checks into engineering workflows, preserve evidence and set a review date for unresolved findings. Choose timing from the actual risk and integration plan rather than claiming a universal optimal period.

Frequently Asked Questions