A PIIA (Proprietary Information and Inventions Agreement) is a written agreement signed by employees that assigns to the employer all inventions, copyrights, and other intellectual property created by the employee during their employment that relate to the company's business or are developed using company resources or time. PIIAs also typically include confidentiality obligations covering the company's trade secrets, non-solicitation provisions for customers and co-workers, and acknowledgment of any pre-existing inventions the employee is carving out from the assignment. In technology M&A, buyers audit whether all current and former employees who contributed to the core IP have signed PIIAs. Missing PIIAs are among the most common IP chain-of-title defects encountered in diligence and typically require cure before closing.

IP Assignment in Technology Acquisitions: Chain of Title Essentials

Q: Who owns code written by an employee?

In most U.S. jurisdictions, code written by an employee within the scope of their employment is owned by the employer under the work-for-hire doctrine, even without a written IP assignment agreement. However, relying solely on the work-for-hire doctrine is a due diligence risk in M&A transactions. Courts have narrowed the doctrine's scope in ways that create ambiguity around code developed partly on personal time, code that falls outside the employee's job description, and inventions made without company resources. For acquisition purposes, a missing or inadequate IP assignment agreement from any employee who contributed meaningfully to the product is a chain-of-title defect that buyers will flag and require resolution before or at closing. Written assignment agreements are the clean answer; work-for-hire is a fallback that creates uncertainty.

Q: Does a contractor automatically assign IP?

No. Unlike employees, independent contractors do not automatically assign intellectual property to the company that hired them. Under U.S. copyright law, a contractor retains ownership of work product they create unless: (1) there is a written agreement assigning the IP to the company, or (2) the work qualifies as a 'work made for hire' under the specific statutory categories for commissioned works, and a written work-for-hire agreement exists. Code and software development generally do not fall within the statutory work-for-hire categories for independent contractors. This means that every contractor who contributed to a technology company's core product should have signed a written IP assignment agreement. In diligence, contractors without assignment agreements are a significant chain-of-title defect, particularly if the contractor contributed to foundational code that underlies the current product.

Q: Can AGPL licensing kill a deal?

AGPL (GNU Affero General Public License) can materially affect deal structure or require remediation before closing, depending on how deeply AGPL-licensed code is incorporated into the product. AGPL's distinguishing feature is its network copyleft provision: if a user interacts with AGPL-licensed code over a network, the AGPL's copyleft obligations are triggered, requiring the company to make the complete source code available to users under AGPL terms. For SaaS products, where all users interact via network by definition, AGPL incorporated into proprietary product code can require disclosure of the entire codebase as open source. Whether this kills a deal depends on the scope of incorporation, whether the company has obtained a commercial license from the copyright holder, and whether remediation (code replacement or isolation) is feasible before closing. AGPL findings in diligence typically require legal analysis and may require technical remediation.

Q: How do buyers audit open source compliance in diligence?

Buyers audit open source compliance through a combination of technical scanning and legal review. On the technical side, buyers use software composition analysis (SCA) tools to scan the codebase and identify all open source components, their versions, and their associated licenses. Common tools used in M&A diligence include FOSSA, Black Duck, and Snyk. The scan output is reviewed by legal counsel to categorize licenses by risk level: permissive licenses (MIT, Apache 2.0, BSD) present minimal compliance risk; weak copyleft licenses (LGPL, MPL) require analysis of how the component is integrated; strong copyleft licenses (GPL, AGPL) require detailed analysis of whether the integration triggers disclosure obligations. Buyers also review the company's internal open source policy, any commercial license agreements for components used under dual licensing, and the company's process for vetting new open source dependencies.

Q: What is perfecting an IP assignment?

Perfecting an IP assignment means completing the formal steps required to make the buyer's ownership of the transferred IP enforceable against third parties, not just the seller. For patents, perfection requires recording the assignment with the U.S. Patent and Trademark Office (USPTO) within a specified period after the assignment date. Recording with the USPTO is necessary because U.S. patent law provides that an unrecorded assignment is void against a subsequent purchaser who takes without notice and records first. For trademarks, assignments should also be recorded with the USPTO. For copyrights, recording with the U.S. Copyright Office is optional but provides constructive notice and priority against subsequent transferees. At closing in a technology acquisition, the parties typically execute a formal IP assignment agreement (or bill of sale that specifically includes IP), and the buyer then files the required recordal documents with relevant government offices after closing.

