Code Escrow, Liability and Licensing Contracts

Why This Topic Matters
Modern software is rarely built entirely in-house. Organizations acquire commercial off-the-shelf (COTS) products, outsource development, integrate open source components, and consume cloud services. Every one of these relationships creates dependency on a third party that the acquirer does not control. If that supplier goes bankrupt, is acquired, discontinues a product, or simply refuses to fix a critical vulnerability, the acquiring organization may be left with software it cannot maintain, patch, or legally continue to use. The CSSLP recognizes that contractual and legal controls are as much a part of software security as encryption and input validation. Code escrow, liability clauses, and licensing contracts are the mechanisms that transfer, share, or mitigate supply chain risk before a single line of vendor code is deployed. For the exam, this topic sits within Domain 8 (Secure Software Supply Chain), specifically under supplier risk assessment and the contractual requirements for software acquisition. Questions tend to test whether you understand which legal instrument addresses which risk, and what the acquirer should insist upon to protect itself.

Part 1: Code Escrow

What It Is
Code escrow (also called software escrow or source code escrow) is a three-party arrangement in which a software vendor (the depositor or licensor) deposits the source code, build instructions, documentation, and other materials with a neutral third party known as the escrow agent. The acquirer (the beneficiary or licensee) gains the right to receive those materials if specific, pre-defined release conditions (sometimes called trigger events) occur. Until a trigger occurs, the licensee only has the compiled binaries and the vendor retains full control of its intellectual property.

Why It Exists
The core problem escrow solves is business continuity risk. If you license a mission-critical application and the vendor ceases to exist, you cannot fix defects, patch security vulnerabilities, or adapt the software to new platforms without source code. Escrow gives the licensee a recoverable path forward while protecting the vendor from having to hand over its trade secrets to every customer up front. It balances two competing interests: the vendor wants to protect its IP, and the customer wants assurance of long-term supportability.

How It Works
1. Agreement: The vendor, licensee, and escrow agent sign a tripartite escrow agreement that defines what is deposited, how often it is updated, what the release conditions are, and what the licensee may do with released materials.
2. Deposit: The vendor deposits source code, build scripts, compiler and toolchain details, third-party library lists, database schemas, design documentation, and anything else needed to rebuild and maintain the product. A deposit missing any of these is effectively useless.
3. Verification: The escrow agent (or an independent party) may verify the deposit. Verification is tiered: Level 1 confirms the media is readable and the file inventory matches the manifest; Level 2 confirms the code can actually be compiled into a working build; Level 3 confirms the compiled build functionally matches the production software the licensee is running. Higher verification levels cost more but provide far greater assurance. Many escrow failures occur because the deposit was never verified and turned out to be incomplete or outdated when it was finally released.
4. Maintenance: The agreement should require deposit updates on a schedule (for example, every major release or at least annually) so that the escrowed version does not drift from the deployed version.
5. Release Conditions: Common triggers include vendor bankruptcy or insolvency, cessation of business, discontinuation of the product, failure to meet maintenance or support obligations, material breach of the license agreement, or acquisition by a competitor. The conditions must be objectively verifiable to avoid disputes.
6. Release and Use Rights: Upon a validated trigger, the escrow agent releases the materials to the licensee. The agreement must specify what the licensee may then do: typically maintain, modify, and support the software for its own internal use, but not resell or redistribute it. Without explicit use rights, possessing source code grants no legal right to modify it.

Security Considerations for Escrow
The escrow deposit itself is a high-value target because it contains complete source code. The escrow agent must provide physical and logical security, access controls, encryption of deposits, and audit trails. Acquirers should assess the escrow agent as a supplier in its own right. Additionally, the escrow deposit should include a Software Bill of Materials (SBOM) so the licensee knows what third-party and open source components are embedded and what their license obligations are.

When Escrow Is Appropriate
Escrow makes sense when the software is mission-critical, the vendor is small or financially uncertain, the software is highly customized, or switching costs are very high. It is less relevant for commodity software with many substitutes or for SaaS offerings where the data, not the code, is the main continuity concern (SaaS escrow variants exist that also cover hosted environments and data).

