Software Development Agreement in India: IP, Payment and Acceptance

A Delhi fintech hires a freelance developer to build its mobile onboarding flow. The developer delivers working code, is paid in full, and six months later the company's investor due diligence asks a simple question: does the company own the source code? The contract says "all work product shall be the property of the company". It is signed by the founder, not by the developer. There is no assignment clause, no list of deliverables and no reference to copyright. The investor's lawyer marks it as a title defect and the funding round slips by two months.

Under Indian copyright law, the answer to "who owns the code" is not decided by who paid for it. It is decided by who wrote it and whether the copyright was assigned in the manner the statute requires. A software development agreement that ignores this produces a company that has paid for software it may not own — a problem that surfaces at exactly the worst moment, during diligence or an acquisition.

What a software development agreement in India must cover

The agreement sits between the commercial intent and the technical delivery. It has to translate "build us an app" into obligations that a court or arbitrator can enforce. In Indian practice, the documents that fail are usually the short ones: a two-page proposal accepted by email, with a scope table and a payment schedule, and nothing on ownership, warranties or liability.

A complete agreement covers the parties and their authority, the scope by reference to a statement of work, the delivery schedule and acceptance procedure, the fee and payment mechanics, intellectual property ownership and licensing, confidentiality, data protection, warranties and indemnities, liability limits, change control, termination and post-termination transition, and dispute resolution. Each of these interacts with the others; a strong IP clause with a weak acceptance clause still leaves the customer paying for code it cannot test.

Intellectual property: the clause that decides the company's value

Copyright in software is governed by the Copyright Act 1957. Computer programs are protected as literary works, and the author is the first owner of copyright. Section 17 creates an exception for works made in the course of employment under a contract of service, where the employer is the first owner. That exception does not extend to an independent contractor. A company that engages a freelancer or a development agency under a contract for services is not the first owner unless there is a valid assignment.

Why a "work product belongs to us" sentence is not enough

Section 19 of the Copyright Act requires an assignment of copyright to be in writing and signed by the assignor or by its duly authorised agent. It must identify the work and specify the rights assigned, the duration and the territorial extent. Where the assignment is silent on duration or territory, the statute supplies a default, but the safest course is to state both expressly.

An assignment clause buried in a purchase order signed by a project manager without authority is vulnerable. So is an assignment in a proposal that the developer never signed. The fix is procedural: a separate intellectual property assignment schedule, signed by the same person who signs the agreement, listing the deliverables and stating the rights transferred. For companies, attach a board resolution authorising the signatory.

The four ownership models

Not every engagement should transfer ownership. The commercial model should drive the IP clause, and the clause should be explicit about what the customer can and cannot do with the code.

Joint ownership sounds fair and is usually a mistake. In India, a co-owner of copyright can exploit the work and license it without the other's consent in many situations, subject to accounting. If the customer's competitive advantage depends on exclusivity, joint ownership destroys it. Choose assignment or licence, and if you need a compromise, use assignment to the customer with a narrow licence-back for pre-existing components.

Pre-existing IP and third-party components

Every development project contains code the developer brought with it: libraries, frameworks, internal tools, boilerplate. The agreement should require the developer to identify pre-existing intellectual property in a schedule and to grant the customer a licence to use it as part of the deliverables. Without that licence, the customer owns the new code but cannot lawfully run it.

Open source components need separate treatment. The agreement should require disclosure of all open source used, a representation that no component is licensed under terms that would require the customer to disclose its own source code, and an indemnity for breach. A developer that embeds a copyleft library into a proprietary product can create an obligation the customer never agreed to.

Moral rights and author attribution

Section 57 of the Copyright Act gives the author special rights, including the right to claim authorship and to restrain distortion or mutilation of the work. These rights continue after assignment and are not extinguished by a transfer of ownership. In software, the practical risk is low, but a developer who objects to the customer's modification of the code could theoretically raise a Section 57 claim. A well-drafted clause records the developer's consent to modification and to the customer's use of the work without attribution, to the extent the law permits.

Payment structures that match software delivery

Software projects fail commercially more often than technically, and the payment structure is usually the reason. Two models dominate Indian practice.

Fixed price ties the fee to deliverables. It gives the customer budget certainty and transfers scope risk to the developer. It works when the requirements are stable and the acceptance criteria are testable. It fails when the requirements are exploratory, because every change becomes a negotiation and the developer either absorbs the cost or delivers the minimum.

Time and materials ties the fee to effort. It is honest for uncertain scope but gives the customer no cost ceiling. The usual compromise is a capped time-and-materials arrangement: a rate card, a not-to-exceed amount, and a monthly burn report so the customer sees the trajectory before the cap is reached.

