# Draft Source Code Escrow Agreement > Draft a beneficiary-oriented source code escrow agreement and a negotiation issues memo for a software-as-a-service license transaction, using the escrow agent's template and the deal documents as inputs. - Skill: `finchipaiorg/draft-source-code-escrow-agreement` (Agent Skill) - Install (CLI): `npx skillmds@latest add finchipaiorg/draft-source-code-escrow-agreement` - Raw SKILL.md: https://api.skillmd.com/api/skills/finchipaiorg/draft-source-code-escrow-agreement/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: FinchipAIOrg (https://skillmd.com/u/finchipaiorg) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/finchipaiorg/draft-source-code-escrow-agreement --- # Skill: Draft Source Code Escrow Agreement ## 1. Subject-matter triage - Identify the governing license architecture first: who is licensor, who is beneficiary, who is escrow agent, what software stack is covered, and whether the escrow is for production access, continuity, or transition support. - Read the license and escrow template together; any release right, use restriction, or verification mechanic in one document must be harmonized with the other. - Determine whether the transaction is one software product, one suite, or multiple deployments; draft separate schedules or defined terms only where the source documents support that structure. - For the issues memo, treat the agreement draft as the primary work product and the memo as secondary; the agreement must be written first and fully populated before the memo is finalized. ## 2. Failure modes the skill is correcting - Drafting off the template mechanically without testing whether the beneficiary actually receives usable source materials, operational continuity, and realistic access upon a release event. - Treating escrow as a formality instead of a negotiated risk-allocation mechanism tied to service continuity, business interruption, and transition leverage. - Leaving deposit requirements vague, so the released package may be incomplete, unbuildable, or unusable in production or maintenance environments. - Narrowing release triggers to insolvency only and omitting business cessation, chronic nonperformance, security failure, or other transaction-specific loss-of-service events. - Failing to align post-release rights with the license grant, support obligations, and any agreed transition assistance. - Omitting verification mechanics, cure periods, update cadence, cost allocation, and the process for disputes over completeness. - Producing an issues memo that lists concerns but does not identify likely objections, beneficiary priorities, fallback positions, and practical next steps. - Drafting positions without checking the source set for the controlling contractual language, then overstating or understating what the documents actually permit. - Writing conclusions about obligations, triggers, or rights without tying them back to the relevant contract language or generally recognized escrow practice. ## 3. Legal frameworks / domain conventions that apply - Source code escrow is typically tripartite: licensor deposits, beneficiary receives conditional access, and escrow agent administers custody and release mechanics. - The agreement should specify the deposited materials with enough precision that the software can be reconstructed, tested, and maintained if released; build artifacts, scripts, dependencies, documentation, and acquisition instructions may matter as much as source files. - Release conditions should be drafted to reduce disputes by using objective events and clear notice/cure mechanics where appropriate. - Verification provisions should state whether completeness is checked by the escrow agent, a technical verifier, or a neutral third party, how often verification occurs, and who bears the cost. - The post-release license to the beneficiary must be consistent with the underlying software license, including scope of use, internal modification rights, support obligations, and limits on disclosure or commercial exploitation. - Common transactional authorities that often matter include the operative license agreement, any escrow exhibit, the deposit schedule, and any transition-services or support provisions; use the actual source documents to determine which controls. - Where the source documents identify a governing law, notice rule, or defined release event, draft to that authority rather than substituting generic language. ## 4. Analytical scaffolds - License review: extract the clauses on escrow, access rights, permitted uses, support, termination, source-delivery obligations, and any restriction on reverse engineering or disclosure. - Deposit specification: define the deposit package as a complete, operational set of materials; include source code, build and deployment instructions, interface documentation, keys or credentials only if the source documents permit, and a completeness certification. - Release conditions: identify the set of events that justify release and separate them from ordinary service issues; include notice, cure, and evidence requirements where the source documents support them. - Verification mechanism: specify the verifier, test standard, update cycle, and dispute path for incomplete or stale deposits. - Beneficiary access rights upon release: draft use rights narrowly enough to fit the license structure but broadly enough to allow continuity, maintenance, bug fixes, security patches, and transition. - Risk allocation: address who pays escrow fees, verification costs, shipping or storage charges, and any cost of supplementing a deficient deposit. - Issues memo: for each substantive point, state the beneficiary goal, the likely counterparty objection, the preferred drafting position, and a fallback position that still preserves continuity value. - Document control: if the source set contains competing forms or inconsistent exhibits, prefer the operative transaction documents and flag any internal inconsistencies in the memo. - Authority support: each legal assertion in the draft or memo should be anchored to the governing contract language, governing law, or recognized escrow practice reflected in the source set. ## 5. Vertical / structural / temporal relationships - Map the relationship among the license agreement, escrow agreement, and any support or transition obligation so that release rights do not exceed the beneficiary’s post-termination use rights unless the source documents expressly permit that result. - Track the temporal sequence of deposit, verification, refresh, notice, cure, release, and post-release access; draft deadlines and intervals so they are administrable rather than aspirational. - If multiple products, environments, or deployment instances are implicated, distinguish which materials belong in the base deposit and which belong in refresh or supplemental deposits. - If the source documents impose milestone-based updates or verification windows, reflect those dates precisely and avoid generic periodicity. - Where the business deal anticipates change in control, service failure, or termination for convenience, test whether those events should affect deposit refresh, release rights, or transition assistance. - Make sure any post-release maintenance rights line up with the beneficiary’s practical need to operate the software after the triggering event, including access to updates or fixes if the transaction documents contemplate them. ## 6. Output structure conventions - Draft the source code escrow agreement first as a complete operative agreement, not as a summary or form note. - Include the core commercial mechanics in conventional agreement form: parties, recitals, defined terms, deposit obligations, verification, release events, notice/cure mechanics, post-release rights, confidentiality, fees, liability allocation, dispute handling, and miscellaneous boilerplate as appropriate to the source documents. - Use schedules or exhibits for the deposit package and any verification or release process details when that is the cleanest way to make the deposit administrable. - Draft the negotiation issues memo as a separate advisory deliverable after the agreement exists; organize it by issue with the beneficiary position, likely objection, fallback, and practical recommendation. - If there are multiple plausible drafting choices, choose the beneficiary-favorable position that still fits the source documents and note the tradeoff in the memo. - Keep the memo concise but action-oriented; it should tell the deal team where the pressure points are and what to ask for next. - Before finishing, confirm that the agreement file contains operative drafting and that the memo file contains substantive negotiation guidance, not merely placeholders or descriptions. - Use conventional legal drafting style and terminology; avoid inventing unusual labels where standard escrow terminology will do.