Skip to main content
Guides Workplace topics IP Assignment Clauses in 2026 — What Your Side Projects Belong To and What Does Not
Workplace topics

IP Assignment Clauses in 2026 — What Your Side Projects Belong To and What Does Not

10 min read · April 25, 2026

IP assignment clauses can quietly decide who owns your side projects, open-source work, startup ideas, and inventions. This guide explains the clauses that matter, the carve-outs to ask for, and how to document a clean separation.

IP assignment clauses in 2026 are where employment paperwork quietly reaches into your side projects, open-source work, startup ideas, writing, designs, code, and inventions. The scary version says the company owns everything you create while employed. The more accurate version is narrower: employers can usually claim work created for the job, with company resources, using confidential information, or closely related to the employer’s actual business; they should not automatically own unrelated work built on your own time with your own tools. The hard part is proving which bucket your project belongs in.

This guide is a practical review and documentation playbook. It is not legal advice, and IP law varies by state and country, but it will help you spot the clauses that matter before you sign or ship something on the side.

The core rule: scope, resources, and relationship to the business

Most employee IP disputes come down to three questions.

| Question | Safer answer for you | Riskier answer for you | |---|---|---| | When was it created? | Nights, weekends, before employment, after termination | During work hours or while being paid to solve the same problem | | What resources were used? | Personal laptop, personal accounts, personal cloud, no company data | Company laptop, GitHub, Figma, Slack, datasets, models, contractors, or office lab | | How related is it? | Different market, different customer, no use of internal knowledge | Same product area, same customer problem, same roadmap, same technical approach |

A personal budgeting app built by a backend engineer at a healthcare company is usually a different fact pattern than a patient scheduling tool built by that same engineer after seeing the employer’s roadmap. A newsletter about management is different from a paid course using confidential internal playbooks. A weekend game prototype is different from an AI feature that overlaps directly with your team’s unreleased product.

Key phrases that change the answer

Read the clause slowly. These phrases matter.

“Hereby assign” or “present assignment.” This language attempts to transfer ownership automatically as soon as the invention exists. It is stronger than “agree to assign,” which is a promise to sign paperwork later. Employers like present assignment language because it avoids a fight over whether you must cooperate after leaving.

“Conceived, developed, reduced to practice, authored, or created.” This broadens the timing. An idea sketched in a notebook may be covered even before code exists if the clause includes “conceived.” “Reduced to practice” usually means the idea became specific enough to implement or test.

“Relates to the business or anticipated research.” This is the phrase that swallows side projects if not narrowed. “Anticipated research” can mean roadmap-adjacent work you learned about internally. Ask for the business to be defined by current products, not every possible future product.

“Using company equipment, supplies, facilities, or confidential information.” This is the cleanest boundary. Do not use company devices, paid software seats, cloud credits, source code, customer lists, internal docs, meeting notes, datasets, prompts, models, or design systems for outside work.

“Works made for hire.” In U.S. copyright law, work made for hire can make the employer the author from the start when the work is created within the scope of employment. Employment agreements often include both work-made-for-hire language and assignment language as a belt-and-suspenders approach.

“Moral rights waiver.” Common in global agreements, this asks you to waive rights to object to modifications or attribution. It matters for designers, writers, researchers, and creators, especially outside the U.S.

State carve-outs are real, but you must preserve them

Several states have worker-protective invention assignment laws. California is the most famous: California Labor Code Section 2870 generally protects inventions developed entirely on the employee’s own time without employer resources if they do not relate to the employer’s business or actual or demonstrably anticipated research, and do not result from work performed for the employer. Other states have similar concepts, including Washington and Illinois-style protections.

The important point is that these laws are not magic shields. They protect certain facts. If you build on a company laptop, use internal docs, or work in the exact product area you were hired to build, the carve-out becomes much weaker. If your agreement includes a notice of state-law exclusions, read it. If it does not, ask for the statutory carve-out to be included in the agreement.

A useful signing request:

Please add the standard state-law carve-out confirming that inventions developed entirely on my own time, without company resources or confidential information, and unrelated to the company’s business or anticipated research, are excluded from assignment.

That sentence will not solve every case, but it frames the boundary correctly.

The prior inventions schedule is not a formality

Many agreements include an exhibit where you list prior inventions, projects, companies, domains, repositories, designs, manuscripts, patents, newsletters, courses, or open-source packages. Employees often leave it blank because they do not want to seem distracted. That is a mistake.

If you have anything meaningful already in progress, list it. Use plain descriptions, not source code. Include project name, short description, date started, URL if public, and whether it is owned by you or an entity you control. If you are unsure whether something is worth listing, list it broadly.

Example:

| Project | Started | Description | Status | |---|---:|---|---| | BudgetFox | 2024 | Personal finance web app for household cash-flow planning | Personal project, no company resources | | async-review-lib | 2023 | Open-source JavaScript library for review workflows | Public GitHub repository | | Manager Notes newsletter | 2022 | Paid newsletter about people management templates | Personal writing project |

Do not attach confidential material from a prior employer. The schedule is a notice tool, not a data dump.

Side project decision matrix

