When a company hires an engineer in India through an employer of record (EOR), the client should verify the entire rights path for software the engineer creates. A clause in the client’s EOR services agreement may not, by itself, prove that the employee assigned copyright to the EOR or that the EOR then transferred those rights to the client. Review the employee-facing terms, EOR-client agreement, any separate assignment, and the actual work record together.
Under the Indian Copyright Act, 1957, the author is generally the first owner, subject to section 17 exceptions. Section 17(c), where clauses (a) and (b) do not apply, makes an employer first owner, absent an agreement to the contrary, of a work made in the course of employment under a contract of service or apprenticeship. Sections 18 and 19 address assignment. The actual employer, relationship, work, and contract terms therefore matter. “EOR” is a commercial label; it does not answer every copyright question.
This guide is a document-review framework, not a conclusion about any particular EOR arrangement. The agreement stack may span India and another country. Governing law, work location, the contracting entities, and the rights claimed can change the analysis. Have qualified counsel review the actual documents before a fundraising, acquisition, product launch or dispute.
Map the parties before reading the IP clause
Start with the legal entities, not a brand name. Identify the startup or client that will use the software, the EOR entity providing employment services, the individual developer, any subcontractor or staffing intermediary, and any affiliate named in the contracts. Confirm which entity signs each document and who has authority to sign an assignment.
Then draw a simple rights chain:
| Link | Document to locate | Key question |
|---|---|---|
| Client to EOR | Master services agreement, order form, IP schedule | What rights must the EOR obtain and transfer? |
| EOR to engineer | Employment or service contract, handbook, invention/IP terms | What rights does the engineer grant or assign, and to whom? |
| Engineer’s actual work | Project scope, repository, tickets, contribution records | Which work was created, when, and within what role? |
| EOR to client | Assignment, licence, deliverable transfer or express flow-through clause | Does the EOR convey the relevant rights to the correct client entity? |
| Third-party components | Open-source notices, vendor licences, pre-existing tools | What rights are not owned by the engineer or EOR? |
The chain should connect the same rights at each stage. A client contract that says “all IP belongs to customer” is not a complete chain if the EOR’s employee terms say something different, cover only inventions disclosed through a particular process, or name another group entity. Likewise, an employment clause assigning rights to the EOR does not show the client received those rights unless the next transfer is documented.
What does Indian copyright law add to the review?
Section 2(o) of the Copyright Act includes computer programs within literary works. Section 17 establishes the author-first-owner rule subject to exceptions. Section 17(c), where the preceding clauses do not apply, addresses work made in the course of employment under a contract of service or apprenticeship and makes the employer first owner unless the parties agree otherwise. This is a statutory rule about the relevant work and employment relationship; it should not be expanded into “every work by every contractor automatically belongs to the hiring company.”
For an EOR arrangement, determine who is the employer under the documents and facts, what law governs those employment terms, and whether the particular program was made in the course of that relationship. Do not assume that a customer’s day-to-day product direction necessarily makes the customer the statutory employer, or that the EOR’s label resolves the matter. Those questions require interpretation of the full arrangement. Section 18 also says that an assignment does not apply to a medium or mode of exploitation that did not exist or was not in commercial use when the assignment was made unless it specifically refers to that medium or mode; counsel should review this point when the documents use broad, future-facing language.
If the parties rely on assignment, sections 18 and 19 matter. Section 18 permits assignment by an owner or prospective owner of future copyright, with an assignment of future work taking effect when the work comes into existence. Section 19 requires a written assignment signed by the assignor or authorised agent, identifying the work and specifying the rights, duration, territorial extent, and royalty or other consideration payable to the author or legal heirs during the assignment; revision, extension or termination is on mutually agreed terms. If duration is omitted, it is deemed five years; if territory is omitted, it is presumed to extend within India. Under section 19(4), an assigned right not exercised within one year is deemed to lapse unless the assignment says otherwise. Ensure the documents cover code, documentation, modifications, releases and other intended deliverables, and address any background code that must remain with the engineer or EOR.
A software product is not one undivided object. Code may include employee contributions, contractor contributions, pre-existing libraries, open-source dependencies, third-party APIs, and customer-provided material. A copyright assignment cannot grant rights in components that the assigning party does not own. Use a component inventory and confirm the relevant licences and notices rather than relying on a broad warranty alone.
The Copyright Office also publishes the official ownership and assignment provisions in Chapter IV. Check the statutory wording against the actual employee and client documents; a commercial label such as EOR is not itself a complete transfer of rights.
Review the EOR-client services agreement
Read the operative text, definitions and document precedence. Search for “work product,” “deliverables,” “inventions,” “developed materials,” “customer materials,” “background technology,” “assignment,” “licence,” “moral rights,” “further assurances,” “subcontractor,” and “payment.” Record every incorporated schedule and policy version. Then answer these questions:
- Does the clause assign rights to the correct client entity, or only to the EOR’s customer generally?
- Does it cover work created by the named employee, permitted substitutes and subcontractors?
- Is the transfer effective as rights arise, at acceptance, after payment, or only on an additional deed?
- Does it include source code, object code, documentation, fixes, test materials and deployment scripts?
- What pre-existing tools are carved out, and does the client receive a licence sufficient to use and maintain the product?
- Are rights to third-party and open-source components expressly excluded from ownership but covered by licence and notice obligations?
- Must the EOR obtain signatures or further documents from the worker, and by when?
- What happens to rights and obligations at termination, employee reassignment, or EOR replacement?
- Does any liability cap, indemnity or exclusion conflict with the promised transfer or remedy?
A contractual promise by the EOR to “cause” an employee assignment differs from a signed assignment already obtained. Ask for evidence of the actual signed terms and a process for future contributors. If the EOR will not share personnel agreements for privacy or confidentiality reasons, counsel can consider a redacted certificate, tripartite instrument, or other acceptable evidence. Do not assume a certificate substitutes for the underlying legal transfer without reviewing what it confirms.
Check the employee-facing agreement and the source record
The client should verify the individual’s employment or service terms through an authorised, privacy-conscious process. Confirm the exact employing entity, start and end dates, role, applicable policy version, assignment language, permitted background materials, and any limits on transfer to a third party. If the employment terms grant rights to the EOR, identify the document or clause that then moves them to the client.
Compare those terms with the project record. Repository commits, issue tracker entries, code review approvals, release tags and build records can help identify the work and contributors. Preserve them in a controlled location. Avoid collecting unrelated personal files or source code from accounts outside the agreed scope. Where a repository includes third-party code, run a technical provenance review and route uncertain items to a knowledgeable reviewer.
For each contribution, record the author, date, repository/path, project, governing document, rights status, third-party dependencies, and evidence location. Mark any gap clearly: missing assignment, unclear employer, client entity mismatch, unsigned amendment, unidentified contractor, or unresolved licence. A risk list is more useful when it states what decision is needed and who owns it.
Worked example: an EOR employee’s code is assigned to the wrong entity
Fictional example. Northstar Labs, a Delaware startup, hires Priya in Bengaluru through EOR India Pvt Ltd. Priya’s employment agreement assigns work-related code to the EOR. The services agreement says the EOR will transfer “deliverables” to Northstar Holdings Inc., but the product is operated by Northstar Software LLC. The repository has contributions from Priya and a short-term contractor; no contractor assignment appears in the data room.
The team should not treat the issue as solved by an invoice or a general statement that “the customer owns the work.” Counsel would confirm the appropriate client entity and review whether each document covers the same rights. The EOR may need to execute a further assignment or confirm an existing transfer, and the contractor’s terms need separate review. The company should distinguish company-owned code from licensed dependencies and document a remediation plan before representing that the chain is complete.
EOR software IP diligence checklist
- List every employing, client, EOR, affiliate and subcontractor entity.
- Collect the signed services, employment, IP, policy, order-form and assignment documents.
- Record the governing law, work location, signatories, effective dates and document hierarchy.
- Trace rights from individual to employer, then from employer to the exact client entity.
- Confirm the assignment identifies the relevant work, rights, duration and territory.
- Check background materials, open-source and third-party components separately.
- Reconcile the contractual scope with repository contributors, project tickets and releases.
- Verify future-work, further-assurance, reassignment and offboarding processes.
- Identify gaps with an owner, evidence request and remediation deadline.
- Obtain qualified legal and technical review before investor or customer assurances.
The India IP due diligence guide explains how to carry rights evidence into a broader diligence record. The intern software ownership guide covers the employee-level statutory starting point; the vendor contract checklist gives a broader review workflow. Gotham’s India contract review workflow provides product context, and you can contact Gotham with workflow questions.
Questions about EOR and software ownership
Does an EOR automatically own every line of code the employee writes?
No blanket conclusion follows from the EOR label. Section 17(c) refers to work made in the course of employment under a contract of service or apprenticeship, subject to agreement to the contrary. The employer, relationship, work and documents must be examined.
Does the client own the software because it paid the EOR?
Payment alone does not prove a copyright transfer. Review the EOR-client agreement and the employee-facing rights terms, then verify the transfer to the intended client entity.
Is an NDA enough to transfer software copyright?
An NDA protects confidential information within its terms. It does not necessarily assign copyright. Check for an assignment or licence that identifies the work and rights, and satisfies the applicable statutory requirements.
Can a client ask to see an employee’s entire personnel file?
The client should request only information necessary to verify the rights chain and use a lawful, privacy-conscious process. Counsel may arrange redacted evidence or a tailored confirmation where the full agreement contains unrelated personal information.
What if the EOR says that its standard contract already covers IP?
Request the operative clause, the signed employee-facing instrument or appropriate evidence of it, the client transfer provision, and a map of how those terms connect. A sales statement or unsigned template does not show what was executed.
What should happen when a contributor leaves or the EOR changes?
The contracts and operational process should identify deliverables, access removal, repositories, credentials, further documents, licences, confidentiality and handover. Update the rights register and close gaps before making new ownership representations.
This article provides general information, not legal advice. EOR structures, employment status, governing law, and IP ownership depend on the full agreements, work, and jurisdictions involved; obtain qualified local advice.
How Gotham researches and reviews field guides



