# IP Essentials for International Commercial Contracts > The IP clauses in a software deal can look fine at signature and still fail when tested — not from carelessness, but from the gap between commercial expectations and technical IP standards. **By Paul Roberts** | 📊 Comprehensive Guide 📊 **49,800 words** | ⏱️ **200 min read** #Legal_Guide #Patent_Law #Software_Patents #Comprehensive #Contracts February 16, 2026 --- ## Introduction A software company can negotiate a clean indemnity, a broad license grant, and a carefully marked confidentiality clause — and still discover, years later, that the patent window closed at launch, the vendor's form silently authorized model training on customer data, or a federal subcontract stripped commercial data rights the business thought it had retained. Those failures rarely announce themselves at signature. They surface in litigation, a failed transaction, or a dispute the contract was supposed to prevent. The gap is not negligence. It is the distance between ordinary commercial expectations about what IP provisions do and the technical legal standards that govern those provisions when they are tested — across patents, copyright, trade secrets, data rights, open source, AI outputs, and the mandatory rules that follow technology across borders. This article maps that gap for contracts counsel and the IP lawyers they escalate to. It proceeds in three parts. **Part I** establishes the IP landscape: what types of intellectual property protect software assets, and what it takes to infringe each one. Infringement standards determine what a counterparty must prove and what the commercial exposure of any given contract provision actually is. **Part II** answers the threshold operating question: which deals warrant escalation to IP counsel before signing, which do not, and how to brief IP so the review is usable — including patent-timing traps that can destroy rights before any clause is negotiated, and an IP Counsel Request Form for structured intake. **Part III** is the issue-spotting library: seventeen categories of contract provisions that routinely produce IP exposure, with particular attention to issues that are common, material, and easy to miss when the deal moves quickly. International and cross-border issues run through all three parts; dedicated chapters on choice of law and dispute resolution sit in Part III once a deal has been flagged for deeper review. Throughout, the analysis proceeds from the perspective of a software company that operates in three common commercial postures: licensing its technology directly to end users; licensing that same technology to other companies that embed, resell, or build on it; and in-licensing software and data from third-party vendors. Those roles create tensions that run through the entire article. The same provisions that protect the company when it sells to end users may need different calibration when the counterparty is another company — and may disadvantage the company entirely when it is the buyer. Negotiating positions appropriate for one posture are often inappropriate for the others. The article uses GlobalTech Int'l, a fictional international software company, as the reference company for illustrative examples. All examples are generic and intended to demonstrate principles rather than describe any actual company or transaction. --- ## Part I — The IP Landscape: What Protects Software and What Counts as Infringement This Part establishes the foundational vocabulary for the analysis that follows. It surveys the IP types relevant to software contracts, identifies the applicable infringement standard for each category, and introduces the concept of the IP bundle — the analytical framework for reading any license grant. Readers who work primarily with contracts rather than IP law may find this Part useful as a reference layer for the escalation screen in Part II and the issue-spotting chapters in Part III. --- ### Chapter 1 — The IP Taxonomy: More Than Four Categories The intuition that IP law encompasses four types — patents, copyrights, trade secrets, and trademarks — is a useful starting point but an incomplete map for commercial contracts work. The full taxonomy of IP rights that may appear in or affect a software company's commercial agreements is considerably broader. | Category | Primary Legal Basis (U.S.) | International Framework | |---|---|---| | Utility Patents | 35 U.S.C. §§ 101–103 | PCT; Paris Convention; TRIPS | | Design Patents | 35 U.S.C. § 171; § 173 | Hague Agreement; TRIPS | | Copyright | 17 U.S.C. §§ 101 et seq. | Berne Convention; TRIPS | | Trade Secrets | DTSA, 18 U.S.C. §§ 1836–1839; state UTSA | TRIPS Art. 39; EU Trade Secrets Directive | | Trademarks & Service Marks | Lanham Act, 15 U.S.C. §§ 1051 et seq. | Madrid Protocol; Paris Convention; TRIPS | | Trade Dress | 15 U.S.C. § 1125(a) | Country-specific unfair competition law | | False Designation of Origin | 15 U.S.C. § 1125(a)(1)(A) | Country-specific | | Trademark Dilution | 15 U.S.C. § 1125(c) | Country-specific | | False Advertising | 15 U.S.C. § 1125(a)(1)(B) | Country-specific | | Right of Publicity / False Endorsement | State law (no federal ROP statute); Lanham Act § 43(a) for false endorsement | Country-specific personality rights | | Moral Rights | 17 U.S.C. § 106A (VARA — visual art only in U.S.) | Berne Convention Art. 6bis; broader in EU/civil law countries | | Database Rights | No standalone U.S. law; protected via contract + trade secret | EU Database Directive (sui generis right) | *Abbreviations used in the table: PCT — Patent Cooperation Treaty; TRIPS — Agreement on Trade-Related Aspects of Intellectual Property Rights; DTSA — Defend Trade Secrets Act; UTSA — Uniform Trade Secrets Act; ROP — right of publicity; VARA — Visual Artists Rights Act. Each is discussed in the sections that follow.* For a company with international commercial relationships, U.S. doctrine is the starting point — not the complete picture. Each category listed above carries an international treaty framework and country-specific variation that may affect how contracts with non-U.S. parties are drafted and enforced. See Chapter 16 of Part III for the full international treatment. --- ### Chapter 2 — Utility Patents **What they protect:** Novel, non-obvious, and useful processes, machines, articles of manufacture, and compositions of matter. 35 U.S.C. §§ 101–103. **For software companies:** Patents protect methods that underlie software products — fraud detection algorithms, data processing pipeline architectures, application programming interface (API) workflow systems, credit scoring methods, and machine learning model architectures where the claims are drafted to cover the method rather than the model weights. **The bundle of rights:** A patent grants the right to exclude others from making, using, selling, offering for sale, or importing the patented invention. 35 U.S.C. § 271. The right to exclude is the patent's core commercial value; it is not a right to practice the invention. **Duration:** 20 years from the earliest effective U.S. filing date, not from grant. Maintenance fees are due at 3.5, 7.5, and 11.5 years post-grant. Term may be extended for regulatory delay (patent term extension) or adjusted for U.S. Patent and Trademark Office (USPTO) processing delays (patent term adjustment). **Filing timing and international rights:** Patent protection requires a filing decision before public disclosure. The U.S. provides a 12-month grace period following the inventor's own disclosure (35 U.S.C. § 102(b)(1)), but a significant number of foreign jurisdictions impose absolute novelty requirements — public disclosure before filing may destroy international patent rights in those jurisdictions regardless of the U.S. grace period. For international filing, the Patent Cooperation Treaty (PCT) provides a unified international application process; nationalization into individual countries occurs within 30 months of the priority date. Patent rights are territorial — a U.S. patent provides no protection in Germany, India, or Brazil absent separate national filings. Part II, Chapter 3 expands this for contracts counsel: commercial use and on-sale bars, absolute novelty (including Europe), and when the inventor’s own disclosures defeat patentability by jurisdiction. See Chapter 16 of Part III for how patent exhaustion and divided infringement standards vary across borders. --- ### Chapter 3 — Design Patents **What they protect:** The novel, ornamental appearance of an article of manufacture — not its function. 35 U.S.C. § 171. Design patents have become a significant strategic tool in software following *Apple Inc. v. Samsung Electronics Co.* (Fed. Cir. 2012, 2016), which addressed design patent damages in the context of smartphone UI elements. **For software companies:** UI/UX designs for consumer-facing products; dashboard layouts; graphical user interface elements; icons. A design patent protects the appearance of the element, not the functionality it delivers. **Duration:** 15 years from the date of grant, not from the filing date. 35 U.S.C. § 173 (as amended by the Patent Law Treaties Implementation Act, Pub. L. 112-211, effective May 13, 2015). No maintenance fees are required. **Key distinction from utility patents:** A design patent does not preclude others from achieving the same functional result through a different visual design. A competitor who builds a UI that performs the same function but looks different has not infringed a design patent. **International variation:** The Hague Agreement (Geneva Act) provides a mechanism for a single international application covering industrial design protection in multiple member countries. Protection periods vary: EU — 25 years (5-year renewable terms); Japan — 25 years from filing; China — 15 years from filing; UK — up to 25 years (5-year renewable terms); India — 10 years (renewable for a further 5). --- ### Chapter 4 — Copyright **What it protects:** Original works of authorship fixed in a tangible medium. 17 U.S.C. § 102. Copyright protects expression, not the underlying idea, procedure, process, system, or method of operation. 17 U.S.C. § 102(b); *Baker v. Selden*, 101 U.S. 99 (1880). **For software companies:** Copyright protects source code and object code; software documentation and technical specifications; API definitions and documentation; UI layouts and screen displays to the extent non-functional; data compilations where the selection and arrangement reflects original judgment (*Feist Publications, Inc. v. Rural Telephone Service Co.*, 499 U.S. 340 (1991)); training datasets to the extent original expression is involved; and marketing materials, reports, and written analyses. **Automatic protection:** Copyright vests upon creation and fixation. No registration is required for the right to exist. **Registration — a closer look at what it gates:** For U.S. works, registration is a prerequisite to filing a civil infringement suit in federal court. 17 U.S.C. § 411(a); *Fourth Estate Public Benefit Corp. v. Wall-Street.com, LLC*, 586 U.S. 296 (2019). For works from Berne Convention countries, registration is not required to bring suit, but remains relevant for remedies. Statutory damages — ranging from $750 to $30,000 per work for non-willful infringement, and up to $150,000 per work for willful infringement — and attorneys' fees are available only where registration was made either before infringement commenced or within three months of first publication of the work. 17 U.S.C. §§ 412, 504(c). Without timely registration, a plaintiff is limited to actual damages and the infringer's profits attributable to the infringement — a standard that is frequently difficult to satisfy in software disputes. A company that commercializes significant software products without a registration program may find itself with limited practical remedies when infringement occurs. **Duration:** Life of the author plus 70 years for individual works. For works made for hire, 95 years from the year of first publication OR 120 years from the year of creation, whichever expires first. 17 U.S.C. § 302(c). **International:** Berne Convention member countries extend automatic copyright protection without registration formalities. Duration varies across jurisdictions — U.S. and EU generally apply life plus 70 years; some countries apply the TRIPS minimum of life plus 50 years. See Chapter 16 of Part III for the treatment of moral rights, database rights, and mandatory local rules that affect software copyright in cross-border transactions. --- ### Chapter 5 — Trade Secrets **Statutory definition (DTSA):** A trade secret is information of any type — financial, business, scientific, technical, economic, or engineering — including patterns, plans, compilations, program devices, formulas, designs, prototypes, methods, techniques, processes, procedures, programs, or codes, in any form, provided that: 1. The owner has taken *reasonable measures* to keep the information secret; **and** 2. The information derives *independent economic value*, actual or potential, from not being generally known to, or readily ascertainable through proper means by, another person who can obtain economic value from its disclosure or use. 18 U.S.C. § 1839(3) (Defend Trade Secrets Act of 2016). State law protection remains available and is not preempted by the DTSA. 18 U.S.C. § 1838. **For software companies:** Trade secrets are the broadest category of protectable IP for software companies. They encompass model weights, parameters, and training methodology; data processing methods and enrichment logic; fraud detection rules and thresholds; platform architecture; customer lists and usage patterns where secrecy is actively maintained; and pricing models and customer-specific configurations. **The reasonable measures element has direct contractual significance:** Unlike patents or copyrights, trade secret protection does not arise from registration or a government grant. It depends on the owner's conduct. Non-disclosure agreements (NDAs), access controls, employee training, and contractual confidentiality obligations are not supplementary precautions — they are elements of the cause of action. A court finding that a company failed to take reasonable measures may defeat a trade secret claim regardless of the economic value of the information at issue. **No expiration:** Trade secret protection persists as long as secrecy is maintained. Once information enters the public domain — through disclosure, publication, or independent discovery — protection is lost permanently. **Misappropriation:** The DTSA defines misappropriation as acquisition by improper means or disclosure and use without consent. 18 U.S.C. § 1839(5). Improper means include theft, bribery, misrepresentation, and breach of a duty to maintain secrecy. Reverse engineering of a lawfully obtained product is expressly not misappropriation under the DTSA. 18 U.S.C. § 1839(6)(B). **International:** TRIPS Agreement Art. 39 obliges World Trade Organization (WTO) member countries to protect undisclosed information meeting comparable criteria. The EU Trade Secrets Directive (2016/943) harmonized protection across EU member states. Enforcement mechanisms and available remedies vary considerably by jurisdiction. See Chapter 16 of Part III. --- ### Chapter 6 — The Lanham Act: A Larger Bundle Than "Trademark" The Lanham Act encompasses a broader set of rights than the trademark label suggests. The following provisions may each appear in or affect a software company's commercial contracts: **15 U.S.C. § 1114 — Registered Trademark Infringement** Protects registered marks against likelihood of confusion as to source, sponsorship, or affiliation. **15 U.S.C. § 1125(a)(1)(A) — False Designation of Origin / Trade Dress / Unregistered Marks** Extends confusion-based protection to unregistered marks and trade dress — the total image and overall appearance of a product or service, including visual design elements, where those elements are non-functional and distinctive. **15 U.S.C. § 1125(a)(1)(B) — False Advertising** A civil cause of action for false or misleading representations of fact about one's own or a competitor's goods, services, or commercial activities. Mark ownership is not required — standing to bring a false advertising claim is broad. **15 U.S.C. § 1125(c) — Trademark Dilution** Protects famous marks against uses that dilute by blurring (weakening distinctiveness) or tarnishment (unsavory association), regardless of likelihood of confusion. **15 U.S.C. § 1125(d) — Anticybersquatting Consumer Protection Act (ACPA)** Addresses bad-faith registration of domain names identical or confusingly similar to, or dilutive of, a protected mark. **15 U.S.C. § 1125(a) — False Endorsement** A federal cause of action arising when a person's identity — name, voice, likeness, or other recognizable persona element — is used in commerce in a way likely to cause consumer confusion about endorsement or affiliation. This provision is the federal analog to state right of publicity law. *Waits v. Frito-Lay, Inc.*, 978 F.2d 1093 (9th Cir. 1992). **Right of Publicity (state law):** The right to control commercial use of one's name, image, likeness, and in some states voice. There is no federal right of publicity statute. State protections vary significantly in scope and duration, and some states treat the right as a property interest that survives death. This right is particularly relevant to vendor contracts involving content generated by artificial intelligence (AI), synthetic personas, digital avatars, and any use of individual identity in commercial contexts. See Chapter 10 of Part III for the AI-specific treatment. **Moral Rights:** 17 U.S.C. § 106A (Visual Artists Rights Act, VARA) provides attribution and integrity rights in the U.S., but only for works of visual art — not software. In EU member states and many civil law countries, moral rights attach more broadly and are frequently inalienable — meaning they cannot be waived or transferred by contract regardless of what the agreement provides. This distinction has material implications for software development contracts with European counterparties. See Chapter 16 of Part III. **For commercial contracts work:** Co-branding provisions implicate § 1114 and § 1125(a). Marketing exhibit language may implicate false advertising under § 1125(a)(1)(B). Vendor contracts involving AI-generated content, digital avatars, or use of individual identities implicate false endorsement and state right of publicity law. **International trademark framework:** The Madrid Protocol provides a mechanism for international trademark registration through the World Intellectual Property Organization (WIPO); the Paris Convention establishes priority rights and national treatment; TRIPS sets minimum standards for WTO member countries; the European Union Trade Mark (EUTM) provides a single registration covering all 27 EU member states. Trademark rights are territorial — registration in the U.S. provides no protection in India, Brazil, or the EU absent separate filings. See Chapter 16 of Part III. --- ### Chapter 7 — The Bundle of Rights IP ownership is not a binary state. It is a bundle of discrete rights that can be divided, limited, and licensed independently. Understanding how the bundle is carved in any given contract is the core analytical task in commercial IP review. Every IP license defines the transaction along several dimensions simultaneously: | Dimension | Questions to Ask | |---|---| | **Subject matter** | Which IP types are covered? Patents only? Copyright only? Trade secrets? All of the above? | | **Scope of rights** | What can the licensee do? Make? Use? Sell? Import? Reproduce? Distribute? Create derivative works? | | **Field of use** | Is use limited to a specific industry, application, or purpose? | | **Territory** | Which countries or regions are covered? | | **Exclusivity** | Is the license exclusive (only the licensee may use), non-exclusive, or sole (licensor retains use but grants no other licenses)? | | **Sublicensability** | Can the licensee sublicense to affiliates? To customers? Only with licensor consent? | | **Duration** | Does the license have a fixed term, or is it perpetual? What triggers termination? | | **Revocability** | Under what conditions may the licensor revoke? With what notice? | | **Modification rights** | May the licensee modify or create derivative works? Who owns the modifications? | A license grant that appears broad in one sentence may be severely restricted by what it omits. A worldwide license that is silent on sublicensing conveys no sublicense right. A license to "use" software that is silent on modification conveys no right to create derivative works. Reading a license grant requires attention to both what is expressly granted and what is absent. --- ### Chapter 8 — The Bundle in Practice: A Software Company Example Consider GlobalTech Int'l, a fictional international software company that develops and licenses a fraud detection API to financial institutions. A single product of this type may involve at least four distinct layers of IP protection: | IP Type | What It Covers | Contract Implication | |---|---|---| | Utility Patent | The method of fraud scoring — the process claims covering how the analysis is performed | A customer license that is silent on sublicensing does not authorize the customer to deploy the method in business units outside the licensed application | | Copyright | The source code implementing the method; the API documentation | A license that is silent on modification does not authorize the customer to modify the code or integrate it into a derivative product | | Trade Secret | Model weights, training data methodology, scoring thresholds, decision logic | These are not granted — they are protected by the contract's confidentiality provisions, which survive termination | | Trademark | The product name and branding | The customer's right to use the product name in marketing materials is a separate grant, typically negotiated in a marketing exhibit or co-branding schedule | When a counterparty licenses a product like this, it receives only what the contract expressly grants. Everything else is retained. The precision of the license grant — and the clarity of the confidentiality provisions protecting what is not granted — is where IP value is either preserved or quietly transferred. --- ### Chapter 9 — Infringement Standards Vary by IP Type A broad IP indemnification clause covering "any IP claim" may appear to provide uniform protection across patent, copyright, trademark, and trade secret claims. In practice, these are fundamentally different causes of action — with different elements, different defenses, and different damages frameworks — and understanding those differences produces more accurate risk allocation in negotiations. **Patent Infringement — 35 U.S.C. § 271** Direct patent infringement is strict liability — intent is not an element. A party infringes by making, using, selling, offering for sale, or importing a patented invention without authorization, regardless of whether it knew the patent existed. The scope of infringement is determined by the patent's claims, as construed by the court as a matter of law. Infringement may be literal (every claim element present in the accused product or method) or may be found under the doctrine of equivalents (each element present in a substantially similar way, performing substantially the same function, in substantially the same way, to achieve substantially the same result). *Warner-Jenkinson Co. v. Hilton Davis Chemical Co.*, 520 U.S. 17 (1997). **Copyright Infringement — 17 U.S.C. § 501** Copyright infringement requires two elements: (1) ownership of a valid copyright in the work; and (2) copying of protected expression — meaning either verbatim reproduction or, more commonly, access plus substantial similarity between the protectable expression in the copyrighted work and the accused work. Ideas, processes, and systems are not protectable expression — only the particular expression chosen to convey them. 17 U.S.C. § 102(b). *Computer Associates International, Inc. v. Altai, Inc.*, 982 F.2d 693 (2d Cir. 1992) (abstraction-filtration-comparison test for software copyright). Intent is not required for liability, but willfulness affects the damages range. **Trademark Infringement — 15 U.S.C. § 1114 / § 1125(a)** The standard is likelihood of confusion as to source, sponsorship, or affiliation, assessed under a multi-factor test. The Second Circuit applies the *Polaroid* factors (*Polaroid Corp. v. Polarad Electronics Corp.*, 287 F.2d 492 (2d Cir. 1961)); the Ninth Circuit applies the *Sleekcraft* factors (*AMF Inc. v. Sleekcraft Boats*, 599 F.2d 341 (9th Cir. 1979)). Relevant factors include the strength of the mark, proximity of goods or services, similarity of the marks, evidence of actual confusion, marketing channels used, and the sophistication of the relevant buyers. Dilution under § 1125(c) applies a different standard — likelihood of dilution by blurring or tarnishment of a famous mark, without regard to likelihood of confusion. **Trade Secret Misappropriation — 18 U.S.C. § 1836 / UTSA** A trade secret claim has two components: (1) the information qualifies as a trade secret under the applicable definition; and (2) the defendant misappropriated it — meaning acquired it by improper means, or disclosed or used it without consent. 18 U.S.C. § 1839(5). Trade secret claims differ from other IP claims in several respects. There is no registration to cite — the claimant bears the burden of proving at the time of misappropriation that the information met the statutory definition, including that reasonable measures were taken to maintain secrecy. Courts require that the trade secret be identified with "reasonable particularity" before discovery begins. And the "reasonable measures" element is a continuing obligation — conduct before or after the misappropriation that weakens the secrecy argument may undermine the claim. **Why infringement standards matter for contracts:** The applicable standard determines what a counterparty asserting an IP claim is required to prove under the applicable statute and what exposure a company faces under an indemnification clause. Patent infringement is strict liability — a company can infringe without knowledge or intent. Copyright infringement requires actual copying — an independent developer who writes functionally identical code without access to the original has not infringed. Trade secret misappropriation requires improper means — a competitor who reverse engineers a lawfully obtained product has not misappropriated. These distinctions are not interchangeable. Drafting and negotiating indemnification provisions with the specific standard in mind produces more accurate risk allocation. --- ### Chapter 10 — Indirect Infringement and Divided Infringement Direct infringement — a single party performing all elements of an infringing act — is relatively straightforward. The more complex exposure in software contracts arises from indirect infringement and the terrain of divided infringement, particularly in international deployments. **Indirect Infringement — U.S.** *Induced Infringement (35 U.S.C. § 271(b)):* Liability for actively inducing another party to directly infringe. The elements are: (1) direct infringement by a third party; (2) the defendant's knowledge of the patent; and (3) specific intent to encourage infringement. *Global-Tech Appliances, Inc. v. SEB S.A.*, 563 U.S. 754 (2011). Willful blindness to the existence of a patent may satisfy the knowledge element. *Contributory Infringement (35 U.S.C. § 271(c)):* Liability for selling or supplying a component of a patented combination, knowing that the component is especially made or adapted for use in infringing the patent and has no substantial non-infringing use. *Aro Manufacturing Co. v. Convertible Top Replacement Co.*, 377 U.S. 476 (1964). *Copyright — Contributory and Vicarious Infringement:* Contributory copyright infringement arises from knowingly inducing, causing, or materially contributing to another party's infringement. *Gershwin Publishing Corp. v. Columbia Artists Management, Inc.*, 443 F.2d 1159 (2d Cir. 1971). Vicarious copyright infringement arises from financial benefit from infringement combined with the right and ability to supervise the direct infringer — intent is not required. *Fonovisa, Inc. v. Cherry Auction, Inc.*, 76 F.3d 259 (9th Cir. 1996). **Contract Implications of Indirect Infringement:** A company that provides a tool or platform that a customer uses to infringe may face contributory or induced patent infringement liability even where the company's own product does not directly infringe. Vendor contracts should include representations that the vendor has no knowledge of pending or threatened patent claims against the licensed technology — because knowledge of a patent is an element of induced and contributory infringement liability, and that knowledge transfers through the contractual relationship. Indemnification provisions should address whether indirect infringement claims arising from the customer's use of the licensed product are covered, and if so, under what conditions. **Divided Infringement (Joint Infringement)** A patent claim may require multiple steps or elements. Where no single party performs all steps, infringement may depend on the combined conduct of two or more parties. Under U.S. law, direct infringement of a method claim requires that a single entity either perform all steps or direct and control a third party's performance of the remaining steps. *Akamai Technologies, Inc. v. Limelight Networks, Inc.*, 797 F.3d 1020 (Fed. Cir. 2015) (en banc). Liability may also arise where parties act as part of a joint enterprise collectively performing all steps. Divided infringement analysis varies across jurisdictions. EU member states apply their own national patent laws, and there is no harmonized standard equivalent to the *Akamai* framework. In the UK, Germany, France, and the Netherlands — the primary European patent litigation venues — multi-party infringement is assessed differently, with varying approaches to which party's conduct is attributed to which other party. For API-based software deployments where a licensor performs certain processing steps remotely on behalf of a licensee, the license grant should expressly authorize the licensor's performance of those steps to avoid creating a circular liability issue. API contracts where one party's servers perform processing steps that are part of a licensed method claim need to address the allocation of patent license rights across the distributed architecture. --- --- ## Part II — When to Escalate to IP Counsel Part I supplies the vocabulary. Part III supplies the clause-by-clause library. This Part answers the threshold question first: which deal patterns are worth escalating to IP counsel before signing, and which are not? Most routine commercial agreements can be closed by contracts counsel. IP issues that do matter are considerably less expensive to address at the drafting stage than at the dispute stage. A contract that has already been executed with a patent-timing miss, a silent AI training grant, or a federal data-rights mistake is a harder problem than the same issue at the redline stage. The goal here is a practical screen: escalate when the pattern fits. Routine deals can usually stay with contracts counsel. When a deal is flagged, Chapters 4 and 5 cover the context that changes the advice and how to engage IP counsel so the review is usable — including the IP Counsel Request Form in Appendix A. Part III is where to dig into the specific provisions. --- ### Chapter 1 — Triggers: Deal Patterns That Warrant IP Review Most commercial contracts do not need a separate IP review. A routine renewal, a standard hosted-software subscription with ordinary license and confidentiality terms, or a one-way NDA covering ordinary business discussions can usually be closed by contracts counsel using the company’s playbook. IP counsel adds the most value when the deal creates a patent-timing problem, moves technology or data in a way that standard forms do not allocate well, or puts the company into a regulatory IP regime (especially U.S. government contracting). The flowchart is a screen. If none of the “yes” paths apply, escalation is usually unnecessary. ```mermaid flowchart TD Start[Contract under review] --> Routine{Is this a routine deal?<br/>Ordinary renewal, standard hosted<br/>software, or boilerplate NDA<br/>with no unusual IP terms?} Routine -->|Yes| Stop[Contracts counsel can usually<br/>close without IP escalation] Routine -->|No| Screen[Ask the screening questions below] Screen --> Q1{Will this commercialize a new<br/>company product or publicly<br/>disclose new technology?} Q1 -->|Yes| E1[Escalate: patent filing timing] Q1 -->|No| Q2{Is the company licensing in technology<br/>in a field where it already has<br/>its own related development?} Q2 -->|Yes| E2[Escalate: provisional filing before<br/>receiving confidential information] Q2 -->|No| Q3{Does the deal involve training data,<br/>model rights, feedback loops, or a<br/>platform that publishes AI content?} Q3 -->|Yes| E3[Escalate: data, model, and<br/>output ownership allocation] Q3 -->|No| Q4{Will the company embed the other<br/>party's technology in something it<br/>sells — or grant bulk API access?} Q4 -->|Yes| E4[Escalate: indemnity, sublicense,<br/>and extraction risk] Q4 -->|No| Q5{Is this a U.S. Government contract,<br/>federal subcontract, or SBIR/STTR work?} Q5 -->|Yes| E5[Escalate: federal data rights<br/>and invention rules] Q5 -->|No| Q6{Custom development with an<br/>improvements or ownership fight,<br/>or delivery of source code?} Q6 -->|Yes| E6[Escalate: preexisting vs.<br/>new IP ownership] Q6 -->|No| Q7{Is there a non-standard IP fight:<br/>open source exclusion, co-branding,<br/>or cross-border terms that may<br/>override negotiated caps?} Q7 -->|Yes| E7[Escalate: targeted IP issue] Q7 -->|No| Stop ``` **When to escalate — readable checklist** **New product about to go to market.** If this is the first commercial contract for a new product or feature, ask whether anyone has considered patent protection before the product is publicly described, demonstrated, sold, or put into commercial use. The United States may still allow filing for up to a year after the company’s own disclosure. Many other markets — including Europe — treat that same disclosure as immediately fatal to patentability. If international rights matter, the filing decision often has to come before launch, not after. This timing problem is discussed in more detail below. **Inbound license in a field where the company already builds.** If the company is about to take a license to a vendor’s technology in an area where the company has already developed related capability, escalate before confidential information is exchanged. Filing a provisional patent application that captures the company’s existing technology *before* the vendor’s disclosures arrive creates a clean record of what the company already owned. Waiting until after those disclosures makes it easier for the vendor to argue that a later patent filing was based on the vendor’s confidential ideas, or that the filing itself breached confidentiality. This problem is discussed in more detail below. **AI, training data, and model improvement.** Escalate when the contract lets a vendor use the company’s data, prompts, corrections, or telemetry to train or improve a shared model — or when the contract is silent on that point. Silence usually favors the vendor. The company benefits from an express choice: no training use; a narrow exception limited to operating this customer’s instance; or priced permission with clear ownership or license-back terms. The same review is worth considering when the company operates a platform on which customers generate and publish AI content: who owns the outputs, what the acceptable-use rules are, and how upstream and downstream infringement risk is allocated are all worth spelling out rather than leaving to a generic software form. **Embedding someone else’s technology in a product the company sells.** If vendor technology will be built into a product or service the company sells to others, the license grant, sublicense rights, and infringement indemnity have to work together. A license that does not allow the downstream use, or an indemnity that falls away when the technology is combined with the company’s code, can leave the company exposed to its own customers. Bulk or high-volume API access raises a related problem: a counterparty may be able to extract or recreate model behavior through intensive querying. Rate limits and restrictions on using outputs to train competing systems usually matter more than a generic reverse-engineering ban. **U.S. Government and SBIR/STTR work.** Direct federal contracts, subcontracts that flow federal clauses down, and commercial licenses that will be delivered into a federal program are not ordinary commercial IP deals. Government rights in technical data and software, required markings, commercial-item characterization, and invention-disclosure duties under Bayh-Dole need review before signing and before development starts. Negotiation effort is usually better spent on delivery scope, commercial-item characterization, and priced rights adjustments than on trying to delete mandatory clauses the Contracting Officer cannot waive. SBIR and STTR awards have their own data-rights timeline and should not be assumed to follow the ordinary mixed-funding rules. **Custom development and source-code delivery.** When the deal funds custom development, co-development, or an “improvements” clause, escalate to draw a clear line between preexisting company IP and newly developed IP — and to make sure customer-funded work does not silently vest in the vendor through broad improvements language. Source-code or detailed technical delivery also changes the risk picture: the recipient can inspect more, so broad “we know nothing” representations and undifferentiated indemnities may need to be aligned with what was actually disclosed. **A few clause fights that are worth a specialist look — not every clause fight.** Ordinary pushback on confidentiality, audit, or indemnity wording does not by itself require IP counsel. Escalation is more likely to pay off when the draft stacks an unqualified non-infringement warranty on top of a full third-party IP indemnity for the same risk; when an open-source exclusion is written broadly enough to narrow patent and copyright coverage materially; when co-branding or marketing rights involve someone else’s marks or a real person’s name, image, or voice; or when cross-border mandatory rules may void a negotiated liability cap or create non-waivable moral-rights or interoperability issues that the form ignores. Those are specific problems — not a sign that every contract needs a full IP pass. --- ### Chapter 2 — The Provisional Patent Window A recurring pattern in software company contracting warrants specific attention: the company is about to license in a third-party tool or technology in a space where the company has already developed — or is developing — related capability of its own. **What this signals, and why filing before disclosure matters:** The inbound license will almost always be accompanied by a confidentiality obligation. Once the vendor's confidential information is in hand, the company's engineers will have seen the vendor's approach, architecture, interfaces, or know-how. If the company later files a patent application covering technology in that same space, inventorship and derivation become harder to prove cleanly. The question shifts from "what did we invent?" to "can we show that this application reflects our pre-existing work rather than the vendor's confidential disclosures?" A provisional patent application filed *before* the company receives the vendor's confidential information creates a contemporaneous record of what the company already owned. That record is far easier to defend than a post-disclosure reconstruction of inventorship from lab notebooks, commit histories, and engineer recollection. Waiting until after confidential information is received creates concrete complications: - The vendor may argue that the patent application was based on its confidential ideas — that the company derived the claimed invention from the disclosure rather than from its own prior work - The vendor may argue that filing the application *disclosed* the vendor's confidential information and therefore breached the NDA or confidentiality clause — even if the company believes the filing covers only its own technology - Distinguishing the company's pre-existing contribution from the vendor's disclosed material becomes a factual fight the company would rather not have, especially if the relationship later sours or the company builds a competing product **Best practice:** If the company has developed technology in the space of a contemplated inbound license, file a provisional covering that technology before the contract is signed and before confidential information is received. The provisional need not be the final claim set; it needs to capture what the company already has, with enough technical detail to support a later non-provisional that claims priority to it. **The sequence:** 1. Flag the inbound license to IP counsel before execution — and before diligence materials or technical disclosures under NDA begin in earnest 2. IP counsel assesses whether the company has developed, or is developing, technology in the same space 3. If yes: file a provisional patent application covering the company's existing technology *before* receiving the vendor's confidential information 4. The provisional establishes a U.S. priority date and a dated record of ownership; the company then has 12 months to decide whether to file a non-provisional 5. Proceed with the license; subsequent development can be evaluated against the provisional baseline rather than reconstructed after the fact **Why the timing is the whole point:** The value of the provisional in this scenario is not primarily that it starts a patent clock for a future product. It is that it freezes a picture of the company's technology *before* the confidentiality relationship contaminates the inventorship narrative. Filing after confidential information is received is still sometimes necessary — but it is a weaker and more contested posture than filing first. --- ### Chapter 3 — New Products: The Patent Filing Window Any contract commercializing a new product or service reflects a business judgment that the product has market value. Commercial value and patent value are not identical — but commercial significance is frequently a signal that patentability is worth assessing before the product is publicly disclosed, offered for sale, or put into commercial use. Contracts counsel is often in the best position to notice when a new product is heading to market before the product team has considered IP protection, and sometimes before any public disclosure that starts — or closes — the filing window. The contracting stage is often the last structured moment at which someone outside the product team can ask whether a filing decision has been made. Once the product is live, demonstrated, sold, or described in enough detail to enable others to practice it, the international patent position may already be compromised. **The questions worth raising at first sight of a new product contract:** - Is this technology patentable, and has anyone assessed that question? - Has there been — or will this contract itself cause — a public disclosure, public use, offer for sale, or commercial launch? - Is a provisional (or non-provisional) patent application warranted *before* that disclosure or launch? - Does the company need protection outside the United States? If so, U.S. grace-period assumptions alone may not be sufficient. --- **What “prior disclosure” means in practice for software companies** For software and SaaS businesses, the damaging disclosure is rarely a published academic paper. It is more often: - A public product launch, website feature description, or press release that enables a skilled reader to understand the invention - A trade-show demo, investor pitch deck, or sales presentation that discloses how the system works - A beta or commercial deployment that puts the invention into public use - An **offer for sale** or commercial sale — including a signed customer contract, quote, or purchase order for the inventive product or method — even if delivery has not yet occurred - Publication of technical documentation, API specs, or white papers that teach the inventive concept Any of these can start a U.S. clock, destroy novelty in absolute-novelty countries, or both. The contracts attorney who is negotiating the first commercial agreement for a new capability is often closest to the event that creates the bar. --- **United States: grace period, but with real bars** Under the America Invents Act, a person is entitled to a patent unless the claimed invention was patented, described in a printed publication, in public use, on sale, or otherwise available to the public before the effective filing date. 35 U.S.C. § 102(a)(1). Separately, U.S. law provides a **one-year grace period** for certain disclosures by the inventor (or by another who obtained the subject matter from the inventor): those inventor-originated disclosures within the year before filing are not prior art against the inventor’s own application. 35 U.S.C. § 102(b)(1). What that means in practice: - The inventor’s **own** public disclosure, public use, or commercial activity can still destroy U.S. patentability if more than one year passes before filing - An **offer for sale** or sale of the inventive product can bar patentability even without a technical paper — the commercial act itself can be the prior art event. The U.S. on-sale bar is a real commercial-contracting issue, not just a publication issue. See *Pfaff v. Wells Electronics, Inc.*, 525 U.S. 55 (1998); *Helsinn Healthcare S.A. v. Teva Pharmaceuticals USA, Inc.*, 586 U.S. 123 (2019). - **Public use** of the invention (including certain commercial uses) can likewise start the clock - Third-party independent disclosures are generally prior art immediately; the grace period is primarily about the inventor’s own (or inventor-derived) disclosures The U.S. grace period is therefore a safety net, not a filing strategy. Relying on it assumes the company will file within twelve months of the first qualifying disclosure — and it does **not** preserve rights in countries that treat the same disclosure as novelty-destroying from day one. --- **Absolute novelty: Europe and similar regimes** Many significant markets — including protection through the European Patent Office (EPO) under the European Patent Convention — apply **absolute novelty**. Under that standard, an invention is not novel if it was made available to the public anywhere in the world, in any way, before the filing (or priority) date. EPC Article 54(2). The inventor’s own disclosure counts the same as a stranger’s. There is no general twelve-month forgiveness for a product launch, sale, demo, or website publication. Europe’s statutory exceptions are narrow. Under EPC Article 55, a disclosure is typically disregarded only if it occurred no earlier than six months before filing and resulted from (a) an evident abuse in relation to the applicant, or (b) display at a very limited set of officially recognized international exhibitions — not ordinary trade shows, customer pilots, or SaaS launches. For contracting purposes, treat Europe as: **file before any public disclosure.** China likewise has no general grace period for ordinary commercial disclosures. Its limited six-month exceptions (for example, certain recognized international exhibitions, specified academic or technological meetings, public-interest disclosures during a state emergency or extraordinary situation, or disclosure without the applicant’s consent) do not cover a normal product launch or customer sale. China Patent Law Art. 24. Other jurisdictions have their own versions of this same problem: an inventor’s own commercial disclosure may count against the inventor unless a local grace-period rule squarely applies. --- **Grace-period jurisdictions outside the United States (still not interchangeable)** Some countries provide a grace period resembling the U.S. model, but the length, covered acts, and procedural requirements differ. Common examples contracts counsel will encounter: - **Canada** — generally a twelve-month grace period for disclosures made by the applicant or by someone who obtained knowledge from the applicant. Canada Patent Act § 28.2(1)(a). - **Japan** — a grace period is available for certain inventor-originated disclosures, generally within one year before filing, but the applicant must claim the exception and submit supporting documentation. Japan Patent Act Art. 30. - **Australia, South Korea, and several others** — grace periods exist, often twelve months, but local definitions of what counts as a protected disclosure vary. Treat these as “ask local patent counsel before relying on the grace period,” not as U.S.-style safe harbors. A U.S. grace-period filing plan does **not** automatically map onto these regimes. Even where a foreign grace period exists, missing a local procedural step can forfeit it. --- **When the inventor’s own work defeats patentability — country-by-country framing** | Jurisdiction type | Can the inventor’s own prior disclosure, sale, or public use defeat patentability? | Practical contracting implication | |---|---|---| | **United States** | Yes — after one year from the inventor’s own disclosure / public use / on-sale event. Within one year, inventor-originated disclosures are generally sheltered by § 102(b)(1). | First commercial contract, offer, or public launch starts a one-year U.S. clock. Note the filing deadline in the deal calendar. | | **Europe (EPO / absolute novelty)** | Yes — immediately. The inventor’s own public disclosure is prior art against the inventor from day one, subject only to narrow Art. 55 exceptions. | If European rights matter, consider a priority filing before launch, public demo, sale, or publication of enabling detail. | | **China (and similar absolute-novelty markets)** | Yes — immediately for ordinary commercial disclosures. Limited statutory exceptions do not rescue a normal SaaS launch. | Same practical timing as Europe for commercial go-to-market events. | | **Canada / Australia / Korea-type grace periods** | Yes — but usually only after the local grace period expires, and only if the disclosure qualifies and any required formalities are met. | Confirm local rules before assuming U.S. timing carries over; a grace period in one country does not automatically protect filings everywhere. | | **Japan** | Yes for unprotected disclosures; inventor-originated disclosures may be excludable if the grace-period procedure is followed. | Filing first is the safer path; if disclosure comes first, involve patent counsel to preserve the Japanese exception. | The unifying point for contracts counsel: **the company’s own commercialization can become prior art that defeats patentability.** In absolute-novelty countries, that can happen the day of the first enabling public disclosure or commercial offer. In the United States, it happens one year later — which is still a short window in a product launch cycle. --- **How companies treat prior disclosure in practice** Sophisticated software companies with international patent programs typically adopt a **file-before-disclose** rule for anything that might need protection in Europe, China, or other absolute-novelty markets. They treat the U.S. grace period as backup for accidental or unavoidable U.S.-only disclosures — not as the plan. Teams without an international filing plan sometimes assume “we have a year in the U.S.” and only later discover that European and Chinese rights were lost at launch. Contracts counsel can surface the issue without practicing patent prosecution by asking, early: 1. Will this agreement, press activity, or go-live make the technology public or put it on sale? 2. Has a provisional or priority application already been filed covering what is being commercialized? 3. Are European, Chinese, or other absolute-novelty filings part of the company’s plan? If the answers suggest a filing decision is needed, IP counsel can help before the disclosure event — not after. The conversation often takes only a short time at the contracting stage. In absolute-novelty jurisdictions, the window can close the day of first public disclosure. In the United States, it can close within twelve months of first public use, sale, or inventor disclosure. --- ### Chapter 4 — Context That Changes the Analysis IP review works best when it is calibrated to the deal, not applied as a generic checklist. The same contract provision may warrant different guidance depending on deal context. Whether to accept a capped IP indemnification depends on whether the company has one vendor option or several. Whether to push hard on an open source clause depends on whether the software is a peripheral tool or a core platform dependency. Whether to insist on audit rights depends on how much the company's proprietary data is involved and how vigorously the vendor is resisting. The more of the following context IP counsel has at the outset, the more useful the review tends to be: - **What the software or technology does, and how the company plans to use it** — whether it is a peripheral tool or a core platform dependency; whether it will be used only internally or embedded in something the company sells; whether it will touch customer data, train or improve models, or be combined with other systems. A field-of-use limit, combination carve-out, or data-rights clause that is harmless for internal use can be deal-breaking for a product the company plans to commercialize. With that context, IP counsel can focus on the provisions that actually matter. - **Who the other party is** — an end customer using the company's product; a company embedding or building on the company's technology; a vendor supplying technology to the company; a reseller, integrator, or channel partner; a co-development counterparty; or something else. The same license, indemnity, and data-rights language reads differently against each of those roles - **What kind of counterparty it is** — relative size, legal sophistication, in-house IP capability, and market power in its sector. A Fortune 50 platform with a non-negotiable paper is a different problem from a mid-market vendor that will trade on IP terms, or from a startup end user with little leverage and little counsel - **What the business consequence is if the deal does not close** — whether this is a nice-to-have tool, a committed customer launch date, a regulatory or contractual dependency for another deal, or a relationship the business considers must-win. Advice that assumes unlimited time and willingness to walk away is much harder to apply when the business needs to sign on a fixed date. The consequence of no-deal helps calibrate which IP points are worth holding and which should be recorded as accepted risk. - **What the company has already agreed to in principle** — pricing, go-live dates, “we’ll accept their paper,” side emails conceding indemnity caps or ownership, or a term sheet that already settled issues IP would otherwise reopen. IP analysis works best inside those commercial constraints. Where the business has already conceded a point, a targeted fix is usually more useful than a clean rewrite that reopens settled ground with the counterparty. - **What the company's negotiating leverage looks like, including whether alternatives exist** — sole-source vendor versus a competitive field; customer that needs the company’s product versus one with ready substitutes; renewing incumbent versus new relationship; time pressure on one side but not the other. Leverage determines whether to fight for non-standard IP terms, accept a capped or narrow indemnity, or escalate only the issues that are truly non-negotiable for the company’s risk profile. A short checklist of the same points, plus a few deal facts that often change the analysis: | Information | Why It Affects the Advice | |---|---| | What the software does | Determines which IP types are at risk and which provisions are most consequential | | How the company plans to use it | Defines the license scope actually needed; reveals whether field-of-use restrictions are problematic | | Who the other party is (end user, embedder/OEM, vendor, reseller, co-developer) | Changes whether the company is negotiating as licensor or licensee — and which risks are primary | | Counterparty size, legal sophistication, and market power | Calibrates what is realistically negotiable; a dominant platform’s paper is not a mid-market vendor’s paper | | Whether the company is reselling or integrating vendor technology into a company product | Changes the entire indemnification and sublicense analysis | | Whether the company has alternative counterparties | Determines negotiating leverage and how hard to push on non-standard terms | | The contract's dollar value and term | Calibrates which issues are worth the negotiating effort and which caps are commercially reasonable | | Whether the company's proprietary data is involved | Triggers data rights, confidentiality, and regulatory overlay analysis | | Whether the software uses AI/ML components | Triggers AI-specific analysis across training data, output ownership, and indemnification gaps | | Whether there is a cross-border element | Triggers choice of law, mandatory local rights, and ADR design analysis (Part III, Chapters 16–17) | | Whether it involves a U.S. Government prime contract or federal subcontract | Triggers FAR/DFARS rights, assertions, markings, and Bayh-Dole duties (Part III, Chapter 15) | | Whether it involves a new product | Triggers patent filing assessment (Part II, Chapter 3) | Chapter 5 turns to the practical question: how to engage IP counsel so that context produces usable advice on the negotiation calendar. --- ### Chapter 5 — Getting Help from IP Counsel Once a deal is flagged, the question is how to bring IP counsel in so the review is usable — and so the work can be scheduled and delivered on time. **Start with the IP Counsel Request Form.** Appendix A captures the context in Chapter 4, the deadline and specific request described below, and the screening flags from earlier in this Part. Completing it as best you can — and sending it with a marked-up draft — gives IP counsel a structured intake that makes it easier to stay organized, prioritize the matter against other work, and allocate the right time and depth. Incomplete answers are fine. Note what is unknown and send rather than delaying the request. The form is useful on every matter, whether or not a call follows. **Schedule a working call when you can.** The form is the foundation; a short call on top of it is usually the fastest path to usable redlines. Contracts counsel walks through deal context in a few minutes; IP counsel reads flagged provisions in real time and proposes specific language rather than abstract positions; contracts counsel pushes back on what the counterparty will accept; IP adjusts in real time. The output is specific redlines with agreed rationale — ready for the next negotiation turn. The completed form doubles as the agenda, so the call can go straight to the issues that matter. **Before the call (or with the written request):** Insert comments in the draft on provisions that feel uncertain — the comment does not need to be a legal analysis, only an identification of what feels important. Fill in the request form as fully as practical. Flag any commercial commitments already made, so IP can work within what the business has already agreed. Chapter 4 lists the context that usually matters most. **A concrete deadline helps more than it may seem.** IP counsel typically manages a large volume of matters with overlapping due dates across the year. Many individual reviews take only a few hours, but the work is constantly prioritized and reordered as new deals arrive and existing deadlines move. A request without a specific date makes prioritization harder. A specific deliverable and date — redline language by Thursday noon; a short risk note before Friday’s business call; comments on three flagged clauses before the next negotiation round — lets IP counsel schedule the work, match the depth of the response to the time available, and adjust if something more urgent arrives. If the real constraint is the business’s timeline, it helps to say that as well: for example, that the customer needs a response by Monday, and that a capped indemnity is acceptable if needed to meet that date. The request form has a dedicated field for this. **A specific request produces a more usable response.** A general invitation to “review the IP” leaves IP counsel to guess the intended output — a full memo, a few redlines, a risk assessment, or something else. Naming the form of help needed usually yields something contracts counsel can use immediately. Common examples (also listed as checkboxes on the form): - Draft redline language and a short explanation contracts counsel can send to opposing counsel - Join a Teams or Zoom call with opposing counsel on a specific IP issue - Review opposing counsel’s redlines and advise what is acceptable, what to push, and what to trade - Evaluate IP risk against a customer’s stated requirements or an RFP/SOW attachment - Confirm whether a proposed compromise creates patent, data-rights, open-source, or ownership exposure the business should accept consciously - Identify the issues that are worth holding if the deal must close on a fixed date A completed form, a concrete deadline, and a specific request together make it much more likely that the review fits the negotiation calendar and that the output is ready for the next turn with the counterparty. --- --- ## Part III — IP Issue Spotting in Commercial Contracts Once Part II’s screen flags a deal — or once contracts counsel already knows the clause fight is non-standard — this Part is the library. It identifies the contract provisions that commonly produce IP exposure for software companies. For each category, the analysis addresses what the provision is, what signals warrant escalation to IP counsel, and how the analysis differs depending on whether the company is the licensor or the licensee. The analysis is organized in seventeen chapters. A company that reviews an indemnification clause without separately reviewing the license grant may negotiate an excellent indemnification for a right it never adequately acquired. The analysis reflects three commercial postures: licensing to end users, licensing to other companies that embed or build on the technology, and in-licensing from vendors. The same provisions that protect the company in one posture often need different calibration — or cut against the company — in another, and negotiating positions appropriate for one role need to be adjusted for the others. --- ### Chapter Guide | Chapter | Topic | |---|---| | 1 | Ownership, Assignment & Work-for-Hire | | 2 | License Grant, Covenants & Use Restrictions | | 3 | Indemnification — As Licensor | | 4 | Indemnification — As Licensee | | 5 | Reverse Engineering | | 6 | Confidential Information & Trade Secrets | | 7 | Open Source Software | | 8 | Data Rights & Data Licensing | | 9 | AI Model Licensing & Contract Terms | | 10 | AI-Generated Content Liability | | 11 | Representations, Warranties & IP Accuracy | | 12 | Audit Rights & Source Code Escrow | | 13 | Competitive Restrictions | | 14 | Pre-Existing IP Clauses | | 15 | FAR & DFARS IP Rights: Preexisting IP and IP Developed Under Contract | | 16 | International IP Considerations & Choice of Law | | 17 | Alternative Dispute Resolution | --- ### Chapter 1 — Ownership, Assignment & Work-for-Hire #### Section 1 — What Ownership Provisions Are and Why They Exist Ownership and assignment provisions in commercial contracts address a default rule that frequently surprises the business: paying for the development of software does not automatically mean owning the result. Copyright and patent defaults apply unless the contract expressly overrides them. These provisions exist because IP rights are creatures of statute with fixed default rules. Copyright vests in the creator. Patent rights vest in the inventor. Neither right follows money automatically. A company that funds custom software development without addressing ownership in the contract may find that the vendor retains full copyright in the deliverable — and that the company has, at best, an implied license of uncertain scope. **The core default rules:** *Copyright:* Vests in the creator at the moment of creation and fixation. 17 U.S.C. § 201(a). An employer owns copyrights created by employees within the scope of employment — the "work made for hire" doctrine. 17 U.S.C. § 101 (first prong). But software delivered by an independent vendor under a services contract does not automatically qualify as work made for hire — the statutory categories of specially commissioned works for which work-for-hire can be agreed contractually do not include most software deliverables. 17 U.S.C. § 101 (second prong). The implication: without an express written assignment, the vendor retains the copyright. *Patents:* Rights vest in the inventor by operation of law. 35 U.S.C. § 261; *Stanford v. Roche*, 563 U.S. 776 (2011). An employer's rights to employee inventions arise from written assignment or employment agreement — not from the employment relationship itself. A vendor whose engineers invent something in the course of a services engagement retains the patent rights unless those rights are assigned in writing. *Assignment validity:* Patent assignments require a written instrument. 35 U.S.C. § 261. Copyright assignments require a writing signed by the assignor. 17 U.S.C. § 204(a). Oral assignments are ineffective for both. **Background vs. foreground IP:** Commercial agreements involving any development work benefit from distinguishing: - *Background IP:* What each party owned or had developed before the engagement — retained by each party regardless of what the contract creates - *Foreground IP:* What is created during the engagement — ownership determined by the contract Without this distinction, disputes arise about whether a deliverable is an original creation (foreground, owned by the commissioning party) or an enhancement of pre-existing work (background, retained by the vendor). --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Relying on work-for-hire language alone** Treating a work-for-hire clause as sufficient to convey ownership is a recurring problem in software contracts. Work-for-hire language works for employee-created software. For vendor-delivered software under a services contract, it frequently does not — the statutory categories for specially commissioned works are narrow and software development agreements typically do not fall within them. A contract that says "all work product is work made for hire" without including an assignment clause may leave ownership with the vendor if a court finds work-for-hire inapplicable. The appropriate approach: include both a work-for-hire clause and a broad assignment clause. The assignment clause assigns all IP rights in the deliverable to the commissioning party, to the extent work-for-hire is held inapplicable. Belt-and-suspenders drafting on ownership is not excessive — it reflects the statutory uncertainty. **2. Overlooking joint authorship** When both parties' engineers contribute to the same deliverable — a common pattern in integration projects, co-development arrangements, and vendor engagements where the customer's team participates — joint authorship may arise under copyright law. Joint authorship gives each co-owner the right to exploit the work independently, without the other's consent, and without accounting for profits. 17 U.S.C. § 201(a); *Childress v. Taylor*, 945 F.2d 500 (2d Cir. 1991). This is almost never the intended outcome. A vendor who is a joint author of software built on a customer's specifications can license that software to competitors without the customer's consent. The contract should address collaborative development specifically — either by allocating sole ownership to one party or by requiring the other to assign its interest. **3. Ignoring change of control on licensed IP** Patent rights and copyright licenses are frequently subject to anti-assignment clauses. When a vendor is acquired, the surviving entity generally succeeds to all contractual rights and obligations — but anti-assignment clauses may render licenses non-transferable without the licensee's consent. A company that discovers after closing that its vendor's acquisition has effectively transferred its technology license to a competitor — without triggering a consent right because the clause was inadequately drafted — has a serious problem. Anti-assignment clauses warrant careful review in both directions: whether the company's outbound licenses survive changes in ownership of the company's customers, and whether the company's inbound licenses survive changes in ownership of its vendors. **4. Treating the assignment clause as self-executing** An assignment clause that says "vendor hereby assigns all right, title, and interest in the deliverables to the company" is self-executing for copyright — the assignment occurs at signing. For patents, an assignment of future inventions is enforceable as a contractual obligation but may not automatically vest title — some courts require a separate, subsequent written instrument for each specific patent. For international work, the rules vary further. Confirm with IP counsel what additional steps are required to perfect title in the relevant jurisdictions. --- #### Section 3 — Negotiating as Licensee (Commissioning Development) As the party paying for development and expecting to own the result, the commissioning party should negotiate for: - **Full assignment of all custom-developed IP:** Both a work-for-hire clause and a broad present-tense assignment ("vendor hereby assigns") covering all IP created during the engagement, in all jurisdictions - **License-back to the vendor for background IP:** Where the deliverable is built on the vendor's pre-existing platform or tools, the vendor retains those background IP rights — but the company should receive an express license to use the vendor's background IP to the extent necessary to use, maintain, and modify the deliverable - **Inventions disclosure and assignment obligation:** Require the vendor to disclose any inventions made during the engagement and to assign them to the company — with individual inventor assignments from the vendor's employees where patent rights are at issue - **Joint development allocation:** If the company's engineers will contribute, address ownership expressly — do not allow joint authorship to arise by default --- #### Section 4 — Negotiating as Licensor (Delivering Development) As the party delivering development and retaining platform rights, the licensor should: - **Retain background IP expressly:** Define background IP specifically — the platforms, frameworks, libraries, and methodologies the vendor brings to the engagement — and confirm in the contract that background IP is retained by the vendor regardless of how it is incorporated into the deliverable - **License foreground IP rather than assigning:** Where the customer insists on ownership of deliverables, consider whether a broad perpetual exclusive license to the specific deliverable — with the vendor retaining ownership — better protects the vendor's ability to reuse methodologies across clients - **Limit the license-back scope:** If the vendor retains background IP and licenses it to the customer, the license should be narrowly scoped to the specific deliverable and the customer's internal use — not a broad license to use the vendor's platform independently - **Address ownership of improvements:** If the customer modifies the deliverable after delivery, who owns those modifications? The contract should answer this expressly --- #### Section 5 — Red Flags and When to Escalate - **The contract covers custom software development but lacks both a work-for-hire clause and an express assignment.** Under U.S. copyright law, a commissioned work is not automatically a work made for hire unless it falls within a narrow statutory category *and* the parties agree in a signed writing. Without both a work-for-hire designation (where available) and a backup assignment of all rights in the deliverable, the developer — not the paying party — may own the copyright. - **Both parties' engineers will contribute to the same deliverable (co-development).** Joint authorship and joint ownership rules can leave each party with undivided rights to exploit the whole work, or can produce disputes over who owns what. The contract needs an express allocation of ownership in jointly created materials before coding starts — not after the relationship sours. - **The vendor contract is silent on background IP, especially where the deliverable sits on the vendor's existing platform.** Silence leaves open whether the customer owns only a thin application layer or also claims rights in the vendor's frameworks, libraries, and methodologies. Define and schedule background IP expressly, and separate it from foreground deliverables the customer is paying to own or exclusively license. - **An acquisition or change-of-control transaction involves a target with inbound licenses that have not been reviewed for anti-assignment provisions.** Many inbound licenses terminate or require consent on assignment. If those licenses are material to the business, closing without that review risks losing rights the buyer assumed would transfer. - **The development engagement is international.** Assignment formalities, moral rights, employee invention statutes, and what constitutes a valid transfer vary by jurisdiction. A New York-style assignment clause may not clear title to work performed by engineers in France, Germany, or China without local-law mechanics. --- ### Chapter 2 — License Grant, Covenants & Use Restrictions #### Section 1 — What These Provisions Are and Why They Exist The license grant is the operative core of any IP-bearing contract. It defines precisely what the counterparty can do with the licensor's intellectual property — and, equally importantly, what it cannot do. Every dimension along which the grant is limited — by subject matter, field of use, territory, duration, exclusivity, sublicensability, or modification rights — defines a corresponding right that the licensor retains. The grant that appears broad may be severely restricted by what it omits. **Covenants not to sue** (also called covenants not to assert, or CNAs) are a distinct provision from licenses. A license conveys a bundle of rights that the licensee can affirmatively exercise. A covenant not to sue is a contractual promise that the IP owner will not bring a claim against the counterparty for specified conduct. The covenant conveys no rights — it is a personal promise, not a property interest. This distinction matters commercially and legally. **Use restrictions** are contractual limits on what the licensee can do with the licensed IP beyond what the license grant itself defines. They appear in vendor contracts as limitations on competitive use, output training, benchmarking disclosure, reverse engineering, and purpose of use. They are negotiated between licensor and licensee and may or may not correspond to legitimate licensor interests. --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Reading only what is granted, not what is absent** A license grant that says "non-exclusive, worldwide license to use the Software" may sound broad. It conveys no sublicense right — without express authorization, the licensee cannot pass the license to affiliates or customers. It conveys no modification right — the copyright owner holds the exclusive right to prepare derivative works under 17 U.S.C. § 106(2), and a silent grant does not include it.[^1] It may not cover all products — software licensed for one product may not authorize use in another. The correct analytical approach reads a license grant for what it does not say as much as for what it does. The question is not "what did the licensor give?" but "what did the licensor retain?" [^1]: Copyright is a divisible bundle of exclusive rights under 17 U.S.C. § 106 — reproduction, derivative works, distribution, public performance, and public display — and each right may be transferred separately. 17 U.S.C. § 201(d)(2). A grant of one right does not convey the others. See *ITOFCA, Inc. v. MegaTrans Logistics, Inc.*, 322 F.3d 928, 930 (7th Cir. 2003); *Automation by Design, Inc. v. Raybestos Products Co.*, 463 F.3d 749, 757–58 (7th Cir. 2006). Federal copyright cases generally read licenses as authorizing only the uses granted. See *S.O.S., Inc. v. Payday, Inc.*, 886 F.2d 1081, 1087–89 (9th Cir. 1989) (mere "right of use" did not authorize copying or preparing a modified version); *Gilliam v. American Broadcasting Cos.*, 538 F.2d 14, 20–21 (2d Cir. 1976) (use exceeding the license constitutes infringement). Courts may imply incidental rights needed to effectuate an express grant — for example, copying needed to distribute authorized copies — but that implication does not create a free-standing right to prepare derivatives or competing substantially similar works. **2. Accepting covenants not to sue on top of licenses** When acting as the licensor, accepting a customer request for a covenant not to sue alongside an existing license creates a structural problem: the covenant gives the customer a second avenue of protection beyond the license, allowing the customer to exceed the license scope and claim the covenant bars enforcement. The mechanics: a software company licenses its fraud detection product to a bank for consumer lending. The existing license authorizes consumer lending use — so any use within that scope is already non-infringing by operation of the license. If the bank separately obtains a covenant not to sue for copyright infringement, and the bank then deploys the software in its commercial lending division (outside the licensed field), the bank can argue that the covenant bars the copyright claim. The bank has used the license for its permitted use and the covenant to cover its unauthorized use. Two bites at the apple from one transaction. The correct response as licensor: make the license grant comprehensive enough to cover all intended uses and resist adding a covenant not to sue on top of a license covering the same IP. If the counterparty insists on a covenant, limit it expressly to conduct within the license scope — so the covenant adds nothing beyond what the license already permits. **3. Accepting use restrictions without mapping them to actual operations** Use restrictions in vendor contracts warrant review against operational impact, not legal form alone. A restriction that prohibits using licensed software "to develop, train, or improve any competing product or service" may seem like standard non-compete language — but it can prohibit the company's engineers from using the vendor's tool in a development environment where the company is simultaneously building its own capability. A restriction that limits use to a defined "purpose" may not cover adjacent uses — model validation, regulatory reporting, dispute resolution — that the business routinely performs. Use restrictions warrant review against actual operational use, not the abstract use case the business described at the term sheet stage. **4. Confusing anti-benchmarking clauses with reverse engineering prohibitions** Anti-benchmarking clauses — prohibiting disclosure of performance test results — are frequently bundled with reverse engineering prohibitions and reviewed as a single provision. They are distinct. A prohibition on reverse engineering addresses the method of analysis; an anti-benchmarking clause addresses what the company can say about the results of permissible testing. Both warrant separate review, and the anti-benchmarking clause warrants specific attention where the company has regulatory obligations that require sharing performance data with auditors, regulators, or customers. --- #### Section 3 — Negotiating as Licensee - **Broad field of use:** The field of use should cover the company's current use case and reasonably anticipated adjacent uses — not just the immediate deployment - **Affiliate and downstream sublicense rights:** Without express authorization, sublicensing is not permitted. Negotiate express rights to sublicense to affiliates and, where needed, to incorporate the licensed software into products sold to customers - **Modification and derivative works rights:** Negotiate express right to modify the software and create derivative works, with clear ownership allocation — modifications funded by the licensee should belong to the licensee - **Carve-outs from use restrictions:** Before accepting any use restriction, map it to the company's actual operations. If any restriction would prohibit current or planned activity, negotiate the carve-out before signing, not after - **Resist anti-benchmarking clauses where regulatory disclosure is required** --- #### Section 4 — Negotiating as Licensor - **Narrow field of use:** Tie the field of use to the specific contracted use case — not the customer's general business category. A license for "fraud detection in consumer credit" does not cover commercial lending, marketing analytics, or any other application - **No sublicense without consent:** Sublicense rights expand the universe of the licensor's IP exposure to parties the licensor did not select and cannot audit. Require written consent for sublicensing - **Modifications license back:** Where the customer is permitted to modify the software, ensure that modifications are licensed back to the licensor on a royalty-free basis — preserving the licensor's ability to incorporate improvements - **Resist CNAs:** As discussed above, do not grant covenants not to sue on top of license grants covering the same IP. The covenant converts a bounded license into a broader shield - **Anti-benchmarking and output restrictions:** For AI and analytics products, include restrictions on: using outputs to train competing models; disclosing benchmarking results to third parties without consent; and systematic querying for the purpose of replicating the licensed methodology --- #### Section 5 — Red Flags and When to Escalate - **The license grant does not expressly address sublicensing, and the company plans to pass rights to affiliates or customers.** Without express authorization, sublicensing is generally not permitted. Affiliates, subsidiaries, and customers who need to use the software will be outside the grant — and the company may be infringing by enabling that use. - **The counterparty asks for a covenant not to sue alongside an existing license covering the same IP.** That is the "two bites at the apple" problem described in Section 2: the license covers permitted use, and the covenant can be argued to bar enforcement of unauthorized use. As licensor, resist the stack; if a covenant is unavoidable, limit it expressly to conduct within the license scope. - **A use restriction references "development," "training," or "competing products" without checking the company's internal programs.** Language that sounds like a standard non-compete can prohibit engineers from using the vendor's tool in environments where the company is building its own capability, or from performing adjacent work such as model validation or regulatory reporting. Map the restriction to actual operations before signing. - **The license is silent on modification rights, but the company's engineers will integrate or customize the software.** The copyright owner's exclusive right to prepare derivative works is not conveyed by silence. Integration and customization that create derivative works can exceed the license and create infringement exposure. - **An anti-benchmarking clause would interfere with regulatory reporting obligations.** Anti-benchmarking clauses restrict disclosure of performance results; they are distinct from reverse-engineering prohibitions. Where auditors, regulators, or customers must receive performance data, negotiate an express carve-out before the clause locks the company into noncompliance. --- ### Chapter 3 — Indemnification: As Licensor #### Section 1 — What Indemnification Provisions Are and Why They Exist IP indemnification is a contractual obligation by one party — the indemnitor — to defend, hold harmless, and reimburse the other party — the indemnitee — against third-party claims asserting that the indemnitor's IP infringes the third party's rights. In software contracts, IP indemnification addresses the risk that the licensor's product contains technology that someone else claims to own — a patent the licensor's engineers were unaware of, a copyright the licensor's code was found to reproduce, or a trade secret the licensor's methodology was alleged to incorporate. Indemnification provisions exist because the party best positioned to know whether its IP is clean — and to do something about it if it is not — is the licensor. The licensor designed the software, conducted (or failed to conduct) freedom-to-operate analysis, and made the architectural decisions that determine whether the product infringes. Allocating the defense obligation to the licensor reflects this asymmetry of knowledge and control. That asymmetry is not absolute. The analysis changes substantially when the licensee combines the licensor's IP with its own systems, data, or third-party components: the licensor no longer controls the accused combination, and the licensee's integration choices may be the but-for cause of the claim. Combination carve-outs exist for this reason — though, as discussed below, their drafting determines whether they fairly allocate that risk or swallow the indemnification entirely. The analysis also changes when the licensor delivers source code or substantial technical documentation. In those engagements, the licensee may be equipped to perform its own freedom-to-operate or noninfringement analysis, which weakens the premise that only the licensor can assess cleanliness and may support a narrower indemnification scope, shared diligence obligations, or more carefully drawn carve-outs for claims the licensee was positioned to evaluate. **Standard indemnification structure:** - The indemnitor controls the defense and selects counsel - The indemnitor pays damages, settlements, and defense costs - The indemnitee provides prompt written notice of any claim - The indemnitee cooperates in the defense - The indemnitor has the right to control settlement, subject to the indemnitee's right to approve settlements that impose affirmative obligations on the indemnitee --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Accepting notice as a condition precedent** Many contracts make timely notice a condition precedent to indemnification — not merely a basis for reducing the indemnitor's obligation, but a complete bar to recovery if the deadline is missed. A 10-day or 15-day notice window that runs from receipt of the claim, treated as a condition precedent, can extinguish an otherwise valid indemnification right through an administrative failure. The preferred approach: notice failure reduces the indemnification obligation only to the extent the indemnitor is actually prejudiced by the delay — not as a blanket forfeiture. **2. Failing to retain the right to cure** An IP indemnification obligation that goes directly to monetary payment leaves the licensor no ability to manage the claim commercially. The licensor should retain the right to resolve an infringement claim by: (a) procuring a license for the customer to continue use; (b) modifying the infringing component to eliminate the infringement; or (c) as a last resort, terminating the affected service and refunding prepaid fees. These cure options preserve the licensor's ability to resolve disputes without paying full infringement damages and without creating precedent across the entire customer portfolio. **3. Accepting open-ended carve-out language** Carve-outs from indemnification — excluding claims caused by customer modifications, combinations, or use outside the licensed scope — are commercially appropriate, for the reasons discussed in Section 1: the licensor does not control the licensee's integration choices. The drafting of those carve-outs matters considerably. Language like "arising from or related to" customer modifications is overbroad: it can exclude indemnification even when the customer's modification was minor and the licensor's software was the primary cause of the infringement. The carve-out should be triggered only when the customer's modification or combination was the sole cause — or at minimum the primary and but-for cause — of the claim. **4. Treating software-as-a-service (SaaS) and source-delivery deals as the same indemnification problem** The knowledge asymmetry that justifies broad licensor indemnification is strongest when the licensee receives only object code or a hosted service. Where the deal delivers source code, detailed design materials, or other technical disclosure sufficient for the licensee to conduct its own freedom-to-operate or noninfringement review, continuing to offer undifferentiated SaaS-style indemnification without addressing that disclosure leaves risk allocation mismatched to the parties' actual information. The pitfall runs both ways: the licensor that fails to narrow or condition coverage may absorb claims the licensee was positioned to evaluate; the licensee that accepts a source-delivery deal with thin indemnification may assume diligence it never performs. Adjust scope, carve-outs, or shared-diligence expectations to the delivery model — do not copy the prior SaaS form by default. **5. Ignoring the international override** Contractual liability caps and limitation clauses are subject to mandatory override in most major international jurisdictions for claims involving intentional misconduct or gross negligence. The German Civil Code (BGB) §§ 307–309 voids caps on gross negligence claims in standard form contracts. French Civil Code Arts. 1170–1171 void exclusions for faute lourde and dol. A cap on IP indemnification that functions under New York law may be ineffective in Germany or France for claims involving willful infringement. See Chapter 16 for jurisdiction-specific rules. --- #### Section 3 — Negotiating as Licensor - **Retain the right to cure:** Modify the software, procure a license, or refund fees — before monetary indemnification is triggered - **Carve-outs tied to customer causation:** Customer modifications and combinations are carved out where they were the sole cause — or at minimum the primary and but-for cause — of the infringement, not merely where they contributed. Prefer this causation standard over open-ended "arising from or related to" language, which customers will (correctly) resist and which overstates the licensor's escape - **Match indemnification scope to the delivery model:** Where the licensee receives only a hosted service or object code, broad indemnification for the product as delivered remains the baseline. Where the licensee receives source code or substantial technical documentation, consider a narrower scope, shared diligence obligations, or carve-outs for claims the licensee was positioned to evaluate from the disclosed materials — consistent with the reduced knowledge asymmetry described in Section 1 - **Cap:** IP indemnification capped at a defined multiple of fees paid, with the cap amount reflecting the licensor's assessed risk exposure across the customer portfolio - **Defense control:** The licensor controls the defense and selects counsel. A customer-controlled defense at the licensor's expense is commercially unacceptable - **Settlement approval:** The indemnitee has the right to approve any settlement that imposes affirmative obligations on it — operational changes, injunctions, or additional payments — but not the right to veto settlements that impose only monetary obligations on the indemnitor - **Resist stacking a non-infringement warranty on top of the indemnity:** If the contract already allocates third-party infringement risk through IP indemnification, do not also give an unqualified representation or warranty that the IP "does not infringe." That is two bites at the apple — the same structure as license + CNA in Chapter 2. Prefer the indemnity as the exclusive remedy for third-party IP claims; keep ownership, pending-litigation, software bill of materials (SBOM), and data-lawfulness representations for disclosure (Chapter 11) --- #### Section 4 — Negotiating as Licensee (Receiving Indemnification) When a customer receiving indemnification from a licensor: - **Separate two different "solely caused by" fights:** Resist limiting the *affirmative* indemnification obligation to claims "solely caused by" the Software — that formulation lets the licensor escape whenever any other stack component contributed. Separately, for *carve-outs* covering the customer's modifications or combinations, insist that the carve-out apply only where the customer's conduct was the sole cause — or at minimum the primary and but-for cause — of the claim, not wherever the claim "arises from or relates to" the combination - **Extend notice periods and remove condition-precedent treatment:** 30 days minimum notice period; failure to notify reduces (does not eliminate) indemnification to the extent of actual prejudice - **Require cure options to have a deadline:** The licensor's right to cure is reasonable — but the cure option should not extend indefinitely. If the licensor cannot procure a license or modify the software within a defined period, the monetary indemnification obligation should activate - **Confirm settlement approval rights:** The customer should have the right to approve settlements that impose ongoing obligations on the customer's operations - **Account for source or documentation delivery:** If the deal includes source code or substantial technical materials, expect the licensor to argue that the knowledge asymmetry has narrowed. Do not concede a broad carve-out for "claims the licensee could have evaluated" without defining what diligence was actually feasible; if accepting a narrower indemnity, ensure the company in fact performs the corresponding review --- #### Section 5 — Red Flags and When to Escalate - **Notice of an IP claim must be given in fewer than 30 days, and late notice is a condition precedent that extinguishes the indemnity.** A short administrative window can wipe out an otherwise valid indemnification right. Prefer a longer period, and treat late notice as reducing the obligation only to the extent the indemnitor is actually prejudiced. - **The deal is cross-border and no one has confirmed that the indemnification cap is enforceable for gross negligence or willful infringement in the counterparty's jurisdiction.** Some jurisdictions refuse to honor liability caps for willful or grossly negligent conduct. If the cap fails locally, the negotiated risk allocation changes materially (Chapter 16). - **The licensor's cure right has no defined deadline.** A right to modify the software, procure a license, or refund fees is commercially reasonable — but an open-ended cure period can defer monetary indemnification indefinitely while the claim proceeds. Require a defined cure window after which the monetary obligation activates. - **A customer-side carve-out uses "arising from or related to" rather than sole causation or primary and but-for causation.** Open-ended "arising from" language lets the licensor escape whenever a combination or modification is anywhere in the causal chain. Carve-outs should apply only where the customer's conduct was the sole cause — or at least the primary and but-for cause — of the claim. - **The affirmative indemnification obligation is limited to claims "solely caused by" the Software.** That is a different fight from a fair customer-side carve-out. Patent claims against integrated systems rarely arise from a single component; "solely caused by" lets the licensor point to any other stack element and walk away. Prefer "caused in whole or in part by." - **The delivery model and the indemnity do not match.** A source-code or substantial-documentation deal that still uses undifferentiated SaaS indemnification language ignores that the licensee can now perform some diligence itself. The opposite problem is equally serious: a sharply narrowed indemnity in a source-delivery deal with no plan for the licensee to actually review what was delivered (see Section 1 and Pitfall 4). --- ### Chapter 4 — Indemnification: As Licensee #### Section 1 — What This Analysis Addresses Chapter 3 addresses the licensor's perspective on IP indemnification. This chapter addresses the licensee's perspective — specifically, what to require from vendors and how to evaluate what vendors actually offer. The two perspectives are mirror images in some respects but differ materially in others, because the licensee has less information about the vendor's IP than the vendor does. A company in-licensing cloud infrastructure, AI models, data feeds, and software tools faces a systematic information disadvantage: it cannot evaluate whether the vendor's software infringes someone else's patent, cannot inspect source code for copyright similarity, and cannot assess whether the vendor's methodology incorporates misappropriated trade secrets. IP indemnification from the vendor is the mechanism that allocates this risk to the party that has the knowledge and control to manage it. --- #### Section 2 — Common Pitfalls in Contracting Practice **The eight drafting techniques that narrow indemnification while appearing broad** Vendor counsel have developed standard drafting practices that make indemnification clauses appear comprehensive while substantially limiting the licensee's actual protection. This section catalogs those techniques so they can be identified and negotiated. *Technique 1 — The "as provided" qualifier:* > *"Vendor shall indemnify Licensee against any claim that the Software, as provided by Vendor and used in accordance with this Agreement, infringes any third-party intellectual property right."* "As provided" limits indemnification to the software used in precisely the manner described in the documentation, without modification or integration. Configuration, parameter tuning, and integration with the licensee's systems will all occur in practice. The vendor can characterize any of these as going beyond "as provided." *Technique 2 — The "solely caused by" standard:* > *"Vendor's indemnification obligation applies only to claims solely caused by the Software."* Patent claims against integrated software systems rarely arise from a single component. This standard allows the vendor to point to the licensee's other stack components and disclaim the obligation. Replace with "caused in whole or in part by." *Technique 3 — Notice as condition precedent:* > *"Vendor's indemnification obligations are conditioned upon Licensee providing prompt written notice of the claim, no later than [10/15/30] days after receipt."* A missed short deadline becomes a complete bar to recovery rather than a basis for reducing damages proportionate to actual prejudice. *Technique 4 — IP type limitation:* > *"Vendor shall defend Licensee against claims that the Software infringes any copyright or trademark of a third party."* Copyright and trademark claims are comparatively infrequent in software disputes. This language excludes patent claims — among the most expensive to defend — while presenting itself as broad protection. *Technique 5 — "Known as of the effective date":* > *"Vendor's indemnification obligation applies only with respect to claims arising from IP rights that existed as of the Effective Date of this Agreement."* Patents applied for years before the contract may issue after the effective date and still cover technology already in use. This clause excludes the majority of real-world patent risk. *Technique 6 — The combination carve-out written to swallow the indemnification:* > *"... or (iii) Licensee's use of the Software in a manner not contemplated by this Agreement."* "Not contemplated" is undefined and allows the vendor to argue after the fact that the licensee's specific deployment was outside the clause's scope. Replace with "expressly prohibited by this Agreement." *Technique 7 — The open source exclusion as an indemnification escape:* > *"Vendor's indemnification obligations do not apply to any claim arising from or related to any open source software components incorporated into the Software."* This technique deserves particular attention because it is deliberate, not incidental. Vendors include broad open source exclusions knowing that modern enterprise software incorporates open source components throughout the codebase. A blanket exclusion for "any claim arising from or related to" open source components — rather than claims arising from the component's own license terms — may eliminate indemnification for a substantial portion of the product. The "arising from or related to" formulation is the tell: it is drafted to reach patent and copyright claims that happen to involve software of open source origin, not just copyleft compliance claims. Response: require an SBOM identifying all open source components; limit the exclusion to claims arising specifically from the component's own license terms (e.g., a copyleft assertion under the GNU General Public License (GPL)); require the vendor to represent no knowledge of patent claims against identified open source components; for components central to the product's function, consider requiring vendor certification or third-party indemnification. *Technique 8 — The AI indemnification exclusion:* Major AI vendors now routinely exclude indemnification for claims arising from AI-generated outputs, citing training data uncertainty and output copyright status. This exclusion has become market standard among major AI platform providers. The gap warrants separate assessment: what is the company's downstream exposure to customers who rely on AI-generated outputs, and how is that gap managed through operational controls, insurance, or customer contract terms? See Chapter 10 for the full AI content liability analysis. --- #### Section 3 — Negotiating as Licensee **What sound indemnification language for the licensee looks like:** > *"Vendor shall defend, indemnify, and hold harmless Licensee against any third-party claim that the Software, as delivered by Vendor, infringes any patent, copyright, trade secret, trademark, or other intellectual property right of any third party. This obligation shall not apply to the extent the claim arises from: (a) modifications to the Software made by Licensee without Vendor's authorization; (b) Licensee's combination of the Software with third-party software, hardware, or data where the claim would not have arisen but for such combination; or (c) Licensee's use of the Software in a manner expressly prohibited under this Agreement."* Note the absence of "as provided," "solely caused by," IP type limitation, date limitation, and "not contemplated" — and the presence of "expressly prohibited" in the combination carve-out. **Additional positions:** - Notice periods of 30 days minimum; notice failure reduces (does not eliminate) indemnification proportionate to actual prejudice - Indemnification expressly covers patents, copyrights, trade secrets, and all other IP types - No effective date limitation — coverage extends to IP rights that exist at any point during the license term - Open source exclusion limited to claims arising from the component's own license terms, not all claims touching open source software - AI output exclusion narrowed by negotiation, or managed through downstream customer contract provisions and operational controls --- ##### The Indemnification Stack in Complex Deals When a software company builds a product using a vendor's platform and sells that product to a customer, three parties may face exposure in a single infringement claim. A patent holder sues the customer; the customer tenders the claim to the software company under the software company's customer contract; the software company needs to pass the claim to the vendor. The questions that arise: 1. Does the software company's customer contract require indemnification for patent claims? 2. Does the software company's vendor contract cover the same claim — and did the software company meet its notice obligations? 3. Are the indemnification scopes back-to-back, or is there a gap? 4. Does the combination argument break the chain — with each party pointing to the others' components? Any deal involving integration, resale, or building on a vendor's technology warrants IP review of the complete indemnification stack before the customer contract is signed. --- #### Section 4 — Negotiating as Licensor (Offering Indemnification) When acting as the licensor offering indemnification to customers: - Prefer customer-side carve-outs limited to sole causation or primary and but-for causation (consistent with Chapter 3) — and do not confuse that with the licensee-hostile technique of limiting the *affirmative* indemnity to claims "solely caused by" the Software (Technique 2 above) - Retain the open source exclusion for copyleft compliance claims (GPL assertion against a customer who modified the licensed software) — but do not draft it to reach patent claims - Cap indemnification at a defined multiple of fees paid; retain cure options before monetary payment is triggered - Treat the indemnity as the primary (preferably exclusive) remedy for third-party infringement; resist also giving an unqualified non-infringement warranty for the same IP (Chapter 11; analogous to Chapter 2's license + CNA problem) --- #### Section 5 — Red Flags and When to Escalate - **The vendor's indemnification clause contains "as provided," "solely caused by," or "not contemplated."** Each phrase is a narrowing technique catalogued in Section 2. "As provided" excludes ordinary configuration and integration; "solely caused by" lets the vendor escape whenever any other stack component contributed; "not contemplated" lets the vendor redefine the deployment after the fact. Flag and renegotiate each one. - **An open source exclusion uses "arising from or related to" rather than limiting the exclusion to the component's own license terms.** Modern enterprise software is full of open source. A blanket "arising from or related to" exclusion can eliminate indemnification for patent and copyright claims that merely touch software of open source origin — not just genuine copyleft compliance claims. Limit the exclusion to claims arising from the component's own license terms, and require an SBOM. - **An AI vendor contract excludes indemnification for claims arising from AI-generated outputs.** That exclusion is now common among major platform providers. Before signing, assess the company's downstream exposure to customers who rely on those outputs, and decide how the gap will be managed — operational controls, insurance, customer contract terms, or a negotiated narrowing of the exclusion (Chapter 10). - **Indemnification is limited to IP rights that existed as of the Effective Date.** Patents applied for before the contract may issue afterward and still cover technology already in use. An effective-date limitation excludes a large share of real-world patent risk. Coverage should extend to IP rights existing at any point during the license term. - **The vendor contract is cross-border and local mandatory law may override the negotiated cap.** Confirm with local counsel whether the jurisdiction will enforce the cap for willful breach or gross negligence before relying on it (Chapter 16). --- ### Chapter 5 — Reverse Engineering #### Section 1 — What Reverse Engineering Provisions Are and Why They Exist Reverse engineering provisions in software contracts define what the licensee may and may not do to understand how the licensed software works. They exist because the licensor's trade secrets — model architecture, algorithm design, scoring logic, data processing methodology — reside in the software and would be exposed if the licensee could examine the source code directly. A prohibition on reverse engineering is the licensor's contractual mechanism for protecting those trade secrets against extraction through technical means. The provision's commercial rationale is straightforward: the licensor licensed functionality, not access to the implementation. A customer who receives a fraud detection API has the right to use the fraud detection results — not to reconstruct the methodology that produces them. Reverse engineering prohibitions enforce that boundary. **What "reverse engineering" covers in a software context:** The term encompasses a spectrum of technical practices that differ significantly in their threat to the licensor's IP: *Decompilation:* Converting compiled binary code back into a human-readable approximation of source code. Directly targets the licensor's source code and trade secrets in implementation. Prohibition is commercially reasonable and routinely enforceable. *Disassembly:* Converting binary code into assembly language — similarly targeted at understanding source implementation. Prohibition is similarly reasonable. *Dynamic analysis and security testing:* Sending inputs to software and observing outputs to identify vulnerabilities, without accessing the binary. Security testing, penetration testing, and fuzz testing use these techniques. A prohibition without a security carve-out sweeps in work that is necessary for the licensee's security operations and that poses no threat to the licensor's source code. *Black-box behavioral analysis and model extraction:* Systematically querying an API and analyzing the input-output relationship at scale to reconstruct a functional approximation of the licensor's methodology — without ever accessing the binary. This is how model extraction attacks work. A standard reverse engineering clause does not address this practice because it involves no access to source code. Rate limits and output-use restrictions are the appropriate contractual response. *Protocol and network traffic analysis:* Inspecting network communications to understand APIs, data formats, and integration interfaces. Necessary for integration work; a potential vector for learning proprietary protocol designs. *Benchmarking:* Testing software against defined performance criteria. Does not access source code. Anti-benchmarking clauses are distinct from reverse engineering prohibitions and warrant separate analysis. --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Accepting blanket prohibitions that sweep in legitimate operations** A standard reverse engineering clause that prohibits "reverse engineering, decompilation, and disassembly" of any kind sweeps in security testing, integration analysis, and benchmarking — activities the licensee's security and engineering teams conduct routinely. Accepting such a clause without carve-outs may place the licensee in technical breach every time its security team runs a vulnerability scan against the licensed software in the licensee's own environment. **2. Failing to address model extraction separately** The black-box behavioral analysis problem — model extraction through systematic API querying — is not addressed by any standard reverse engineering clause, because it involves no access to code. A licensor that prohibits decompilation but imposes no query rate limits or output-use restrictions has left its most valuable IP exposed to reconstruction through a permissible method. These require separate contractual provisions. **3. Conflating the statutory floor with the contractual ceiling** The Digital Millennium Copyright Act (DMCA) § 1201(f) provides a non-waivable right to reverse engineer for the specific purpose of achieving interoperability with independently created software. EU Software Directive Art. 6 (2009/24/EC) provides an equivalent non-waivable EU right. These rights cannot be contractually eliminated — a prohibition that purports to restrict interoperability-motivated reverse engineering is unenforceable to that extent in the U.S. and EU. Practitioners sometimes accept or propose prohibitions broader than the law permits, creating unenforceability risk. --- #### Section 3 — Negotiating as Licensee Seek a prohibition narrowly scoped to decompilation and model extraction, with express carve-outs for: - Security testing, vulnerability scanning, penetration testing, and fuzz testing conducted in the licensee's own environment - Integration analysis: inspecting network protocols, API behaviors, and data formats for the purpose of integrating the vendor's software with the licensee's systems - Performance benchmarking against defined metrics for the licensee's internal evaluation - Any analysis required by applicable law or by regulators with supervisory authority over the licensee **Suggested carve-out language:** > *"The foregoing prohibition does not apply to: (a) decompilation to the limited extent required by applicable law, including for interoperability under 17 U.S.C. § 1201(f) or equivalent local law; (b) security testing, penetration testing, and vulnerability analysis conducted in Licensee's own environment for the purpose of identifying and reporting security vulnerabilities; (c) inspection of network traffic, API calls, and data formats for the purpose of integrating the Software with Licensee's systems; or (d) benchmarking the Software against defined performance metrics for Licensee's internal evaluation."* --- #### Section 4 — Negotiating as Licensor As licensor, the prohibition should cover: - Decompilation and disassembly targeted at source code access - Systematic querying of the licensor's APIs or services for the purpose of reconstructing a functional equivalent of the licensed methodology (model extraction) — address separately from the decompilation prohibition with specific rate limits and output-use restrictions The prohibition should not sweep in standard integration work, security testing by the licensee in its own environment, or internal benchmarking. **The model extraction provision** should address query volume limits and output-use restrictions: "Outputs of the Software may be used only for [licensed purpose] and may not be used to develop, train, or validate any model, system, or product that provides functionality similar to the Software." --- #### Section 5 — Red Flags and When to Escalate - **The reverse engineering prohibition has no carve-out for security testing, and the licensee has active security operations.** Security teams routinely analyze software for vulnerabilities. A blanket ban can put ordinary security work in contractual breach. Negotiate an express carve-out for security testing, vulnerability research, and compliance assessments conducted in the licensee's own environment. - **A high-volume API access arrangement has no output-use restriction or rate limiting.** Systematic querying at scale can extract a model's behavior and replicate its methodology — model extraction. Without rate limits and restrictions on using outputs to train competing models, the licensor's core asset is exposed through ordinary API access. - **The prohibition purports to restrict interoperability analysis beyond what DMCA § 1201(f) or EU Software Directive Art. 6 permit.** U.S. and EU law preserve certain rights to reverse engineer for interoperability. A contract that tries to waive those rights may be partially unenforceable — and may create false comfort for the licensor while leaving the licensee uncertain about lawful analysis. - **The contract is cross-border and the reverse engineering provision has not been reviewed against non-waivable interoperability rights in the counterparty's jurisdiction.** Several jurisdictions treat interoperability analysis as a mandatory right that contract cannot eliminate. Confirm local limits before relying on a blanket prohibition (Chapter 16). --- ### Chapter 6 — Confidential Information & Trade Secrets #### Section 1 — What Confidential Information Provisions Are and Why They Exist A confidentiality provision — also called a non-disclosure agreement (NDA) when it stands alone, or a confidentiality clause when embedded in a broader commercial agreement — is a contractual obligation by a receiving party to protect information disclosed to it by the disclosing party, to use that information only for the purposes of the contract, and to return or destroy it when the relationship ends. These provisions exist for two distinct but related reasons. The first is contractual: they define what the receiving party can do with information it obtains through the relationship. The second is legal: trade secret protection under the Defend Trade Secrets Act requires that the owner take "reasonable measures" to maintain secrecy. 18 U.S.C. § 1839(3). The contract with any party to whom confidential information is disclosed is the primary "reasonable measure" for that disclosure. A weak or absent confidentiality provision is not only a contractual risk — it may defeat a future trade secret claim by establishing that the owner did not take the steps the statute requires. **Practical scope and the bilateral problem** The practical scope of a confidentiality provision in a software contract is broad. In the course of a vendor engagement, the vendor may learn a company's software architecture, model design, pricing logic, customer configurations, and internal development roadmap. The company may learn the vendor's proprietary methods, platform design, and pricing structure. Both directions of disclosure warrant attention — but bilateral drafting does not produce bilateral symmetry in practice. A software company that drafts strong confidentiality terms to protect its own disclosures, then accepts a counterparty's insistence that those terms apply reciprocally, may find that the same language now restricts the company's use of data, configurations, and operational learnings it received from the vendor or from a customer. That problem becomes sharper after termination, when return-and-destruction and survival obligations apply to information sitting in the company's own systems. The party disclosing its most competitively sensitive information has the most at stake and should take the most care with the terms. The drafter should also model how the clause reads when the company is the receiving party. See Section 2, Pitfall 6, and Section 4. **Confidential information vs. trade secrets** These terms are often used interchangeably in contracts. They are not interchangeable. *Confidential information* is a **contractual category**. It is whatever the agreement defines as confidential — by marking, by circumstances of disclosure, or by categorical list. The parties can make the definition broad: pricing discussions, draft term sheets, customer configurations, integration documentation, and ordinary business communications can all be confidential information if the contract says so. Protection comes from the contract. The remedy for misuse is breach of contract. Duration is whatever the contract provides. *A trade secret* is a **statutory category of intellectual property**. Under U.S. law (DTSA / UTSA), information qualifies only if: (1) the owner has taken reasonable measures to keep it secret; and (2) the information derives independent economic value from not being generally known or readily ascertainable by proper means. 18 U.S.C. § 1839(3). Protection arises by operation of law, not by contract label. The remedy for misuse is a misappropriation claim. Protection lasts as long as the statutory elements continue to be met. The relationship is nested, not identical: | | Confidential information | Trade secret | |---|---|---| | **Source** | The contract's definition | Applicable statute (DTSA, UTSA, or local equivalent) | | **Scope** | As broad as the parties draft | Only information meeting statutory elements | | **Calling it so** | Parties can designate almost anything | Labeling information "confidential" or "trade secret" in a contract does not make it one | | **Remedy** | Breach of contract | Misappropriation (plus, usually, contract) | | **Typical examples** | Stale pricing proposals; draft SOWs; meeting notes | Model architecture; scoring methodology; training data logic; source code | Not all confidential information is a trade secret. Pricing discussions from a three-year-old vendor negotiation may still be "confidential information" under a surviving contractual obligation, yet lack the economic value from secrecy that trade secret law requires. Conversely, information that qualifies as a trade secret should almost always be covered by the confidentiality clause — the clause is both a contractual remedy and evidence of the "reasonable measures" element of the statutory claim. See Part I, Chapter 5, for the full trade secret definition and misappropriation standard. This distinction drives the two-tier duration structure discussed below: a fixed post-termination term for general confidential information; an obligation lasting "for as long as the information qualifies as a trade secret under applicable law" for trade secrets. Collapsing the two into a single five-year confidentiality term leaves true trade secrets underprotected once the contractual term expires, and overprotects ordinary business information that never met the statutory test. **International framing** The same conceptual split appears in most major jurisdictions, though the vocabulary differs. TRIPS Agreement Art. 39 requires WTO members to protect "undisclosed information" that is secret, has commercial value because it is secret, and has been subject to reasonable steps to keep it secret. The EU Trade Secrets Directive (2016/943) Art. 2 defines a trade secret in substantially the same three-part structure. Civil-law contracts often use *know-how* or *undisclosed information* as the contractual label; that label may overlap with the statutory trade secret cause of action but is not always coextensive with it. Cross-border drafting implications: - A U.S.-style "confidential information" definition can still be broader than what local law will treat as a protectable trade secret. Contractual breach remains available; statutory misappropriation may not. - "Perpetual" contractual obligations for trade secrets are common U.S. drafting. In some EU B2B contexts, very long or indefinite confidentiality duties can face unfair-terms or competition-law scrutiny depending on party status and local mandatory rules. - Local law may limit enforcement regardless of the clause: the EU Trade Secrets Directive includes whistleblower and other exceptions; several jurisdictions impose mandatory limits on post-employment confidentiality and non-use obligations. See Chapter 16. - Lawful reverse engineering is generally not misappropriation under U.S. law and many other systems; the EU Software Directive Art. 6 adds a non-waivable interoperability right. A confidentiality clause cannot convert reverse engineering that local law permits into a trade secret claim. See Chapter 5. For choice of law, mandatory local rights, and enforcement of confidentiality and trade secret provisions across borders, see Chapter 16. **The key components of a confidentiality provision:** *Definition of Confidential Information:* Specifies what information is covered. Definitions range from mark-based (information is confidential only if labeled as such) to circumstance-based (information is confidential if a reasonable person in the context of the disclosure would understand it to be confidential) to categorical (a list of categories that are always covered regardless of marking). *Obligation of confidentiality:* What the receiving party agrees to do — and not do — with covered information. The obligation has two separable components that are often drafted as a single block: a **nondisclosure** obligation (maintain secrecy, restrict access to need-to-know personnel) and a **use** obligation (use the information only for the purpose of the agreement). They are not the same restriction. A party can accept strong nondisclosure while negotiating the scope of permitted use — a distinction that matters when the company expects to be a net receiver of information from the counterparty. See Section 2, Pitfall 6, and Section 4. *Permitted disclosures:* Exceptions to the obligation — disclosures required by law or court order, disclosures to advisors and affiliates under equivalent obligations, disclosures of information already in the public domain or independently developed. *Duration:* How long the obligation lasts after the agreement ends. *Return and destruction:* What happens to the information when the relationship terminates. --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Mark-based definitions leave important disclosures unprotected** Mark-based definitions — information is confidential only if labeled "CONFIDENTIAL" or "PROPRIETARY" — are operationally unreliable. In a software development engagement, information is exchanged constantly through meetings, calls, email, and working sessions. Engineers and product managers do not stop to stamp every disclosure. A company whose confidentiality protection depends entirely on marking will find that its most sensitive information — disclosed informally and unlabeled — may not be covered. Circumstance-based or categorical definitions are more protective. A circumstance-based definition that covers "information that a reasonable person in the context of the disclosure would understand to be confidential" protects what was actually sensitive regardless of how it was labeled. A categorical definition that expressly covers software architecture, model methodology, pricing, customer data, and business plans leaves no ambiguity about what is covered. **2. Accepting residuals clauses without negotiation** A residuals clause permits the receiving party to use, without restriction, any information retained in the unaided memory of individuals who had access to confidential information. On its face this sounds limited — it only covers what someone happened to remember. In practice, for technically sophisticated professionals who have spent months reviewing a company's proprietary systems, "unaided memory" is a significant carve-out. A vendor engineer who has internalized a company's model architecture, fraud logic, and data processing methodology during an engagement can invoke residuals protection when building a competing system at a new employer. Residuals clauses appear frequently in technology agreements — they are a standard ask from large technology vendors who argue they cannot operationally restrict their engineers from using general knowledge gained on client engagements. The correct response is to resist the clause outright or, if the counterparty insists, to narrow it: residuals protection should cover general professional skills and knowledge but expressly exclude specific technical information, proprietary methodologies, trade secrets, and any information that qualified for protection under the confidentiality clause. **3. The duration problem: a fixed term for trade secrets** Standard commercial confidentiality provisions include a post-termination term of two to five years. This is appropriate for general business information — pricing discussions from a vendor negotiation three years ago have limited competitive value. It is not appropriate for trade secrets. Trade secret protection under the DTSA persists as long as the information remains secret and the owner continues to take reasonable measures. 18 U.S.C. § 1839(3). A contractual confidentiality obligation that expires in three years does not mean the trade secret expires — but it does mean the primary contractual protection for that secret lapses. If the former vendor subsequently uses the information, the company is left relying on trade secret law alone, without the contractual obligation that was the "reasonable measure" supporting the trade secret claim. The correct structure is two-tiered: a fixed post-termination term for general confidential information; a perpetual obligation — lasting "for as long as the information qualifies as a trade secret under applicable law" — for trade secrets. The contract should say this in express terms, not leave it to implication. **4. Survival clauses are missing or ambiguous** Confidentiality obligations that lack an express survival clause may not survive termination of the agreement. Courts in some jurisdictions have found that obligations in a terminated contract lapse with the contract, absent an express survival clause. Every confidentiality provision should include a survival clause specifying which obligations survive, and the two-tiered duration structure (fixed term for general CI, perpetual for trade secrets) should be reflected there. **5. The entity binds but the individuals walk** A confidentiality provision binds the counterparty entity. The individuals who actually received and processed the confidential information are employees of that entity — and they may leave. A vendor engineer who signed no individual agreement and whose employer's confidentiality obligations expire in three years is not effectively bound after departure. The confidentiality clause should require: (a) the counterparty to flow down equivalent written obligations to all individuals who access confidential information; (b) those obligations to survive the individual's employment; and (c) the counterparty to notify the disclosing party if a key individual who had significant access to sensitive information departs, within a defined period after the departure. **6. The bilateral provision that binds the drafter** Software companies frequently generate strong confidentiality provisions — broad definitions, purpose-of-use restrictions, perpetual trade secret obligations, and aggressive return-and-destruction requirements — to protect their own disclosures to vendors and customers. Counterparties routinely insist that confidentiality be bilateral. The result is a provision that reads as mutual protection but operates as a self-inflicted constraint: the company's own drafting now limits what it may do with information received from the vendor (integration documentation, configuration data, performance metrics, support materials) or from a customer (usage data, business requirements, deployment configurations). After termination, the return-and-destruction and survival language the company proposed may prohibit retaining or using that information in ongoing operations — even where the information has operational value unrelated to the counterparty's trade secrets. The pitfall is accepting bilateral reciprocity without modeling the company's role as a net receiver. Workarounds include: - **Separating nondisclosure from use:** Concede strong nondisclosure — no distribution beyond need-to-know personnel, equivalent care, compelled-disclosure procedures — while resisting or narrowing the purpose-of-use restriction. Nondisclosure protects the counterparty's secrets; a broad use restriction protects against the company's ordinary operation with information it lawfully received. - **Carving out the company's own data and derivatives:** Expressly exclude from the counterparty's confidential information definition any data, configurations, or outputs that the company generates from its own systems, its own customers, or its own operations — even if those outputs reflect interaction with the counterparty's product. - **Narrowing post-termination obligations for received information:** Permit retention of copies required for legal, regulatory, or audit purposes; specify that operational logs, analytics, and customer-facing records the company created are not subject to return-and-destruction as "counterparty confidential information." - **Asymmetric structure where appropriate:** Where the company is primarily receiving information (in-licensing a vendor platform, receiving customer data through a hosted service), negotiate confidentiality obligations that run primarily in one direction, with a lighter reciprocal obligation for the limited categories of information the company actually discloses. --- #### Section 3 — Negotiating as the Disclosing Party The disclosing party has the most at stake and should treat the confidentiality provision as a substantive negotiating priority rather than boilerplate. **Definition:** Resist mark-based definitions. Push for circumstance-based or categorical definitions that cover information exchanged in the normal course of the engagement without requiring affirmative labeling. Include in the definition: software architecture, model methodology, data processing methods, algorithm design, pricing and commercial terms, customer lists and configurations, and the existence of specific business relationships. **Standard of care:** "Reasonable measures" is a legal floor, not a contractual target. Specify: no distribution beyond need-to-know personnel with a legitimate purpose under the agreement; written confidentiality obligations on all receiving personnel and contractors; the same standard of care the receiving party applies to its own most competitively sensitive information. **Residuals:** Resist entirely. If the counterparty insists, narrow the clause expressly: residuals apply only to general professional skills and knowledge, and expressly exclude any specific technical information, methodology, algorithm design, model architecture, or information that qualified as a trade secret under applicable law. **Permitted disclosures:** Each permitted category expands the universe of potential disclosure. For disclosures to affiliates and contractors, require that each recipient execute a written confidentiality agreement with terms equivalent to those in the main agreement. For compelled disclosures, require prompt written notice and cooperation in seeking a protective order before disclosure. **Duration:** Two-tiered structure: fixed term (three to five years) for general confidential information; perpetual obligation for trade secrets, lasting "for as long as the information qualifies as a trade secret under applicable law." Express survival clause required. **Return and destruction:** Require return or certified destruction of confidential information in all forms and formats — including backup copies, derivative notes, and copies in cloud storage systems — on termination. Require a written certificate of destruction specifying the formats and systems from which information was deleted. Do not accept "we will use commercially reasonable efforts to delete" as a destruction obligation. --- #### Section 4 — Negotiating as the Receiving Party The receiving party's interests are not simply the mirror image of the disclosing party's. The receiving party has legitimate operational needs that overbroad confidentiality provisions impede — particularly where the receiving party is a vendor whose engineers work on multiple client engagements and cannot practically segregate every piece of knowledge they acquire. The analysis differs again where the company is **in-licensing** software or services and expects to be a net receiver of vendor or customer information: the bilateral confidentiality clause the counterparty insists on may be the company's primary exposure, not its primary protection. **Definition:** Seek definitions that have clear boundaries — categorical lists with specificity are preferable to open-ended circumstance-based standards that create uncertainty about what is covered. Push for express carve-outs: information already known to the receiving party before disclosure; information independently developed without reference to the disclosing party's information; information in the public domain through no fault of the receiving party. Where the company receives customer or vendor data through the licensed service, seek carve-outs for data and outputs the company generates in its own environment. **Nondisclosure without use restriction:** Where the counterparty demands bilateral confidentiality, a workable structure is to accept strong nondisclosure obligations — maintain secrecy, limit access, apply reasonable care — while resisting a broad purpose-of-use limitation that would bar the company from using information it received in the ordinary course of the relationship. Nondisclosure addresses the counterparty's concern that secrets will be shared with third parties; use restrictions address what the company may do with information inside its own operations. Conceding the former while negotiating the latter is often commercially acceptable because counterparties focus on leakage, not internal use. **Party-neutral improvement restriction (in-licensing):** When representing a company licensing in vendor software, consider a restriction drafted in neutral terms — not "Vendor shall not use Licensee's confidential information" but a clause limiting use of confidential information to improve the **delivered service** or **licensed product**. Because the clause does not name the parties, counterparties sometimes accept it without recognizing that it primarily constrains the vendor's ability to train on, benchmark against, or productize the customer's data and usage patterns. This is not a substitute for explicit data-rights and AI-training provisions where those apply — see Chapters 8 and 9 — but it can supplement them in engagements where the counterparty resists customer-specific language. Draft carefully: overbroad neutral language can still boomerang if the company is also receiving substantial vendor confidential information. **Standard of care:** Avoid "same care as own most sensitive information" if the receiving party is a large technology company with extremely stringent internal security standards that are impractical to apply to routine client engagements. "Reasonable care" with a defined minimum standard is more operationally workable. **Residuals:** Seek a narrow residuals clause covering general professional knowledge retained without deliberate memorization. Make clear this is not a license to deliberately retain and use specific technical information — frame it as covering incidental retention of general knowledge, not deliberate appropriation of specific methodology. **Duration:** Fixed terms are appropriate for the receiving party. Resist perpetual obligations for categories of information that cannot realistically be segregated from general professional knowledge over time. If the disclosing party insists on perpetual trade secret protection, negotiate a carve-out for information that the receiving party can demonstrate was independently developed after the termination of the agreement. **Return and destruction:** Retain the right to keep copies required by applicable law or professional regulatory obligations (legal holds, audit requirements). Specify that backup copies in automated systems that are not accessible in the ordinary course of business satisfy the destruction obligation when those systems are overwritten in the normal backup cycle. Where the company is a net receiver, resist return-and-destruction obligations that would require deleting operational data, customer records, or analytics the company created from lawful use of the licensed service. --- #### Section 5 — Red Flags and When to Escalate The following circumstances warrant IP counsel review of the confidentiality provisions before execution: - **The counterparty will have access to model architecture, algorithm design, scoring methodology, or training data.** Those categories typically qualify as trade secrets, not ordinary business information. They need the two-tier duration structure (fixed term for general confidential information; perpetual for trade secrets), residuals resistance, and flow-down obligations to individuals — not a boilerplate NDA. - **The counterparty's standard form includes a residuals clause.** Residuals permit use of information retained in "unaided memory." For engineers who have spent months inside a company's systems, that carve-out can cover substantial proprietary methodology. Resist it, or narrow it to general professional skills and expressly exclude specific technical information and trade secrets. - **Trade secret protection is capped at a fixed two-to-five-year term.** Trade secret protection under the DTSA lasts as long as the information remains secret and reasonable measures continue. A contractual obligation that expires in three years leaves true trade secrets underprotected once the term ends. Use a perpetual obligation lasting "for as long as the information qualifies as a trade secret under applicable law." - **A large technology vendor's standard form has not been negotiated.** Vendor forms are drafted to protect the vendor — often with residuals clauses, mark-based definitions, and short fixed terms. Treat the form as a starting point for negotiation, not as market custom that cannot be changed. - **The engagement involves co-development.** Both parties are contributing proprietary information, and ownership of jointly developed IP overlaps with the confidentiality analysis. Confidentiality terms alone will not resolve who owns the joint work product; coordinate with the ownership and pre-existing IP clauses (Chapters 1 and 14). - **The counterparty operates in jurisdictions with mandatory limits on post-employment confidentiality.** Local law may restrict how long individuals can be bound after they leave, regardless of what the corporate NDA says. Confirm enforceability before relying on flow-down obligations (Chapter 16). - **The company drafted strong confidentiality terms and the counterparty insisted on bilateral reciprocity.** Model the clause from the receiving-party perspective before signing. The same language that protects the company's disclosures can restrict its use of vendor documentation, customer configurations, and operational data — including after termination. - **A broad purpose-of-use restriction would bar the company from using vendor or customer data in ongoing operations after termination.** Separate nondisclosure (no leakage to third parties) from use (what the company may do inside its own operations). Concede strong nondisclosure while negotiating the use restriction. - **Return-and-destruction language would require deleting operational data, analytics, or customer records the company generated from lawful use of the licensed service.** Those materials are often the company's own work product, not the counterparty's confidential information. Carve them out expressly, and preserve copies required for legal, regulatory, or audit purposes. - **A party-neutral "improve the delivered service" restriction is proposed without assessing whether it also constrains the company.** Neutral drafting can primarily constrain the vendor's training and productization of customer data — but if the company is also receiving substantial vendor confidential information, the same language can boomerang. Assess both directions before accepting it. --- ### Chapter 7 — Open Source Software #### Section 1 — What Open Source Provisions Are and Why They Exist Open source software licenses are copyright licenses — not public domain dedications, and not permissions to use software without obligation. Every open source license imposes conditions on the recipient's use, modification, and distribution of the software. Compliance with those conditions is a copyright obligation; failure to comply is copyright infringement. Open source provisions in commercial software contracts exist because virtually all commercial software incorporates open source components, and those components bring their license obligations with them. A vendor's product may be marketed as proprietary — and its core architecture may be proprietary — while incorporating dozens of open source libraries throughout the codebase. The obligations attached to those libraries bind anyone who receives and deploys the software. **License categories and risk levels:** | License Type | Examples | Key Obligation | Risk to Licensee | |---|---|---|---| | **Permissive** | MIT, BSD, Apache 2.0 | Attribution; patent notice (Apache) | Low — comply with attribution requirements | | **Weak Copyleft** | LGPL, MPL | Modifications to the licensed component must be shared; surrounding code is not infected | Moderate — requires careful integration architecture | | **Strong Copyleft** | GPL v2/v3 | Modifications to GPL-licensed software must be released under GPL | High — may require disclosure of proprietary modifications | | **Network Copyleft** | AGPL (Affero GPL) v3 | Same as GPL, but triggered by deployment as a network service — not only by distribution | Very High — SaaS deployment may trigger source code release obligations | --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Misunderstanding when the copyleft trigger fires** The copyleft risk in strong copyleft licenses — GPL, AGPL — is triggered by modification, not by mere use. Using GPL-licensed software without modification, as an independent component, generally does not trigger the copyleft obligation to release source code. Modifying GPL-licensed software — customizing it, extending it, combining it in ways that create a derivative work — may trigger an obligation to release those modifications under the GPL. Presence of GPL components in a vendor's software does not, by itself, create immediate copyleft risk to the licensee's proprietary codebase. That framing is overbroad. The risk materializes when the licensee's engineers modify the GPL-licensed component or integrate it in a way that creates a derivative work under the GPL. The operative question is not "does the vendor's software contain GPL components?" but "will the licensee modify or integrate those components in a way that triggers the copyleft obligation?" **2. Treating the AGPL as equivalent to GPL** AGPL v3 extends the GPL copyleft trigger beyond distribution. Under AGPL, deploying software as a network service — providing access to its functionality over the internet — triggers the obligation to release the corresponding source code, even if no binary is distributed. A licensee that deploys software containing AGPL components as a cloud service may trigger the AGPL obligation without ever having distributed any software. The AGPL's network service trigger is a significant open source risk for SaaS companies and deserves explicit identification in any open source review. **3. Accepting the open source indemnification exclusion as written** The open source indemnification exclusion (Technique 7 in Chapter 4) is a deliberate drafting technique vendors use to escape indemnification liability — not a neutral carve-out reflecting a category of risk the vendor cannot assess. Vendors include broad open source exclusions knowing that their software incorporates open source components. The standard formulation — excluding indemnification for "any claim arising from or related to any open source software components" — is drafted to reach patent and copyright claims that touch any part of the software stack with open source origins, not merely copyleft compliance claims. The licensee who accepts this exclusion without requiring an SBOM does not know what it has given up. A vendor whose software incorporates significant open source components throughout the codebase — and most modern enterprise software does — can exclude a substantial portion of its indemnification obligation through this clause, without the licensee having any visibility into what was excluded. **4. Relying on a one-time SBOM without update obligations** A Software Bill of Materials provided at contract signing reflects the software as it existed at that moment. A vendor that updates its software — adding features, patching vulnerabilities, incorporating new libraries — may introduce new open source components after the SBOM was produced. An SBOM without an ongoing update obligation provides a snapshot, not continuous visibility. --- #### Section 3 — Negotiating as Licensee - **Require an SBOM at signing and on material updates:** The SBOM should identify all open source components, their versions, and their licenses. A material update should be defined to include any change that adds new components or changes the license terms of existing components - **Limit the open source indemnification exclusion to copyleft compliance claims:** The exclusion should cover claims arising from the component's own license terms — e.g., a GPL assertion that the vendor failed to release required source code — not patent or copyright claims that happen to involve software of open source origin - **Require a vendor representation of no known patent claims against identified open source components** - **For AGPL components: require vendor disclosure of any AGPL-licensed components before deployment** — the licensee needs to assess the network service trigger before deploying - **For components central to the product's function:** consider requiring vendor certification of license compliance or third-party indemnification --- #### Section 4 — Negotiating as Licensor As licensor delivering software that may incorporate open source components: - **Conduct and maintain an internal SBOM** for the company's own products — the ability to provide an accurate SBOM to customers is a precondition of responsible open source management - **Avoid copyleft components in customer-facing code** where the company intends to distribute binary software to customers and retain proprietary rights in the source — GPL and AGPL components in distributed software create copyleft risk for the company's own IP - **Customer contract representations:** Include a representation in outbound licenses that the licensed software does not contain copyleft-licensed components that impose obligations on the customer's proprietary codebase — and have the internal SBOM to back it up - **Open source indemnification exclusion:** The exclusion in outbound licenses should be limited to copyleft compliance claims against the customer — not to all claims touching open source software --- #### Section 5 — Red Flags and When to Escalate - **The open source indemnification exclusion uses "arising from or related to" rather than limiting coverage to the component's own license terms.** That formulation is an indemnification escape technique (Chapter 4, Technique 7). It can reach patent and copyright claims that merely involve software of open source origin, not just GPL-style copyleft compliance claims. Limit the exclusion to claims arising from the component's own license terms. - **Vendor software will be deployed without an SBOM at signing.** Without a software bill of materials, the licensee cannot identify which open source components are in the product, under which licenses, or with what obligations. The open source representation is unverifiable. Require an SBOM before deployment. - **The deployment involves AGPL-licensed components in a SaaS or cloud service context.** AGPL's network-service trigger can require source disclosure when the software is offered as a service over a network — even without traditional "distribution." Assess whether any AGPL component is in the serving path before go-live. - **The company's engineers will modify vendor-delivered software.** Modification of GPL or AGPL components can trigger copyleft obligations that reach the company's own code. Identify which components are copyleft-licensed *before* modifications begin, not after. - **The SBOM is delivered once, with no obligation to update when the software changes.** Material updates can introduce new open source components and new license obligations. Require SBOM updates on material releases or version changes. --- ### Chapter 8 — Data Rights & Data Licensing #### Section 1 — What Data Rights Provisions Are and Why They Exist Data rights provisions govern what each party can do with data that flows through the commercial relationship — the data a company shares with a vendor, the data a vendor shares with a company, and the outputs derived from processing either party's data. They exist because data is frequently the most commercially valuable asset in a software company's operations — and because the legal framework for protecting data is considerably weaker than the framework for protecting patents or copyrights. **Why contract does the work that IP law cannot** There is no general copyright in raw data or facts under U.S. law. *Feist Publications, Inc. v. Rural Telephone Service Co.*, 499 U.S. 340 (1991). The idea-expression dichotomy means that the underlying data — the facts, figures, observations — is not protectable. Only original selection and arrangement of data may qualify for thin copyright protection, and only where the selection and arrangement reflects genuine creative judgment. For most commercial data sets, the primary legal protection is trade secret law (where secrecy is maintained and reasonable measures are taken) and contract (where the parties expressly agree on how data may be used). This combination — weak statutory protection, strong contractual dependence — means that data rights provisions do the work that IP law cannot. A poorly drafted data rights provision is not supplemented by background legal protections. It is simply insufficient. **Three layers: software license, modifications, and data rights** Software commercial agreements typically address IP across three layers. Each answers a different question and is governed by different contract provisions — often in different sections of the same agreement. A complete review maps all three. | Layer | What it covers | Typical contract question | Where this book treats it | |---|---|---|---| | **1. Software license** | The program itself — source code, object code, APIs, documentation | What may the licensee *do with the software*? Use, copy, modify, sublicense, integrate? | Chapter 2 (license grant); Chapter 7 (open source in the stack) | | **2. Modifications and improvements** | Changes to the *software* — customizations, configurations that become code, extensions, derivative works of the licensed product | Who *owns* modifications the licensee makes to the vendor's product? Does the licensor get a license back? | Chapters 1 and 14 (ownership, assignment, pre-existing IP, improvements clauses) | | **3. Inputs, outputs, and derived data** | Information that flows *through* the software — customer data ingested, vendor data provided, reports, scores, predictions, generated content, analytics | Who owns or may use the *results* of running the software? May the licensee keep using outputs after the software license ends? May the vendor use customer data or outputs to improve its product? | **This chapter**; Chapters 9–10 for AI-specific terms | A software license grant does not, by itself, resolve Layers 2 and 3: - A **license to use the Software** authorizes operation of the program. It does not, without express terms, allocate ownership of **outputs** the program generates from the licensee's data. Silence on outputs is not cured by a broad "use" grant. - An **improvements clause** that assigns modifications to the vendor addresses who owns changes to the **software**, not who owns **analytical results** produced when the licensee runs the unmodified product on proprietary data. - Conversely, a **data license** or output-ownership clause does not grant rights to **modify the underlying software** — that remains in the license grant and improvements provisions. **Inputs vs. outputs vs. vendor system data** Within the data layer, three subcategories warrant separate treatment: *Inputs* are data the licensee (or its customers) provides to the software — transaction records, documents, configurations, prompts. The contract should address permitted use, confidentiality, return/deletion on termination, and whether the vendor may use inputs for model training or product improvement. *Outputs* are results the software generates from processing inputs — fraud scores, risk ratings, summaries, reports, predictions, generated text. The contract should address ownership, the licensee's post-termination right to retain and use outputs, and whether the vendor claims any license to outputs for its own commercial purposes. *Vendor system data* is information the vendor provides through the service — reference datasets, benchmark baselines, proprietary models embedded in the product. The software license may authorize use of this data only while the license is active; data rights provisions should address what happens on termination. **Post-termination is where the gaps surface** When the software license ends, three distinct questions arise. They are independent of one another: 1. May the licensee **continue running** the software? (Layer 1 — usually no, unless a survival or perpetual license exists) 2. May the licensee **retain and use** modifications it made to the software? (Layer 2 — depends on the improvements and license-back clauses) 3. May the licensee **retain and use** outputs and its own input data? (Layer 3 — depends on express output ownership and data portability provisions; termination of the software license does not automatically answer this) A vendor that owns or claims a license in outputs may argue that the licensee's right to use scores, reports, or generated content ended with the software subscription — even where the licensee provided all underlying data. Address Layer 3 expressly; do not infer it from the software grant. For AI and foundation-model deployments, the same three-layer analysis applies with additional complexity around weights, fine-tuning, and generated content. See Chapters 9 and 10. --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Failing to address AI training use** Commercial data licenses — particularly those executed before the widespread adoption of generative AI — frequently do not address whether either party may use the other party's data to train an AI model. The use case was not anticipated when many licenses were drafted. As a matter of *contract*, silence is not ambiguity in the way parties sometimes assume. Absent an express covenant prohibiting model training — or another provision that already bars the use (purpose-of-use limitation, confidentiality use restriction, or ownership terms that withhold the right) — neither party typically has a contractual claim to stop the other from training on data it lawfully possesses under the agreement. The commercial exposure of silence is that training may be *permitted* by default, not that it is *forbidden but unenforceable*. Copyright and fair use are a separate overlay, and that overlay is unsettled. Early district court decisions diverge on whether training on copyrighted works is fair use: training that builds a competing product with the same function has been held not fair use, while training that extracts statistical patterns for a non-substitutive generative system has been held fair use as a matter of law. *Compare Thomson Reuters Enterprise Centre GmbH v. Ross Intelligence Inc.*, No. 1:20-cv-613-SB (D. Del. Feb. 11, 2025) (not fair use), *with Bartz v. Anthropic PBC*, No. 3:23-cv-04648-WHO (N.D. Cal. June 23, 2025), *and Kadrey v. Meta Platforms Inc.*, No. 3:23-cv-04647-VC (N.D. Cal. June 25, 2025) (fair use). These are early decisions; there is no circuit consensus as of this writing. See Paul Roberts, [Training Data on Trial: AI's First Fair Use Test](https://ip.modernpatentlaw.com/Legal+Updates/Fair+Use+and+AI+Training+Data/Training+Data+on+Trial+Essential) (Dec. 27, 2024, updated with 2025 decisions). The correct approach for new and renewed licenses is therefore contractual clarity, not reliance on silence or on unsettled fair use doctrine: prohibit training without written consent, or define the permitted scope expressly. Existing licenses that predate this issue warrant audit — to identify where silence leaves training contractually open, and to close that gap where the commercial relationship requires it. **2. Ignoring output ownership** Vendor AI and analytics platforms generate outputs — scores, predictions, insights, analyses — derived from the data the customer provides. Vendors may claim ownership of those outputs, or a license to use them for model improvement, under terms buried in their standard form. A company that provides its proprietary customer data to a vendor's platform and receives back analytical outputs it believes it owns may find that the vendor's terms claim a license to those outputs for the vendor's own commercial purposes. This is a Layer 3 issue (see Section 1). The license grant — use, copy, modify — addresses the software, not the outputs. Output ownership should be addressed expressly: outputs generated from the company's data are the company's property. The vendor has no license to use outputs derived from the company's data for any purpose outside the contracted service. Separately address whether the licensee may retain and use those outputs after the software license terminates. **3. Missing the feedback loop** If the company's usage of a vendor's AI system generates data — usage patterns, error corrections, model performance feedback — that the vendor uses to improve its model, the company has transferred value to the vendor without consideration. The improved model, trained on aggregated customer interactions, becomes a more valuable product that the vendor sells to competitors. This value transfer is frequently unaddressed in vendor contracts and is easy to miss at signing. Address it expressly. Best practices, from most protective to more commercially balanced: - **Prohibit by default.** The vendor may not use the company's inputs, outputs, usage telemetry, error corrections, ratings, or performance feedback to train, fine-tune, validate, or improve any model — or to develop features for other customers — without the company's written consent. Cover *usage and interaction data*, not only raw customer content. - **If the vendor insists on a service exception, narrow it.** Permit use solely to operate, secure, and troubleshoot *this customer's* instance. Prohibit incorporation into shared or base models, and prohibit aggregation that lets the company's contribution improve a multi-tenant product sold to others — including "anonymized" or "aggregated" usage that still informs model weights or product features. - **If improvement is permitted, obtain consideration.** Do not leave the transfer unpriced. Options include: ownership of (or a perpetual royalty-free license to) models or weights trained on the company's data; a fee reduction or most-favored pricing reflecting the value contributed; a contractual bar on offering products trained on or materially informed by the company's data to the company's direct competitors; and audit rights to verify training and deletion practices. - **Separate content from telemetry.** Prompt text, documents, and datasets are one category; clickstreams, corrections, and ratings are another. Vendors often treat the latter as free "service analytics." Address both. - **Align with confidentiality.** Pair the data-rights restriction with purpose-of-use and "improve the delivered service" limits so the feedback loop is not an end-run around Chapter 6 confidentiality. See also Chapter 9 (Vendor-Builds-on-Company-Data). - **Address post-termination reality.** Require deletion of inputs and, where feasible, derived training artifacts. If model weights have already absorbed the signal, deletion does not undo the value transfer — competitor restrictions and ownership/license-back terms do more work than a deletion certificate alone. **4. Neglecting data portability and deletion obligations** When a vendor contract ends, what happens to the data the vendor holds? The vendor may retain data in production systems, backup systems, or analytical systems derived from the company's data. Without express portability and deletion obligations — specifying format, timeline, and what "deletion" means across backup systems — the company has no contractual basis to compel return of its data or confirmation of its deletion. Distinguish return of **inputs** from retention of **outputs**. Portability obligations should cover the licensee's input data and, separately, outputs the licensee is entitled to retain. Termination of the software license should not be treated as terminating the licensee's right to outputs it owns unless the contract says so expressly. **Technical feasibility is not a drafting afterthought.** Once data has been integrated into a production system, separating it may be difficult or impossible. Attorneys often draft "delete all Customer Data within thirty days and certify destruction" without knowing whether the obligation asks for something operationally real. Best practice: before locking deletion and portability language, consult the development or data-engineering team — on *both* sides of the deal when the company is also a data holder subject to reciprocal destruction duties. Engineers can usually say what is actually involved; counsel often cannot. A useful analogy: - Asking a counterparty to remove data that has already been baked into a model, feature set, or merged dataset is like asking them to **remove the flour from a cake already baked** — the contribution is no longer separable. - Asking them to delete discrete stored records, files, or identifiable database rows is more like asking them to **scrape the icing off the cake** — still work, but usually feasible. Draft to the cake that actually exists. If the deal contemplates training, enrichment, or irreversible integration, do not rely on a deletion certificate as the sole remedy — pair it with use restrictions, competitor locks, and ownership/license terms for the "flour" that cannot be extracted. If the data remains separable ("icing"), define deletion with enough technical specificity that engineers can implement it: which systems, which identifiers, backups and disaster-recovery copies, derived datasets, and timelines for each tier. **Deletion without audit is an honor system.** Portability and deletion provisions connect tightly to audit rights (Chapter 12). A certificate of deletion answers nothing about whether the icing was actually scraped. Negotiate in tandem: - How will compliance be verified — self-certification by a named officer, customer-directed questionnaire, or independent technical audit? - Who performs the audit — the company's personnel, a mutually agreed neutral third party, or the company's designated auditor under NDA? - What is the scope — production databases only, or also backups, analytics stores, logs, staging environments, and subprocessors? - What is the timeline — audit window after the deletion deadline; how long may the auditor take; what access is required? - Who pays — vendor pays if material undeleted data is found; otherwise customer or shared cost? - What is the remedy if undeleted data is found — immediate deletion, liquidated or actual damages, termination rights, or expanded audit frequency? Without those mechanics, the deletion clause is a promise the company cannot test. See Chapter 12 on data-use and security audit design. **5. Stopping at the license grant and improvements clause** In data-heavy vendor deals, the license grant, improvements clause, and confidentiality provisions may be fully negotiated while Layer 3 remains thin or absent. Each layer requires its own provision. Confidentiality alone does not close data rights: a purpose-of-use or nondisclosure clause may limit leakage without allocating outputs, barring model improvement, or making deletion enforceable. A complete review maps all three layers (Section 1) and confirms the agreement answers at least the following: - **During the term:** Who may use inputs, outputs, vendor system data, and usage telemetry — and for what purposes? - **Training and improvement:** Is model training or product improvement prohibited, narrowly excepted for this customer's instance, or permitted for consideration? Silence typically leaves training contractually open (Pitfall 1). - **Feedback loop:** May the vendor use corrections, ratings, and performance feedback to improve shared or base models (Pitfall 3)? - **Output ownership and post-termination use:** Who owns outputs, and may the licensee keep using them after the software license ends (Pitfall 2; Section 1)? - **Portability and deletion:** Are return and deletion drafted to technical reality — flour vs. icing — with engineering input (Pitfall 4)? - **Verification:** Can deletion and data-use restrictions be audited — who, when, who pays, what remedy (Pitfall 4; Chapter 12)? If those questions are answered only by inference from the license grant or improvements clause, the Layer 3 review is incomplete. --- #### Section 3 — Negotiating as Licensee (Sharing Data with Vendors) - **No model training without consent:** The contract should expressly prohibit the vendor from using the company's data — or outputs derived from the company's data — to train, improve, or validate any model without the company's express written consent - **No feedback-loop improvement without consent:** Extend the prohibition to usage telemetry, error corrections, ratings, and performance feedback — not only raw inputs. If a service-only exception is unavoidable, limit it to operating and troubleshooting this customer's instance; bar incorporation into shared/base models and multi-tenant product improvement - **No aggregation without consent:** The vendor should not aggregate the company's data with other customers' data in a form that allows the company's data to inform products sold to third parties - **If training or improvement is permitted, price it:** Require ownership or a perpetual royalty-free license to models trained on the company's data; competitor lockout for products informed by that data; and/or commercial consideration (fee reduction or most favored nation (MFN) pricing). Cross-check Chapter 9 - **Output ownership:** Outputs generated from the company's data are the company's property; the vendor has no license to use them beyond delivering the contracted service - **Post-termination output use:** The licensee retains the right to use outputs it lawfully received during the term, independent of whether the software license is renewed — address expressly; do not assume survival from the license grant - **Data portability on termination:** The company receives its data in a specified, usable format within a defined period on termination, at the vendor's cost. Confirm with engineering that the format and extraction path are technically workable before signing - **Deletion obligations — draft to technical reality:** Consult development or data engineering before accepting or proposing deletion language. Distinguish separable stored data ("icing") from contributions baked into models or merged systems ("flour"). For separable data, specify systems, identifiers, backups, derived stores, and timelines. For irreversible integration, do not rely on deletion alone — use ownership, license-back, and competitor restrictions - **Deletion verification / audit:** Pair deletion with audit rights: who verifies (named officer certificate vs. neutral third-party technical audit); scope (production, backups, analytics, subprocessors); timeline after the deletion deadline; who pays if undeleted data is found; remedies. See Chapter 12 --- ##### The Regulatory Overlay For companies that handle regulated data — consumer financial data (the Fair Credit Reporting Act (FCRA) and the Gramm-Leach-Bliley Act (GLBA)), health data (the Health Insurance Portability and Accountability Act (HIPAA)), or personal data subject to the EU General Data Protection Regulation (GDPR) — the regulatory framework constrains what the contract can convey. A data license that grants rights exceeding what applicable law permits cannot override the law. Data rights provisions and regulatory compliance provisions in the same contract require joint review. --- #### Section 4 — Negotiating as Licensor (Licensing Data to Customers) - **Permitted purpose definition:** Define the permitted use precisely — not "analytics" but the specific use case. Adjacent uses (model training, marketing analytics, dispute resolution) should be expressly addressed rather than left to inference - **Prohibition on model training:** Outbound data licenses should prohibit using the licensed data to train, validate, or improve any model without express written consent - **Prohibition on sublicensing:** Customers should not be permitted to sublicense data to affiliates or third parties without the licensor's written consent - **Combination restriction:** Prohibit combining the licensed data with third-party data in a manner that obscures the licensor's contribution or allows the customer to market a derivative product without the licensor's involvement --- #### Section 5 — Red Flags and When to Escalate - **The vendor contract involves the company's proprietary data but does not expressly address AI model training use.** Silence on training is typically contractual permission, not a ban. If the vendor may train on customer data, say so expressly — or prohibit it. Do not leave the question to implication (Section 2, Pitfall 1). - **The contract is silent on who owns outputs derived from processing the company's data.** Outputs — reports, scores, embeddings, fine-tuned weights — are often where the commercial value sits. Without an express ownership or license allocation, the parties will dispute the point after the fact. - **Output use after termination is not addressed separately from the software license term.** Ending the software license does not automatically answer whether the vendor (or the customer) may continue using models, analytics, or derived data sets created during the term. Address post-termination use expressly. - **A data-heavy vendor deal has a negotiated license grant and improvements clause but no data rights or output ownership section.** That is an incomplete three-layer review (Section 1). Software license, modifications, and data/inputs/outputs each need their own allocation. - **An AI or machine learning (ML) vendor contract does not address the feedback loop.** Usage data, corrections, and telemetry often improve the vendor's shared model. Decide the structure before signing: ban training on customer data; allow a narrow exception for improving the delivered service only; or grant priced permission. Leaving the loop unaddressed usually favors the vendor. - **The vendor form authorizes "aggregated," "anonymized," or "service improvement" use without a defined limit excluding shared-model training.** Those labels are often broad enough to cover training a model that serves other customers. Define what aggregation and anonymization mean, and exclude use that improves a shared model unless that is the bargained-for deal. - **There is no data portability or deletion obligation on termination.** Without a right to retrieve data in a usable format and a corresponding deletion duty, the company may lose access to its own information while the vendor retains copies indefinitely. - **A deletion or "certificate of destruction" clause was drafted without engineering input on whether the data is separable from receiving systems.** Mixing customer data into shared models, indexes, or embeddings can make clean deletion impossible — the flour-vs-icing problem. Confirm technical feasibility before promising (or accepting) a certificate of destruction. - **The deletion obligation has no paired audit or verification mechanism.** Without specifying who audits, on what timeline, who pays, and what remedies apply if data remains, the deletion promise is largely aspirational (Chapter 12). - **The customer operates in an adjacent market where models trained on the licensed data could compete with the licensor.** Field-of-use and competitive-use restrictions on derived models matter as much as restrictions on the raw data itself. --- ### Chapter 9 — AI Model Licensing & Contract Terms #### Section 1 — What AI Model Licensing Provisions Are and Why They Exist AI model licensing addresses a category of commercial transaction that does not fit the traditional software licensing framework. When a company licenses a foundation model — LLaMA, Mistral, Claude, GPT-4 — it is not receiving access to source code that it can inspect, copy, or modify in the traditional sense. It is receiving access to trained weights, the outputs those weights generate, and (in some cases) the ability to fine-tune those weights on its own data. The legal instruments governing this access were not designed for it. Traditional software licenses address copying, modification, and distribution of source code. AI model licenses govern something structurally different: the use of trained weights to generate outputs, the ownership of those outputs, the permissibility of using outputs to train competing models, and the conditions under which the licensee can build commercial products on top of the model. Model developers have responded to this novelty by writing custom "community licenses" that look like open source licenses but contain significant commercial restrictions — restrictions that often appear in acceptable use policies (AUPs) incorporated by reference rather than in the signed agreement itself. These provisions exist because the commercial value of a foundation model depends entirely on the model developer's ability to control how the model is used and what downstream models are built from it. A model that can be freely used to train a competitor's model, or that can be deployed without restriction in high-risk applications, loses its commercial distinctiveness rapidly. --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Treating "open source" AI models as legally equivalent to traditional open source** The label "open source" applied to a model like LLaMA or Mistral does not mean what it means applied to Linux or Apache. These are custom licenses written by the model developer, with commercial restrictions that traditional open source licenses do not contain. The failure to distinguish between model licenses and traditional open source licenses leads to deployment decisions made without understanding the applicable restrictions. **2. Not reading the AUP as part of the contract** The operative restrictions in most AI model licenses appear not in the license document itself but in an acceptable use policy incorporated by reference. That AUP may prohibit specific industry applications (financial services, credit scoring, insurance), specific uses (generating content that could mislead, training competing models), or specific jurisdictions. The AUP may be updated unilaterally by the model developer. A contract that does not specify which version of the AUP governs — and what notice the licensee receives of material changes — has left the company's compliance obligations subject to unilateral modification. **3. Failing to map actual use cases against the license** Sector restrictions in AI model licenses are increasingly common. Some models prohibit use in financial services, credit risk assessment, or insurance. Others prohibit use in applications that could affect individual legal rights or access to essential services. These restrictions are directly relevant to software companies whose core business involves exactly these applications. The restrictions must be identified and evaluated before deployment — not after. **4. Not distinguishing API access from model download** Many commercial AI deployments involve calling a model through an API — the model never resides on the company's systems. In that case, the relevant document is not the model license but the API terms of service, which addresses different questions: who owns the inputs and outputs, whether inputs are used to train the provider's models, what happens to data retained by the provider, and on what terms access can be terminated. Conflating the model license with the API terms produces a review of the wrong document. **5. Ignoring the indemnification gap** As discussed in Chapter 4 (Technique 8), most major AI vendors explicitly exclude indemnification for claims arising from AI-generated outputs. The company deploying an AI model needs to identify this gap before entering customer contracts that promise IP indemnification, because the gap means the company cannot pass the upstream AI content liability risk to the model vendor. See Chapter 10 for the full downstream liability analysis. --- #### Section 3 — Negotiating as Licensee **Five steps before any AI model deployment:** *Step 1:* Obtain and read the actual license for the specific version in use. Model licenses change between versions. *Step 2:* Identify the AUP and treat it as part of the contract. Negotiate: which AUP version governs; what notice the company receives of material changes; whether the company has the right to continue operating under the prior AUP version for a defined transition period after a material change. *Step 3:* Map the company's actual use cases against the permitted use categories — entity size thresholds, sector restrictions, output training prohibitions, geographic restrictions. *Step 4:* Confirm whether the deployment is via API or downloaded model, and review the applicable document for that deployment type. *Step 5:* Confirm indemnification coverage and identify the gap. Assess how the gap is managed through downstream customer contract provisions, operational controls, or insurance. **What contracts with AI model vendors should address:** - The specific model version and AUP version that governs - A change control mechanism requiring the vendor's consent to material modifications of the AUP, or the company's right to a defined transition period - An express prohibition on the vendor using the company's inputs to train or improve the vendor's models - Output ownership: outputs generated from the company's inputs are the company's property - Data deletion: the vendor deletes inputs and derived data within a defined period after termination --- ##### The Vendor-Builds-on-Company-Data Problem A specific risk that warrants dedicated attention: the company licenses its proprietary data to a vendor — including an AI/ML company — that uses that data to build or improve a model. The risk: the vendor builds a model trained on the company's data. The vendor sells that model — which encodes the predictive value of the company's data — to the company's competitors. The company's competitive advantage has been converted into a competitor's tool. The contract should address: - An explicit prohibition on using the company's data (or outputs derived from it) as training data for any model without express written consent - If training use is permitted: the company owns the trained model, or receives a perpetual royalty-free license to any model trained on its data - A prohibition on the vendor offering any product trained on or materially informed by the company's data to the company's direct competitors --- #### Section 4 — Negotiating as Licensor (Providing AI Capabilities to Customers) As a company that provides AI-powered services to customers: - The license from the foundation model vendor may govern what the company can offer to customers — sector restrictions that apply to the company's use of the model may flow through to customer use - Ensure the foundation model license permits sublicensing or commercial integration into the company's product before offering AI capabilities to customers - Address in customer contracts what happens if the company loses access to the underlying model: transition assistance, alternative model options, or termination rights for the customer --- #### Section 5 — Red Flags and When to Escalate - **An AI model will be deployed without review of the actual license and acceptable use policy for the specific version being used.** Community licenses and AUPs vary by model and version, and material restrictions often live in documents incorporated by reference rather than in the signed agreement. Read the version-specific terms before go-live, not the marketing summary. - **The AUP restricts use in financial services, credit scoring, or insurance.** Sector restrictions can make an otherwise attractive model unusable for the intended product. Assess applicability to the actual use case before engineering commits to the model. - **API terms of service permit the vendor to use the company's inputs for model training without an express opt-out.** Inputs can include proprietary prompts, customer data, and business logic. Confirm whether training use is on by default, whether an opt-out exists, and whether the opt-out is operationally available for the company's account tier. - **A customer contract promises IP indemnification for AI-generated outputs without confirming the upstream AI vendor's indemnification scope.** If the upstream vendor excludes output claims (Chapter 4, Technique 8), the company that promises downstream indemnity is absorbing a gap it cannot pass through. Map the indemnification stack before making the customer promise. - **A fine-tuning arrangement does not address ownership of the fine-tuned model.** Fine-tuning on the company's data can produce a model that is commercially valuable and competitively sensitive. The contract should say who owns the fine-tuned weights, who may use them after termination, and whether the vendor may reuse the fine-tune for other customers. --- ### Chapter 10 — AI-Generated Content Liability #### Section 1 — What These Provisions Address and Why They Matter When a company or its customers use AI tools to generate content — reports, marketing copy, summaries, financial communications, analyses — that content carries IP risks not present in human-authored content. The risks arise from the nature of generative AI: models produce outputs by drawing on patterns learned from training data, and those patterns may reproduce protected expression, simulate real people, or generate false statements, without the human authorial judgment that traditionally managed these risks. These provisions matter because the company that deploys an AI content generation capability — whether for its own use or as a platform its customers use — may face liability for what that capability produces, regardless of whether the company's engineers wrote the infringing content or the defamatory statement. The platform provider, not the end user, may be the party with the deepest pockets and the clearest association with the harm. --- ##### The Seven Categories of Liability **Category 1 — Copyright infringement from training data:** AI models produce outputs by drawing on patterns learned from training data. Where training data includes copyrighted material, model outputs may exhibit substantial similarity to the training material. Outputs may independently infringe copyrighted training material regardless of how the separate training question is ultimately resolved. Whether the *training* itself is fair use remains unsettled. Early district court decisions diverge on function and market substitution: training for a competing product with the same commercial function has been held not fair use, while training that extracts statistical patterns for non-substitutive generative outputs has been held fair use. *Compare Thomson Reuters Enterprise Centre GmbH v. Ross Intelligence Inc.*, No. 1:20-cv-613-SB (D. Del. Feb. 11, 2025), *with Bartz v. Anthropic PBC*, No. 3:23-cv-04648-WHO (N.D. Cal. June 23, 2025), *and Kadrey v. Meta Platforms Inc.*, No. 3:23-cv-04647-VC (N.D. Cal. June 25, 2025). Related suits remain pending (*e.g.*, *The New York Times Co. v. Microsoft Corp.*; *Authors Guild v. OpenAI*). There is no circuit consensus as of this writing. **Category 2 — Trademark infringement from inadequate guardrails:** A model without adequate content controls can produce content that uses third-party brand names misleadingly, generates false endorsement, or mimics a competitor's trade dress — particularly when used to generate customer-facing content at scale. The platform enabling this generation may face contributory infringement liability. **Category 3 — Uncopyrightable outputs:** The U.S. Copyright Office's current position is that purely AI-generated content — produced without sufficient human creative control over the expressive elements — does not qualify for copyright protection. A company that warrants to customers that AI-generated deliverables are copyrighted works owned by the company may be making a false representation if the human authorship threshold has not been met. Trade secret law may provide an alternative protection layer where AI outputs incorporate proprietary data or methodology. **Category 4 — Defamation and hallucination liability:** AI models generate confident, fluent, factually false statements. When those statements concern real people or entities and are published, defamation exposure arises. **Section 230** of the Communications Decency Act, 47 U.S.C. § 230, immunizes a provider of an "interactive computer service" from being treated as the publisher or speaker of information "provided by another information content provider." It is a shield for hosting or transmitting *third-party* content — not a general immunity for content the platform itself creates or develops. What is relatively settled under Section 230 generally: platforms are not liable as publishers for user posts they host; they lose that shield when they are responsible "in whole or in part" for creating or developing the challenged content, including when they "contribute[] materially to the alleged illegality" of the content. *Fair Hous. Council of San Fernando Valley v. Roommates.com, LLC*, 521 F.3d 1157 (9th Cir. 2008) (en banc). Algorithmic amplification of third-party content typically remains within Section 230. *See, e.g., Dyroff v. Ultimate Software Grp., Inc.*, 934 F.3d 1093 (9th Cir. 2019). What remains unsettled for generative AI: whether model *output* is "provided by another" (for example, treated as the user's prompt) or is content the AI provider itself created. No circuit court has squarely held that Section 230 covers large language model (LLM) chat outputs. Early signals cut against relying on the shield where the system generates the expressive content. In *Bouck v. Meta Platforms, Inc.*, No. 25-cv-05194-RS, 2026 WL 810036 (N.D. Cal. Mar. 24, 2026), allegations that Meta's generative-AI ad tools "literally generat[ed]" fraudulent ad text and images were enough, at the pleadings stage, to treat Meta as an information content provider and defeat Section 230 — while a companion theory focused only on algorithmic amplification remained protected. Defamation suits against LLM operators have often been resolved or defended on traditional tort grounds rather than Section 230; *e.g.*, *Walters v. OpenAI, LLC*, No. 23-A-04860-2 (Ga. Super. Ct. Gwinnett Cty. May 19, 2025) (summary judgment for OpenAI on defamation elements and "reasonable reader"/disclaimer analysis, not on Section 230). Planning on Section 230 for AI-generated content is not a sound risk-management approach. **Category 5 — Right of publicity:** AI tools can generate synthetic voice, synthetic image, and synthetic text that depicts or simulates real people without their consent. This implicates state right of publicity law and Lanham Act § 43(a) false endorsement. Customer-facing AUPs for any platform enabling AI content generation should expressly prohibit generation of content depicting identifiable real persons without consent. **Category 6 — Trade secret contamination through AI inputs:** Inputting confidential information into a third-party AI tool may result in that information being used for model training, surfaced to other users through model outputs, or retained in vendor logs accessible to the vendor. Contracts with AI vendors should address: whether inputs are used for model training; data retention practices; whether inputs could be surfaced to other users; and security controls on data in transit and at rest. **Category 7 — Accuracy warranties in AI deliverables:** AI outputs are probabilistic, not deterministic. A contract that delivers AI-generated analysis as a contractual deliverable without expressly disclaiming accuracy warranties creates breach of warranty exposure when the analysis is materially incorrect. Fitness-for-purpose warranties for AI-generated outputs are warranted to be disclaimed expressly unless the company has implemented and can warrant specific human review controls. --- ##### The Layering Problem The scenario that creates the deepest commercial exposure: a company provides a platform that customers use to generate and publish AI content; a third party sues the customer (and the platform provider) claiming the content infringes their copyright, defames a real person, or violates a right of publicity; the customer looks to the platform provider's IP indemnification; the platform provider looks to the AI model vendor's indemnification and finds the exclusion from Chapter 4 (Technique 8). The platform provider is caught in the middle. This outcome requires three documents to work together: the vendor contract (training data provisions, output risk allocation, data retention); the customer AUP (prohibited uses, customer indemnification for customer-generated content); and the platform provider's own limitation of liability provisions (accurate disclaimer of fitness-for-purpose warranties for probabilistic outputs). These documents need to be reviewed as a set — not in isolation. --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Assuming Section 230 covers AI-generated content** **Section 230** of the Communications Decency Act, 47 U.S.C. § 230, is premised on the platform hosting or transmitting content "provided by another information content provider" — third-party speech — not content the platform itself creates or develops. Under settled Ninth Circuit doctrine, material contribution to the illegality of the content takes the provider outside the shield. *Roommates.com*, 521 F.3d 1157. Whether generative-AI outputs are third-party content or platform-created content is unsettled; no circuit has resolved it for LLM chat products. Early district-court treatment of generative-AI *creation* tools cuts against immunity where the system generates the challenged text or images (*Bouck*, 2026 WL 810036), while pure amplification of third-party ads remains protected. Do not plan on Section 230 as the primary defense for AI content liability — negotiate contractual allocations that remain viable if courts treat AI-generated content as first-party. **2. Not distinguishing the seven categories** The seven categories of liability have different legal bases, different defenses, and different contractual responses. Treating "AI content liability" as a single category produces a single contractual response that may address some categories while leaving others unmanaged. Each category warrants its own contractual treatment. **3. Omitting accuracy disclaimers from AI deliverables** Contracts that deliver AI-generated analysis as a professional deliverable without an accuracy disclaimer treat probabilistic output as if it carried the same reliability as human professional judgment. The disclaimer is not a weakening of the deliverable — it is an accurate representation of what AI-generated analysis actually is. --- #### Section 3 — Negotiating as Licensee (Using AI Content Capabilities) - **Upstream indemnification:** Push back on AI output indemnification exclusions (Technique 8 in Chapter 4) where the company deploys vendor AI for customer-facing content generation and cannot pass downstream liability to customers without upstream protection - **Training data and output terms:** Confirm whether model outputs may incorporate protected expression from training data; negotiate training-data representations where vendors offer them, and treat absent representations as an identified gap rather than an assumed safe harbor - **Publication controls:** Require human review before AI-generated content is published externally; align internal use policies with contractual commitments made to customers and regulators - **Accuracy representations:** Do not accept fitness-for-purpose warranties for AI-generated deliverables in inbound vendor contracts without corresponding downstream disclaimers; the licensee posture is to match inbound and outbound accuracy language before the company warrants reliability to its own customers - **Section 230:** Do not treat Section 230 as the primary contractual defense for AI content liability; negotiate allocations that remain viable if courts treat AI-generated content as platform-created rather than third-party content - **Right of publicity and likeness:** Prohibit use cases that generate synthetic depictions of identifiable persons without consent; confirm vendor API terms and acceptable-use policies address likeness and endorsement risks before deployment - **Trade secret contamination:** Prohibit inputting confidential information into third-party AI tools without vendor terms that forbid using inputs for model training, surfacing inputs to other users, or retaining inputs beyond the contracted service period --- #### Section 4 — Negotiating as Licensor (Providing AI Capabilities) - **AUP:** Prohibit: use of the platform to generate content that infringes third-party IP; generation of content that falsely implies endorsement or affiliation; generation of content depicting real persons without consent; systematic generation of content for publication without human review - **Customer indemnification:** Require customers to indemnify the platform provider for third-party claims arising from content the customer generates using the platform - **Accuracy disclaimer:** AI-generated outputs are provided for informational purposes; fitness-for-purpose warranties are disclaimed; outputs should be independently verified before use in decisions with material consequences --- #### Section 5 — Red Flags and When to Escalate - **A platform contract lets customers generate and publish AI content without a reviewed acceptable use policy covering the seven liability categories in Section 1.** Copyright, trademark, right of publicity, defamation, privacy, professional advice, and regulatory-content risks all travel with generative output. An AUP that does not address them leaves the platform exposed when customers misuse the capability. - **A contract for AI-generated deliverables has no accuracy disclaimer.** Generative models produce plausible but unreliable text. Without a clear disclaimer of fitness-for-purpose and a requirement that outputs be independently verified before material use, the company that delivers the content may face warranty and professional-liability exposure for errors it did not author in any traditional sense. - **The contract warrants that the company owns AI-generated content without confirming the human authorship threshold has been met.** U.S. Copyright Office guidance and case law require human authorship for copyright registration. A warranty of ownership over purely machine-generated output can be false on its face. Confirm meaningful human contribution before making the representation. - **The contract relies on Section 230 (47 U.S.C. § 230) to defeat liability for AI-generated content.** Section 230 protection for generative AI is unsettled. Courts have treated platforms as content providers when they generate or materially contribute to the challenged content, and recent decisions have questioned 230's application to AI-generated advertising and similar outputs. Do not treat 230 as a reliable substitute for contractual risk allocation and operational controls. - **The vendor contract, customer AUP, and customer-facing limitation of liability are being reviewed in isolation.** These three documents allocate the same risk stack. A vendor that excludes AI-output indemnity, a thin AUP, and a customer contract that promises broad IP protection create a gap that only appears when the three are read together. --- ### Chapter 11 — Representations, Warranties & IP Accuracy #### Section 1 — What IP Representations and Warranties Are and Why They Exist Representations and warranties in IP contracts are assertions of fact about the IP being licensed or delivered — who owns it, whether it infringes anyone else's rights, what restrictions attach to it, and what legal proceedings surround it. They exist because the licensee often cannot independently verify most of these facts. A licensee cannot determine from the outside whether a vendor's software was developed with misappropriated trade secrets, whether it incorporates open source components in ways that may create copyleft obligations, or whether a patent infringement lawsuit is pending against it. IP representations and warranties are the contractual mechanism for allocating this information asymmetry: the licensor, who typically has the knowledge, makes representations; the licensee, who lacks it, receives them. When the representations prove false, the licensee has a breach of contract claim. That asymmetry is not uniform across deals — the same point that structures IP indemnification in Chapters 3 and 4. Where the licensee receives only object code or a hosted service, representations (and broad indemnification) remain the primary diligence substitute. Where the deal delivers source code or substantial technical documentation, the licensee may be positioned to perform some noninfringement or open-source review itself. In those engagements, do not drop representations; instead, align them with the delivery model: keep ownership, authority, open-source/SBOM, pending litigation, and data-lawfulness reps; consider knowledge qualifiers on absolute non-infringement where the licensee can review disclosed materials; and ensure any narrowing of indemnification for "claims the licensee could have evaluated" is not wider than the diligence that was actually feasible. See Chapter 3, Sections 1 and 2 (Pitfall 4). **The critical limitation (licensee view):** A representation without indemnification backing provides limited practical protection. A breach gives rise to a breach of contract claim requiring the licensee to prove damages — which, in IP disputes, is frequently difficult. Where the indemnification clause covers third-party IP claims (or expressly covers breach of IP representations), the licensee can invoke defense funding and loss coverage rather than litigating damages from scratch. Review representations and indemnification together, including the Chapter 4 narrowing techniques (especially IP-type limits, "as of effective date," open-source exclusions, and AI-output exclusions) that can leave a strong representation commercially hollow. **The stacking problem (licensor view):** The mirror risk is giving *both* a non-infringement representation or warranty *and* a third-party IP indemnification for the same exposure. That is two bites at the apple — the same structural problem as stacking a covenant not to sue on top of a license grant (Chapter 2). If the licensor already indemnifies the licensee against third-party claims that the licensed IP infringes, the licensee does not need a separate contractual promise that the IP "does not infringe." The indemnity is the remedy path for that risk. Stacking both lets the licensee (1) tender a third-party claim under the indemnity and (2) separately sue for breach of warranty — including, in some formulations, for damages, fee refunds, or termination rights that go beyond the negotiated indemnity cap, cure options, and defense control. Best practice as licensor: choose the indemnity as the vehicle for third-party infringement risk; keep representations focused on facts the indemnity does not fully replace (ownership/authority, no pending litigation, open-source disclosure with SBOM, data lawfulness, encumbrances). If the counterparty insists on a non-infringement representation, qualify it to knowledge and expressly provide that the indemnity is the exclusive remedy for third-party infringement claims. --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Accepting representations without a workable remedy path** IP representations and warranties should not be reviewed as a standalone provision. For ownership, pending litigation, open source, and data-lawfulness representations, confirm that breach has a workable path — either through the indemnification mechanism or through clear contractual remedies. A vendor can provide a comprehensive list of representations and simultaneously hollow out the indemnity (Chapter 4 Techniques 4–8), leaving the licensee with damages claims that are hard to prove. That is different from the stacking problem in Pitfall 6: for third-party infringement specifically, a robust IP indemnity is usually the primary remedy, and an absolute non-infringement warranty on top of it is often redundant rather than protective. Map the representation set against Chapter 4's narrowing techniques. An open-source representation is weak if Technique 7 excludes all claims "arising from or related to" open source; an ownership representation does not cure Technique 5's "IP rights as of the Effective Date" limit on indemnity; and a non-infringement representation stacked on a hollowed-out indemnity is worse than a clean indemnity alone. **2. Omitting the "no pending litigation" representation** Knowledge of pending IP litigation against a vendor's technology is directly relevant to induced infringement risk — a company that licenses software knowing about a patent infringement claim against it becomes a potential induced infringer if it continues using the software in a way the patent holder asserts infringes. A "no pending or threatened litigation" representation transfers to the licensor the obligation to disclose what it knows; without it, the licensor has no contractual obligation to inform the licensee of pending claims. **3. Not requiring ongoing disclosure obligations** A representation made at signing reflects facts as of the signing date. A patent claim filed the day after signing is not covered. Representations should be supplemented by ongoing disclosure obligations: the licensor should be required to notify the licensee promptly if any claim, proceeding, or threat comes to its attention during the license term that would have rendered the representations false if made at that time. Ongoing disclosure is especially important where indemnification is limited to rights existing as of the Effective Date (Chapter 4, Technique 5) — without notice, the licensee may continue deploying into expanding risk. **4. Accepting open source representations without requiring delivery of an SBOM** An open source disclosure representation — "the software does not contain open source components that impose obligations on Licensee's proprietary codebase" — is only as useful as the licensee's ability to verify it. A representation without an accompanying SBOM is unverifiable. The licensor's statement that no problematic open source exists, standing alone, provides no basis for independent assessment. Pair the representation with Chapter 7 SBOM obligations and with an indemnification exclusion limited to the component's own license terms — not all claims touching open source (Chapter 4, Technique 7). **5. Treating non-infringement representations and indemnification carve-outs as separate fights** A broad non-infringement representation ("Software does not infringe any third-party IP") can be hollowed out by an indemnification carve-out that excludes claims "arising from or related to" customer combinations or modifications. Align the two: if the representation is absolute, the carve-out should use sole or primary/but-for causation, not open-ended "arising from" language (Chapters 3–4). Conversely, if the deal is a source-delivery engagement where the licensee will combine or modify extensively, a knowledge-qualified representation plus a fair combination carve-out may be more coherent than an absolute rep plus a carve-out that swallows the indemnity. **6. Stacking a non-infringement warranty with IP indemnification (two bites)** From the licensor's side, agreeing to both an unqualified non-infringement representation/warranty and a full third-party IP indemnity for the same IP is often poor practice. The indemnity already allocates third-party infringement risk — defense, settlement, and damages under negotiated caps and cure rights. The warranty adds a second claim for breach of contract that may escape those mechanics. This is the Chapter 2 "two bites" problem in a different context: license + CNA there; warranty + indemnity here. Prefer one primary path for third-party infringement (usually the indemnity). Retain other representations that serve disclosure and diligence (ownership, pending claims, SBOM, data lawfulness). If both must appear, make the indemnity the exclusive remedy for third-party IP claims and knowledge-qualify any non-infringement statement. --- #### Section 3 — Negotiating as Licensee ##### The Core Representations Worth Requiring from Vendors | Representation | Why It Matters | |---|---| | Non-infringement | Often sought as the foundation of an indemnification claim — but see Pitfall 6; a robust third-party IP indemnity may make an absolute non-infringement warranty redundant, and stacking both gives the licensee two remedies for one risk | | Ownership or authority | The vendor owns, or has sufficient rights to license, the IP being conveyed | | No encumbrances | The IP is free of liens, security interests, exclusive licenses, or prior assignments that impair the licensee's rights | | Open source disclosure (with SBOM) | All open source components and their licenses are disclosed — enables compliance assessment and verification (Chapter 7) | | No government rights | The IP was not developed under a government contract that imposes government-purpose, unlimited, or limited rights under the Federal Acquisition Regulation (FAR) or the Defense Federal Acquisition Regulation Supplement (DFARS) — see Chapter 15 | | Data lawfulness | Licensed data was obtained lawfully and in compliance with applicable privacy and data protection law | | No pending litigation | There are no pending or threatened IP claims, proceedings, or communications asserting rights against the licensed technology | ##### Additional representations for data and AI deals (Chapters 8–10) | Representation | Why It Matters | |---|---| | No training / improvement without consent | Vendor does not use Licensee data, outputs, or usage telemetry to train, fine-tune, or improve models or shared products except as expressly agreed (Chapter 8 feedback loop) | | Training-data practices (AI vendors) | Whether inputs are used for training; whether the vendor represents no knowledge of pending copyright claims against material training sources — do not treat silence as a safe harbor (Chapters 8–10) | | Output ownership | Outputs generated from Licensee inputs are Licensee's property; Vendor claims no ownership or commercial license beyond delivering the service | | AI authorship / accuracy (outbound or customer-facing) | Do not warrant that purely AI-generated deliverables are copyrighted works owned by the company without human-authorship review; do not warrant fitness-for-purpose of probabilistic outputs without matching disclaimers (Chapter 10) | --- - Prefer a robust third-party IP indemnification as the primary remedy for infringement risk; treat an absolute non-infringement warranty as optional and, if insisted upon, knowledge-qualified with the indemnity as exclusive remedy for third-party claims (avoid two bites — same structure as Chapter 2's license + CNA problem) - Tie ownership, pending-litigation, open-source, and data-lawfulness representations to the deal; do not assume every representation must also be an independent damages path parallel to the indemnity - Confirm the indemnity is not hollowed out by Chapter 4 Techniques 4–8 - Align any non-infringement language with combination/modification carve-outs using sole or primary/but-for causation (Chapters 3–4) - Match representation scope to delivery model: knowledge qualifiers may be appropriate where source or substantial documentation is delivered and the licensee can review it; do not use knowledge qualifiers as a substitute for ownership, SBOM, or pending-litigation reps - Require an ongoing disclosure obligation: licensor notifies the licensee within a defined period (10–15 business days) if any fact comes to the licensor's attention that would render any representation false - For the open source representation: require delivery of an SBOM at signing and on material updates - For international transactions: confirm whether additional representations are warranted under local law regarding IP registration, ownership validity, or government rights under local equivalents of FAR/DFARS (see Chapter 15 for U.S. federal contracts); confirm indemnity caps remain viable for willful breach (Chapter 16) --- #### Section 4 — Negotiating as Licensor As the party making representations: - **Prefer indemnity over a non-infringement warranty for third-party IP risk.** If the contract already indemnifies the licensee against third-party claims that the licensed IP infringes, resist adding a parallel representation or warranty that the IP "does not infringe." The licensee does not need both. Stacking them creates two bites at the apple — indemnity tender plus breach-of-warranty damages — analogous to stacking a covenant not to sue on a license grant (Chapter 2). Keep the indemnity as the exclusive remedy for third-party infringement claims. - Still give (and diligence) representations that the indemnity does not replace: ownership or authority to license; no known pending or threatened IP claims; open-source disclosure with SBOM; data lawfulness; no encumbrances that defeat the grant. - If the counterparty insists on non-infringement language, qualify it to "licensor's knowledge" and state expressly that the IP indemnification is the sole and exclusive remedy for third-party infringement claims (subject to negotiated caps, cure rights, and carve-outs). - Qualify other representations to "licensor's knowledge" where appropriate — particularly no-pending-litigation — to facts actually known to the licensor as of signing - In source-delivery deals, knowledge qualifiers on non-infringement may also reflect that the licensee can review disclosed materials (Chapter 3) - Link any remaining infringement-related language to indemnification carve-outs using sole or primary/but-for causation, not "arising from or related to" (Chapters 3–4) - Do not offer absolute non-infringement or ownership reps for AI-generated deliverables without human-authorship review; disclaim fitness-for-purpose for probabilistic outputs (Chapter 10) - If representing open-source cleanliness, deliver and update an SBOM — and keep any open-source indemnity exclusion limited to copyleft compliance claims (Chapters 4 and 7) --- #### Section 5 — Red Flags and When to Escalate - **The contract contains both an unqualified non-infringement warranty and a full third-party IP indemnity, with no exclusive-remedy clause.** If you are the licensor, this gives the licensee two separate remedies for the same infringement risk: it can tender a third-party claim under the indemnity, and it can also sue for breach of warranty — potentially recovering damages outside the indemnity's cap, cure rights, and defense-control mechanics. This is the same "two bites at the apple" structure as granting a covenant not to sue alongside a license (Chapter 2). Either remove the warranty or make the indemnity the exclusive remedy for third-party infringement claims. - **The licensee has neither a workable indemnity nor a meaningful set of representations.** One of the two must carry the load. If the indemnity has been narrowed into uselessness and the representations covering ownership, pending claims, and open source are missing or heavily qualified, the licensee is taking the vendor's IP position entirely on faith. - **The representations look strong on paper, but the indemnification clause has been narrowed so that breach leads nowhere.** Chapter 4 catalogs the narrowing techniques: limiting covered IP types, limiting coverage to rights existing as of the Effective Date, excluding anything "arising from" open source, and excluding AI-generated output. A comprehensive representation set paired with these exclusions gives the licensee statements it cannot practically enforce. - **An absolute non-infringement representation sits next to a carve-out excluding indemnification for claims "arising from or related to" the licensee's combinations or modifications.** The representation promises everything; the carve-out takes most of it back, because nearly any real-world deployment involves some combination with other software. The two provisions need to be aligned: if the representation is absolute, the carve-out should apply only where the licensee's conduct was the sole (or at least the primary and but-for) cause of the claim. - **The deal delivers source code or substantial technical documentation, but the representations and indemnity are copied from a SaaS template.** As Chapter 3 explains, delivering source code narrows the knowledge asymmetry that justifies broad, absolute vendor promises — the licensee can now review the materials itself. The contract should reflect who is actually positioned to evaluate the infringement risk, rather than assuming the vendor knows everything and the licensee knows nothing. - **The vendor contract has no "no pending or threatened litigation" representation.** Without it, the vendor has no contractual duty to tell the licensee about IP claims already asserted against the technology — and a licensee that keeps using software it knows is accused of infringement can itself become an induced-infringement defendant. This matters most in technology areas with active patent litigation. - **The contract includes an open source representation but no obligation to deliver a software bill of materials (SBOM).** A vendor's bare statement that the software contains no problematic open source cannot be verified. The SBOM is what makes the representation checkable. - **The deal involves proprietary data, model training, or AI-generated content, but the contract says nothing about them.** There should be representations or operative terms addressing whether the vendor may use the licensee's data for training or product improvement, who owns AI-generated output, and what the vendor's own training-data practices were (Chapters 8–10). Silence on these points generally favors the vendor. - **Representations are made only as of the signing date, with no ongoing disclosure obligation.** A patent claim filed the day after signing is not covered. The vendor should be required to notify the licensee if facts arise during the term that would have made the representations false. - **The vendor operates in a technology area known for heavy patent assertion.** Standard representations and indemnities may not be adequate; the deal deserves specialist review of the vendor's litigation history and the indemnity's real capacity to absorb a claim. - **The deal is cross-border and no one has confirmed whether the indemnity cap survives local law.** In some jurisdictions, liability caps are unenforceable for willful breach or gross negligence (Chapter 16). If the cap fails locally, the risk allocation behind the representations changes materially. --- ### Chapter 12 — Audit Rights & Source Code Escrow #### Section 1 — What Audit Rights Are and Why They Exist An audit right is a contractual provision granting one party — typically the licensor — the right to examine the other party's records, systems, or operations to verify compliance with the terms of the license. In software contracts, audit rights serve a function that has no technical equivalent: a software license defines what the counterparty can do with the licensor's IP, but it is a legal instrument, not a technical control. The licensor cannot install a gate that prevents a customer from deploying licensed software in unauthorized geographies, sublicensing without consent, or using licensed data beyond the permitted purpose. The audit right is the mechanism that gives the legal instrument operational teeth. Source code escrow is a related but distinct arrangement. Rather than granting an ongoing right to inspect, escrow places a copy of the licensor's source code with a neutral third-party agent, to be released to the licensee only upon defined trigger events — typically the licensor's insolvency, material uncured breach, or cessation of product support. Escrow addresses a different risk: not license scope compliance, but the licensee's ability to maintain and operate software it depends on if the licensor can no longer support it. **What audits cover in a software licensing context:** - License metric compliance: are the licensee's actual deployment, user count, or API usage within the licensed parameters? - Field of use compliance: is the software being used for purposes within the licensed scope? - Geographic compliance: is the software deployed exclusively in authorized jurisdictions? - Sublicensing compliance: has the licensee sublicensed without authorization? - Data use compliance: is licensed data being used for permitted purposes, and no others? - Open source compliance: does the software contain undisclosed open source components, and are their license obligations being met? --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Negotiating existence, not operability** The most pervasive error is treating the audit right as a checkbox — you either have it or you don't — without negotiating whether it can actually be exercised. A vendor that agrees to an audit right subject to 90-day advance notice, pre-approved auditors, a two-day window, business hours in a single timezone, and a scope limited to records the vendor itself selects has agreed to an audit right that will never produce useful results. Audit right operability is in the mechanics, not the headline. **2. Omitting the consequences** An audit clause that grants the right to audit but is silent on what happens when the audit finds a violation leaves the licensor with a breach of contract claim requiring litigation — and damages requiring proof — rather than a defined remedy it can invoke. The clause should specify: if the audit reveals underpayment or out-of-scope use above a defined threshold, the audited party pays the shortfall plus interest, and bears the cost of the audit. If material out-of-scope use is found, the licensor has defined options — termination, an expanded license at current pricing, or damages. Without this, the audit is a fact-finding exercise without a lever. **3. Failing to address the SaaS measurement problem** In traditional on-premise software licensing, an audit could independently count installed copies, active users, or CPU cores. In SaaS and API-based licensing, the license metric is frequently usage-based — API calls, records processed, monthly active users — and the vendor controls the systems that measure it. An audit right that accesses only vendor-generated logs is not an independent verification. It is a review of the vendor's self-reporting. The clause should specify the methodology for independent measurement: what records the licensee's own systems generate that can be cross-referenced against vendor logs; what access the auditor gets to the vendor's metering and billing systems directly; and how conflicts between vendor records and independent measurements are resolved. **4. Treating open source compliance as an engineering problem** Open source compliance audits are rarely addressed in license agreement audit clauses — they are treated as an engineering matter handled through SBOMs and procurement checklists. But the SBOM captured at signing reflects the software as it existed when the contract was executed. A vendor that updates its software and incorporates new GPL or AGPL components after the SBOM was produced has effectively nullified the original disclosure without triggering any contractual obligation. The audit right should expressly include the right to commission an independent software composition analysis of the current deployed version — not the version described at signing. **5. Assuming source code escrow delivers what it promises** Source code escrow is frequently negotiated as protection against vendor insolvency or product discontinuation. In practice, two problems are pervasive. *Release triggers are contested.* Standard triggers — vendor insolvency, material uncured breach, cessation of support — sound clear and are not. "Cessation of support" in particular is almost always disputed when it matters. A vendor that reduces support quality, increases response times, eliminates support tiers, or shifts to community-only support may argue it has not "ceased" support within the meaning of the escrow agreement. The licensee needs to litigate whether the trigger has been met before it can access the code it needs, often under time pressure. *The deposited code is often not buildable.* A vendor that deposits source code may deposit a version that is months or years out of date, missing build instructions, missing dependencies, requiring proprietary development tools the licensee does not have, or documented insufficiently to be maintained by the licensee's engineers. An escrow arrangement that does not specify cadence of updates, required contents (source code, build instructions, dependency lists, third-party license documentation), and a verification mechanism confirming the deposit is current and buildable provides false comfort. --- #### Section 3 — Negotiating as Licensee The licensee's interest in audit rights runs in two directions: inbound (the right to audit vendors) and outbound (the obligation to submit to the licensor's audit). Each deserves attention. **Outbound — as the audited party:** *Scope limitation:* The audit right should be limited to the specific license metrics in the agreement — not a general right to inspect business operations. Negotiate express exclusions: systems and data unrelated to the licensed product; records subject to attorney-client privilege or work product protection; systems containing third-party confidential information the licensee is contractually prohibited from disclosing. *Annual limit with cause carve-out:* Accept a reasonable annual audit frequency (once per calendar year) while confirming that cause-based audits are separately defined and require a reasonable threshold of evidence before they can be invoked — not just the licensor's suspicion. *Auditor qualification:* The licensee should have the right to object to a proposed auditor with a reasonable basis — conflicts of interest, relationships with competitors, lack of relevant technical qualifications. Objections should be raised within a defined period and resolved promptly so the audit is not delayed indefinitely. **Inbound — audit rights the licensee should seek from vendors:** *Open source composition analysis:* Express right to commission an independent software composition analysis of the current deployed version of the vendor's software, not only the version described in the SBOM at signing. This is the mechanism that detects undisclosed GPL and AGPL components introduced through updates. *Data use and deletion audit:* For any vendor processing the licensee's proprietary data, the right to audit data handling practices — including whether data is being used for model training, shared with other customers, retained beyond the permitted period, or processed outside authorized jurisdictions — and, on termination, whether deletion and return obligations were performed. Deletion audits should address the same mechanics as Chapter 8: separable records vs. irreversible integration; production and backup systems; auditor identity (including neutral third party); timeline; cost allocation; and remedies if data remains. *Security audit:* Right to conduct or commission a security assessment of vendor systems storing or processing the licensee's data, or to receive the vendor's own security audit reports (SOC 2 Type II, ISO 27001) annually without needing to initiate a dispute. *Escrow verification:* If source code escrow is part of the arrangement, include in the main license agreement (not only the escrow agreement) an annual right to receive confirmation from the escrow agent that the deposit has been updated, and a right to commission technical verification — at the licensee's cost — confirming the deposited code is buildable with the disclosed dependencies. --- #### Section 4 — Negotiating as Licensor The licensor's goal is an audit right that deters non-compliance and produces reliable information when exercised — without creating an operationally unreasonable burden that damages the customer relationship for minor discrepancies. **Trigger and frequency:** Standard audits on the licensor's request with 30 days' advance notice. Cause-based audits — triggered by specific evidence of non-compliance — with shorter notice (five to ten business days) and outside the standard annual frequency limit. **Auditor:** A qualified neutral third-party auditor — accounting firm, software audit specialist, or technical consultant — under NDA. The licensor should retain the right to approve the auditor to prevent the licensee from designating a firm with a commercial relationship with the licensor's competitors. **Scope:** Limited to records, systems, and data relevant to the specific license metrics at issue. Not a general inspection of the licensee's operations. **Cost allocation:** Licensor bears the cost of standard audits. If the audit reveals underpayment or out-of-scope use above a defined threshold — commonly expressed as a percentage of fees payable over the audit period — the licensee bears the full audit cost plus the shortfall plus interest at a defined rate. This creates a compliance incentive proportional to the magnitude of the violation. **Consequences:** Define them in the clause: material out-of-scope use triggers the licensor's right to terminate, require the licensee to take an expanded license at the then-current list price for the actual usage, or seek damages for the unauthorized period. The licensor should retain discretion on remedy rather than being bound to a single outcome. --- #### Section 5 — Red Flags, Vendor Tactics, and When to Escalate **Vendor resistance tactics and responses:** *"You can see everything in your admin console."* The admin console shows the licensee's own usage data as the vendor reports it. It does not independently verify license scope compliance, sublicensing, data use outside permitted purpose, or open source composition. It is the vendor's self-reporting tool, not an independent audit mechanism. *"An audit would expose our proprietary systems to your inspection."* A neutral auditor under NDA, with a scope limited to license compliance records, does not expose the vendor's proprietary systems to the licensee. This objection conflates the scope of an audit with a general inspection. A well-drafted audit clause should address this by specifying auditor qualifications, NDA obligations, and the express scope limitation. *"We've never had a customer ask for this."* A vendor whose standard form was drafted for small-business customers will make this argument against any non-standard term. It is a negotiating position, not a policy. A vendor with robust compliance programs has no reason to resist an audit right — the audit will confirm what they already know. *"We'll agree to self-certification instead."* A vendor potentially in breach of its license terms is unlikely to self-certify accurately. Self-certification has value as a supplementary mechanism — requiring a named officer to certify compliance creates individual accountability that can deter misconduct. It does not substitute for an independent audit right. **When the vendor will not agree — the alternative dispute resolution (ADR) partial substitute:** Where a vendor declines to agree to a contractual audit right despite reasonable negotiation, the arbitration clause can provide a partial substitute. In court, a plaintiff is required to plead facts sufficient to make a claim plausible before obtaining discovery — a threshold that creates a chicken-and-egg problem for license compliance disputes. In arbitration, the parties can specify in the clause itself that document production of license compliance records is available upon initiation of a dispute without first establishing a threshold showing of merit, and that the burden of demonstrating compliance rests on the licensee. This language accomplishes that: > *"In any arbitration proceeding under this Agreement, either party may request production of records sufficient to verify compliance with the license scope, permitted use, and field-of-use provisions without first establishing a threshold showing of merit. The tribunal shall order such production subject to a confidentiality order upon request, and the responding party shall bear the burden of demonstrating compliance with the applicable license restrictions."* This is not a full substitute — it requires a dispute to be initiated before discovery is available. But it removes the pleading burden and shifts the compliance burden to the party best positioned to demonstrate it. **Escalation signals:** - **The vendor resists audit rights with unusual intensity.** Intense resistance is itself informative: a vendor with robust compliance programs has little reason to fear a narrowly scoped audit under NDA. Unusual pushback warrants asking what the vendor expects an audit to find. - **The license is usage-based (API calls, records processed, active users) and the vendor controls the measurement systems.** Where fees or compliance turn on metrics the vendor alone measures, the licensee cannot independently verify what it is paying for or whether it is within scope. Audit rights — or at least a right to challenge and reconcile the vendor's meters — become essential. - **The vendor's indemnification excludes open source claims, and no SBOM or composition audit right has been negotiated.** The licensee then has neither indemnity coverage for open source risk nor a practical way to verify what components are in the product. Pair a limited open source exclusion (Chapter 4, Technique 7) with SBOM delivery and a composition audit right (Chapter 7). - **The vendor's software is mission-critical and no escrow arrangement has been discussed.** If the vendor fails, is acquired, or stops supporting the product, the licensee may have no path to continued use or remediation. Source code escrow (or an equivalent continuity mechanism) belongs in the conversation before dependence becomes irreversible. - **The license is cross-border and the licensor operates in jurisdictions with different attitudes toward audit enforcement.** Audit clauses that work under U.S. commercial practice may face privacy, data-localization, or public-policy limits elsewhere. Confirm enforceability and practical access to records before relying on the clause (Chapter 16). --- ### Chapter 13 — Competitive Restrictions #### Section 1 — What Competitive Restrictions Are and Why They Exist Commercial agreements between software companies frequently include provisions that limit one or both parties' ability to compete with the other, to offer better terms to third parties, or to recruit each other's personnel. These provisions are negotiated into commercial agreements for a straightforward reason: the relationship creates information asymmetry and competitive exposure that would not exist but for the contract. A vendor that licenses its technology to a customer learns something about that customer's competitive position, development roadmap, and technical architecture. A customer that commits to an exclusive relationship with a vendor has foreclosed alternatives in exchange for something — typically better pricing, preferred access, or a commitment not to supply competitors. Competitive restrictions in commercial agreements fall into four distinct categories that operate differently: **Non-compete clauses:** One party agrees not to offer products or services that compete with the other party, within a defined scope and for a defined period. In software licensing, this typically means the licensor agrees not to license substantially similar technology to the licensee's named competitors, or the licensee agrees not to develop or deploy a competing product using the licensor's technology or information. **Exclusivity clauses:** The licensor commits not to license the same technology to a defined category of competitors, or the licensee commits not to use competing technology from other vendors. Exclusivity is a form of the licensor's commitment, backed by the licensor's obligation to turn away other business. **Most Favored Nation (MFN) clauses:** One party is entitled to terms — pricing, functionality, service levels — at least as favorable as those offered to similarly situated counterparties. MFN is a pricing and terms commitment, not a restriction on who the vendor can serve. **Non-solicitation clauses:** One party agrees not to solicit the other's employees or customers for a defined period. In software contracts, non-solicitation of employees is the more common form and carries IP implications beyond the competitive restriction context. These are not variations of the same provision. Each has a different legal basis, a different enforceability profile across jurisdictions, and a different negotiating dynamic. Treating them interchangeably produces drafting errors and missed negotiating opportunities. --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Accepting vague definitions of competition** The definition of "competing" or "competitive" product or service is a commonly misdrafted element in non-compete and exclusivity provisions. Broad definitions — "any product or service that competes with the licensee's business" — can encompass the licensor's entire product portfolio if the licensee operates in a sufficiently broad market. A software company that licenses fraud detection technology to a financial institution and agrees not to offer "competing services" has potentially agreed not to license any fraud detection product to any financial institution — if "competing services" is interpreted by reference to the licensee's overall business rather than the specific licensed use case. The definition of competition should be tied precisely to the licensed use case — not the licensee's business category. If the license covers consumer credit fraud detection, the non-compete covers only products that are substantially equivalent to that specific functionality, not the licensor's entire portfolio of fraud, risk, or analytics products. **2. Treating MFN clauses as meaningful without enforcement mechanisms** An MFN clause without an audit right or certification mechanism is commercially near-worthless. To invoke an MFN, the beneficiary needs to know what terms the licensor is offering to comparable customers — information that is universally confidential. Vendors comply with the letter of MFN clauses while defeating their purpose through: product bundling (the "comparable" product is technically different because it includes an additional feature); tiering (the favorable terms apply to a customer classification the MFN holder does not qualify for); and geographic carve-outs (the favorable terms apply in markets where the MFN holder does not operate). An MFN clause that has no enforcement mechanism, no definition of "similarly situated" counterparties, and no audit or certification right is decorative. **3. Ignoring change of control** A non-compete or exclusivity provision that binds a vendor becomes dramatically more significant — in either direction — when the vendor is acquired. If the licensor's technology startup agrees not to license to the licensee's ten named competitors and is then acquired by one of those competitors, what happens to the non-compete? If the licensee holds exclusivity in a defined market and is acquired by a company that operates in that market at a different scale, does the exclusivity expand? Standard commercial agreements are frequently silent on these questions. The surviving entity after acquisition generally succeeds to all contractual rights and obligations, but whether a competitive restriction is assignable and what it means after a material change in either party's business are questions the contract rarely addresses — until they matter. **4. Underestimating the antitrust dimension** Competitive restrictions in commercial agreements can constitute antitrust violations independent of their contractual enforceability. A non-compete that forecloses a significant share of a relevant market, or an exclusivity arrangement between parties with substantial market power, may be challengeable under TFEU Art. 101 in the EU or under U.S. antitrust law — regardless of what the parties agreed. This risk is not hypothetical: the EU has investigated exclusivity provisions in platform agreements and licensing arrangements involving technology companies with significant market positions. The antitrust analysis is distinct from the contract law analysis and warrants separate attention for any competitive restriction of material market scope. **5. Conflating non-solicitation with non-compete** Non-solicitation of employees is regularly drafted alongside non-compete clauses and enforced under the same analysis — but the legal basis is different, the enforceability profile varies significantly, and the IP implications are distinct. A non-solicitation clause that prevents the licensee from hiring the licensor's engineers has value beyond the competitive restriction context: those engineers may carry the licensor's trade secrets, proprietary methodologies, and platform knowledge. Conversely, a non-solicitation clause that prevents the licensor from hiring the licensee's personnel who worked closely with the licensed technology protects the licensee's proprietary knowledge from walking out through the licensor. Drafting these as boilerplate alongside the non-compete — with identical duration, geographic scope, and enforceability analysis — misses the IP protection function that non-solicitation serves and the different enforceability standards that apply. **6. Negotiating confidentiality and reverse engineering without identifying the vendor's actual competitive concern** A vendor may defend a broad reverse engineering prohibition, a residuals clause, or a right to use the customer's confidential information for “service improvement” as necessary to protect its technology. Those provisions do not all protect the same interest. A reverse engineering prohibition restricts how the customer may examine the vendor's product. A confidentiality clause governs disclosure and use of information exchanged between the parties. A competitive restriction addresses the commercial conduct that may follow from either activity. Identifying the vendor's actual concern creates negotiating leverage. If the concern is that the customer will study the product and build a competing offering, address that concern directly through a narrowly defined restriction on using the vendor's confidential information or licensed technology to develop a substantially equivalent competing product. The vendor does not also need a prohibition broad enough to prevent security testing, interoperability analysis, or ordinary integration work (Chapter 5). Conversely, a vendor that receives a focused protection against competitive misuse has less justification for demanding a residuals clause or a broad right to use the customer's confidential information for its own product development (Chapter 6). This is not an invitation to accept a general non-compete. The substitute should identify the protected information or technology, the prohibited competitive use, the relevant product or functionality, and the duration. The negotiation works because it replaces indirect and overbroad controls with a provision aimed at the commercial harm the vendor says it is trying to prevent. --- #### Section 3 — Negotiating as Licensee The licensee seeking competitive restrictions — exclusivity, non-compete, or MFN — is acquiring something of real value that the licensor will resist granting broadly. **Use a focused competitive restriction to narrow other IP controls:** When a vendor insists on a blanket reverse engineering prohibition or on confidentiality language that permits it to use the licensee's confidential information, ask what competitive harm the provision is intended to prevent. Offer a narrowly drafted restriction against using specified vendor technology or confidential information to develop a substantially equivalent competing product. In exchange, require appropriate reverse engineering carve-outs for security testing, interoperability, and integration, and remove residuals or “service improvement” language that would permit the vendor to use the licensee's confidential information for its own development. This makes the trade explicit: each party receives protection against competitive misuse without obtaining broader control over the other party's lawful technical work or confidential information (Chapters 5 and 6). **Named-competitor lists over categorical definitions:** Rather than negotiating the definition of "competition" in the abstract, propose a schedule listing the specific companies whose access to the licensor's technology is the actual concern. Licensors will frequently agree to a named-competitor restriction even when they resist a broad categorical non-compete — and a named-competitor list that covers the licensee's real competitive concerns is often more valuable in practice than a broadly drafted clause that is difficult to enforce. **MFN with a real enforcement mechanism:** An MFN clause is only as good as the mechanism for invoking it. Negotiate for one of two alternatives: (a) an annual written certification from a named officer of the licensor that no customer in a defined comparable class has received materially more favorable commercial terms in the preceding year; or (b) an audit right specifically scoped to pricing and commercial terms offered to a defined category of comparable customers. Without one of these, the MFN is largely unenforceable. **MFN scope — economic equivalence, not formal identity:** Vendors will attempt to limit MFN to identical products at identical volume tiers. Negotiate for MFN to cover economically equivalent arrangements — preventing the vendor from packaging additional features with the core product and claiming the resulting effective lower price does not trigger MFN because the product is technically different. **Change of control protection for the licensee:** If exclusivity was a primary reason for the commercial relationship, the licensee should have the right to terminate the exclusivity arrangement — with a defined transition period — if the licensor is acquired by one of the licensee's competitors. The acquirer's ownership of the licensor effectively means the licensee's competitor is now providing the licensee's critical technology. **Non-solicitation — the IP protection dimension:** The licensee should seek a non-solicitation clause that prevents the licensor from placing, for a defined period, any individual who had significant access to the licensee's proprietary systems or confidential information on engagements for the licensee's named competitors. This is distinct from a standard employee non-solicitation — it is a specific non-deployment restriction tied to access to the licensee's confidential information, not a general prohibition on hiring. --- #### Section 4 — Negotiating as Licensor The licensor granting a competitive restriction — agreeing not to license to certain counterparties, or to offer the licensee MFN terms — is making a commitment with real commercial value. That value should be priced and scoped carefully. **Non-compete scope:** Any non-compete the licensor grants should be limited to the specific licensed functionality, not the licensor's product portfolio. Define competition by reference to the specific features, methods, or use cases covered by the license — not by reference to the licensee's business category. A licensor who agrees not to license "substantially equivalent fraud detection functionality" to a list of named competitors has made a defined, manageable commitment. A licensor who agrees not to provide "competing services" to any entity in financial services has potentially capped its entire go-to-market strategy. **Non-compete term:** Coterminous with the license term is the commercially defensible position. A non-compete that survives contract termination — particularly if the licensee terminates for convenience — provides a competitive advantage to a counterparty that is no longer paying for it. **Exclusivity pricing:** Exclusivity has real commercial value and should cost something commensurate with that value. Structure the exclusivity premium as a minimum annual commitment, not a volume forecast — a forecast that is not met does not produce revenue, while a minimum commitment does. Include an automatic conversion from exclusive to non-exclusive if the minimum is not maintained, without requiring renegotiation. **Change of control protection:** The licensor should retain the right to terminate the exclusivity or non-compete obligation — on defined notice — if the licensee is acquired by an entity whose business materially changes the competitive impact of the restriction. What was a reasonable commitment when made to a regional bank may become an unreasonable foreclosure of a global market if that bank is acquired by a systemically important institution. **MFN — offer certification instead of audit exposure:** Rather than agreeing to an MFN with a full audit right over pricing across the licensor's customer portfolio, offer an annual certification from a named officer that no customer in a defined comparable class has received materially more favorable commercial terms. This creates accountability without exposing the licensor's entire pricing structure to inspection. --- #### Section 5 — Red Flags and When to Escalate **Enforceability signals that warrant legal review before reliance:** - **A non-compete would apply to operations in California.** Employee and business non-competes are broadly void under Cal. Bus. & Prof. Code § 16600. Do not rely on a California non-compete as a substitute for confidentiality, trade secret, or license-scope protections. - **A broad non-compete would apply to EU operations.** EU competition law (TFEU Art. 101) limits the scope and duration of competitive restrictions in commercial agreements. A clause that works under New York reasonableness review may be unenforceable — or create competition-law risk — in the EU. - **The non-compete extends beyond the license term.** Post-term non-competes are rarely enforceable and are commercially difficult to justify once the licensed relationship has ended. Prefer in-term restrictions tied to the licensed IP and confidentiality obligations that survive termination. - **An MFN clause has no certification or audit mechanism.** Without a way to verify what other customers received, the MFN is largely aspirational. Prefer annual officer certification for a defined comparable class, or a narrowly scoped audit right — not a naked promise. **Contract signals that warrant IP counsel review:** - **The vendor seeks both a broad reverse engineering prohibition and the right to use the licensee's confidential information, while describing both as protection against competition.** The positions are commercially asymmetric: the vendor restricts the licensee's technical activity while preserving its own ability to learn from the licensee's information. Identify the claimed competitive harm and replace the stack with reciprocal, narrowly defined non-use protection and appropriate reverse engineering carve-outs (Chapters 5 and 6). - **An exclusivity provision is silent on change of control of either party.** Acquisition of the exclusive partner by a competitor — or acquisition of the restricted party — can lock the company into an unwanted exclusive relationship or free a competitor from the restriction. Address assignment, change of control, and termination rights expressly. - **The non-compete defines the restricted field as the licensee's "business" or "competitive space" rather than the specific licensed functionality.** Open-ended market definitions expand far beyond what the licensed IP justifies and invite enforceability challenges. Tie the restriction to the licensed product or field of use. - **A non-solicitation clause is coextensive with the non-compete but does not separately address the IP-protection function.** The individuals who hold the most valuable technical knowledge are not necessarily the same people a market non-compete is designed to keep away from competitors. Address key-person and knowledge-holder solicitation separately from general competitive hiring restrictions. - **A competitive restriction appears in a cross-border agreement with no governing-law analysis.** Enforceability of non-competes, exclusivity, and MFN clauses varies materially by jurisdiction. Confirm the chosen law and the mandatory local rules where the restriction would actually operate (Chapter 16). --- ### Chapter 14 — Pre-Existing IP Clauses #### Section 1 — What Pre-Existing IP Provisions Are and Why They Exist Pre-existing IP clauses define what each party owned before the engagement began and what each party retains regardless of what the contract creates. They are the boundary between the IP each party brings to the table and the IP created during performance. These provisions exist because most custom development and professional services engagements do not start from scratch. A vendor building custom software for a customer typically uses its existing platform, frameworks, libraries, and development methodology as the foundation. The customer wants to own what it paid to build. The vendor wants to retain the tools and methods it brings to the engagement so it can serve other clients. The pre-existing IP clause is where this tension is resolved — or left unresolved, with consequences that become apparent only when the relationship ends. The commercial stakes are substantial. A company that funds significant custom development — a proprietary fraud scoring model, a custom data integration platform, a purpose-built analytics system — and receives back only a license to that development rather than ownership has paid for work it does not own. The vendor retains the ability to offer similar development to competitors, to build on the funded improvements for other clients, and to claim that enhancements made during the engagement belong to the vendor because they are "improvements" to pre-existing IP. Federal procurement overlays this same background/foreground problem with funding-based license rights under the Federal Acquisition Regulation (FAR) and the Defense Federal Acquisition Regulation Supplement (DFARS). When the engagement sells to a U.S. Government agency or into a federal prime contract, see Chapter 15. --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Failing to read the improvements clause in combination with the pre-existing IP clause** The pre-existing IP clause does not operate in isolation. It interacts with the foreground IP clause (who owns what is created during the engagement) and the improvements clause (who owns enhancements to pre-existing IP). A vendor whose standard form retains all pre-existing IP and then defines improvements to pre-existing IP as belonging to the vendor has effectively claimed ownership of custom development built on its platform — regardless of who funded it, who specified it, and who it was built for. The overreaching formulation to recognize: "Vendor retains all right, title, and interest in and to any and all pre-existing works, inventions, data, methodologies, tools, and know-how, including any improvements, enhancements, or derivatives thereof developed in the course of performing this Agreement." The phrase "improvements, enhancements, or derivatives thereof developed in the course of performing this Agreement" sweeps in work performed during the engagement — including work the company paid for — as long as the vendor can characterize it as an enhancement to something the vendor already owned. This is not a hypothetical risk. It is a standard claim vendors make when commercial relationships end contentiously. **2. Accepting open-ended know-how retention** "Know-how" is undefined and potentially limitless. A vendor that retains all "know-how" used or developed during an engagement retains everything its engineers learned — including knowledge of the company's proprietary systems, data architecture, model design, and business logic. A vendor engineer who learned the company's fraud detection methodology during an engagement can use that knowledge — characterized as retained know-how — to build similar systems for competitors, without violating a clause that does not separately address non-use. **3. Treating the pre-existing IP schedule as optional** Pre-existing IP that is not specifically identified in a schedule at contract signing is effectively defined by the vendor's subsequent characterization of what it owned before the engagement. A clause that says "vendor retains all pre-existing IP" without a schedule attached leaves the company with no basis to challenge the vendor's post-dispute definition of what was pre-existing and what was funded by the company. **4. Not separating the license-back from the ownership question** Where the vendor's pre-existing IP is genuinely incorporated into the deliverable, the company may need a license to the vendor's background IP to use the deliverable effectively. This license-back should be expressly addressed — but it is a license, not an ownership claim. The common drafting error is allowing the license-back discussion to blur into an implicit acknowledgment that the deliverable is fundamentally the vendor's IP with minor customization. The two questions — who owns the foreground IP created during the engagement, and what license does the company need to the vendor's background IP that was incorporated — should be addressed separately and expressly. --- --- #### Section 3 — Negotiating as Licensee (Commissioning Development) - **Require a named schedule of vendor pre-existing IP:** Vendor pre-existing IP should be listed in a schedule attached at signing — platforms, frameworks, libraries, and methodologies specifically identified. Anything not on the schedule and created during the engagement is foreground IP, owned by the company - **Define improvements to exclude company-funded work:** "Improvements" to vendor pre-existing IP should expressly exclude work developed specifically for the company, using the company's data and specifications, and funded by the company - **Ownership or perpetual license for funded improvements:** Work funded by the company that the vendor characterizes as an improvement to its platform should belong to the company — or the company should receive a perpetual, royalty-free, irrevocable license to that specific improvement - **Non-use restriction on retained know-how:** Prohibit the vendor from using knowledge learned during the engagement — specifically including knowledge of the company's proprietary systems, data architecture, model design, and business logic — to develop competing products for the company's direct competitors for a defined post-engagement period - **Limit the license-back:** If the vendor retains background IP incorporated into the deliverable, the company's license to that background IP should be scoped to what is genuinely necessary to use, maintain, and modify the specific deliverable — not a general license to the vendor's platform --- #### Section 4 — Negotiating as Licensor (Delivering Development) As the party delivering development and retaining platform rights: - **Name the schedule and populate it before signing:** A specific, populated schedule is protection for the vendor as well as the customer — it defines precisely what the vendor is retaining and prevents subsequent disputes about whether a given component was pre-existing or created during the engagement - **Define improvements in favor of the platform owner:** Improvements that build on the vendor's core platform methodology, architecture, or algorithms and that have value beyond this specific engagement belong to the vendor — but this should be expressly defined, not left to post-dispute characterization - **License the company's foreground IP back to the vendor:** Where the customer will own the foreground IP, the vendor should retain a license to use the methodologies and learnings from the engagement — not to replicate the specific deliverable for competitors, but to apply professional knowledge gained to future engagements --- #### Section 5 — Red Flags and When to Escalate - **A custom development contract includes an improvements clause covering "enhancements, derivatives, or improvements developed in the course of performing this Agreement."** Read with a broad pre-existing IP retention, that language lets the vendor claim ownership of custom work the customer funded — because the work is characterized as an improvement to the vendor's platform rather than as foreground IP. Flag and renegotiate immediately: customer-funded custom development should not automatically vest in the vendor as an "improvement." - **The vendor contract retains open-ended "know-how" with no non-use restriction.** Vague know-how retention can amount to a license for the vendor to reuse the customer's funded methods, configurations, and domain logic for competitors. If know-how is retained, pair it with a non-use restriction covering the customer's confidential information and competitively sensitive learnings from the engagement. - **The pre-existing IP clause has no attached, populated schedule.** An empty schedule — or a clause that incorporates a schedule "to be attached" — leaves the boundary between background and foreground undefined. Populate the schedule at signing with the platforms, libraries, tools, and methodologies the vendor actually brings. - **The vendor's platform will be meaningfully modified or extended during the engagement.** The pre-existing IP and improvements clauses then determine who owns the results of that modification. Resolve ownership of platform extensions, plugins, and customer-specific modules before development begins. - **A post-engagement dispute has already arisen about ownership of a deliverable.** Missing or ambiguous pre-existing IP schedules and improvements clauses are significant litigation risk factors. Escalate for specialist review of the paper trail, the schedules (if any), and the parties' course of performance before positions harden. --- ### Chapter 15 — FAR & DFARS IP Rights: Preexisting IP and IP Developed Under Contract #### Section 1 — What These Provisions Are and Why They Exist Federal procurement does not use ordinary commercial “who owns the IP?” drafting as the primary allocator of rights in technical data and computer software. When a software company sells to a U.S. Government agency — or sells to a **prime contractor** (the company that holds the direct contract with the Government and may subcontract portions of the work) that will deliver into a federal program — the contract typically incorporates clauses from the Federal Acquisition Regulation (FAR) and, for Department of Defense (DoD) work, the Defense Federal Acquisition Regulation Supplement (DFARS). Those clauses allocate **license rights to the Government** in deliverable technical data and computer software, and separately address **patent rights in inventions** made in performance of funded research or development. Title to copyright in software often remains with the contractor; what changes is what the Government may do with the delivered materials. These provisions exist because the Government pays for development, integration, sustainment, and competition. Unlimited Government rights in privately developed commercial platforms would destroy the contractor’s commercial value. Unlimited contractor restrictions on Government-funded work would lock the Government into a single vendor. The regulatory compromise is a rights ladder keyed primarily to **how the item, component, process, or software was developed** — and to whether the deliverable is commercial or other-than-commercial — rather than to ordinary commercial ownership clauses alone. This chapter focuses on the questions that map directly onto commercial preexisting-IP analysis (Chapter 14): 1. What happens to **IP the company already owned** when it is delivered, modified, or integrated under a federal contract? 2. What happens to **IP first developed or generated under the contract** with Government funds, mixed funds, or private funds? 3. What **procedures** (assertions, markings, schedules) are required to preserve restricted rights — and what happens if they are missed? **Two parallel regimes (do not conflate them)** | Track | Primary instruments | What it allocates | |---|---|---| | **Technical data & computer software** | FAR Subpart 27.4 / 52.227-14 (and related clauses); DFARS Subparts 227.71 / 227.72 and clauses such as 252.227-7013, 7014, 7015, 7017, 7018 | License rights to use, reproduce, modify, release, and disclose **data and software deliverables** | | **Patents / subject inventions** | Bayh-Dole Act (35 U.S.C. §§ 200–212); FAR 52.227-11 (and related patent clauses); DFARS patent supplements where applicable | Title to **inventions** conceived or first actually reduced to practice in performance of a funding agreement, subject to Government license and march-in | A company can retain title to a patent under Bayh-Dole while simultaneously granting the Government broad license rights in technical data or software that describe or implement the same technology. Patent ownership and data rights are related commercially; they are not the same clause set. **FAR vs. DFARS — why the agency matters** Civilian agencies generally apply FAR Part 27 and FAR 52.227-14 (*Rights in Data—General*) and related clauses. DoD applies DFARS Part 227 and a denser set of standard rights in technical data and computer software. The commercial intuition is similar — preexisting / privately developed material can be restricted; Government-funded development produces broader Government rights — but the **definitions, rights categories, marking rules, and commercial-item treatment differ**. Do not assume a DoD “government purpose rights” analysis applies unchanged to a civilian FAR contract, or the reverse. **The DFARS rights ladder (other-than-commercial)** For other-than-commercial technical data and computer software under the standard DFARS clauses (notably 252.227-7013 for technical data and 252.227-7014 for computer software), funding and development status drive the Government’s license: | Development funding | Typical Government rights in deliverable technical data | Typical Government rights in deliverable computer software | |---|---|---| | **Exclusively with Government funds** | Unlimited rights | Unlimited rights | | **Mixed funding** | Government purpose rights (often for a negotiated or standard period, then commonly converting to unlimited rights) | Government purpose rights (same structure) | | **Exclusively at private expense** | Limited rights | Restricted rights | **Unlimited rights** allow the Government to use, modify, reproduce, release, or disclose the data or software for any purpose, and to authorize others to do so — including, in practical effect, competitive reprocurement support. **Government purpose rights** allow Government use and disclosure for government purposes (including to other contractors for government work) but not for commercial purposes by third parties during the government-purpose period. **Limited rights** (technical data) and **restricted rights** (computer software) keep the deliverable largely inside the Government, with defined exceptions (for example, emergency repair/overhaul and covered Government support contractors, as the clause provides). **What is mandatory vs. what can be negotiated** This is the practice point that saves wasted negotiation capital: much of the FAR/DFARS IP framework is not ordinary commercial deal terms. Some elements are prescribed for covered contracts; some rights attach by operation of the incorporated clause once the funding and development facts are fixed; and only a defined set of issues is actually open to bargaining with the Contracting Officer. *Generally not available as a commercial redline (do not spend the deal fighting these):* - **Deleting or stripping prescribed clauses from a covered contract.** When the FAR or DFARS clause prescription applies to the solicitation or contract type, the Contracting Officer is generally required to include the prescribed data-rights or patent clause. Asking the agency to “take out 252.227-7013” or “replace FAR 52.227-14 with our commercial ownership clause” is usually a non-starter absent a formal deviation — which is not a routine commercial negotiation. - **Denying the standard Government license that the clause grants for exclusively Government-funded development.** Under the DFARS ladder, technical data or computer software developed exclusively with Government funds is typically subject to unlimited rights. A side letter saying the contractor “retains all IP” does not defeat that grant while the company keeps the Government funding and delivers the data or software under the clause. - **Waiving the Government’s Bayh-Dole license or march-in rights by private agreement.** Where Bayh-Dole and FAR 52.227-11 (or the applicable patent clause) apply to a funding agreement, contractor title retention is paired with a paid-up Government license and residual march-in authority. Those statutory/regulatory features are not ordinary commercial concessions the agency can delete in a mark-up. - **Demanding rights below the regulatory floor in a specially negotiated license.** DFARS permits specially negotiated licenses, but the Government may not accept less than limited rights in technical data (and the software clauses similarly protect a restricted-rights floor). Negotiating for “no Government use at all” of delivered limited-rights data is not a viable ask. - **Making award conditional on a special license.** Under DFARS policy, specially negotiated license rights are authorized by mutual agreement, and award is not to be conditioned on the contractor agreeing to negotiate them. Treat special licenses as a post-award (or separately documented) rights negotiation, not as a proposal contingency that the agency must accept to make award. *Open to negotiation or practical shaping (this is where effort belongs):* - **Specially negotiated license rights.** The parties may modify the standard grant by mutual agreement — for example, the Government accepting less than unlimited or government purpose rights (but not below the limited/restricted floor), or the contractor granting additional rights the Government does not automatically receive. The contractor is not obligated to grant more than the standard grant; the Contracting Officer is not required to accept less than the standard grant. Price, consideration, and acquisition strategy matter. - **The government purpose rights period.** The DFARS clauses provide a nominal period (commonly five years). Either party may request a different period; longer periods are often appropriate when five years is too short for commercial exploitation or to protect subcontractor interests. - **Commercial-item characterization and commercial license terms.** Whether software or data qualifies as a commercial product or commercial computer software is not a label the parties can simply paste on — but it is often contestable on the facts, and the outcome changes which clause set applies. Commercial computer software is typically acquired under the contractor’s customary commercial license (subject to federal law and any FAR 52.227-19-type minimums), not under the full other-than-commercial DFARS funding ladder. Commercial technical data developed exclusively at private expense is commonly governed by DFARS 252.227-7015, which gives the Government a more limited license than unlimited rights. Spend negotiation capital on the issues that actually change the result: (1) documenting that the product meets the FAR commercial-item definition and was developed at private expense; (2) resisting statement of work (SOW) or prime contractor template language that recharacterizes preexisting commercial software as “developed under” the contract; (3) confirming whether Government-funded work creates a split — 7013 for the Government-funded portion, 7015 for the private-expense portion; and (4) negotiating the customary commercial license terms (users, field of use, modification, support) within those federal minimums. That path often preserves more commercial value than trying to delete a prescribed other-than-commercial clause. - **What must be delivered.** SOW and Contract Data Requirements List (CDRL) scope — source vs. object code, form/fit/function data vs. detailed manufacturing data, manuals vs. models — often matters more than abstract rights labels. Narrowing delivery can preserve value even when the clause set is fixed. - **Assertions, segregation, and private-expense proof.** The standard rights follow the facts. Documenting that a module was developed exclusively at private expense, at the lowest practicable segregable level, is how restricted or limited rights are preserved — not by rewriting the clause. - **Price for additional rights.** When the Government wants broader rights than the standard grant (for example, moving from limited to government purpose or unlimited for competitive reprocurement), that is a priced negotiation, not a free upgrade. - **Small Business Innovation Research (SBIR) / Small Business Technology Transfer (STTR) protection-period details** where the applicable clause and Small Business Administration (SBA) Policy Directive permit post-award negotiation of the protection period. The operational rule for counsel: **identify whether the ask is (1) removing a prescribed clause, (2) contradicting a standard rights grant that follows from funding facts, or (3) shaping delivery, characterization, period, price, or a special license within the regulatory floors.** Only category (3) is usually worth the conference room. **“Developed” and “exclusively at private expense” are defined terms.** Under DFARS, private-expense determinations are made at the **lowest practicable segregable level**. Software or a component that was “developed” (for computer programs: successfully operated and tested to show it can reasonably be expected to perform its intended purpose) **before** direct Government funding, using independent research and development (IR&D) or other private/indirect funds, can support a restricted-rights assertion for that segregable portion — even if later Government work improves surrounding modules. Conversely, modules first developed under the contract with direct Government charges typically support unlimited or government purpose rights. Segregation is therefore not a documentation nicety; it is the rights-allocation method. **Commercial products, commercial services, and commercial computer software** Commercial technical data and commercial computer software are treated differently from other-than-commercial deliverables. Under DFARS, technical data pertaining to commercial products or services developed exclusively at private expense is commonly governed by 252.227-7015, which provides a more limited Government license than unlimited rights. Commercial computer software is often acquired under the contractor’s **customary commercial license**, subject to federal law and agency policy — not under the full other-than-commercial restricted-rights regime — though the contract must still be read carefully for incorporated DFARS/FAR clauses, negotiated addenda, and marking requirements. Under the FAR, commercial computer software may be addressed through policy favoring customary commercial licenses and, where used, clauses such as 52.227-19 (*Commercial Computer Software License*), which sets minimum Government use/duplication/disclosure rights and requires a prescribed notice on delivered software. Failure to manage commercial vs. other-than-commercial characterization — and the corresponding clause set — is a common source of unintended rights grants. **Small Business Innovation Research (SBIR) / Small Business Technology Transfer (STTR)** SBIR and STTR awards use a distinct data-rights structure (for DoD, see DFARS 252.227-7018). Under the current DoD implementation of the SBA Policy Directive, SBIR/STTR data rights generally protect covered data for a **single, non-extendable 20-year** protection period from award (unless otherwise negotiated after award), after which the Government typically receives **perpetual government purpose rights** rather than automatic conversion to unlimited rights. Companies performing SBIR/STTR work should not assume the ordinary 7013/7014 mixed-funding ladder applies unchanged. **Preexisting IP vs. IP developed under the contract — the practical map** | Situation | Commercial analogy (Chapter 14) | Federal rights tendency | |---|---|---| | Platform, libraries, models, or code **already developed at private expense** before the contract, delivered or used under the contract | Background / preexisting IP | Eligible for limited / restricted rights **if** properly asserted, marked, and segregable; commercial items may use commercial-item clauses / customary licenses | | New modules, documentation, or software **first developed under the contract with Government funds** | Foreground IP paid for by the customer | Typically unlimited rights (DFARS) or broad Government license under FAR data clauses | | Development with **both** private and Government funding | “Improvements” / mixed funding disputes | Typically government purpose rights under DFARS for the mixed-funded portion | | **Minor modifications** to privately developed items | Thin customization on background IP | Often still treated with the privately developed item — but “minor” is contested; material Government-funded redesign can change the analysis | | **Subject invention** conceived or first actually reduced to practice under a funding agreement | Patent assignment / ownership clause | Contractor may retain title under Bayh-Dole if disclosure/election/reporting duties are met; Government receives a paid-up license and retains march-in rights | --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Treating FAR/DFARS rights as if they were ordinary commercial ownership clauses — or fighting mandatory terms the Government cannot waive** Commercial counsel sometimes negotiate a strong preexisting-IP schedule and assignment of deliverables, then leave the FAR/DFARS clause set untouched — or, conversely, burn negotiation capital trying to delete prescribed clauses or negate unlimited rights in exclusively Government-funded work. Both mistakes are costly. In federal work, the prescribed clause set often **controls the Government’s license** regardless of how elegantly the commercial ownership language is drafted. A schedule that says “Vendor retains all preexisting IP” does not, by itself, prevent the Government from obtaining unlimited rights in software modules first developed under the contract with Government funds — and it does not preserve restricted rights in preexisting modules if assertion and marking requirements are missed. Equally, asking the Contracting Officer to remove a prescribed data-rights clause, waive the Bayh-Dole Government license, or accept less than the regulatory limited/restricted floor is usually asking for something the agency cannot grant in ordinary negotiations. Put the effort into delivery scope, commercial-item characterization, private-expense segregation, government purpose periods, priced additional rights, and specially negotiated licenses within those floors (see Section 1). Read the solicitation and award as a layered stack: (1) FAR/DFARS clauses and agency supplements; (2) attachments listing asserted restrictions; (3) commercial license or data-rights assertions; (4) the SOW’s delivery requirements (source code, schemas, APIs, training data, model weights, operations and maintenance (O&M) manuals). Delivery requirements frequently expand what must be furnished — and therefore what rights must be granted or asserted. **2. Confusing “we paid for it with IR&D” with “we can withhold everything”** Two different questions are easy to conflate: 1. **Must the company deliver** the software or technical data at all? 2. **What license rights** does the Government obtain in what is delivered? Private-expense development answers the second question, not the first. Developing software with IR&D or other private funds can support **limited rights** in technical data or **restricted rights** in computer software — if the item is segregable, properly asserted, and properly marked. It does **not** mean the company may refuse to deliver whatever the contract’s SOW and CDRLs require. “We built this at private expense” is an argument about the **rights category** that attaches to a required delivery; it is not a privilege to withhold the delivery itself. Under FAR 52.227-14 (*Rights in Data—General*), there is a limited alternative in some configurations: the contractor may withhold qualifying limited rights data or restricted computer software from delivery and instead furnish **form, fit, and function** data — enough information for the Government to understand interfaces and interchangeability without receiving the proprietary detailed design or source. That path exists only where the clause (including any applicable alternates) and agency practice allow it. It is not automatic, and it does not apply merely because the company prefers not to deliver source code. Under DFARS, the posture is usually stricter. The Government can require delivery of privately developed software or technical data that the contract specifies. The contractor’s protection is to assert and mark the correct rights category (restricted or limited) so that the Government’s use and disclosure are constrained — not to decline delivery. A company that treats an IR&D origin as a withholding right, then refuses a CDRL delivery, risks breach, cure notices, and loss of the cooperative posture needed to sustain its assertions. The practical sequencing follows from that distinction: - **At proposal:** negotiate what must be delivered (object code vs. source; manuals vs. detailed design; form/fit/function vs. manufacturing data). Delivery scope is often more negotiable than the clause set. - **At award and performance:** for whatever *is* required to be delivered and was developed exclusively at private expense, assert, segregate, and mark restricted or limited rights. - **Do not** wait until delivery is due and then argue that private expense means nothing need be furnished. Private expense preserves commercial value **inside** the required delivery package. It does not delete the delivery package. **3. Missing identification and assertion of restrictions (DFARS 252.227-7017)** DoD solicitations commonly require offerors to identify technical data and computer software to be furnished with less than unlimited rights, state the basis for the assertion, and specify the asserted rights category. Failure to submit a complete, signed assertion package can render an offer ineligible for award or leave the contractor without a contractual anchor for later markings. Assertions should be maintained as living records when new subcontractors, modules, or open-source components enter the deliverable set. **4. Delivering without required restrictive legends** An **assertion** under DFARS is the contractor’s formal identification — typically under DFARS 252.227-7017 before award, and then as a contract attachment — that specified technical data or computer software will be furnished with less than unlimited rights, stating the basis (for example, developed exclusively at private expense) and the asserted rights category (limited, restricted, government purpose, SBIR/STTR, or specially negotiated). Assertion without marking is incomplete. DFARS permits the contractor (and its subcontractors or suppliers) to assert restrictions on the Government’s rights **only by marking** the deliverable subject to restriction.[^2] The assertion list attached to the contract identifies what the contractor *claims*; the legend on the delivered item is what actually restricts use and disclosure. [^2]: The marking rules come from the DFARS clauses themselves — principally paragraph (g) of DFARS 252.227-7013 (technical data) and DFARS 252.227-7014 (computer software), with parallel treatment under DFARS 252.227-7018 for Small Business Innovation Research (SBIR) / Small Business Technology Transfer (STTR) data, and implementing guidance at DFARS 227.7103-10 and 227.7203-10. **Only authorized legends count.** Except for limited exceptions (such as a copyright notice under 17 U.S.C. § 401 or 402, or a preexisting restrictive legend that still applies from a prior contract), the clauses authorize specific legends only — typically government purpose rights, limited rights (technical data), restricted rights (computer software), special license rights, and the SBIR/STTR data rights legend where that clause applies. Each clause reprints the required legend text.[^3] [^3]: Homemade stamps — “Proprietary,” “Confidential,” “Company Sensitive,” or a commercial end-user license agreement (EULA) footer — are **nonconforming**. They do not create DFARS restrictions. The Contracting Officer can require correction; if the contractor fails to correct within the prescribed period (commonly 60 days after notice), the Government may ignore or strike the nonconforming marking at the contractor’s expense. **How marking must be effected.** The clauses require the contractor to mark **conspicuously and legibly**: - Place the authorized legend on the **transmittal document** or **software storage container**, and on **each page** (or portion) of printed material containing the restricted software or data. - For software transmitted electronically from one computer or terminal to another, include a **notice of asserted restrictions** with the transmission. - Do **not** insert instructions that interfere with or delay operation of software solely to display a restrictive legend — especially software that will or might be used in combat or combat-simulation conditions — unless the Contracting Officer has given written permission. - For computer software documentation, affix to the transmittal document a statement of the license rights obtained. - Under DFARS 252.227-7014, the contractor generally **may not deliver software with restrictive markings unless that software is listed** on the contract attachment identifying asserted restrictions. Marking an item that was never asserted (or never added by permitted post-award assertion procedures) is another path to nonconformance or challenge. **Reproduction of markings.** The legends themselves require that any reproduction of the marked software or data — or portions of it — also reproduce the markings. Downstream copies without the legend lose the visual cue the Government and support contractors rely on. **Consequence of omission.** Technical data or computer software delivered or otherwise provided **without** restrictive markings is **presumed** delivered with **unlimited rights** and may be released or disclosed without restriction. That is a clause-driven presumption, not a courtesy. Correction is possible but limited: the contractor may request permission, at its expense, to place conforming and justified markings on unmarked deliverables. The request must ordinarily reach the Contracting Officer within **six months** after delivery (or a Contracting Officer-approved extension), identify the unmarked items, show the omission was inadvertent and the proposed marking is justified and conforming, and **acknowledge in writing that the Government has no liability** for any use, reproduction, or disclosure made before the marking was added. Even if correction is granted, interim unrestricted use may already have occurred. **Unjustified vs. nonconforming.** A marking in the wrong *format* is nonconforming and corrected under the marking paragraphs. A marking that uses the right format but asserts rights the contractor is not entitled to is **unjustified** and is challenged under the validation clauses (DFARS 252.227-7019 for software; DFARS 252.227-7037 for technical data). Either path can strip the restriction. Marking is therefore an operations and configuration-management problem as much as a legal drafting problem: release checklists, build systems, and software bill of materials (SBOM) processes must apply the **correct authorized legend** to the **correct segregable item**, tied to the contract assertion attachment, before anything ships to the Government. **5. Letting Government-funded “improvements” swallow preexisting platforms** This is the federal version of Chapter 14’s improvements-clause problem. A company delivers a commercial engine developed at private expense, then performs extensive Government-funded adaptation. If the parties and the cost accounting treat the work as creating new software rather than minor modification of preexisting software, the Government may obtain broader rights in the adapted whole — or at least in newly developed modules. Protect preexisting value by: - identifying preexisting software and data at the lowest practicable segregable level before performance; - documenting private-expense development (IR&D records, prior commercial releases, version control history); - scoping Government-funded work as integration, configuration, or segregated new modules where accurate; and - avoiding SOW language that characterizes the entire platform as being “developed under” the contract. **6. Applying the wrong clause set to commercial software** Commercial computer software sold with a standard end-user license agreement (EULA) can still be pulled into an other-than-commercial DFARS clause set through the prime contractor’s template, a poorly scoped CDRL, or an agency’s insistence that the software is “developed” under the program. Conversely, software that is not actually commercial may be mislabeled as commercial to avoid data-rights scrutiny — a characterization the Government can challenge. Confirm commercial-item status against the FAR definition and the actual sales history, and confirm which of 7013/7014/7015 (or FAR 52.227-14 / 52.227-19) the contract actually incorporates for each deliverable category. **7. Ignoring flow-down and subcontractor rights** Prime contractors must flow down data-rights clauses and respect subcontractor restrictive markings. A prime contractor that strips subcontractor legends or delivers subcontractor software to the Government with broader rights than the subcontract allows creates liability upstream and downstream. Subcontractors should ensure the subcontract preserves their assertion/marking rights and does not grant the prime contractor a broader license than the prime contractor needs to perform. **8. Separating patents from data rights — or forgetting Bayh-Dole duties** Subject inventions under funding agreements typically allow contractor title retention under FAR 52.227-11 if the contractor discloses the invention, elects title, and files/reports as required. Missing disclosure deadlines can forfeit title. Even when title is retained, the Government receives a license to practice the invention, and march-in rights remain a residual risk in defined circumstances. Patent filings and data-rights markings should be coordinated so that public disclosure, marking strategy, and invention reporting do not conflict. **9. Assuming SBIR protection is perpetual unlimited-rights avoidance** SBIR/STTR protection is powerful but time-bounded and clause-specific. Under current DoD rules, the long protection period is followed by perpetual government purpose rights in covered SBIR/STTR data — not by a permanent commercial lockout of Government use for government purposes. Transition planning for Phase III (follow-on commercialization or procurement after the SBIR/STTR research phases) and other follow-on vehicles should reflect the post-protection rights posture. --- #### Section 3 — Negotiating as the Direct Contracting Party with the Government (the Prime Contractor) When the company is the prime contractor or a direct contractor to a civilian or DoD agency: - **Separate mandatory structure from negotiable terms before the first mark-up.** Confirm which FAR/DFARS clauses are prescribed for the solicitation. Do not open with demands to delete those clauses, negate unlimited rights in exclusively Government-funded development, waive Bayh-Dole Government license/march-in features, or drive below the limited/restricted floor. Open instead on delivery scope, commercial-item path, assertion/segregation strategy, government purpose rights period, priced grants of additional rights, and specially negotiated licenses the regulation actually permits. - **Map deliverables to clause sets before proposal.** Separate commercial computer software, commercial technical data, other-than-commercial software, other-than-commercial technical data, and SBIR/STTR data. Confirm which FAR/DFARS clauses the solicitation prescribes for each. - **Build the assertion list early (DFARS 252.227-7017).** Identify each item to be delivered with less than unlimited rights; state private-expense or other basis; assign limited, restricted, government purpose, SBIR/STTR, or specially negotiated rights. Update for subcontractors. - **Segregate preexisting IP at the lowest practicable level.** Use module, repository, and SBOM discipline consistent with Chapter 7 and Chapter 14 schedules. Private-expense arguments fail when preexisting and Government-funded code are inseparably commingled in cost accounts and source trees. - **Negotiate specially negotiated licenses only deliberately — and usually after award posture is clear.** DFARS permits mutually agreed special licenses and encourages consideration of them when they better balance the parties’ interests, but the Government is not required to accept less than the standard grant, the contractor is not required to grant more, and award is not to be conditioned on agreeing to negotiate a special license. Trade price, exclusivity of maintenance, or delivery of form/fit/function substitutes against broader rights requests; document the special license in the contract. - **Align the SOW and CDRLs with the rights strategy.** If the company will not deliver source code, say so in the proposal and keep CDRLs consistent. A rights assertion for restricted rights in source is of limited value if the CDRL requires unmarked source delivery. - **Implement marking in the release process.** Authorized legends only; correct expiration dates for government purpose or SBIR/STTR periods; no homemade “proprietary” stamps in lieu of DFARS legends. - **Preserve Bayh-Dole compliance.** Invention disclosure procedures, election of title, and filing deadlines belong in the same closing checklist as data-rights markings. Do not treat statutory Government license or march-in features as commercial delete-sets. - **Price the rights.** Unlimited rights in core engines are a commercial concession. If the Government requires them beyond what the standard funding-based grant already provides — or requires delivery that effectively forces that outcome — the proposal should reflect that value, or substitute a segregated Government-funded module architecture that leaves the commercial core under restricted or commercial licenses. --- #### Section 4 — Negotiating as a Downstream Contractor (the Subcontractor to the Prime Contractor) When the company performs as a subcontractor on a covered program — including as a commercial software vendor whose product the prime contractor will deliver to the Government: - **Do not rely on the commercial EULA alone.** Require the subcontract or teaming agreement to identify the applicable FAR/DFARS clauses, attach the company’s assertion list, and obligate the prime contractor to flow markings unchanged to the Government. - **Prohibit the prime contractor from granting the Government greater rights than the company granted the prime contractor.** Expressly bar unmarked delivery, legend stripping, and “unlimited rights” characterizations of the company’s preexisting commercial software. - **Keep preexisting commercial software on a commercial-item path where accurate.** Resist SOW language that recharacterizes commercial products as being developed under the prime contract. Prefer DFARS 252.227-7015 / commercial computer software treatment over 7013/7014 for qualifying commercial deliverables. - **Control Government-funded modifications.** If the prime contractor or agency funds enhancements, define whether those enhancements are segregable new modules (with corresponding Government rights) or minor modifications to commercial software (retaining commercial/restricted treatment). This is the Chapter 14 improvements fight with regulatory consequences. - **Require notice of challenges to asserted restrictions.** DFARS provides Government challenge procedures; the subcontractor needs prompt notice and control of the response for its own assertions. - **Address open source and third-party components.** Federal delivery of software containing third-party or open-source components requires rights sufficient to grant what the FAR/DFARS clause grants. Map Chapter 7 SBOM obligations to assertion tables and indemnity/flow-down risk. - **For international parents and foreign performance.** Additional DFARS/FAR restrictions may apply to foreign ownership, overseas contracts, and disclosure to foreign governments. Coordinate with Chapter 16 international analysis and export controls — data-rights clauses do not replace compliance with the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). --- #### Section 5 — Red Flags and When to Escalate - **A proposal or subcontract incorporates DFARS 252.227-7013/7014 (or FAR 52.227-14) but has no assertion list, no preexisting-IP schedule, and no marking plan.** Without those, preexisting and privately developed software is at material risk of being treated as unlimited-rights material once delivered. - **Negotiation capital is being spent to delete a prescribed FAR/DFARS data-rights or patent clause, to negate unlimited rights in exclusively Government-funded development, to waive Bayh-Dole Government license or march-in features, or to drive below the limited/restricted floor.** Those asks are generally outside what the Contracting Officer can grant in ordinary negotiations. Redirect to delivery scope, commercial-item characterization, segregation/assertions, government purpose periods, priced additional rights, and specially negotiated licenses within regulatory floors. - **The SOW requires delivery of source code, models, training data, or detailed design data for a commercial product that was developed exclusively at private expense.** Broad delivery plus weak assertions can convert a commercial platform into a Government-competitive asset. Escalate before proposal commitment. - **Government-funded development will modify the company’s core commercial engine, and the contract is silent on segregation of preexisting modules from new modules.** This is the federal improvements problem. Resolve module boundaries, cost charging, and rights categories before work begins. - **Deliverables have shipped — or are about to ship — without authorized restrictive legends.** Escalate immediately for marking correction strategy and assessment of whether unlimited rights have attached. - **A prime contractor’s form requires the subcontractor to grant the Government unlimited rights in all software “used in performance,” not merely software first developed under the contract.** That formulation can reach preexisting commercial tools. Narrow to deliverables and to the applicable DFARS/FAR standard grant. - **The company assumes Bayh-Dole title retention without an invention-disclosure process.** Missed disclosure or election deadlines can forfeit patent title even when data rights were handled carefully. - **SBIR/STTR data is being reused in a follow-on or Phase III vehicle without confirming the protection period and post-period government purpose rights posture.** Rights do not remain static across program phases. - **Civilian FAR clauses and DoD DFARS clauses are being analyzed interchangeably on a mixed agency portfolio.** The rights categories and commercial-item pathways differ. Confirm the awarding agency and the clauses actually on contract. - **Open-source or third-party components are embedded in a deliverable that must be provided with Government license rights the company does not hold.** Escalate for substitution, separate assertion, or license expansion before delivery. - **Any dispute, challenge to markings, or Contracting Officer request to validate asserted restrictions.** These are specialized proceedings with short fuses; ordinary commercial IP negotiation postures are not a substitute for DFARS challenge practice. --- #### Key Clause Quick Reference Verify current FAR/DFARS text and any Department of Defense (DoD) class deviations before relying on a specific clause version in a live matter. | Clause / authority | Role | |---|---| | FAR 52.227-14 | Rights in Data—General (civilian / FAR-based) | | FAR 52.227-19 | Commercial Computer Software License (where used) | | FAR 52.227-11 | Patent Rights—Ownership by the Contractor (Bayh-Dole implementation) | | DFARS 252.227-7013 | Rights in Technical Data—Other Than Commercial Products and Commercial Services | | DFARS 252.227-7014 | Rights in Other Than Commercial Computer Software and Documentation | | DFARS 252.227-7015 | Technical Data—Commercial Products and Commercial Services | | DFARS 252.227-7017 | Identification and Assertion of Use, Release, or Disclosure Restrictions | | DFARS 252.227-7018 | SBIR/STTR technical data and computer software rights | | 35 U.S.C. §§ 200–212 | Bayh-Dole Act | --- --- ### Chapter 16 — International IP Considerations & Choice of Law #### Section 1 — What These Provisions Are and Why They Exist International IP considerations in commercial contracts turn on a fundamental feature of IP law: IP rights are territorial. A U.S. patent provides no protection in Germany. A U.S. copyright registration supports no suit in India. A non-compete enforceable in New York is void in California and subject to competition law limits in the EU. Every IP provision in a commercial contract carries implicit assumptions about the applicable legal framework — assumptions that collapse when the contract involves parties, performance, or enforcement across jurisdictions. These provisions exist because the parties to an international commercial contract need to agree on: which country's law governs the substantive IP questions the contract raises; which forum resolves disputes; and how judgments or awards are enforced across borders. Without express agreement on these questions, default rules apply — and the defaults are frequently neither party's preference. The international dimension is not an edge case for software companies. Distribution through APIs, cloud services, and platform licensing is inherently cross-border. A software company that licenses a fraud detection API to a bank in Germany, France, and Brazil simultaneously has entered into three relationships governed by three different bodies of mandatory law — regardless of what the contract's choice of law clause says. --- #### Section 2 — Common Pitfalls in Contracting Practice **1. Treating choice of law as boilerplate** Choice of law clauses determine the substantive rules on ownership, infringement, enforceability, moral rights, copyright duration, and remedies. Selecting governing law without analyzing what that law says about the specific provisions at issue is a significant error. Common examples: *Copyright ownership under French vs. U.S. law:* Under French law (Code de la Propriété Intellectuelle), moral rights are inalienable — individual authors retain attribution and integrity rights regardless of any assignment. A software development contract with a French firm may successfully assign economic rights under New York law while leaving intact inalienable moral rights under French law that the assignment clause cannot reach. *Non-compete enforceability:* California law voids non-competes in commercial agreements under Cal. Bus. & Prof. Code § 16600. New York applies a reasonableness standard. English law enforces non-competes if reasonable in scope, duration, and geographic reach. The same clause has three different outcomes in three jurisdictions. *Patent exhaustion:* Under U.S. law after *Impression Products, Inc. v. Lexmark International, Inc.*, 581 U.S. 360 (2017), an authorized foreign sale exhausts U.S. patent rights. Under other jurisdictions' law, exhaustion may be territorial — a sale in one country may not exhaust rights in a third country. **2. Assuming choice of law resolves the enforcement problem** Choice of law determines what law applies to the merits. It does not determine where judgments are enforceable. A U.S. federal court judgment governed by New York law is not automatically enforceable in Germany, India, China, or Brazil. Courts in these jurisdictions apply their own recognition rules, and many require separate local proceedings to give effect to a foreign judgment — proceedings that may fail on public policy or reciprocity grounds. Arbitration under the 1958 New York Convention addresses this enforcement gap. An arbitral award made in a Convention signatory country is enforceable in a large number of signatory countries through a streamlined recognition proceeding. The choice of law clause and the dispute resolution clause warrant drafting together. See Chapter 17. **3. Ignoring non-waivable local rights** Some IP rights cannot be contracted away regardless of the governing law clause. The EU Software Directive Art. 6 provides a non-waivable right to reverse engineer for interoperability — a contractual prohibition is unenforceable to that extent in EU member states. EU moral rights are inalienable in countries that recognize them broadly. The EU Trade Secrets Directive includes whistleblower exceptions that limit trade secret enforcement in some contexts. The EU AI Act (Regulation (EU) 2024/1689) imposes mandatory transparency, accuracy, and human oversight requirements for high-risk AI applications that cannot be contracted away. These rights exist regardless of what the contract says. **4. Failing to address GDPR data transfer requirements** EU personal data cannot be transferred outside the EU without adequate legal basis — Standard Contractual Clauses (SCCs), Binding Corporate Rules (BCRs), or a country adequacy decision. Any contract involving EU personal data flowing to non-EU systems that does not address the transfer mechanism has a compliance gap that is also an IP problem: the data rights provisions the contract creates may be unenforceable to the extent the underlying data transfer is impermissible. --- #### Section 3 — Negotiating as Licensee in International Contracts - **Select governing law consciously:** Assess what the proposed governing law says about the specific provisions at issue — ownership, non-competes, liability caps, moral rights — before accepting or proposing it - **Require a representation of global rights:** A licensor who represents that it has rights to grant a "worldwide license" should be required to represent that it actually holds the rights in the jurisdictions where the license is operative — not merely that it holds U.S. rights - **Address GDPR transfer mechanisms expressly:** Any contract involving EU personal data should specify the applicable transfer mechanism and require the licensor to maintain that mechanism for the contract's duration - **Require local counsel sign-off on liability caps:** For cross-border indemnification caps, assume the cap may be unenforceable for intentional misconduct or gross negligence claims in the counterparty's jurisdiction and require local counsel confirmation before execution --- #### Section 4 — Negotiating as Licensor in International Contracts - **Address mandatory local rights in the license:** Acknowledge non-waivable rights (EU interoperability, moral rights) rather than attempting to prohibit them — a prohibition that is unenforceable creates false expectations - **Structure the ADR clause with enforcement in mind:** A New York-governed contract arbitrated in Singapore produces an award enforceable in a large number of countries. A New York-governed contract litigated in New York produces a judgment enforceable in a small number of countries. See Chapter 17 for the full ADR design analysis - **Require IP registration in key markets:** For patents and trademarks, a "worldwide" IP portfolio is only as good as the registrations actually obtained. Representations about worldwide rights should be backed by a schedule of registrations or applications --- #### Section 5 — Red Flags and When to Escalate - **A cross-border contract has a choice of law clause that has not been assessed against the specific provisions at issue.** Governing law is not neutral boilerplate. It determines ownership rules, moral rights, non-compete enforceability, exhaustion doctrine, and remedy availability. Selecting New York law without checking what New York (and mandatory local law) say about the actual clauses is a substantive error, not a drafting detail. - **A contract with a European counterparty does not address moral rights, non-waivable interoperability rights, or GDPR data transfer mechanisms.** French and other EU moral rights may survive an assignment of economic rights; EU Software Directive Art. 6 preserves interoperability analysis that contract cannot waive; and personal data leaving the EEA needs a lawful transfer mechanism. Silence on these points creates enforceability and compliance gaps the choice of law clause will not close. - **A cross-border indemnification cap has not been reviewed for enforceability in the counterparty's jurisdiction.** Some jurisdictions refuse to honor liability caps for willful breach or gross negligence. Confirm local enforceability before treating the negotiated cap as the real outer bound of exposure. - **A "worldwide" license grant is not backed by a representation that the licensor actually holds rights in the operative jurisdictions.** IP rights are territorial. A worldwide grant from a licensor that only owns U.S. rights does not create rights the licensor never held. Require a representation (and, for patents and trademarks, a schedule of registrations) covering the markets where the license will actually be used. - **The counterparty is in China, India, Brazil, or another jurisdiction where U.S. judgment enforcement is limited, and enforcement of a potential award has not been assessed.** The choice between court and arbitration is most consequential precisely where foreign court judgments are hard to enforce. Assess New York Convention coverage and practical enforcement before signing (Chapter 17). --- ### Chapter 17 — Alternative Dispute Resolution in IP Contracts #### Section 1 — ADR as a Design Tool, Not a Forum Selection ADR in IP contracts is not merely a choice between court and arbitration. It is a substantive design decision: the parties can use an arbitration agreement to engineer the procedural rules, discovery scope, evidentiary standards, available remedies, and applicable law that will govern any future dispute — replacing the default rules of whichever court would otherwise have jurisdiction with rules the parties control. **The baseline case for arbitration in IP disputes:** - **Enforceability across borders:** A U.S. federal court judgment is not automatically enforceable in most foreign jurisdictions. A foreign arbitral award is enforceable in a large number of countries under the 1958 New York Convention. For international contracts, this is frequently the decisive consideration. - **Technical expertise:** IP disputes involving software architecture, AI models, or data pipeline design require technical understanding that generalist federal judges and lay juries frequently lack. In arbitration, the parties select the arbitrators and can require specific IP or technical qualifications. - **Confidentiality:** Court proceedings are public records. Trade secret litigation in open court risks further disclosing the very information the claimant seeks to protect. Arbitration is private by default. - **Speed:** Complex IP litigation in U.S. federal court may run several years from filing to trial. Arbitration under expedited rules can resolve in a shorter timeframe. - **Neutrality:** For disputes with counterparties in foreign jurisdictions, a neutral seat — London, Singapore, Geneva, Hong Kong — is commercially acceptable to both parties. #### Section 2 — Discovery and Evidence Design Arbitration allows the parties to draft their own discovery and evidence rules. For IP disputes, this is often the primary benefit. In U.S. federal court, broad discovery allows an adverse party to demand production of virtually any document or data "reasonably calculated to lead to the discovery of admissible evidence." In IP disputes, this means a counterparty alleging misappropriation can demand production of the most sensitive technical documentation, model weights, and internal communications — using the discovery process as competitive intelligence. International counterparties may have no equivalent disclosure obligation in their home jurisdictions, creating asymmetric exposure. In arbitration, the parties can agree to: - Limit document production to specific, identified categories - Prohibit or limit depositions - Restrict interrogatories and requests for admission - Establish confidentiality tiers, including "attorneys' eyes only" designations for trade secret materials - Specify that proceedings are governed by the IBA Rules on the Taking of Evidence in International Arbitration — a widely used framework for international commercial disputes For contracts involving particularly sensitive IP, the arbitration clause benefits from specifying that: (a) all proceedings and materials are confidential; (b) designated trade secret materials are subject to a protective order limiting access to named individuals; and (c) the tribunal has authority to sanction breach of the confidentiality order. #### Section 3 — Remedies Design The parties can expand or limit the tribunal's remedial authority in the arbitration clause. Points worth addressing expressly: - **Emergency relief:** Most institutional rules — International Chamber of Commerce (ICC) Art. 29, London Court of International Arbitration (LCIA) Art. 9, Singapore International Arbitration Centre (SIAC) Rule 30, WIPO Art. 48 — provide for emergency arbitrator proceedings. But the clause must also preserve court access for emergency injunctive relief without waiving arbitration — trade secret cases may require a temporary restraining order (TRO) before the arbitration is constituted. - **Specific performance:** Courts are reluctant to order specific performance in commercial disputes; tribunals are often more willing when expressly empowered. For IP contracts where a party needs a counterparty to deliver source code, assign a patent, or certify destruction of materials, specific performance may be more valuable than damages. - **Damages methodologies:** The parties can agree in advance on the methodology for calculating damages by dispute type — actual damages, disgorgement, or reasonable royalty for copyright; reasonable royalty or unjust enrichment for trade secrets; comparable license methodology for patents. Agreed methodology removes a major source of expert dispute. - **Exclusions:** The clause can specify that the tribunal may not award punitive, statutory, or consequential damages — providing a more predictable damages ceiling than litigation. #### Section 4 — ADR as a Choice-of-Law Workaround When local law is unfavorable, a well-drafted arbitration clause can often replace it with a more favorable substantive regime while still producing an award enforceable in the local jurisdiction under the New York Convention. The seat of arbitration determines which courts have supervisory jurisdiction over the proceedings. The substantive governing law is chosen separately. A tribunal seated in Singapore, applying New York law to a dispute between parties from different jurisdictions, produces an award governed on the merits by New York law — but enforceable through local New York Convention recognition proceedings. *Practical examples:* *Germany:* German mandatory law (BGB §§ 307–309) may void liability caps on cardinal obligations and caps on gross negligence claims in court proceedings governed by German law. An arbitration clause applying New York law and seating proceedings in London may allow the cap to function as intended, with the London award remaining enforceable in Germany under the New York Convention (subject to a narrow public policy exception that German courts have historically applied narrowly in commercial disputes). *Brazil:* Brazil's Consumer Defense Code can void contractual liability caps under Brazilian law in certain commercial contexts. An ICC arbitration applying New York law may allow the cap to hold, with the award enforceable in Brazil under the New York Convention. *China:* Arbitration under SIAC or Hong Kong International Arbitration Centre (HKIAC) rules, with a seat in Singapore or Hong Kong, produces an award enforceable in China under the New York Convention. China ratified the New York Convention in 1987 and has generally enforced foreign awards subject to a public policy exception. *The limits:* Truly mandatory local rules — particularly those protecting fundamental public policy — may not be displaced by a foreign choice of law even in arbitration. Local counsel review is warranted before relying on this approach for any jurisdiction with significant exposure. #### Section 5 — International Enforcement: The New York Convention Advantage IP infringement is territorial, but commercial harm from infringement is not. When a counterparty infringes across multiple jurisdictions, a licensor faces a fundamental enforcement problem: separate litigation in each country, under each country's law, before each country's courts, with local counsel, subject to local procedural rules. A judgment in one country has no effect in others. The 1958 New York Convention on the Recognition and Enforcement of Foreign Arbitral Awards has been ratified by a significant number of countries. Under the Convention, signatory courts are required to recognize and enforce arbitral awards made in other signatory countries, subject only to narrow exceptions (invalid arbitration agreement; improper notice; award exceeds scope; violation of public policy). A well-drafted arbitration clause can consolidate multi-country infringement disputes into a single proceeding. The arbitration covers the entire commercial relationship; a single award addresses contractual damages for global conduct; the award is enforced through local New York Convention recognition proceedings in each jurisdiction where the defendant has assets. **What the clause should include for global enforcement:** - Scope language broad enough to capture multi-country infringement as a contractual claim: "all disputes arising out of or relating to this Agreement, including disputes concerning the scope of the license grant, compliance with license restrictions, and any conduct that constitutes both a breach of this Agreement and an infringement of any intellectual property right" - Authority for the tribunal to award damages measured by aggregate global harm - Authority to order injunctive relief applicable to the counterparty's worldwide conduct - Seat selection in a jurisdiction with mature arbitration law and strong New York Convention enforcement: Singapore, London, and Geneva are among the strongest options for global portfolios **Where national proceedings remain necessary:** Statutory IP remedies — criminal prosecution for willful infringement, customs seizure orders, patent office invalidity proceedings, domain name cancellation — are sovereign acts that arbitral tribunals cannot perform. These remedies are pursued through parallel national proceedings. Third-party infringers — entities not party to any contract — must also be pursued through national courts. #### Section 6 — IP-Specific Clause Drafting Checklist Beyond the standard arbitration clause elements (institution, seat, number of arbitrators, language, governing law), IP-bearing contracts warrant attention to the following: **1. Arbitrator qualifications:** Specify that at least one arbitrator shall have demonstrated IP expertise, and for technically complex disputes, at least one shall have relevant technical expertise. **2. Confidentiality:** Expressly state that all proceedings, submissions, and evidence are confidential; that neither party may disclose the existence, nature, or outcome without the other's consent (subject to legal requirements); and that the tribunal has authority to issue protective orders for designated trade secret materials with sanctions for breach. **3. Discovery scope in the clause:** Specify: document production limited to specifically identified categories under the IBA Rules Art. 3 standard; depositions permitted only with tribunal approval; source code production through a secure code review protocol with access limited to designated experts. **4. Emergency court relief carve-out:** "Notwithstanding the foregoing arbitration agreement, either party may seek emergency injunctive, interim, or provisional relief from any court of competent jurisdiction without waiving its right to arbitrate the underlying dispute." Without this carve-out, a court may find the arbitration agreement bars emergency court relief. **5. Validity challenge bifurcation:** Specify how patent or trademark validity challenges will be handled — carved out to the relevant patent office or court; decided by the tribunal with effect binding only the parties; or dealt with by staying the arbitration pending a parallel validity proceeding. **6. Remedies authorization:** Specify what the tribunal is empowered to award (injunctive relief, specific performance, actual damages, disgorgement, reasonable royalty, delivery up and destruction, attorneys' fees) and what it is not empowered to award (punitive damages, statutory damages, consequential damages — if those exclusions are desired). **7. Multi-contract consolidation:** Where multiple related agreements govern the same commercial relationship, each arbitration clause should permit consolidation of related disputes into a single proceeding. **8. Seat and institution selection:** Choose the seat and the administering institution for the deal you have, not for institutional prestige. Three questions usually decide the answer: (1) Where does the counterparty have assets, and where must an award actually be enforced? (2) Where are the parties comfortable appearing? (3) Is the likely dispute ordinary commercial contract litigation, or does it turn on specialized IP or technical issues? Seat, institution, and governing law are separate choices — New York law with a Singapore seat and SIAC rules is a common and coherent combination. | Deal profile | Prefer | Why | |---|---|---| | Cross-border commercial IP deal with multi-country enforcement needs | London (LCIA) or Singapore (SIAC) | Mature arbitration seats with deep commercial experience and strong New York Convention enforcement. Default choices when the counterparty’s assets may be in more than one region. | | Dispute is likely to turn on patents, copyright, trademarks, trade secrets, or complex licensing — including standard-essential patents (SEPs) and FRAND (fair, reasonable, and non-discriminatory) licensing | Geneva (WIPO Arbitration and Mediation Center) | Purpose-built IP rules and a specialized IP arbitrator roster. Prefer when subject-matter expertise matters more than general commercial arbitration volume. | | Counterparty or key assets in Mainland China | Hong Kong (HKIAC), or Singapore (SIAC) as an alternative | HKIAC offers Mainland interim-measures access and mutual-enforcement pathways that go beyond the ordinary New York Convention route. SIAC awards are still enforceable in Mainland China as foreign Convention awards. Pick HKIAC when Mainland interim relief or enforcement is central; pick SIAC when the parties prefer a Singapore seat. | | Parties and assets primarily in the Americas; U.S.-centric commercial relationship | New York (ICDR — international division of the AAA) | Familiar U.S. institutional practice and an Americas-weighted party pool. Prefer when New York Convention advantages matter less than domestic comfort and speed. | | Need for emergency interim relief (trade secret TRO, preservation orders) | Any major institution (ICC, LCIA, SIAC, WIPO, HKIAC, ICDR) — *and* preserve court access | Every major set of rules provides an emergency arbitrator. That is not a substitute for the court-relief carve-out in item 4 above. Trade secret cases often need a court TRO before any tribunal exists. | *Practical rule of thumb:* If the contract is international and enforcement location is uncertain, default to London/LCIA or Singapore/SIAC. If the expected dispute is heavily IP-technical, add WIPO AMC to the shortlist. If Mainland China enforcement or interim relief is material, prefer HKIAC. If the deal is essentially domestic U.S. with an international flavor, ICDR is usually enough. Do not pick a seat solely because one party’s counsel is used to it — pick it because that is where the award needs to work. #### Section 7 — Mediation and Tiered Dispute Resolution For long-term commercial relationships — multi-year platform agreements, joint development agreements, data licensing partnerships — tiered dispute resolution can preserve the business relationship and reduce cost while ensuring binding resolution is available when needed. **Standard tiered structure:** 1. **Good faith negotiation (15–30 days):** Written notice of dispute triggers an obligation for senior representatives to meet and negotiate in good faith. Suspends limitation periods during the period. 2. **Executive escalation (30 days):** Dispute escalated to C-suite or general counsel level. Resolves disputes that deadlocked at the working level. 3. **Mediation (30–60 days):** Non-binding mediation before a neutral. The 2019 Singapore Convention on International Settlement Agreements Resulting from Mediation makes mediation settlements enforceable in a growing number of signatory countries — making mediation a more powerful mechanism for international IP disputes than it was historically. 4. **Arbitration:** Binding resolution if mediation fails. All prior proceedings are confidential and without prejudice. **One drafting caution:** Mandatory pre-arbitration steps must be drafted carefully. Courts and tribunals have found that mandatory steps, if not completed, deprive the tribunal of jurisdiction. Specify exact trigger conditions, time periods, and what constitutes completion of each step. --- --- --- ## Appendix A — IP Counsel Request Form This appendix reproduces the standalone file `IP_Counsel_Request_Form.md` for convenience. Contracts counsel may copy either version, complete the fields as best they can, and send the form with the draft when requesting IP assistance — then schedule a short working call if one is feasible. The form is the foundation for every request, with or without a call. Completing it helps IP counsel stay organized, prioritize the matter, and allocate the appropriate time and depth so overlapping work can be delivered on time. Blank fields are fine when information is unknown — note that and send rather than delaying the request. Brief guidance under each field explains why the information helps; it is not a requirement to write a memo. See Part II, Chapters 4–5. --- ### 1. Request logistics | Field | Your answer | |---|---| | **Date of request** | | | **Requestor name / team** | | | **Matter or deal name** | | | **Draft attached?** | ☐ Yes — filename/link: _______________ ☐ Not yet (describe status): _______________ | | **Marked-up comments in the draft?** | ☐ Yes ☐ No — key clauses flagged below instead | | **Deadline for the IP deliverable (date and time)** | **Business or customer deadline driving it (if different)** | |---|---| | <br> | <br> | *Guidance:* A specific date lets IP counsel schedule the work and match depth to the time available. If the real constraint is a business or customer deadline, say that too (for example: “customer needs a response by Monday”). | **What happens if that deadline is missed?** | |---| | <br><br> | --- ### 2. Specific request What do you need back? Check all that apply: - ☐ Draft redline language and a short explanation I can send to opposing counsel - ☐ Join a call with opposing counsel on a specific IP issue - ☐ Review opposing counsel’s redlines — what is acceptable, what to push, what to trade - ☐ Short risk evaluation against customer requirements / RFP / SOW - ☐ Confirm whether a proposed compromise creates patent, data-rights, open-source, or ownership exposure - ☐ Identify which IP issues are worth holding if the deal must close on a fixed date - ☐ Working call with me to review flagged provisions together (preferred when feasible) - ☐ Other: ________________________________________________ | **In one sentence, what deliverable do you need?** | |---| | <br><br> | *Guidance:* Naming the form of help needed usually yields something you can use on the next negotiation turn. “Review the IP” leaves the output form to guesswork. --- ### 3. Deal and counterparty | Field | Your answer | |---|---| | **Counterparty name** | | | **Counterparty role** | ☐ End customer ☐ Embedder / OEM ☐ Vendor ☐ Reseller / integrator / channel ☐ Co-developer ☐ Other: _______ | | **Relative size, legal sophistication, and market power** | | | **Approximate contract value and term** | | | **Governing law / seat (if known)** | | | **Cross-border element?** | ☐ No ☐ Yes — jurisdictions: _______________ | *Guidance:* The same license, indemnity, or data clause reads differently depending on whether the other party is a customer, vendor, embedder, or co-developer — and on how much leverage each side has. --- ### 4. Technology and intended use | **What does the software or technology do? (2–4 sentences)** | |---| | <br><br><br><br> | **How the company plans to use it:** - ☐ Internal use only - ☐ Embedded in or combined with a company product or service sold to others - ☐ Resold or sublicensed - ☐ Touches customer or company proprietary data - ☐ Used to train, fine-tune, or improve a model - ☐ Other: ________________________________________________ *Guidance:* A field-of-use limit or combination carve-out that is harmless for internal tools can be deal-breaking for a commercialized product. --- ### 5. Commercial constraints | **Why does the company need this deal?** | |---| | <br><br><br> | | **What happens if the deal does not close?** | |---| | <br><br><br> | **What has already been agreed in principle** (pricing, go-live, “accept their paper,” indemnity caps, ownership, term sheet points, side emails): | **Response** | |---| | <br><br><br><br> | **Negotiating leverage / alternatives:** - ☐ Sole-source / limited alternatives - ☐ Competitive field / ready substitutes - ☐ Renewing incumbent - ☐ New relationship - ☐ Time pressure on our side - ☐ Time pressure on their side - ☐ Notes: ________________________________________________ *Guidance:* IP analysis works best inside commercial constraints already set. Where a point has been conceded, a targeted fix is usually more useful than reopening settled ground. --- ### 6. Screening flags Check any that apply (see Part II for why these matter): - ☐ New product or feature about to be publicly described, demonstrated, sold, or put into commercial use - ☐ Inbound license in a field where the company already has related development (consider provisional filing *before* receiving confidential information) - ☐ AI / ML components, training data, model improvement, feedback loops, or platform-published AI content - ☐ Company’s proprietary data involved - ☐ Custom development, co-development, or improvements / ownership fight - ☐ Source code or substantial technical delivery - ☐ U.S. Government prime, federal subcontract, or SBIR/STTR - ☐ Open source exclusion or non-standard open source indemnity fight - ☐ Co-branding / publicity / name-image-likeness issues - ☐ Other non-standard IP issue: ________________________________________________ --- ### 7. Provisions of concern List the two or three provisions that most need IP attention: | Provision / clause location | Concern or help requested | |---|---| | 1. <br><br> | <br><br> | | 2. <br><br> | <br><br> | | 3. <br><br> | <br><br> | **Anything else IP counsel should know before starting?** | **Response** | |---| | <br><br><br> | --- ### 8. Attachments checklist - ☐ Current draft (Word / PDF) - ☐ Prior redlines or counterparty mark-up - ☐ Term sheet / RFP / SOW / customer requirements - ☐ Related NDAs or prior agreements with this counterparty - ☐ SBOM or open source disclosure (if available) - ☐ Other: ________________________________________________ --- *Please send a completed form with the draft whenever you can. Incomplete answers are better than delaying the request — IP counsel can follow up on gaps. A short call on top of the form is welcome when schedules allow.* --- ## Disclaimer This document is provided for informational and educational purposes only. It does not constitute legal advice, and no attorney-client relationship is created by reading, downloading, or using this document in any form. Readers with specific legal questions should consult qualified counsel in the relevant jurisdiction. The views expressed in this document reflect the author's independent analysis and do not necessarily represent the positions of any current or former employer, client, or affiliated organization. This document was prepared with the assistance of generative AI tools and may contain inaccuracies such as mischaracterization of legal principles, oversimplification of nuanced doctrines, citation issues, and the introduction of errors that may not be apparent on review. Readers should independently verify any legal authority cited before relying on it. Nothing in this document should be read as an assertion that any particular outcome is certain, that any legal standard described is universally applicable, or that the analysis provided is complete with respect to any specific set of facts or jurisdiction. --- *© Paul Roberts | Modern Patent Law | modernpatentlaw.com*