Q: Do trademarks transfer automatically in an asset purchase?

No. Trademarks do not transfer automatically in an asset purchase. Under U.S. trademark law, a trademark assignment must be in writing and must include an assignment of the goodwill associated with the trademark. An assignment of a trademark without its associated goodwill is considered an 'assignment in gross' and is invalid, meaning the assignee does not acquire valid trademark rights. In an asset purchase, the asset purchase agreement must specifically identify the trademarks being transferred (including registration numbers) and include language assigning the goodwill of the business associated with those marks. After closing, the assignment should be recorded with the USPTO to provide constructive notice of the transfer. Domain names associated with the brand must be transferred separately through the relevant domain registrar.

Q: What happens if an employee never signed an IP assignment?

If a current or former employee contributed to the company's core IP without signing a PIIA or IP assignment agreement, the company has a chain-of-title defect that must be addressed before or at closing. The available remedies depend on the circumstances. If the employee is still with the company, the company can have the employee sign a nunc pro tunc (retroactive) assignment agreement covering all prior work product. If the former employee is reachable and cooperative, a similar retroactive assignment can be obtained with appropriate consideration. If the former employee is unreachable or uncooperative, the company must assess the risk based on the scope of the employee's contribution: a significant contributor to foundational code without an assignment is a material IP defect that may require escrow, indemnification, or price adjustment. In some cases, buyers require the seller to obtain missing assignments before closing as a condition precedent.

In a technology acquisition, the buyer is not purchasing physical assets or manufacturing capacity. The buyer is purchasing intellectual property: the software, the patents, the brand, the accumulated trade secrets, and the customer relationships governed by contracts that grant the company the right to use and monetize those assets. If the target does not own its core IP cleanly, the transaction is built on a defective foundation.

Chain of title is the legal concept that describes the unbroken sequence of ownership transfers leading from the original creation of IP to the current owner. In a technology acquisition, establishing clean chain of title requires tracing ownership back through every founder, employee, contractor, and third-party component that contributed to the product. Gaps in the chain, whether a missing employee PIIA, an unassigned contractor contribution, or a copyleft-licensed open source component, create legal uncertainty that buyers must resolve before acquiring the asset.

This guide is part of the Technology and SaaS M&A Guide cluster. It covers the complete IP assignment and chain-of-title framework for technology acquisitions: the legal rules governing who owns what, the diligence process for identifying defects, and the mechanics of perfecting assignment at close.

Buyers evaluating the broader transaction structure for a technology acquisition should review the M&A due diligence guide and the asset purchase agreement guide. The IP assignment analysis in this guide fits within the broader diligence and deal-structuring framework those resources cover.

Request Engagement Assessment

Why IP Chain of Title Matters in Tech M&A

A buyer who acquires a technology company expects to receive ownership of the software, the patent portfolio, the brand, and the trade secrets that give the business its value. What the buyer actually receives is only as good as the chain of title that connects each IP asset to the seller. If the seller does not own an asset, the seller cannot transfer it. And in technology companies, gaps in IP ownership are far more common than in other industries, for reasons rooted in how technology businesses are built.

Technology companies are built by people: founders who may have contributed code before the company was formed, early employees who joined before IP policies were formalized, contractors hired to build specific modules without proper assignment paperwork, and open source communities whose contributions carry licensing terms the company may not fully understand. Each of these relationships is a potential chain-of-title weakness.

The Business Consequences of IP Defects at Closing

Post-close litigation exposure: A former contributor who never assigned their IP retains a legal claim that can be asserted after closing. The buyer inherits the liability without having received a representation that covered the specific defect.

License termination risk: Open source licenses that were violated by the target company remain violated after acquisition. The copyright holders of those components can terminate the license and seek injunctive relief, potentially forcing the buyer to remove the components from the product post-close.

Indemnification claims: If IP defects are discovered post-close, buyers typically look to the seller's indemnification obligations in the purchase agreement. Whether those claims are covered depends on what was represented and how the indemnification baskets and caps were negotiated.

