IP assignment in Indian employment contracts: what engineers building side projects need to know

Six months into building your side project (every weekend, personal laptop, your own cloud account), you go back and read your employment contract. There it is, buried in clause 14: 'Any intellectual property created by the Employee during the term of employment, whether or not using Company resources, and whether or not related to the Company's business, shall be the exclusive property of the Company.'

You stop reading. Is that clause actually enforceable?

The answer in India is: it depends on what kind of IP you have, and on three specific words in the clause itself. What follows covers what that clause typically reaches, where it usually cannot, and what you can do about it before you commercialise anything. This is not legal advice. Consider it the map you need before you talk to a lawyer.

What the standard clause actually says

Most Indian tech employment agreements follow one of two patterns.

The first type, call it the catch-all clause, assigns everything to the employer: any IP the employee creates during the employment period, regardless of whether they used company time, equipment, or knowledge. These clauses typically run two to four sentences and sweep up inventions, designs, software, trade secrets, and know-how in one go.

The second is narrower: it assigns IP that is created using Company resources, or that relates directly to the Company's current or planned business activities. The phrase 'relates to the Company's business' does substantial work here, and courts have generally read it to mean the employer's actual commercial domain, not everything the employer could conceivably enter.

Which type you have matters enormously. Check whether the operative word is 'or' (broader: catches either condition) versus 'and' (narrower: requires both). That single conjunction can change the outcome.

The scope question: three clause types, three risk profiles

Once you locate the clause, read it for three specific things.

The trigger condition. Does it activate on 'during the term of employment' (meaning any calendar time you are employed) or on 'within the scope of employment' (meaning your actual job duties and work product)? The latter is meaningfully narrower and leaves more room to argue.

The nexus test. Does the clause require a connection to the company's business, or does it sweep up everything? 'Any IP created while employed' is the strongest employer position. 'IP relating to the Company's field of business' leaves scope for a genuine argument.

The resource condition. 'Created using Company equipment, systems, or proprietary information' is different from 'created during employment.' Many engineers inadvertently shift this into the employer's favour by using a work laptop or work accounts for side-project commits, even occasionally.

The practical test: if you built your project on a personal laptop, using a personal GitHub account, outside working hours, in a domain the company has no presence in. You are in the strongest possible position, even against a broad clause.

Patents and copyright work differently in India

This distinction matters more than most articles acknowledge.

Copyright in India attaches to the author at creation. Section 17 of the Copyright Act creates a default exception for works made in the course of employment: the employer owns the copyright if the work is created in the course of the author's employment under a contract of service. 'In the course of employment' is the operative phrase; it does not automatically extend to all work done during the employment period. A side project with no functional connection to your job description, built outside work hours on personal infrastructure, is arguable. Add a broadly-worded contract clause that explicitly assigns all IP created during employment, and the argument gets harder.

Patents are different. India has no statutory equivalent of the 'employed to invent' doctrine found in some other jurisdictions, where the employer automatically owns inventions within the employee's job duties. Under Indian patent law, the default rule is that the inventor owns the patent. An employer can only claim ownership of an employee invention if there is an explicit, written contractual assignment. This makes the quality of the clause language especially consequential for any side project with patentable elements.

The non-compete is probably unenforceable. The IP assignment is a separate matter.

A common assumption among engineers: if the non-compete in my contract is unenforceable, the IP assignment clause must be similarly toothless. These are separate provisions with different legal foundations.

Section 27 of the Indian Contract Act renders post-employment non-compete restraints largely unenforceable. Indian courts have consistently held that preventing a former employee from earning a livelihood in their professional field amounts to an unreasonable restraint of trade. Exceptions exist, typically in very senior roles with strong confidential-information arguments, but for most engineers, the non-compete's post-employment reach is narrow.

IP assignment is different. A signed copyright assignment is a property transfer, not a restraint of trade. A validly executed assignment clause, covering IP that genuinely falls within its scope, can be enforced after you leave. The non-compete tries to stop what you do next; the IP assignment claims ownership of what you have already made. Do not conflate them.

Before you sign: the carve-out conversation

The cleanest way to protect a pre-existing or in-progress side project is to address it before you sign the offer letter.

Some Indian tech employers — increasingly, particularly companies that have hired from or been shaped by global tech culture — are open to a side project carve-out schedule attached to the employment agreement. The carve-out names the project, describes its scope, confirms it is excluded from the IP assignment, and sets conditions: typically no company resources, no work on the project during company hours.

The conversation is less awkward than it feels. Employers who hire engineers understand that engineers build things. Raising this at the offer stage, before you sign, reads as professional and clear-headed about boundaries. Raising it three months into employment is harder; raising it the day before you resign is the worst possible timing.

If you are evaluating an offer and you have something worth protecting, get the carve-out named in writing before the ink dries. Even a brief email exchange acknowledging the project's exclusion from the IP clause — replied to and retained — is better than nothing.

Already employed: what you can still do

If you are already employed and have not negotiated a carve-out, your options are fewer but not zero.

First, re-read your contract and categorise it against the three clause types above. Broad catch-all or narrower scope-based? The difference shapes your exposure.

Second, keep clean records. Commit history with timestamps, personal accounts throughout — no company email, no corporate GitHub organisation, no work-issued cloud accounts — and a clear audit trail of what was built, when, and on which device. This documentation is not definitive proof of ownership, but it matters if the question is ever raised.

Third, check whether your company has a policy on outside employment or conflicts of interest. Many employers require disclosure of outside commercial activity. If your project could plausibly compete with the employer, or if a reasonable reading of your contract would bring it within scope, proactive disclosure is the less risky path. The conversation is awkward; the alternative is worse.

Fourth, if your project is gaining commercial traction and the IP question is more than theoretical, talk to a lawyer who knows employment law in your state before you take investment, sign a customer contract, or form a company around the project.

Before you quit: a practical checklist

If you are planning to leave employment to pursue your side project full-time, sort these things before you hand in your notice.

• Read your employment agreement end to end, not just the summary. Understand the trigger condition, nexus test, and resource condition in the IP clause.
• Audit your commit history. Are all commits from personal accounts? Were any made during working hours? Does any code overlap with work you did for the employer?
• Identify whether your project falls within the nexus test in your contract. If it does, you have a problem to solve before you quit, not a risk to accept after.
• Talk to a lawyer before you resign — not after. A single consultation with someone who knows employment law in your jurisdiction is worth more than any amount of post-hoc cleanup.
• Do not copy, repurpose, or carry out any company code, documentation, or proprietary tooling into your new project. This is the fastest way to convert a scope dispute into a straightforward infringement claim.
• Check your notice period and any garden-leave provisions. Some contracts prevent you from working on a competing project during notice. If this applies, factor it into your timing.
• Check whether your contract contains a disclosure obligation for inventions created during employment. If it does, take legal advice on how and whether to fulfil it as part of your exit.

The engineers who navigate this cleanly are not the ones who hired the best lawyers after the dispute started. They are the ones who read the contract before they built, negotiated before they signed, and kept their records straight throughout.