Commissioning the development of software is one of the most commercially significant and legally complex transactions a business undertakes. Unlike buying a physical product, software development involves an evolving deliverable, a relationship between the commissioning party and the developer that can span months or years, and ownership of intellectual property whose value may far exceed the cost of development. A poorly drafted software development agreement can leave a business owning no rights in software it has paid to build, exposed to IP claims, or unable to recover its losses if the developer fails to deliver.
This article examines the ten provisions that every software development agreement in India must address.
The scope of work provision must define, with precision, exactly what the developer is being engaged to build. Vague descriptions, “a mobile application for customer management”, invite disputes at every stage.
Best practice: attach a detailed Technical Specification as a schedule to the agreement. The specification should cover functional requirements (what the software must do), non-functional requirements (performance, scalability, security standards), technology stack, integration requirements (APIs, third-party services), and platform coverage (iOS, Android, web browser, etc.).
The agreement must also address the change request procedure: how the parties handle requests for features or modifications beyond the agreed scope. A change request procedure typically requires: (a) the commissioning party to submit a written change request; (b) the developer to provide a change impact assessment (cost, timeline); and (c) written approval by the commissioning party before the change is implemented. Without this, scope creep, the gradual expansion of deliverables without formal agreement, is almost inevitable.
2. Intellectual Property Ownership and Assignment
This is the most critical provision in the agreement, and the one most often inadequately addressed.
Under Section 17 of the Copyright Act, 1957, the author of a work (including a computer programme) is ordinarily the first owner of copyright in that work. The proviso to Section 17 provides that where a work is made by an author in the course of their employment under a contract of service, the employer is the first owner of copyright. However, this proviso applies only to employees, it does not apply to independent contractors.
The consequence: where a company commissions software development from an independent developer or a development agency, without an express written assignment of copyright, the developer retains the copyright in the code. The commissioning party gets a licence to use the software, but does not own it.
A software development agreement must therefore contain an express, written assignment of intellectual property, covering:
- All source code, object code, and executables
- All documentation
- All databases and data structures
- All user interface designs and graphics
- All APIs and integration code developed for the project
- All modifications, enhancements, and derivative works
- All related know-how and technical information
The assignment should be drafted as “hereby assigns” (present tense, effective immediately) or accompanied by a signed IP assignment deed, rather than an agreement to assign at a later date.
Pre-existing IP: The developer will typically retain ownership of pre-existing tools, frameworks, libraries, and components (“Background IP”) brought to the project. The agreement should license Background IP to the commissioning party on a non-exclusive, royalty-free basis to the extent embedded in the deliverables.
3. Acceptance Testing
Acceptance testing is the procedure by which the commissioning party verifies that each deliverable meets the agreed specification before formally accepting it.
The acceptance clause should specify: (a) the acceptance test protocol (how testing is conducted); (b) the acceptance period (how many days the commissioning party has to complete testing); (c) what constitutes “acceptance” (no material defects, or specific pass criteria); (d) the cure period (how many days the developer has to fix defects identified during testing); and (e) what happens if the deliverable fails to pass after the cure period.
The link to payment milestones is important: payment for each deliverable should be triggered upon acceptance, not upon delivery. This gives the commissioning party meaningful leverage to ensure defects are remedied before payment.
4. Service Level Agreement for Maintenance
If the developer is also engaged for ongoing maintenance and support following deployment, the agreement must include service levels.
Standard provisions:
- Availability/uptime: 99.9% uptime for production systems (allowing approximately 8.7 hours of downtime per year) is typical for business-critical applications
- Response times: tiered by severity, critical defects (system down) within 1 hour; major defects within 4 hours; minor defects within 24 hours
- Resolution times: distinct from response times; committed timelines to fix, not merely acknowledge
- SLA credits: financial remedies for SLA breaches (typically a credit against future fees proportionate to the breach, not a right to terminate immediately)
5. Limitation of Liability
Standard limitation of liability provisions are particularly important in software development agreements because the potential downstream losses from software failure can be enormous relative to development fees.
The clause should: (a) cap total aggregate liability at the fees paid in the preceding 12 months (or the total contract value); (b) exclude liability for indirect, consequential, or special loss, specifically including loss of data, loss of profits, business interruption, and loss of revenue; and (c) carve out fraud and wilful misconduct from the cap and exclusions.
6. Data Protection Obligations Under the DPDP Act, 2023
The Digital Personal Data Protection Act, 2023 (DPDP Act) requires Data Fiduciaries (entities that determine the purpose and means of processing personal data) to ensure that Data Processors (entities processing personal data on behalf of Data Fiduciaries) are bound by written contractual data processing obligations.
Where a developer will process the commissioning party’s customers’ personal data, which is common in any customer-facing application, the agreement must include a data processing agreement incorporating: (a) the scope and purpose of processing; (b) data security measures; (c) restrictions on sub-processing; (d) breach notification obligations; and (e) data deletion or return on termination.
Failure to address DPDP Act compliance creates regulatory exposure for the commissioning party as Data Fiduciary.
7. Source Code Escrow
Source code escrow is an arrangement where the developer deposits the source code with a third-party escrow agent, to be released to the commissioning party upon the occurrence of specified trigger events, typically: insolvency of the developer, material breach of maintenance obligations, cessation of support, or discontinuation of the product.
Without source code escrow, the commissioning party may find itself unable to maintain, modify, or rebuild a business-critical system if the developer ceases to operate or refuses to cooperate.
8. Non-Solicitation of Employees
Developers invest significantly in training technical staff. A non-solicitation clause prevents the commissioning party from directly poaching the developer’s employees or contractors engaged on the project during the agreement and for a defined period post-termination (typically 12 months). A mutual non-solicitation (restricting both parties from approaching each other’s staff) is common.
9. Confidentiality
All pre-contract discussions, the technical specification, all code, all business information shared during development, and all test data constitute confidential information. A robust mutual NDA should cover: (a) definition of confidential information (broad, with specific inclusions); (b) obligations of confidentiality and non-use; (c) permitted disclosures (to employees and advisors on need-to-know basis); (d) survival post-termination (typically 3-5 years); and (e) return or destruction of materials on termination.
10. Governing Law and Dispute Resolution
For domestic software development agreements: Indian law, with arbitration (recommended for fast-moving technology disputes where courts may lack technical expertise) or exclusive jurisdiction of a specified High Court city.
For agreements with offshore developers: specify governing law (India or Singapore is common) and institutional arbitration with a specified seat. Enforcement of awards against developers in other jurisdictions is facilitated by New York Convention membership.
Key Takeaways
- Under Section 17 of the Copyright Act, 1957, an independent software developer owns the copyright in code it writes unless copyright is expressly assigned in writing, every software development agreement must contain a comprehensive IP assignment clause.
- Acceptance testing provisions tied to payment milestones are the commissioning party’s primary protection against substandard deliverables; without them, the developer’s obligation to perform is effectively unenforceable.
- DPDP Act, 2023 compliance requires data processing provisions in any software development agreement where the developer will access or process personal data of the commissioning party’s customers.
This article is for informational purposes only and does not constitute legal advice. Readers should seek appropriate professional counsel for their specific circumstances.
META TITLE: Software Development Agreement India: 10 Key Provisions