Part 2: Liability

What It Is
Liability in a software context refers to who bears legal and financial responsibility when the software fails, causes damage, infringes a third party's intellectual property, or contains security vulnerabilities that lead to a breach. Software contracts manage liability through several interlocking clauses.

Key Liability Mechanisms
Warranties: A warranty is a promise about the software's condition or performance. Express warranties are written into the contract (for example, that the software will perform substantially in accordance with documentation for 90 days, or that it contains no known malicious code). Implied warranties, such as merchantability and fitness for a particular purpose, arise by law in many jurisdictions unless expressly disclaimed. Most vendors disclaim implied warranties and offer limited express warranties. From a security perspective, acquirers should negotiate warranties that the software was developed using secure development practices, has been tested for common vulnerability classes, and is free from known vulnerabilities at delivery.
Indemnification: An indemnity is a promise by one party to compensate the other for specified losses. The most common is IP indemnification, where the vendor agrees to defend and pay for claims that its software infringes someone else's patent, copyright, or trade secret. Security-related indemnification, where the vendor covers breach costs arising from defects in its code, is harder to obtain but increasingly negotiated.
Limitation of Liability: Vendors almost always cap their total liability, often at the fees paid in the preceding twelve months, and exclude consequential, indirect, and punitive damages. Acquirers should attempt to carve out exceptions to the cap for gross negligence, willful misconduct, breach of confidentiality, data breach, and IP indemnification. Understanding the cap is critical: a liability cap of one year of license fees may be trivial compared to the cost of a breach.
Disclaimers: Software is frequently licensed as is, particularly open source software, which disclaims virtually all warranties and liability. This means the acquirer absorbs the full risk of defects. Organizations consuming open source must recognize that there is no one to sue and no contractual remedy; the mitigation is internal due diligence, scanning, and maintaining the ability to patch.
Service Level Agreements (SLAs): SLAs define measurable performance and support commitments, such as uptime percentages, incident response times, and patch delivery timelines for vulnerabilities of a given severity. SLAs should include remedies (service credits, termination rights) for failure. For security, SLAs should specify the vendor's obligation to notify the acquirer of vulnerabilities and breaches within a defined period.
Right to Audit: This clause allows the acquirer to inspect the vendor's security practices, development processes, and compliance evidence. It transforms vendor security promises from assertions into verifiable commitments.

Liability and the Supply Chain
Liability flows down the chain. If your product incorporates a vendor's library and that library causes harm to your customer, your customer sues you, not the library vendor. Your contract with the vendor determines whether you can recover. This is why flow-down clauses, requiring your suppliers to accept obligations equivalent to those you owe your customers, are essential in multi-tier supply chains. Regulatory trends, including software liability proposals in several jurisdictions, are gradually shifting responsibility toward software producers, which makes contractual clarity more important each year.

Part 3: Licensing Contracts

What a License Is
Software is protected by copyright. The copyright holder has exclusive rights to copy, modify, and distribute the work. A license is permission granted by the copyright holder to do things that would otherwise be infringement. Using software without a valid license, or in violation of license terms, is copyright infringement and may also be breach of contract. Licensing contracts define the scope of permitted use, restrictions, duration, fees, and the obligations of each party.

