IP Ownership and Open Source License Audit in Technical Due Diligence

IP ownership and open source licensing issues have killed deals and created significant post-close liability across the software acquisition landscape. They are also among the most overlooked areas in technical due diligence because they sit at the intersection of legal and technical review, and both sides sometimes assume the other is handling it. Neither the legal team nor the technical reviewer alone has the full picture.

A focused IP and license audit during technical due diligence surfaces these issues early, when they can be addressed or priced into the deal — not after close, when they become the acquirer's problem.

Why IP Ownership Is Not a Given

Most founders assume they own their code. In practice, IP ownership is only clear when it has been deliberately established. Several common patterns create ambiguity:

Early contractor work: Code written by a contractor or freelancer without a written agreement typically remains the property of the contractor under default intellectual property law in most jurisdictions. If the first version of the product was built by an agency or freelancer without a work-for-hire agreement or assignment clause, the IP ownership of that version is uncertain.

Founding team changes: Code written by co-founders or early employees who later departed may have been written before proper invention assignment agreements were signed. If a departing co-founder never signed an IP assignment, their contributions to the codebase are potentially their property, not the company's.

Open source contributions by employees: Code that employees wrote for personal open source projects during their employment, using company equipment or company time, may have complicated IP status depending on the employment agreement and jurisdiction.

Government-funded research origins: Products that originated in academic or government-funded research contexts sometimes have IP encumbrances tied to the funding agreements.

What an IP Ownership Audit Covers

An IP audit in the context of technical due diligence typically covers:

• Review of inventor assignment agreements for all employees and contractors who contributed to the codebase.
• Verification that all significant contributors have signed IP assignment agreements, not just a subset.
• Review of any IP that was licensed in from third parties — including whether those licenses are transferable in an acquisition.
• Assessment of any IP that was assigned out or licensed to third parties — including exclusivity provisions that might limit the acquirer's use.
• Review of employment agreements for restrictive covenant provisions that might affect the team's ability to continue their work post-acquisition.

This audit is primarily a legal exercise, but the technical reviewer contributes by mapping contributions to specific contributors — using git history, code comments, and team interviews — so the legal team knows whose agreements to check.

Open Source License Audit

Open source license compliance is a technical and legal issue. The technical component is identifying which open source components are used, under what license, and whether the way they are used complies with the license terms. The legal component is assessing whether any non-compliance creates material liability.

License Categories and Their Implications

Open source licenses generally fall into three categories with meaningfully different implications for commercial software:

Permissive licenses (MIT, Apache 2.0, BSD): These allow use in commercial products with minimal restrictions — typically just attribution and preservation of the license notice. Most commercial software uses permissive-licensed components without legal concern.

Weak copyleft licenses (LGPL, MPL): These require that modifications to the licensed library itself be made available under the same license, but generally do not require that the application using the library be open-sourced. The specific requirements depend on the license and how the library is integrated.

Strong copyleft licenses (GPL, AGPL): These are the material concern for commercial software. GPL requires that any software distributed with GPL-licensed code be released under the GPL as well. AGPL extends this to software accessed over a network — meaning a web application using AGPL-licensed code may be required to release its source under the AGPL. Using GPL or AGPL code in a commercial product without a commercial license from the copyright holder is a serious compliance issue.

What the License Audit Looks For

• Every third-party dependency used in the product and the license under which it is used.
• Whether any GPL or AGPL-licensed components are included in the production application — either directly or as transitive dependencies.
• Whether any AGPL-licensed components are used in server-side code exposed as a network service.
• Whether the attribution and notice requirements of permissive licenses are being met.
• Whether any components have dual licensing (open source for some uses, commercial license required for others) and whether the company's use requires the commercial license.
• Whether any components have been modified and whether those modifications have been contributed back as required by the license.

Tools like FOSSA, Black Duck, or Snyk Open Source can automate a first pass over the dependency tree. Manual review is required for the findings that carry real risk.

Common Findings and Their Deal Implications

Undocumented contractor work without assignment agreements: This is fixable in most cases by locating the contractor and having them execute a retroactive assignment, but it requires time and sometimes negotiation. If the contractor cannot be located or declines to assign, the ownership of their contributions is permanently uncertain.

GPL code in a commercial product: This is a material finding. The resolution options are: replace the GPL component with a permissive alternative, purchase a commercial license from the copyright holder if one is available, or negotiate an escrow or holdback tied to remediation post-close.

Missing attribution for permissive-licensed components: A lower-severity finding, but one that should be remediated. Most licenses require that the license notice be included in distributions of the software.

AGPL exposure in server-side code: This is increasingly common as more infrastructure tooling is licensed under the AGPL. Depending on the specific component and how it is integrated, this may require remediation before close.

Who Does What

A well-run IP and license audit involves both the technical due diligence reviewer and the deal counsel:

• The technical reviewer maps the dependency tree, identifies open source components and their licenses, reviews git history for contributor mapping, and assesses whether usage patterns comply with license terms.
• Deal counsel reviews contributor agreements, assesses the legal risk of specific findings, and advises on deal structure implications.

Both are necessary. A purely technical review misses the contract and employment law dimensions. A purely legal review misses the dependency tree analysis and git history review.

If you need a technical-layer IP and license audit as part of a deal process, Clixo can scope and deliver the technical component in coordination with your deal counsel.