Saya & Associates Get in touch
Insights · Intellectual property

Software development agreements in India: rights, licences and handover

By Yash Aggarwal, Partner5 October 20267 min readIntellectual property

Three questions the project treated as one

A founder commissions an agency to build a platform. The final invoice is paid and the application works. Months later, a new developer asks for the repository, the deployment instructions and permission to change a reusable module.

Those requests raise three separate questions: who owns the rights, what the business is allowed to do, and whether it can run the software without the original agency. A useful agreement answers all three before delivery.

This guide covers the agency engagement and the exit. For the copyright rules on individual freelancers in more detail, see our guide to software built by a freelancer.

Who owns the code first

Under section 17, the author is the first owner, unless an exception applies. In an agency project there may be several authors, and the chain matters:

Who wrote the codeFirst ownerWhat the company needs
The agency's own employeesThe agency, under section 17(c), unless agreed otherwiseA written assignment from the agency
Freelancers or subcontractors the agency engagedEach of them, as authorProof the agency holds written assignments from each, so it can pass the rights on
The company's own employeesThe company, under section 17(c), unless agreed otherwiseEmployment terms that confirm it

A promise from the agency and a documented chain from the people who wrote the code answer different questions. Ask how the agency obtained the rights it proposes to transfer.

Start with an inventory, not a sentence saying the client owns everything. List the application code, designs, documentation, integrations and pre-existing modules, and mark which are new to this project.

What the assignment must say, and when rights move

Section 19 requires an assignment to be in writing and signed by the assignor. It must identify the work and specify the rights, the duration and the territory, and the royalty or other consideration.

If no period is stated it is deemed to be five years, and if no territory is stated it is presumed to be India. For a product sold abroad, check the territory clause against the markets you actually plan to reach.

Software is built in stages, so timing needs its own clauses:

SituationWhat the agreement should say
Code not yet writtenSection 18(1) lets future work be assigned, but the assignment takes effect only when the work exists. Take a confirmatory assignment at each milestone or at handover
Rights conditional on payment or acceptanceWhat the company may use, host and modify while the condition is outstanding
Termination mid-projectWhat happens to partly completed work, and who may finish it
Rights not used for a yearSection 19(4) deems an assignment to lapse if the rights are not exercised within one year, unless the assignment says otherwise. Say otherwise

The agency's reusable framework

An agency may reasonably want to keep a framework it uses across clients. The company then needs a licence wide enough to operate, adapt and maintain the delivered application, including through a different developer later.

Describe the retained component and the licence precisely enough that another engineer can see the boundary. A blanket ban on reuse may not fit the architecture, and a vague licence may not survive a change of supplier.

Third-party and open-source components

An assignment of the agency's work does not replace the licences that govern external components. Ask for a dependency list with versions, sources and licence information, and have the technical team check it against the delivered build.

Public code is not free to use just because it is visible. GitHub's documentation says that without a licence, default copyright law applies and no one may reproduce, distribute or create derivative works from the code.

Its terms let other users view and fork a public repository, but that is not a licence to build it into a commercial product. Read the licence for each component.

AI-assisted development

Where the agency uses AI coding tools, ask which tools were used, what material went into them and what review took place. Record any restrictions in the tools' terms.

A broad statement that the company owns all output does not identify what was delivered, and does not answer a third party's claim. Keep the record with the dependency list.

Make the handover testable

A rights clause cannot install a missing build tool or recover an account the business never controlled. Make handover a milestone the receiving team can demonstrate, covering:

  • source repositories, branches and release versions;
  • build and deployment instructions, with configuration documented safely;
  • ownership of or access to cloud, domain, app-store and integration accounts;
  • dependency records and third-party licences;
  • database structure, migration steps and backup procedures; and
  • documentation, known defects and the agreed support boundary.

Never put credentials in shared documents. Transfer them through a secure process, then rotate them. Ask a receiving engineer to run the agreed deployment and record what is missing before treating handover as complete.

For a project already delivered

Preserve the signed documents, invoices, repository history and correspondence first.

A confirmatory assignment can close gaps, but it must carry true parties, dates and authority. Do not backdate a signature or describe an earlier transfer that never happened.

Cross-border projects also need attention to governing law, disputes and the countries where the rights will be used. This guide covers Indian law only.

A review before signing

  1. Read the documents together. Compare the proposal, statement of work and main agreement, and check the same deliverables appear in each.
  2. Map the authors. Identify the agency's employees, subcontractors and freelancers, and how the agency holds their rights.
  3. Fix the assignment terms. State the rights, full term, worldwide territory, consideration and the one-year lapse wording.
  4. Separate the components. List new code, the agency's reusable framework with its licence, and third-party components with theirs.
  5. Write the handover schedule. Name each repository, account, record and instruction to be delivered, and how credentials are transferred.
  6. Test before acceptance. Have a receiving engineer deploy from the handover and log every gap before signing off.

Frequently asked questions

Does owning the GitHub account prove my company owns the code?

No. Controlling the account and holding the copyright are separate questions. Keep the repository records with the agreements that explain who wrote the code and how the rights passed.

Can the agency reuse parts of my code for other clients?

It depends on the agreement. Decide which components need exclusive control and which can stay reusable under a licence to you. A blanket ban may not suit the architecture.

Is code in a public GitHub repository free to use?

Not without a licence. GitHub's guidance says that without one, default copyright law applies and others may not reproduce, distribute or create derivative works. Check each component's licence.

Can I use a standard assignment template?

Only after checking it against the actual authors, deliverables, existing modules, payment stages and markets. A template cannot supply facts the project never recorded.

What should I bring to a contract review?

The proposal, signed terms, change requests, subcontractor arrangements, a component inventory and the handover plan, with a technical contact who can explain the build.

The takeaway

Compare the rights language with one actual delivered release and its component list. That shows whether the agreement matches the software, which a clause read on its own cannot.

To review a development agreement or a handover plan, contact Saya & Associates with a short, non-confidential summary of the project.

This article provides general information as at 5 October 2026. Ownership, licensing and enforceability depend on the facts, the documents and the applicable law. It is not legal advice.

Sources