Whichever model is used, the payment clause should tie each tranche to an acceptance event rather than a calendar date, provide for a disputed-invoice mechanism, and state the interest rate on late payment. For Indian developers dealing with larger customers, the MSMED Act 2006 payment discipline may apply if the developer is a registered micro or small enterprise, in which case the statutory forty-five day limit and compounded interest override a longer contractual period.

Acceptance testing and deemed acceptance

Acceptance is the point at which the customer's obligation to pay becomes unconditional and the warranty period begins. The agreement should define the test set, the environment, the review window, the defect severity definitions and the deemed acceptance rule.

Defect severity should be defined by impact, not by adjective. A workable scheme has three tiers: Severity 1 is a failure that prevents the core transaction from completing or causes data loss; Severity 2 is a failure in a material function with no workaround; Severity 3 is a cosmetic or non-blocking defect. Acceptance should require zero open Severity 1 and 2 defects. Severity 3 defects can be fixed in the warranty period, and the agreement should say so — otherwise a customer can withhold acceptance over a misaligned button.

The review window should start on a defined event: deployment to the test environment together with delivery of the test report. Ten working days is typical for a module, fifteen to twenty for a full release. If the customer does not respond in writing within the window, the deliverable is deemed accepted. Indian courts generally enforce deemed acceptance where the procedure is clear and the customer had a genuine opportunity to test.

The warranty period — commonly ninety days to twelve months from acceptance — should cover defects in the delivered work, not new requirements. The distinction matters: customers routinely use the warranty to obtain free enhancements, and developers routinely accept them to preserve the relationship. A clause that defines a defect as "failure to conform to the specification in the statement of work" gives the developer a defensible line.

Warranties, indemnities and liability caps

What the developer should warrant

Standard warranties in Indian development contracts: the work will conform to the specification; the developer has the right to deliver it; the deliverables do not infringe third-party intellectual property; the code contains no known malicious component; and the developer will perform with reasonable skill and care. Each warranty should have a survival period, typically twelve to twenty-four months after acceptance.

What the customer should warrant

The customer side is often left blank, which is a mistake. The customer should warrant that it has the right to use any data, content and third-party systems it provides, that its instructions are lawful, and that it will provide the access and resources listed in the statement of work on time. A customer that supplies a dataset it has no right to use should indemnify the developer for the consequences.

Caps and carve-outs

A liability cap is standard and enforceable in Indian commercial contracts, subject to the reasonableness review that courts apply to exemption clauses. The usual structure caps aggregate liability at the fees paid in the preceding twelve months, with carve-outs for intellectual property infringement, breach of confidentiality, and fraud or wilful misconduct. Carve-outs are typically uncapped or capped at a higher multiple.

Excluding consequential loss — lost profits, lost business, loss of data — is common and usually upheld between commercial parties. Excluding liability for death or personal injury, or for fraud, is not effective. Note that the cap only helps if the claim falls under this agreement; if the customer sues in tort for negligence, the clause may still apply but the argument is harder.

Data protection, security and the DPDP Act

Most software development involves access to personal data, whether in a test environment or in production. Under the Digital Personal Data Protection Act 2023, the customer is usually the data fiduciary and the developer is a data processor. The agreement should include a data processing annexure that sets out the categories of data, the purpose, the security measures, the sub-processor rules, the breach notification timeline, the return and deletion obligations and the audit rights.

Where the developer's team is offshore or works from a different state, the location of processing should be disclosed. Cross-border transfer rules under the DPDP Act are notified by the central government, and sectoral restrictions — notably the RBI's requirements for payment data — may apply on top. A development agreement that is silent on data location is a compliance gap that surfaces during a security audit.

Security obligations should be specific enough to be auditable: encryption at rest and in transit, access controls, logging, vulnerability remediation timelines and the standard the developer follows. "Reasonable security practices" is the statutory phrase in the Information Technology Act 2000 and its rules, but a contract should translate it into commitments.

Termination, transition and code handover

Termination clauses in Indian development contracts usually cover breach and insolvency. The clause that matters more in practice is convenience termination: can the customer exit without cause, on what notice, and what does it pay? A customer that can terminate for convenience on thirty days' notice while the developer has mobilised a twelve-person team is a customer that will use the right at the worst moment. Price the exit: a termination fee, payment for work in progress, and a notice period that matches the mobilisation cycle.

The transition clause is the one customers forget until they need it. On termination, the developer should be obliged to deliver the source code, build instructions, credentials, documentation, database schema, deployment scripts and a knowledge transfer plan, against payment of outstanding invoices. The obligation should survive termination and should have a defined timeline — ten to fifteen working days is typical.