Customer contract implications: SaaS customers who contracted for clean IP ownership in the software they use may have breach claims if a post-close IP dispute undermines the seller's representations of ownership to those customers.

Employee vs Contractor IP Assignment

The threshold question in any IP chain-of-title analysis is: who created the IP, and in what capacity? The legal rules for IP ownership differ significantly depending on whether the creator was an employee or an independent contractor, and the distinction is one of the most commonly misunderstood issues in early-stage technology company IP management.

For employees, U.S. law provides a baseline of employer protection through the work-for-hire doctrine: work created by an employee within the scope of their employment is generally owned by the employer as a matter of law, even without a written agreement. But this baseline is narrower than most technology company founders assume. Code developed on personal time, inventions made without company resources, and work that falls outside the employee's defined job function may fall outside the doctrine's scope. Written IP assignment agreements fill these gaps and provide the clean title that M&A buyers require.

For independent contractors, the situation is categorically different. Contractors retain ownership of their work product by default unless there is a written assignment agreement. The statutory work-for-hire categories under U.S. copyright law do not include most software development work, meaning that the commissioning company must have a written assignment agreement to claim ownership of contractor-created code. This is a structural gap in many early-stage technology companies that relied heavily on contractors to build their initial product.

Founder IP: Code and inventions created by founders before the company was incorporated present a distinct chain-of-title issue. If a founder wrote foundational code on their own time before the company existed, that code is not automatically owned by the company. Founders should assign all pre-incorporation IP to the company as part of the company formation process. Missing founder IP assignments are a significant diligence finding, particularly for companies whose core technology was developed by the founders before seed funding.

Work-for-Hire Doctrine and Its Limits

The work-for-hire doctrine is the primary mechanism by which employers claim ownership of employee-created IP without requiring a written assignment for every piece of work product. Under Section 101 of the U.S. Copyright Act, a work is made for hire if it is prepared by an employee within the scope of their employment, or if it is specially ordered or commissioned under one of the specific statutory categories with a written agreement.

The "scope of employment" analysis is a factual inquiry that courts apply on a case-by-case basis. The Restatement and most case law focus on three factors: whether the work was the type the employee was hired to perform, whether the work occurred substantially within authorized work hours and space, and whether the work was motivated at least in part by a purpose to serve the employer. Code written during work hours on a company laptop by a software engineer whose job description includes software development will almost always fall within the scope of employment. Code written at home on personal time by the same engineer, outside their official responsibilities, may not.

Moonlighting risk: Engineers who work on side projects in the same technical domain as their employment may inadvertently create IP ownership disputes. If the side project uses company resources, was developed during work hours, or is related to the company's business, the employer may have a claim to the work product even without an assignment agreement. Conversely, the engineer may believe the work-for-hire doctrine extends to their outside work, creating confusion about who owns what.

State law variations: Several states, including California, Delaware, Illinois, Minnesota, Washington, and North Carolina, have statutes that limit an employer's ability to claim ownership of employee inventions created on personal time without the use of employer resources. These statutes typically carve out from the employment IP assignment obligation any inventions that do not relate to the employer's business and are developed without employer resources. IP assignment agreements in those states must include specific statutory language and carve-outs to be enforceable.

Joint works: If IP was created by an employee and a contractor working together, or by two employees where one's contribution falls outside their scope of employment, the resulting work may be a joint work under copyright law. Joint works give each co-author independent rights to exploit the work, including the right to license it to third parties without the other co-author's consent (subject to an accounting obligation). Joint authorship in foundational product code is a material IP defect that requires resolution through an IP assignment from every joint author.

IP Assignment Agreements (PIIA, CIIA)

The foundational documents in technology company IP ownership are the Proprietary Information and Inventions Agreement (PIIA) and the Contractor Intellectual Property Agreement (CIIA). These agreements establish written chains of title from every contributor to the company, supplementing the work-for-hire doctrine where it applies and replacing it where it does not.