Use this before you ship, raise money, open-source, or mention a side project publicly.

| Situation | Risk level | What to do | |---|---|---| | Built before joining and listed as prior invention | Low to moderate | Keep clean records; avoid using employer resources after joining | | Unrelated project built on personal time and personal tools | Lower | Document separation; consider a brief disclosure if your agreement requires it | | Related industry but different customer and no confidential information | Moderate | Get legal review before monetizing; narrow the overlap in writing | | Same customer problem your team works on | High | Pause, get counsel, and do not pitch customers or investors yet | | Uses internal data, code, designs, prompts, roadmap, or customer insights | Very high | Stop using the material; get advice before any disclosure | | Co-founder or coworker from the same employer joins | Higher | Check employee non-solicit, confidentiality, and assignment clauses for both people |

The pattern is simple: the closer your side project is to your job’s paid problem space, the cleaner your process needs to be.

Practical examples

The unrelated app. You work in enterprise security and build a recipe app at night on your own laptop. You do not use company design assets, internal libraries, or customer data. Risk is usually low, especially if you list it or disclose it if required.

The adjacent tool. You work in customer success software and build a small Chrome extension that summarizes support tickets. Even if you write it on weekends, the overlap is real. If your employer has AI support features on the roadmap, this is attorney-review territory.

The open-source library. You maintain a general-purpose logging library. Your employer uses it too. If you started it before joining and keep contributions separate, risk is manageable. But if you add features during work hours because your team needs them, ownership and license questions get messy.

The founder idea. You are a product manager at a fintech company and start validating a new banking workflow with potential customers. If those customers overlap with your employer’s prospects, or if your idea came from internal strategy, this is high risk even before code exists.

The content business. You write a paid interview-prep guide using lessons from your career. General experience is yours. Internal interview rubrics, confidential scoring sheets, candidate packets, and company-specific question banks are not.

Clean-room rules for side projects

If you want the best argument that a project belongs to you, make the separation boring and provable.

  • Use a personal laptop you bought.
  • Use personal GitHub, cloud, email, Figma, Notion, and domain accounts.
  • Do not connect personal projects to company SSO.
  • Do not copy internal docs, tickets, datasets, prompts, dashboards, or code.
  • Do not work on the project during meetings, work hours, on-call shifts, or paid travel days.
  • Keep lightweight time records for major milestones.
  • Keep receipts for personal software, contractors, and hosting.
  • Avoid asking coworkers to contribute unless both agreements are reviewed.
  • Do not test with company customers or vendors without permission.
  • Do not describe the project using confidential roadmap language.

The goal is not paranoia. The goal is evidence. If a dispute happens later, “I built it separately” needs support.

Disclosure: when it helps and when it creates risk

Some agreements require disclosure of inventions that may relate to the company’s business. Others require approval for outside business activities, board roles, consulting, or paid speaking. Read both the IP agreement and the conflict-of-interest policy.

Disclosure can help when the project is benign and you want a written record. It can hurt when you disclose vaguely and invite a broad claim. If you disclose, be specific without over-sharing:

I am maintaining a personal project called BudgetFox, a consumer budgeting app started before my employment. I use only personal equipment and accounts, do not work on it during company time, and do not use company confidential information. I understand my confidentiality obligations and will keep the project separate.

If the company responds with approval, save it. If it responds with “we own this,” pause and get advice before you keep building.

Negotiating the clause before you sign

Reasonable edits include:

  1. Define “Company Business” by current products and services, not any conceivable future business.
  2. Add the state-law invention carve-out in the agreement body.
  3. Exclude prior inventions listed on the schedule.
  4. Exclude inventions developed entirely on personal time without company resources and unrelated to company business.
  5. Exclude passive investments and unrelated creative work.
  6. Clarify that open-source contributions made outside the scope of employment are not automatically assigned.
  7. Require written notice if the company claims an invention after disclosure.

You do not need to sound adversarial. Try:

I am happy to assign work I create for the company and anything using company resources or confidential information. I also maintain unrelated personal projects, so I need the agreement to preserve those and the standard personal-time invention carve-out.

Most sophisticated employers understand this request. If they refuse any carve-out at all, treat that as a serious signal about future ownership fights.

Leaving the company with side projects in motion

Before you resign, make sure your personal repositories and accounts do not contain company material. Do not wipe company devices without following policy, but do remove personal accounts. Return all equipment. If you are joining or founding a business near the old employer’s market, write a short memo to yourself describing what you will not use: customer lists, pricing, roadmap, unreleased features, models, source code, internal research, and confidential partner terms.

If the company asks you to sign a termination certificate, read it carefully. Some certificates ask you to reaffirm broad IP assignment language, state that you have disclosed all inventions, or assign inventions created during employment. Do not sign quickly if you have a side project that overlaps even slightly.

Bottom line

IP assignment clauses in 2026 are manageable if you treat ownership as a process, not a vibe. List prior projects. Narrow the agreement. Use separate tools. Keep records. Avoid company resources and confidential information. Get review before monetizing anything close to your employer’s product area. The cleanest side project is one you can explain in one sentence: built on my time, with my tools, outside the company’s business, and documented from the start.