A founder hires an agency, pays the invoice, gets the product, and assumes they own it. In Indian law, that assumption is wrong far more often than founders realise — and the gap usually surfaces at the worst possible time: during a funding round's due diligence, or when the relationship with the vendor breaks down.
This is not legal advice for your specific situation — every contract needs a lawyer's eyes before signing. But understanding the default rules and what to look for will make you a far more informed party at the negotiating table.
The default rule almost nobody knows
Under the Indian Copyright Act, 1957, the default rule is that the creator of a work owns the copyright in it — not the person who paid for it. This applies to software code, designs, written content, and most creative or technical output.
There is one major exception: under Section 17, if the work is created by an employee in the course of their employment, the employer owns it by default. But this exception applies specifically to employees — not to freelancers, contractors, or agencies.
That means if you hire an external developer, design agency, or hardware consultancy without an explicit IP assignment clause in the contract, the default legal position is that they own what they built for you — not you. You may have an implied licence to use it, but ownership, the right to modify it freely, resell it, or prevent others from using it, can remain with the creator.
This surprises almost every founder who hears it for the first time. It shouldn't be a surprise — it should be the first thing checked in any vendor contract.
Work-for-hire vs assignment — they are not the same
In the US, "work for hire" is a specific legal doctrine that automatically vests ownership with the hiring party under certain conditions. India has no equivalent doctrine. Many Indian contracts borrow the phrase "work for hire" from American templates, but the phrase has no special legal weight under Indian law — it does nothing on its own.
What actually transfers ownership in India is an explicit assignment clause — language that says the creator assigns, transfers, and conveys all right, title, and interest in the work to the hiring party, executed in writing and signed by the assignor, as required under Section 19 of the Copyright Act.
If your contract says "work product shall be considered work made for hire" and stops there, with no separate assignment language, you may not actually own what you paid for under Indian law — regardless of what the contract intended.
What a proper IP clause actually says
A contract that properly transfers ownership to you should include, at minimum:
- An explicit statement that all intellectual property created under the agreement is assigned to the client, not merely licensed
- Language covering copyright, patents, trade secrets, design rights, and any other applicable IP category — not just "copyright" narrowly
- A clear definition of what counts as "work product" — does it include preliminary drafts, internal tools built along the way, documentation, and test code, or only the final deliverable?
- Confirmation that the assignment is irrevocable and worldwide, not limited to a specific territory or time period
- A clause requiring the vendor to sign any further documents needed to perfect the assignment — sometimes required for patent filings specifically
- The assignment should be tied to payment in a way that's unambiguous — typically "upon full payment" is cleaner than vague language about "upon completion"
Code and software ownership specifically
For software specifically, a few additional things matter beyond the general assignment clause.
Source code, not just the compiled product. Some vendor contracts deliver a working application but are vague about whether you receive the actual source code, repository access, and the right to modify it independently. Make sure the contract explicitly states you receive full source code and repository ownership — not just a hosted, working version you cannot modify without the vendor.
Pre-existing IP vs newly created IP. If a vendor uses a framework, library, or internal tool they built before working with you, that pre-existing IP usually remains theirs — and should. What matters is that the contract clearly separates "pre-existing IP, licensed to you for use" from "new IP created specifically for you, assigned to you outright." A contract that's silent on this distinction creates ambiguity later.
Right to use after the relationship ends. Confirm the licence to any pre-existing components the vendor retains ownership of survives the end of the engagement — you don't want your product to stop working legally because a vendor relationship ended.
Hardware designs, PCBs, and physical IP
Hardware introduces its own category of IP that founders often overlook: schematics, PCB layouts, mechanical CAD files, firmware, and any patents arising from the design work.
PCB layouts and circuit designs are protected partly under copyright and partly under India's Semiconductor Integrated Circuits Layout-Design Act, 2000, which has its own registration and ownership framework separate from general copyright law. A standard software IP clause may not adequately cover this category — hardware-specific language, or at minimum a clause broad enough to capture "all designs, schematics, layouts, and technical drawings," is needed.
Firmware sits in a grey zone — it's software, but tightly coupled to specific hardware. Make sure firmware is explicitly included in the assignment, not left ambiguous as "part of the hardware deliverable."
If any part of the hardware design is patentable, the contract should specify who has the right to file for patent protection, who bears the cost, and how ownership of any resulting patent is allocated — this is a separate question from copyright assignment and is frequently missed entirely.
AI models and training data — the newest grey area
AI introduces ownership questions that most standard contract templates were never written to address, because the legal framework is still catching up to the technology.
The trained model itself. Is the model weights file — the actual trained artifact — assigned to you, or does the vendor retain rights to the trained model and only license its use to you? These are very different outcomes, and contracts are frequently silent or ambiguous on this specific point.
The training data. If you provided proprietary data to train the model, the contract should be explicit that this data, and any derivative datasets created from it during the engagement, remain yours and cannot be reused by the vendor for other clients or retained after the engagement ends.
The training pipeline and methodology. Vendors often want to retain rights to their general training methodology, evaluation scripts, and pipeline tooling, since these get reused across multiple clients. This is usually reasonable — but the contract should clearly separate "the trained model and its outputs, which are yours" from "the general-purpose tooling used to train it, which the vendor retains."
Because this area lacks settled legal precedent in India, the contract language itself carries more weight than it would for more established categories like code or hardware. Precision here matters more, not less.
Third-party and open-source components
Almost no product is built entirely from scratch. Open-source libraries, third-party APIs, and licensed components are part of virtually every software and hardware product.
The contract should require the vendor to disclose which third-party and open-source components are used, and confirm that their licences are compatible with your intended use — commercial use, in particular, since some open-source licences (notably certain copyleft licences like AGPL) impose obligations that can be incompatible with a closed-source commercial product if not handled carefully.
Without this disclosure, a founder can unknowingly end up with a product that infringes a third-party licence, creating liability that surfaces months or years later — often during investor due diligence, which is one of the most common places this issue is discovered.
Moral rights — the clause everyone forgets
Under Indian law, moral rights — the creator's right to be credited and to object to derogatory treatment of their work — exist separately from copyright ownership and, notably, cannot be fully waived under Indian law, even by contract, though they can be limited in scope.
In practice this rarely creates real problems for routine commercial software or hardware work. But a well-drafted contract should still include a clause where the creator agrees not to assert moral rights in a way that would interfere with your commercial use, modification, or rebranding of the work — even though full waiver isn't legally available. This is a narrower but still meaningful protection, and competent contract drafters include it as standard practice.
Red flags to watch for in a vendor contract
- The contract uses "work for hire" language with no separate, explicit assignment clause
- IP assignment is conditioned on vague terms like "completion" rather than a specific, verifiable milestone
- The contract is silent on source code delivery and repository ownership
- There's no distinction between pre-existing vendor IP and newly created IP
- AI/ML engagements have no specific language about trained model ownership separate from general code ownership
- No disclosure requirement for third-party or open-source components used
- The assignment clause is narrow — covers "the software" but not designs, documentation, or related technical materials
- No requirement for the vendor to execute further documents if needed for patent filing or formal registration
A practical checklist before you sign
| Check | Why it matters |
|---|---|
| Explicit assignment clause, not just "work for hire" language | "Work for hire" has no legal effect in India on its own |
| Source code and repository access included | Without this, you may only own a working product you can't modify |
| Pre-existing vs newly created IP clearly separated | Prevents disputes over what's actually yours after the engagement |
| Hardware-specific language if applicable | Standard software clauses may not cover PCB layouts and physical designs |
| Trained model ownership explicitly addressed (if AI involved) | This is a new area with limited legal precedent — precision matters |
| Third-party / open-source disclosure requirement | Protects you from hidden licence conflicts discovered later |
| Assignment tied to a clear, verifiable trigger (e.g. full payment) | Avoids disputes over when ownership actually transferred |
| Reviewed by a lawyer familiar with Indian IP law specifically | Templates from other jurisdictions often don't translate cleanly |
None of this is meant to make every vendor relationship feel adversarial — most agencies and freelancers have no intention of withholding what they were paid to build. But intentions don't matter once a dispute arises; only what the contract says does. A properly drafted IP clause, checked at the start of the engagement, costs very little time relative to the protection it provides.
This article is general information, not legal advice for any specific situation — always have a qualified lawyer review your actual contracts. If you're working through an engagement involving software, hardware, or AI development and want to discuss the technical side of a project, get in touch with us.