IPR transfer & source-code escrow — owning what you actually bought

What the FA is actually asking

The literal question: "Who owns the IPR?" The FA's real concern is operational. Three years from now, when the system needs a security patch and the original engineers have moved on:

• Will the source code be complete and current?
• Will the documentation be enough that a successor vendor can pick it up?
• Will the build pipeline run independently of the original vendor's environment?
• Will the third-party licences allow continued use after vendor exit?

"Ownership" without these four is paper ownership.

Why thin responses fail

The standard failure is a one-line clause: "All IPR vests in the purchaser on full payment." The vendor signs happily because they know that:

• The source code handed over may be incomplete (deployment scripts missing, third-party fork not flagged)
• The documentation is thin or non-existent
• Dependencies are pinned to deprecated versions
• The original engineers have moved on; nobody else can run the build
• Third-party licences (databases, libraries, APIs) may not transfer with the IPR

Two years later, when the department tries to engage a successor vendor, the successor demands a full rewrite. The "ownership" was illusory.

The shape of a holding response

Part 1 — Layered IPR clause

Replace the one-liner with an explicit list of what transfers:

• Source code (all repositories, all branches, full git history)
• Documentation (architecture, API, deployment, troubleshooting, change-log)
• Build scripts & CI/CD configurations
• Infrastructure-as-Code (Terraform, Ansible, Kubernetes manifests)
• Design files (Figma exports, brand assets, accessibility audits)
• Third-party licence inventory with continuation-of-use rights
• Test suites & test data
• Database schemas, seed data, migration scripts
• Operational runbooks & on-call documentation
• Security & pen-test reports

Part 2 — Source-code escrow agreement

A tripartite agreement (department + vendor + escrow agent). Recognised escrow agents in India: NSDL, NIXI, KEONICS, several private specialists.

• Quarterly deposits of source code + dependency snapshots
• Release triggers: vendor bankruptcy, persistent SLA breach, vendor refusal to maintain, contract termination
• Verification audits: annual smoke-test by the escrow agent that the deposited code builds successfully

Part 3 — Knowledge-transfer plan

Structured weeks of overlap between vendor and client engineers (or successor vendor):

• Architecture walkthrough sessions (recorded)
• Module-by-module code reviews
• Build-and-deploy pair sessions on department infrastructure
• Operational handover (incidents, alerts, on-call rotation)
• Sign-off by client engineers that they can independently maintain

Costed into the contract upfront — typically 4–8 weeks of post-go-live KT, billed at agreed rates.

Part 4 — Code-quality acceptance test

Performed before final payment. The test:

• Static-analysis pass (SonarQube or equivalent) with agreed thresholds
• Dependency vulnerability scan with no critical vulnerabilities open
• Documentation completeness check (architecture doc, API doc, deployment doc all present and current)
• Independent build by client IT cell from a clean environment
• Independent deploy by client IT cell to a staging environment
• Sign-off by an independent technical reviewer (CDAC, NIC, or empanelled consultant)

The legal anchors

• Indian Contract Act 1872 — IPR assignment provisions
• Copyright Act 1957 — assignment of software copyright requires writing under §19
• Patents Act 1970 — patent assignment formalities
• GFR Rule 154 / Manual for Procurement of Consultancy 2021 — IPR ownership default rules in government contracts
• MeitY guidelines on government software — open-source preference and IPR vesting
• NeGD model contract clauses — IPR boilerplate that withstands audit

Typical FA pushback patterns

• "Why escrow if IPR vests in us?" — answer: IPR transfer ≠ operational continuity; escrow is the insurance
• "Who pays for escrow?" — typically the vendor; cost should be in the contract value
• "What about third-party libraries?" — pre-attach the licence inventory with continuation rights
• "Can the vendor reuse the architecture for other clients?" — clarify in the IPR clause: vendor retains right to deliver the same architectural pattern, not the same product
• "What if the documentation is thin at handover?" — link to the code-quality acceptance test which includes documentation completeness

What we hand you

• A layered IPR clause for insertion in your contract — covers source, docs, IaC, design, test, third-party licences
• A source-code escrow agreement template — tripartite, with NSDL or your preferred escrow agent
• A knowledge-transfer plan with sample SOW, sample weekly KT schedule, sign-off checklist
• A code-quality acceptance test specification — measurable thresholds, sample tooling, independent-reviewer checklist
• A third-party licence inventory template — populated with the libraries we'd typically use for your stack
• A second-round pushback pack for the five most common FA IPR challenges

Read the rest of the FA-Objection Field Guide

• The pillar — all 8 FA objections at a glance
• 1. Cost reasonableness — defending the price tag
• 2. Single-vendor / Rule 161 nomination — the 70% kill zone
• 3. IPR transfer & source-code escrow — owning what you bought
• 4. Scope creep & cost overrun — the change-control protocol
• 5. Hosting — on-prem vs NIC vs cloud vs hybrid
• 6. Exit terms & vendor lock-in — the 14-clause exit annexure
• 7. "Why not NIC / NICSI / CDAC?" — the comparison done right
• 8. MSME / GeM / Make-in-India preference — the screen note

Related reading

• Big Helpers Government & PSU programme
• 7 legitimate procurement routes (no GeM, no MSME yet)
• Vendor lock-in: hidden ₹crores in PSU IT
• NIC eHRMS alternatives