A well-drafted PIIA covers several distinct obligations. The IP assignment clause assigns to the company all inventions, discoveries, developments, and works of authorship that the employee creates during their employment that relate to the company's actual or anticipated business. The confidentiality clause obligates the employee to protect the company's trade secrets and proprietary information. The non-solicitation clause (where enforceable under state law) restricts the employee from recruiting co-workers or soliciting customers for a period after departure. And the prior inventions schedule carves out any pre-existing inventions the employee wishes to retain ownership of.

PIIA Diligence Checklist for Buyers

✓All current employees who have access to or contribute to the product have signed a PIIA
✓Key former employees who contributed to the core product during their tenure have signed a PIIA or a retroactive assignment
✓Founders have assigned all pre-incorporation IP to the company, either through the PIIA or a separate founder IP assignment agreement
✓Prior inventions schedules have been reviewed: carve-outs for pre-existing inventions that are now incorporated in the product are red flags requiring follow-up
✓PIIA templates comply with applicable state law (California, Washington, etc.) requirements for invention assignment carve-outs
✓All contractors and freelancers who contributed to the product have signed a CIIA or equivalent written IP assignment

For a contractor IP assignment agreement (CIIA), the critical provisions are the IP assignment clause (which must be explicit and cover all work product, not just "deliverables"), the confidentiality obligations, and the warranty that the contractor's work does not infringe third-party rights and does not incorporate open source code without disclosure. The CIIA should also address whether the contractor has any prior inventions relevant to the engagement that are carved out from the assignment.

Pre-Employment Inventions and Carve-Outs

Most well-drafted PIIAs include a prior inventions schedule on which the employee lists any inventions, IP, or works they created before their employment that they wish to retain ownership of. This schedule serves two functions: it carves out the listed prior inventions from the PIIA's assignment scope, and it provides the company with notice of what the employee is retaining.

From a diligence perspective, the prior inventions schedule is among the most important documents to review in a technology M&A transaction. An employee who listed a software library, algorithm, or technical architecture that is now incorporated into the company's product on their prior inventions schedule retained ownership of that IP. The company is using it without a license or assignment, which creates a chain-of-title defect.

Prior inventions incorporated in the product: When a prior inventions carve-out covers technology that is now embedded in the company's product, the company typically needs to either obtain a written license from the employee (or former employee) for the specific use, or obtain a retroactive assignment. If the employee has departed and is uncooperative, the company may need to assess whether the prior invention can be identified, isolated, and replaced in the codebase before closing. Buyers who discover this issue in diligence should factor remediation cost and timeline into their deal assessment.

Open Source License Compliance in Codebase

Modern software products are built on open source components. The average commercial software product contains hundreds of open source packages, and technology companies that have not implemented a formal open source governance policy often have components with license terms they have not fully reviewed. In M&A diligence, open source compliance is analyzed through a software composition analysis (SCA) scan, which identifies all open source components in the codebase and maps their associated licenses.

Open source licenses exist on a spectrum from permissive to copyleft. Permissive licenses, such as MIT, Apache 2.0, BSD 2-Clause, and BSD 3-Clause, impose minimal obligations: typically attribution and license notice inclusion. These licenses are broadly compatible with commercial software development and present low compliance risk in M&A. The buyer's compliance obligation is largely limited to confirming that the required attributions and notices are included in the software distribution.

Copyleft licenses impose more significant obligations that vary in scope across the different license categories. Understanding those obligations and how they interact with a commercial SaaS product is the core of the open source compliance analysis in technology M&A. The detailed framework for copyleft risk is addressed in the following section.

Open Source License Categories: Risk Overview

Permissive (MIT, Apache 2.0, BSD): Allow use in proprietary software with minimal restrictions. Primary obligations are attribution and license notice inclusion. Low compliance risk in M&A.

Weak copyleft (LGPL, MPL, Eclipse): Allow use in proprietary software if the copyleft component is dynamically linked or otherwise isolatable. Modifications to the copyleft component itself must be released under the same license. Risk depends on integration method.

Strong copyleft (GPL v2, GPL v3): Any software that incorporates or links to a GPL-licensed component may need to be distributed under the GPL. For software distributed as a binary, this requires releasing the full source code. Risk analysis depends heavily on distribution model.

