Outsourcing software development to an Indian company does not automatically mean the customer owns the source code or all intellectual property created during the project. Under Indian copyright law, ownership depends on who created the work, whether the developer is an employee or an independent contractor, and—most importantly in outsourced projects—what the written development agreement says.
For overseas companies and Indian businesses using external development teams, the safest approach is to deal expressly with source-code ownership, copyright assignment, pre-existing IP, third-party software, open-source components, confidential information and AI-assisted development before coding begins.
Does the Client Automatically Own Software It Pays an Indian Developer to Build?
No. Payment for software development and ownership of copyright are separate legal questions.
Computer programs are protected under the Copyright Act, 1957. Section 2(o) includes computer programs within the definition of “literary work”, while Sections 13 and 14 deal with copyright protection and the rights available to the copyright owner.
The starting rule under Section 17 is that the author is ordinarily the first owner of copyright, subject to statutory exceptions. One significant exception applies where a work is created by an employee in the course of employment under a contract of service: subject to an agreement to the contrary, the employer will ordinarily be the first owner in circumstances covered by Section 17(c).
An independent software development company or freelancer, however, is not automatically the customer's employee merely because the customer is paying for the work.
That distinction makes the development agreement critical.
A contract that only says:
“Developer will build the software for Client for ₹X”
may establish what must be delivered, but it does not necessarily create the comprehensive copyright assignment the customer expects.
Official source: Copyright Act, 1957 — India Code
Why Is an IP Assignment Clause So Important?
Because Indian copyright law imposes specific requirements on assignments.
Under Section 18 of the Copyright Act, copyright owners may assign copyright wholly or partially, including rights in future works once those works come into existence.
Section 19 then deals with the form of an assignment. Among other things, an assignment must be in writing and signed by the assignor or an authorised agent. It should identify the work and specify the rights assigned, duration and territorial extent.
This is not merely technical drafting.
If the duration is not specified, Section 19 provides a statutory default of five years. If territorial extent is not specified, the statutory presumption is that the assignment extends only to India.
For a global technology business, both defaults can be commercially unsuitable.
A properly drafted software development agreement should therefore make clear whether copyright is being assigned:
exclusively;
for the full legally permissible duration;
throughout the world;
across the relevant rights and forms of exploitation;
in present deliverables and future works when they come into existence; and
subject to any clearly identified background or pre-existing IP retained by the developer.
The Madras High Court has also emphasised that compliance with Section 19 is important for a copyright assignment and that a valid assignment requires the necessary written documentation.
For businesses preparing technology contracts, this issue belongs alongside the wider protections required in a commercial agreement. See Edvisars' guidance on commercial contracts and business documentation.
Businesses should also ensure that the assignment clause clearly distinguishes newly developed IP from the developer’s pre-existing tools, libraries, frameworks and know-how. Without this distinction, disputes may arise over ownership of deliverables and the rights required to use, modify, maintain or commercialise them. The agreement should also address third-party and open-source components, ensuring that the business receives the necessary rights to use and exploit the deliverables without infringing third-party rights.
What Exactly Should the Client Own?
A strong agreement should not use “software” as an undefined catch-all.
Depending on the project, the intellectual-property provisions may need to deal separately with:
source code;
object code;
APIs;
scripts;
databases and database structures;
architecture;
UI and UX materials;
graphics and design assets;
technical documentation;
specifications;
testing material;
deployment scripts;
configuration files;
custom libraries;
prompts or workflows developed specifically for AI-enabled features; and
modifications, updates and derivative versions developed under the engagement.
The agreement should also distinguish project IP from background IP.
What Is Background IP?
Background IP is technology, code, libraries, frameworks, tools, templates or know-how that existed before the project or was developed independently of it.
A software vendor may legitimately want to retain ownership of its reusable framework or proprietary tools.
That does not necessarily create a problem.
The problem arises when the customer receives ownership of the application but not the rights necessary to run, modify, maintain or commercialise it independently.
Where vendor-owned background IP is embedded in the deliverable, the customer may therefore require a sufficiently broad, durable licence allowing the customer and its future service providers to use the delivered product without repeatedly obtaining permission from the original developer.
What About Open-Source Software?
Open-source software is not the same as software with “no copyright”.
It remains subject to the licence under which its copyright owner has made it available.
Depending on the licence, conditions can include attribution, preservation of notices, disclosure requirements, source-code obligations or conditions affecting distribution of modified or combined software.
The development contract should therefore require the developer to maintain a software component or dependency record and identify material open-source components used in the project.
For important projects, the customer may also require prior approval before software governed by particular licence categories is incorporated into the product.
A useful contractual framework may require the developer to disclose:
the name of the component;
the version used;
its licence;
where it appears in the product;
whether it was modified; and
any obligations triggered by distribution or commercial use.
The exact risk depends on the licence involved. It should not be assumed that every open-source licence produces the same legal consequences.
Can the Developer Reuse the Same Code for Another Client?
It depends on the agreement and on what rights the developer has retained.
Where copyright has been validly and exclusively assigned to the customer, the vendor cannot simply treat the assigned proprietary code as its own reusable asset contrary to the rights transferred.
But many software projects contain a mixture of:
client-specific code;
generic utilities;
existing vendor frameworks;
third-party libraries; and
general programming knowledge.
The contract should therefore identify what the developer may continue using and what belongs exclusively to the customer.
This can prevent future arguments over whether an allegedly reused module was proprietary project code or merely generic vendor technology.
Who Owns Code Written by the Vendor's Employees and Subcontractors?
This is one of the most overlooked outsourcing risks.
Even where the contracting software company promises to transfer IP to the customer, the customer should ask whether that company actually has the necessary rights to transfer.
For work created by employees in circumstances falling within Section 17(c), the employer may be the first copyright owner, subject to the contract and statutory conditions.
The position may be different for freelancers, consultants and subcontractors.
The customer's agreement should therefore require the development company to ensure that every employee, contractor and subcontractor involved in creating project materials has signed appropriate confidentiality and IP documentation sufficient for the vendor to perform its obligations to the customer.
A useful representation may require the vendor to confirm that:
it owns or controls the rights it promises to assign or license;
contributors have executed necessary agreements;
no undisclosed third party owns project deliverables; and
the deliverables do not knowingly incorporate unauthorised third-party material.
Who Owns AI-Assisted Code?
This is currently more legally uncertain than ordinary human-written software.
The Copyright Act contains an existing provision for certain computer-generated literary, dramatic, musical or artistic works. Section 2(d)(vi) states that, in relation to such a work, the “author” is the person who causes the work to be created.
However, that wording predates today's generative-AI ecosystem.
It should therefore not be treated as conclusively resolving every copyright question involving code generated substantially or autonomously by modern generative-AI systems.
As of October 2026, businesses should be cautious about assuming that every AI-generated output automatically receives the same copyright protection, authorship treatment or ownership outcome as conventionally written human code.
The practical contract therefore matters even where copyright law remains uncertain.
What Should the Contract Say About AI-Assisted Development?
The agreement should first answer a simple question:
May the developer use generative AI at all?
The answer may be:
prohibited;
permitted only with written approval;
permitted for limited functions;
permitted only with approved enterprise tools; or
generally permitted subject to confidentiality, security, IP and documentation requirements.
Where AI use is allowed, the agreement should address at least four areas.
1. Confidential Information
Developers should not upload customer source code, credentials, personal data, trade secrets or confidential technical material to public or third-party AI systems where doing so conflicts with confidentiality obligations or exposes the information to unacceptable processing or retention risks.
2. Third-Party Rights
The developer should not represent that AI output is automatically “original” or infringement-free merely because it came from an AI system.
Appropriate review may still be necessary before AI-assisted code enters production.
3. Tool Terms
AI platforms operate under their own contractual terms.
Those terms can affect how inputs and outputs are treated, whether content may be retained or processed, and what warranties or indemnities the AI provider gives—or does not give.
A software development agreement should therefore avoid relying on broad assumptions about every AI provider.
4. Human Review
For commercially important software, AI-generated or AI-assisted code should ordinarily be subjected to appropriate developer review, testing and security checks before delivery.
The contract can require the vendor to remain responsible for the deliverable even where its team used AI tools during development.
From a contractual perspective, AI-assisted development should not create a gap in accountability between the developer and the customer. The agreement should clarify that the developer remains responsible for compliance with its contractual obligations, regardless of whether the deliverables are created by human developers, AI tools or a combination of both. For higher-risk projects, businesses may also require disclosure of material AI use, maintain records of approved tools and impose restrictions on the use of AI-generated components where ownership, licensing or security risks cannot be adequately assessed. These safeguards help ensure that the use of AI does not undermine the customer's rights in the deliverables or the developer's existing contractual commitments.
Can Software Be Patented in India?
Not every software innovation is patentable.
Section 3(k) of the Patents Act, 1970 excludes “a mathematical or business method or a computer programme per se or algorithms” from patentability.
This does not mean every invention involving software is automatically excluded. Patentability can be highly fact-specific and depends on the nature of the claimed invention and its compliance with the Patents Act and applicable examination standards.
Businesses should therefore avoid casually describing ordinary source code as “patented technology” unless an actual patent position has been established.
Official source: Patents Act, 1970 — India Code
What About Customer Data and Personal Data?
Software-development projects frequently give vendors access to personal information belonging to customers, employees or users.
India's Digital Personal Data Protection Act, 2023 distinguishes, among other concepts, between a Data Fiduciary that determines the purpose and means of processing personal data and a Data Processor that processes personal data on behalf of a Data Fiduciary.
The Digital Personal Data Protection Rules, 2025 were notified on 13 November 2025 with staged commencement provisions. Not all operative rules commenced on the same date.
Technology contracts being entered into during this transition should therefore be structured with both the presently applicable requirements and upcoming statutory obligations in mind.
Relevant issues may include:
permitted processing;
security safeguards;
confidentiality;
access controls;
use of subprocessors;
incident reporting;
deletion or return of information;
data localisation requirements where separately applicable;
audit obligations; and
restrictions on using customer data for unrelated analytics or AI training.
Official source: Digital Personal Data Protection Rules, 2025 — MeitY
What Clauses Should a Software Development Agreement Include?
For a substantial outsourced-development project, businesses should consider addressing at least the following:
Issue
What the agreement should clarify
Scope
What exactly must be built and delivered
Acceptance
Testing and acceptance criteria
Milestones
Delivery dates and dependencies
Payment
Milestone, hourly or fixed-price structure
Source code
When and how repositories and credentials are transferred
IP ownership
Ownership of newly created project IP
Assignment
Written copyright assignment complying with applicable law
Background IP
What the developer retains
Third-party software
Disclosure and licence responsibility
Open source
Approved licences and component disclosure
AI use
Whether AI tools are permitted and under what conditions
Confidentiality
Protection of code, business information and credentials
Data protection
Processing and security responsibilities
Warranties
Authority, quality and third-party-right representations
Indemnity
Allocation of specified third-party IP or contractual risks
Maintenance
Bugs, support, upgrades and service levels
Exit assistance
Handover if the relationship ends
Termination
Rights following termination
Disputes
Governing law, jurisdiction or arbitration
Businesses can review Edvisars' broader Commercial Contracts and Corporate Advisory practice areas when structuring cross-border technology agreements.
Should the Client Receive the Source Code Before Final Payment?
There is no universal legal rule requiring one particular commercial arrangement.
The contract should decide it.
From the customer's perspective, waiting until the project is completely finished before receiving repository access can create unnecessary dependency.
For larger projects, a safer structure may include:
customer access to the repository during development;
periodic backups;
milestone-based code handovers;
delivery of documentation and build instructions;
transfer of administrative credentials; and
confirmation at termination that current source materials have been handed over.
Where commercial concerns prevent immediate control of the repository, source-code escrow may be considered for suitable projects.
The appropriate solution depends on bargaining position, project value and technical architecture.
Should the Contract Use Indian Courts or Arbitration?
Cross-border development contracts should deal expressly with governing law and dispute resolution.
Arbitration can be attractive where confidentiality, international enforceability or selection of the decision-maker is particularly important, although arbitration is not automatically faster or cheaper in every dispute.
Court litigation may remain appropriate for other types of claims.
The decision should be made when the agreement is drafted rather than after the relationship has broken down.
For a practical comparison, see Edvisars' guide: Arbitration vs Litigation in India: Choosing the Right Forum for Your Dispute.
A Practical Pre-Signing Checklist
Before sending a software project to an Indian developer, confirm:
Who will create the code?
Are freelancers or subcontractors involved?
Who owns newly created project IP?
Is the copyright assignment written and properly structured?
Does the assignment specify duration and worldwide territory?
What background IP remains with the vendor?
Does the client have sufficient rights to embedded background IP?
Which open-source components may be used?
Are generative-AI tools permitted?
Can confidential material be entered into an AI system?
Who reviews AI-assisted output?
Where is the source-code repository?
Who owns or controls the repository account?
What happens to the code if the contract terminates?
How must customer data be protected?
What happens if third-party IP claims arise?
Which law governs the agreement?
Which court or arbitral forum will resolve disputes?
Frequently Asked Questions
1. If I paid for the software, do I own the copyright?
Not necessarily. Payment and copyright ownership are different questions. In an outsourced project, an express written IP assignment is generally the safer approach.
2. Can an Indian software developer retain ownership of the code?
Yes, if the contractual arrangement provides for the developer to retain ownership. The customer may instead receive a licence. Whether that is commercially acceptable depends on the product and the licence terms.
3. Can copyright in future software be assigned?
Section 18 permits assignment relating to future works, but such an assignment takes effect when the work comes into existence.
4. Does the IP assignment need to be written?
Yes. Section 19 requires a copyright assignment to be in writing and signed by the assignor or authorised agent.
5. What happens if the copyright assignment does not state its duration?
Subject to Section 19, the default period is five years where the duration is not stated.
6. What happens if the assignment does not specify territory?
The statutory presumption under Section 19 is that it extends within India. A global software transaction should therefore address territory expressly.
7. Who owns software created by an employee?
Where the requirements of Section 17(c) apply, the employer is ordinarily the first copyright owner in work created in the course of employment under a contract of service, unless there is an agreement to the contrary. The precise position remains dependent on the employment relationship and circumstances.
8. Is AI-generated software automatically protected by copyright in India?
That should not presently be assumed. The Copyright Act contains a provision concerning authorship of computer-generated works, but applying that provision to modern generative-AI output raises issues that are not conclusively resolved for every factual situation.
9. Can developers use ChatGPT or other AI tools while writing customer software?
They can if the contractual arrangement and applicable policies permit it, but businesses should address confidentiality, data protection, third-party rights, security, tool terms and human review before allowing such use.
10. Is copyright registration compulsory before software is protected?
Copyright protection generally arises by operation of law when the statutory requirements are satisfied; registration is not the act that creates copyright. Registration can, however, be relevant as part of an evidentiary and IP-management strategy. The Government Copyright Office separately provides a registration framework for computer software works.
The Practical Takeaway
When software development is outsourced to India, the safest assumption is not that ownership follows payment.
The agreement should establish a clear chain of title from the people actually creating the software, through the development company, and ultimately to the customer where assignment is intended.
For modern projects, that chain of title should extend beyond conventional source code. It should address vendor background IP, subcontractors, open-source dependencies, confidential information, personal data and the increasing use of generative-AI tools.
A short generic “all IP belongs to the client” sentence may not adequately resolve these issues.
Careful drafting before development begins is usually far easier than reconstructing ownership after the software has become commercially valuable or a dispute has started.
For businesses entering technology or outsourcing arrangements in India, see Edvisars' Commercial Contracts and India Entry advisory services.