If the developer holds the code in its own repository, the customer should have a step-in right or at least a repository access arrangement. Customers who discover after termination that the code lives in a contractor's private account and the contractor has stopped replying have learned an expensive lesson.

Stamp duty and execution formalities

A software development agreement is an agreement not otherwise specifically provided for in most state stamp schedules and typically attracts a fixed duty. Where the agreement includes an assignment of copyright, some states treat the assignment as a separate instrument; where it includes a licence of premises or of a trademark, additional duty may apply. Rates vary by state and are revised, so confirm the current rate with the sub-registrar or the state e-stamp portal before execution.

Registration is not required, because the agreement does not create or transfer rights in immovable property. Execution by email is valid under Section 10A of the Information Technology Act 2000, but the customer should retain the signed PDF, the authority documents and the version history. Where the developer is a company, obtain a board resolution; where it is a partnership or LLP, obtain the authorisation under the partnership deed or LLP agreement.

Common mistakes in Indian software development agreements

• No written assignment of copyright. The customer pays but does not own; Section 19 requires a signed writing.
• Assignment signed by someone without authority. A project manager cannot assign the company's IP.
• Pre-existing IP not scheduled. The customer owns the new code but has no licence to the components it depends on.
• Open source not disclosed. A copyleft library creates an obligation the customer never bargained for.
• Acceptance left to "satisfaction". No test set, no severity definitions, no deemed acceptance.
• Warranty open-ended. The developer ends up funding enhancements rather than fixing defects.
• No liability cap or an uncapped IP indemnity. One infringement claim can exceed the entire contract value.
• No data processing annexure. The developer processes personal data without a lawful processor arrangement.
• No handover obligation. The customer cannot take the code in-house after termination.

Frequently asked questions

Who owns the copyright in software developed by a freelancer in India?

The freelancer, unless the copyright is assigned in writing. Section 17 of the Copyright Act 1957 makes the employer the first owner only for work done under a contract of service. A freelancer or an agency engaged under a contract for services is an independent contractor, and the first owner is the author.

To transfer ownership, the customer needs a written assignment signed by the freelancer or the agency's authorised signatory, identifying the work and stating the rights, duration and territory. An oral understanding or a payment receipt is not an assignment.

Should the agreement assign the copyright or license it?

Assign it if the software is core to the customer's business, if the customer expects to raise funding or be acquired, or if the customer wants to modify and commercialise the code without restriction. License it if the developer is delivering a product it also sells to others, or if the customer only needs to use the software as a service.

A middle path is common: assign the custom deliverables to the customer and license back the developer's pre-existing components on a non-exclusive basis. That gives the customer ownership of what it paid for without forcing the developer to give away its reusable toolkit.

What should the acceptance criteria look like for a software project?

They should be a numbered test set in an annexure, each with an input, an expected result and a pass condition, written in business language. Acceptance should require all Severity 1 and 2 tests to pass. The agreement should define severity by impact and should give the customer a fixed review window, a capped number of remediation rounds and a deemed acceptance rule.

If the customer cannot articulate the tests, the requirements are not ready and the project should not be priced as fixed scope.

How long should the warranty period be?

Ninety days to twelve months from acceptance is the Indian market range. A longer period is justified for enterprise or regulated software where defects have serious consequences; a shorter period is common for small projects and for time-and-materials work where the developer continues to support the product.

Whatever the period, define what a defect is — a failure to conform to the specification — and exclude new requirements, changed third-party environments and customer modifications from the warranty.

Can liability be capped in an Indian software contract?

Yes. Indian courts enforce limitation of liability clauses between commercial parties where the clause is clear and the cap is not unreasonably low relative to the risk. Caps at the fees paid in the preceding twelve months are common and generally upheld.

Exclusions for fraud, wilful misconduct and death or personal injury are not effective. Intellectual property indemnities are usually carved out of the cap, or given a separate higher cap, because that is the risk customers care about most.

Does the developer have to hand over the source code?

Only if the contract says so. There is no statutory right to source code in India, and a customer that buys a licence rather than an assignment has no entitlement to it. If the customer needs the code — for maintenance, regulatory review or business continuity — the agreement must impose an express delivery obligation, with a timeline and a list of what is delivered.

For mission-critical software, pair the delivery obligation with a source code escrow so the code is available even if the developer disappears.

Drafting Support

Our drafting team prepares software development agreements for Indian customers and developers, including copyright assignment schedules, acceptance test annexures and data processing terms.