Network copyleft (AGPL): Extends GPL copyleft obligations to network interactions. For SaaS products, AGPL incorporation can require releasing the entire codebase as open source. Highest compliance risk for SaaS acquisitions.

Copyleft Risks: GPL, AGPL, and LGPL

Copyleft licenses are designed to ensure that derivative works and modifications remain available under the same open source terms. The mechanism varies by license, but the core principle is the same: if you use, distribute, or make available software that incorporates a copyleft-licensed component in certain ways, your own software becomes subject to the same copyleft license obligations. For a commercial technology product, this can mean being required to release proprietary source code to users.

GPL v2 and GPL v3 obligations are triggered by distribution: if a company distributes software that incorporates GPL-licensed code (as a combined work or by linking), the distribution triggers an obligation to make the full source code available under GPL terms. For desktop or on-premise software that is distributed to end users, this is the operative analysis. For SaaS products that are not distributed in the traditional sense, the original GPL was designed in an era of software distribution and does not clearly trigger on network access alone.

AGPL v3 was created specifically to address this gap. The AGPL adds a network use provision that triggers copyleft obligations when users interact with the software over a network, even if no distribution of the software itself occurs. For SaaS products, where all user interaction is via network by definition, AGPL incorporation means that users who interact with the SaaS product over the network have the right to receive the complete corresponding source code. This effectively requires the company to make its full codebase available as open source to any user.

LGPL (Lesser GPL): The LGPL is designed to allow use of copyleft-licensed libraries in proprietary software under specific conditions. If the LGPL library is used as a dynamically linked library that can be replaced by users with a modified version of the library, the LGPL obligations generally do not extend to the proprietary software using the library. If the library is statically linked or its code is incorporated into the application, the analysis is more complex. LGPL compliance is a technical and legal analysis that requires both a review of the license terms and an understanding of how the library is integrated into the product.

Commercial licenses as a remedy: Many open source projects that use copyleft licenses also offer commercial licenses under dual-licensing arrangements. A company that obtained a commercial license for an AGPL or GPL component before incorporating it into a proprietary product is not subject to the copyleft obligations under the commercial license. In diligence, buyers should verify which AGPL and GPL components are licensed under commercial agreements and confirm those agreements are transferable as part of the acquisition.

Remediation options: When copyleft-licensed components are discovered that were incorporated without compliance, remediation options include: replacing the component with a permissively licensed alternative (may require significant engineering effort), isolating the component so that copyleft obligations do not extend to the proprietary codebase, obtaining a retroactive commercial license from the copyright holder (if available), or structuring the acquisition to leave the noncompliant component outside the acquired assets and rebuilding the functionality post-close. The cost and timeline of each option should be assessed before close.

Trademark Ownership and Domain Name Registration

Trademarks protect the brand identity of a technology product: the product name, the company name, logos, and in some cases distinctive design elements and trade dress. In a technology acquisition, the buyer is typically acquiring not just the software but the brand recognition and customer relationships built under the seller's trademark. Confirming clean trademark ownership and understanding the transfer mechanics are essential steps in IP diligence.

Trademark ownership analysis begins with a review of the seller's trademark portfolio: which marks are registered with the USPTO, which are pending registration, and which are being used without registration (common law marks). Registered marks provide presumptive validity and constructive notice nationwide. Unregistered marks provide rights only in the geographic areas where the mark has actually been used in commerce, which may be narrower than the company's actual operating footprint if registration was never pursued.

Domain names are often closely linked to the trademark portfolio but are held through separate registrar accounts and do not transfer automatically with the trademark. The asset purchase agreement should specifically identify all domain names to be transferred, and the transfer must be executed through the domain registrar's transfer process after closing. Buyers should confirm that the seller controls the registrar accounts for all relevant domains and that there are no disputes, liens, or third-party claims on the domain registrations.

Trademark Diligence Points for Technology Acquisitions

✓Confirm registered trademarks are current, maintained, and not subject to pending cancellation proceedings
✓Review any trademark assignments or licenses in the chain of title to confirm the seller holds clean ownership
✓Identify all domains used in connection with the product and confirm the seller controls the registrar accounts
✓Assess any third-party uses of similar marks that could create post-close infringement exposure
✓Confirm that the asset purchase agreement specifically identifies all marks and domains and includes goodwill assignment language
✓Plan for post-close recording of trademark assignments with the USPTO and domain transfers through the registrar