Proprietary Licensing
Commercial licenses typically grant a limited, non-exclusive, non-transferable right to use the software in object code form only. Important terms include: scope (per user, per device, per CPU core, per site, enterprise-wide, or subscription), restrictions (no reverse engineering, no decompilation, no redistribution, no use beyond the licensed metric), term (perpetual versus subscription), maintenance and support (often a separate recurring fee that funds security patches), and termination (what happens to the acquirer's data and right to use upon expiry or breach). End User License Agreements (EULAs) are the consumer-facing form, usually accepted by clicking through, and are typically non-negotiable. Enterprise agreements and master services agreements are negotiated and can include escrow, security warranties, and audit rights.

Open Source Licensing
Open source licenses grant broad rights to use, study, modify, and redistribute, but attach conditions. The CSSLP expects you to distinguish the main categories:
Permissive licenses (MIT, BSD, Apache 2.0): Allow use in proprietary products with minimal obligations, typically preserving copyright notices and, for Apache, stating changes and including the license text. Apache 2.0 also includes an express patent grant, which is valuable for reducing patent liability.
Weak copyleft licenses (LGPL, Mozilla Public License, Eclipse Public License): Require that modifications to the licensed component itself be released under the same license, but allow the component to be linked with or combined into proprietary code under certain conditions. LGPL, for example, generally permits dynamic linking with proprietary code while requiring that modifications to the library itself be shared.
Strong copyleft licenses (GPL v2, GPL v3): Require that any distributed work that incorporates or is derived from the licensed code be released in its entirety under the same license, including source code availability. This is the viral effect that can force disclosure of proprietary source code if GPL code is improperly incorporated and distributed. GPL v3 adds anti-tivoization and explicit patent provisions.
Network copyleft (AGPL): Extends copyleft to software offered as a network service, closing the SaaS loophole where GPL obligations were avoided because the software was never distributed.
Public domain and permissive equivalents (Unlicense, CC0): Waive copyright entirely.

License Compliance as a Security Control
License compliance is a supply chain risk. Using a component in violation of its license exposes the organization to injunctions, forced source disclosure, and reputational damage. Compliance requires: maintaining an accurate SBOM; using Software Composition Analysis (SCA) tools to detect components and their licenses; establishing an open source policy that defines approved, restricted, and prohibited licenses; reviewing license compatibility when combining components (for example, GPL v2 and Apache 2.0 are generally considered incompatible); fulfilling attribution and notice requirements in distributed products; and training developers to avoid copying code from unknown sources. The same SBOM that supports license compliance supports vulnerability management, which is why the CSSLP treats these as unified supply chain practices.

Licensing in the Development Context
Beyond consuming licensed software, development organizations must also consider the licenses of their tools (compilers, IDEs, testing frameworks), the licenses they grant to their own customers, and work-for-hire and IP assignment clauses with contractors and outsourced developers. If a contractor writes code and the contract does not assign copyright to the paying organization, the contractor may legally own that code. Development contracts must address IP ownership, ownership of deliverables, treatment of pre-existing contractor IP, and the contractor's obligations regarding open source they introduce.

Part 4: Integrating These Controls into the Acquisition Lifecycle
The CSSLP frames supply chain security as a lifecycle. In the planning phase, define security requirements, including escrow needs, acceptable license types, and minimum liability terms. In supplier assessment, evaluate the vendor's financial stability (informs escrow need), security maturity (informs warranties and audit rights), and licensing posture. In contracting, negotiate the specific clauses: escrow with verification, security warranties, vulnerability notification and patching SLAs, IP and security indemnification, audit rights, flow-down requirements, SBOM delivery, and defined license scope. In acceptance, verify deliverables against the contract, including confirming escrow deposits and reviewing the SBOM for license conflicts. In operations and maintenance, monitor the vendor's continued compliance, update escrow deposits, track license renewals, and re-scan for newly discovered vulnerabilities and license changes. In disposal or transition, enforce data return and destruction clauses and ensure continued rights to use escrowed code if needed.

Exam Tips: Answering Questions on Code Escrow, Liability and Licensing Contracts

Tip 1: Match the risk to the instrument. If the question describes a vendor that might go out of business, be acquired, or stop supporting a product, the answer is almost always code escrow. If it describes a third party claiming the software infringes a patent, the answer is IP indemnification. If it describes uptime, response times, or patch timelines, the answer is SLA. If it describes needing to inspect the vendor's practices, the answer is right to audit. If it describes being forced to release proprietary source code, the answer involves copyleft (GPL) license violation.

Tip 2: Remember escrow is three parties. Questions may offer distractors where the vendor gives code directly to the customer, or the customer holds the code itself. Neither is escrow. Escrow requires a neutral escrow agent, a depositor, and a beneficiary.

Tip 3: Escrow is only as good as its verification and currency. If a question asks what the greatest weakness of an escrow arrangement is, or what most commonly causes escrow to fail, look for answers about unverified, incomplete, or outdated deposits. Knowing that the escrowed code can actually be built (Level 2 verification) is far more valuable than merely knowing media exists.

Tip 4: Release conditions must be objective and pre-defined. Answers that suggest the customer can obtain code whenever it feels dissatisfied, or that leave triggers vague, are wrong. Release conditions are negotiated up front and must be verifiable events such as bankruptcy or failure to support.

Tip 5: Open source means no contractual recourse. If a question involves a vulnerability in an open source library and asks who is liable or what remedy exists, recognize that open source licenses disclaim warranties and liability. The acquirer owns the risk and must mitigate through SCA, SBOM, patching discipline, and internal controls, not through litigation against the maintainers.

Tip 6: Know the copyleft spectrum. Be able to order licenses by obligation: public domain and permissive (MIT, BSD, Apache) impose the least; weak copyleft (LGPL, MPL) require sharing modifications to the component; strong copyleft (GPL) requires the whole derived work to be open; AGPL extends this to network use. When a question asks which license poses the greatest risk of forced source disclosure for a proprietary product, the answer is GPL or AGPL. When asked which is safest for inclusion in a commercial product, choose MIT, BSD, or Apache.

Tip 7: Distributing triggers copyleft; internal use usually does not. GPL obligations attach when the software is distributed. Purely internal use generally does not require source disclosure. AGPL is the exception for network services. Watch for questions that hinge on whether the software is distributed.

Tip 8: Liability caps are the vendor's friend, carve-outs are yours. Questions about negotiating contracts from the acquirer's perspective favor answers that expand vendor accountability: carve-outs from liability caps for data breach and gross negligence, security warranties, flow-down clauses, and audit rights. Questions from the vendor's perspective favor limitation of liability and disclaimers.

Tip 9: Contractor code belongs to whoever the contract says. If a question involves outsourced development and asks about IP, the answer focuses on explicit IP assignment or work-for-hire clauses. Paying for code does not automatically confer ownership.

Tip 10: SBOM connects everything. The SBOM is the artifact that enables license compliance, vulnerability tracking, and a useful escrow deposit. If an answer option mentions SBOM in a question about managing third-party component risk, it is usually a strong candidate.

Tip 11: Contracts are preventive controls negotiated before acquisition. The CSSLP emphasizes building security in early. If a question asks when security requirements, escrow, or licensing terms should be addressed, the answer is during planning and contracting, not after deployment. Trying to add escrow after a vendor is already in financial trouble is too late.

Tip 12: Read for the role. Identify whether the question is asked from the viewpoint of the acquirer, the vendor, or the developer integrating components. The best answer depends on whose risk is being managed. Acquirers want escrow, warranties, indemnity, and audit rights. Vendors want IP protection, liability caps, and controlled release conditions. Developers want license compatibility and clear attribution obligations.

Tip 13: Eliminate technical distractors. This topic is about legal and contractual controls. If a question is clearly about contracts and one option is a technical control such as code signing or static analysis, it is usually a distractor unless the question explicitly asks about verifying a deliverable.

Summary
Code escrow protects continuity by ensuring a licensee can obtain source code from a neutral agent when defined triggers occur, but only if deposits are complete, verified, and current. Liability clauses, including warranties, indemnification, limitation of liability, SLAs, and audit rights, determine who pays when software fails or is breached, and acquirers should negotiate carve-outs and security-specific commitments. Licensing contracts define what the acquirer may legally do with software, and open source licenses in particular carry obligations ranging from simple attribution to full source disclosure. Together these instruments form the legal foundation of a secure software supply chain, and the CSSLP expects you to recognize which instrument addresses which risk, who benefits from each clause, and when in the lifecycle they must be established.