Conducting IP Diligence on a Technology Acquisition?

Alex Lubyansky works with technology buyers on IP chain-of-title diligence, open source compliance review, and IP assignment at close. Submit your transaction details for an engagement assessment.

Patent Portfolio Review in Tech Deals

Not all technology companies have patent portfolios, but for those that do, the patent diligence analysis is one of the more technically intensive components of IP review. Patents provide a time-limited monopoly over specific inventions, and a strong patent portfolio can be a significant asset or a source of unexpected liability, depending on what the portfolio contains and how it has been maintained.

The starting point for patent diligence is confirming that the seller actually owns the patents in its portfolio. Patent ownership requires a written assignment from every inventor. In the U.S., patents are owned initially by the inventors, not the company. Assignment from the inventors to the company is required to transfer ownership. If any inventor failed to sign an assignment when the patent application was filed, or signed a defective assignment, the company may not have clean title to the patent.

Beyond ownership, buyers evaluate the technical scope of the patent claims, the prosecution history (the record of how the claims were argued before the USPTO during examination), any inter partes review (IPR) or post-grant challenges to the patents, and the remaining term of each patent. For strategic acquisitions where the patent portfolio is a primary acquisition driver, a formal patent landscape analysis and claim scope evaluation are typically performed by patent counsel.

Patent Portfolio Diligence: Key Review Points

Inventor assignment: Confirm all inventors have signed assignment agreements transferring their rights to the company. Review assignment records at the USPTO for each patent and pending application.

Maintenance fees: U.S. patents require maintenance fee payments at 3.5, 7.5, and 11.5 year intervals after issuance. Confirm all required maintenance fees have been paid on time. Lapsed patents due to missed maintenance fees cannot be reinstated after a certain point.

License encumbrances: Review any licenses granted by the seller on the patent portfolio. Exclusive licensees may have rights that limit the buyer's ability to use or enforce the patents. Non-exclusive licensees receive implied covenants that may survive the acquisition depending on how the deal is structured.

Prior art exposure: For patents that are central to the deal's value, assess whether significant prior art exists that was not cited during prosecution and could form the basis for a post-grant challenge.

Trade Secret Protection Measures

For technology companies that have not pursued patents, trade secret protection is often the primary legal framework for protecting proprietary technology. Trade secrets can protect source code, algorithms, technical architecture, customer data structures, pricing models, and other business information that derives value from being kept confidential. Unlike patents, trade secrets do not expire, but they require active protection measures to maintain their legal status.

To qualify as a trade secret under the Defend Trade Secrets Act (DTSA) and most state trade secret laws, information must meet two requirements: it must have independent economic value from not being generally known or readily ascertainable, and the company must have taken reasonable measures to keep it secret. The "reasonable measures" requirement is where many technology companies are exposed in M&A diligence. A company that has not implemented formal trade secret protection measures may have difficulty establishing that its confidential information qualifies for trade secret protection.

Access controls: Limiting access to source code, customer data, and other confidential information on a need-to-know basis is a foundational trade secret protection measure. Technical controls (code repository permissions, database access controls, VPN requirements) and policy controls (documented access policies, off-boarding procedures) both contribute to the "reasonable measures" showing.

Confidentiality obligations: Employees, contractors, and business partners who have access to trade secrets should be bound by written confidentiality obligations. PIIA confidentiality provisions cover employees. Vendor and partner agreements should include mutual or one-way NDA provisions appropriate to the nature of the relationship. In M&A diligence, buyers look for any gaps in confidentiality coverage that could support a third party's claim that trade secrets were disclosed without restriction.

Trade secret inventory: Companies with a formal trade secret program maintain an inventory of their key trade secrets, the access controls applicable to each, and the confidentiality agreements in place. In diligence, a trade secret inventory signals a mature IP governance program. The absence of any inventory or policy is a factor that can affect the buyer's assessment of trade secret protection measures.

Customer IP Clauses in SaaS Contracts

SaaS customer agreements frequently contain IP-related provisions that can affect the seller's IP ownership and the buyer's ability to acquire clean title. These provisions are easy to overlook in diligence because they appear in commercial contracts rather than in the IP assignment documents that diligence typically focuses on. A buyer acquiring a SaaS company should review the form customer agreements and any negotiated enterprise agreements for IP clauses that could create post-close complications.

The most common customer IP provisions that create issues in SaaS M&A fall into several categories. Ownership of customizations and enhancements provisions address who owns code written specifically for a customer's implementation. If the SaaS company agreed that custom features built for an enterprise customer belong to that customer, the buyer may be acquiring software that includes customer-owned code. Data ownership provisions address who owns the customer's data and the derived analytics or insights generated from that data. Work product provisions in professional services agreements may assign ownership of configuration work, integrations, or other services deliverables to the customer.

Change-of-control provisions in customer agreements: Many enterprise SaaS agreements include provisions that give customers consent rights or termination rights upon a change of control of the SaaS company. These provisions are relevant to both IP diligence and commercial due diligence: customers who can terminate or renegotiate their contracts upon a change of control represent both revenue risk and potential IP complication if their agreements include IP ownership provisions. Buyers should identify all customer agreements with change-of-control provisions as part of their diligence process.

The SaaS valuation multiples guide addresses how contract quality, including the presence of unfavorable IP and change-of-control provisions, affects the valuation analysis for SaaS acquisitions. Buyers should evaluate IP risk in customer contracts alongside commercial and financial diligence rather than treating them as separate exercises.

Perfecting Assignment at Close: Bill of Sale and Patent Assignment

The final step in the IP chain-of-title analysis is ensuring that the actual transfer of IP at closing is executed correctly and that the post-close recordal steps are completed. Perfecting an IP assignment means completing all legal formalities required to make the buyer's ownership enforceable, not just against the seller, but against the world, including subsequent purchasers and creditors of the seller.

The asset purchase agreement or bill of sale must specifically identify the IP assets being transferred. General language transferring "all assets of the business" is insufficient for IP: each category of IP (patents, trademarks, copyrights, trade secrets, domain names) should be identified with enough specificity to enable post-close recordal. For patents, the specific registration numbers should be listed. For trademarks, the registration numbers and the goodwill assignment language must be included. For domain names, each domain should be identified.

After closing, the patent and trademark assignments should be recorded with the USPTO. Under U.S. patent law, failure to record a patent assignment within three months of the assignment date risks the assignment being void against a subsequent purchaser who takes without notice and records first. This is a significant risk in any transaction: if the seller were to pledge the same patent as collateral for a loan and the lender recorded before the buyer recorded the assignment, the lender's interest could prevail. Prompt post-close recordal is a non-negotiable post-closing obligation in every technology acquisition.

IP Transfer Closing and Post-Closing Checklist

✓Execute IP assignment agreement or bill of sale that specifically identifies all patents, trademarks, copyrights, trade secrets, and domains
✓Include goodwill assignment language in any trademark assignment document
✓File patent assignment recordal with USPTO within 3 months of closing (or as promptly as possible)
✓File trademark assignment recordal with USPTO after closing
✓Execute domain name transfers through the relevant registrars for each domain
✓Transfer code repository ownership and revoke seller's access to code hosting accounts
✓Update software license accounts, API keys, and third-party service accounts to reflect buyer ownership

The mechanics of IP transfer fit within the broader asset purchase closing framework. Buyers structuring a technology acquisition as an asset purchase should review the asset purchase agreement guide for the complete closing mechanics, including IP-specific schedules, representations and warranties, and indemnification provisions that address IP chain-of-title defects. The indemnification framework for IP representations is addressed in the indemnification provisions guide.

Acquiring a Technology Company and Need IP Chain-of-Title Analysis?

Acquisition Stars works with technology buyers on IP diligence, open source compliance review, employee and contractor assignment audits, and IP perfection at close. Alex Lubyansky handles each engagement directly. Submit your transaction details to begin the engagement assessment process.

Request Engagement Assessment

Frequently Asked Questions

Who owns code written by an employee?

Code written by an employee within the scope of their employment is generally owned by the employer under the work-for-hire doctrine. However, relying on the doctrine alone creates uncertainty in M&A diligence. Code developed on personal time, outside the employee's job description, or without company resources may fall outside the doctrine's scope. A written PIIA that assigns all employment-related IP to the company is the clean answer. Missing or inadequate PIIAs are a chain-of-title defect that buyers will require resolution before closing.

What is a PIIA?

A PIIA (Proprietary Information and Inventions Agreement) is a written agreement signed by employees that assigns to the employer all inventions and IP created during employment that relate to the company's business or are developed using company resources. PIIAs also include confidentiality obligations, non-solicitation provisions, and a prior inventions schedule for carve-outs. In technology M&A, buyers audit whether all current and former employees who contributed to the core IP have signed PIIAs. Missing PIIAs are among the most common IP chain-of-title defects found in diligence.

Does a contractor automatically assign IP?

No. Independent contractors retain ownership of their work product by default. Unlike employees, contractors are not covered by the work-for-hire doctrine for most software development work. A written IP assignment agreement (CIIA) is required to transfer contractor-created IP to the company. Companies that used contractors to build foundational product components without written assignment agreements have a chain-of-title defect that must be cured. Every contractor who contributed meaningfully to the product should have a signed assignment agreement in the company's records.

Can AGPL licensing kill a deal?

AGPL incorporation can materially affect deal structure or require pre-close remediation. AGPL's network copyleft provision triggers disclosure obligations when users interact with AGPL-licensed code over a network, which for SaaS products means all users. AGPL incorporated into proprietary product code can require releasing the entire codebase under AGPL terms. Whether this kills a deal depends on the scope of incorporation, the availability of a commercial license from the copyright holder, and the feasibility of technical remediation. AGPL findings in diligence require specific legal analysis and may require engineering remediation before close.

How do buyers audit open source compliance in diligence?

Buyers use software composition analysis (SCA) tools to scan the codebase and identify all open source components and their licenses. Common tools include FOSSA, Black Duck, and Snyk. The scan output is reviewed by legal counsel to categorize licenses by risk level: permissive licenses present minimal compliance risk; weak copyleft licenses require integration analysis; strong and network copyleft licenses require detailed compliance review. Buyers also review the company's open source policy, commercial license agreements for dual-licensed components, and the process for vetting new open source dependencies.

What is perfecting an IP assignment?

Perfecting an IP assignment means completing all formal steps required to make the buyer's ownership enforceable against third parties. For patents, this requires recording the assignment with the USPTO within three months of the assignment date. An unrecorded patent assignment is void against a subsequent purchaser who takes without notice and records first. For trademarks, assignments should also be recorded with the USPTO. For domain names, transfer must be executed through the domain registrar. Prompt post-close recordal is a non-negotiable obligation in every technology acquisition.

Do trademarks transfer automatically in an asset purchase?

No. Trademarks require a written assignment that includes the goodwill associated with the mark. An assignment of a trademark without goodwill is invalid under U.S. trademark law. The asset purchase agreement must specifically identify all trademarks by registration number and include goodwill assignment language. After closing, the assignment should be recorded with the USPTO. Domain names must be transferred separately through the domain registrar and do not transfer automatically with the trademark.

What happens if an employee never signed an IP assignment?

A missing PIIA from a contributor to core IP is a chain-of-title defect requiring remediation. If the employee is still with the company, a retroactive assignment can be obtained. If the former employee is reachable and cooperative, a retroactive assignment with consideration can cure the defect. If the former employee is uncooperative or unreachable, buyers assess the scope of contribution and may require escrow, indemnification holdback, or price adjustment. For significant contributors to foundational code, the missing assignment may be a condition precedent to closing, requiring the seller to resolve it before the deal proceeds.

Complete the Technology M&A Framework

IP assignment is one component of the broader technology M&A legal framework. Review the related guides for the complete picture.

Technology and SaaS M&A Guide: Complete Overview SaaS Valuation Multiples: How ARR, NRR, and Growth Shape Price M&A Due Diligence Guide Asset Purchase Agreement Guide Indemnification Provisions in M&A M&A Deal Structures