Employees’ Side Projects: Who Really Owns What?
Remote work, GitHub at night, a little SaaS on the side… and somewhere in HR’s SharePoint there’s a “Proprietary Information and Inventions Assignment Agreement” you clicked through on day one.
This is the collision point:
You feel like “it’s my side project.”
Your employer assumes “we own anything you build while you work here.”
This article walks through how ownership of employee side projects actually works in the U.S., with matrices you can adapt into policies, NDAs, or onboarding docs.
🎯 The Three Legal Buckets: Copyright, Patents, Contract
Most “who owns my side project?” analysis reduces to three overlapping pieces:
| 🧩 Type of Right | What It Covers In Side Projects | Default Rule (Without Any Contract) |
|---|---|---|
| Copyright | Code, UI, text, designs, training data, documentation, content. | Creator is the owner unless (1) it’s a “work made for hire” (within scope of employment) or (2) rights are assigned. (U.S. Copyright Office) |
| Patents | Patentable inventions: new software methods, hardware designs, processes. | The inventor owns the patent rights unless there’s an assignment or duty to assign; the employer may only get an implied license. |
| Contract (invention assignment) | “PIIAA” style agreements that say: you assign certain inventions to the employer. | Often drafted very broadly; their enforceability is then limited by state law (e.g., California Labor Code 2870). ) |
You only really answer “who owns my app?” once you’ve walked through all three.
🧑💻 Work Made For Hire vs True “Side Project”
The phrase “work made for hire” gets thrown around a lot in tech, often incorrectly.
Under U.S. copyright law, a work is “made for hire” if: (U.S. Copyright Office)
- You’re an employee, and
- You created the work within the scope of your employment (the kind of thing you’re paid to do, on your employer’s time, for their benefit),
or (less common here) it’s a specifically commissioned work in one of a few narrow categories with a written “work for hire” agreement.
Applied to side projects:
| Scenario | Work-For-Hire Likely? | Why It Matters |
|---|---|---|
| You’re a software engineer building an internal tool during your normal workday at your employer, under a ticket assigned to you. | 🟢 Yes | That code is almost certainly owned by the employer as work made for hire. |
| You’re the same engineer building an unrelated mobile game at home at night, not using company resources. | 🔴 Usually no | It’s outside scope of employment; default copyright stays with you (subject to any contract/2870 issues). ) |
| Marketing employee writing a fantasy novel on weekends. | 🔴 No | Completely outside role and business. |
| Product designer prototyping a SaaS UX that’s close to employer’s roadmap, using Figma on work laptop during “down” time. | 🟡 Gray | Scope-of-employment + employer devices + relation to business all cut against “pure side project.” |
So: work-for-hire is a narrow doctrine, but when it applies, the employer is the initial copyright owner even before any contract.
📜 Invention Assignment Agreements: The Real Battleground
Most tech employers don’t rely solely on work-for-hire. They use Proprietary Information and Inventions Assignment Agreements (PIIAA) that say, in effect:
“You assign to us any inventions you create during your employment that relate to our business, or that you create using our equipment or confidential information.”
In many states, broad assignment clauses like that are enforceable unless limited by specific statutes.)
But a subset of states now have employee-protection laws that carve out side projects.
🗺️ State “Employee Invention” Laws: The Side-Project Shield
Several states follow a California-style approach: certain employee inventions must not be swept into assignment clauses.
California (the template)
California Labor Code § 2870 says an employee’s agreement to assign inventions does not apply to any invention the employee: (Justia Law)
- Developed entirely on their own time,
- Without using employer equipment, supplies, facilities, or trade secrets,
except if the invention:
- Relates to the employer’s business or actual/anticipated R&D, or
- Results from work performed for the employer.
Employers must also give employees written notice of these limits (2871–2872) and often attach a statutory notice. (cdn-static.findly.com)
Other states
Illinois, Washington, Minnesota, North Carolina, Delaware, New York and others have similar statutes limiting forced assignment of truly independent inventions. (Illinois General Assembly)
Common pattern:
- No assignment where invention is developed on the employee’s own time,
- Without employer resources or trade secrets,
- And not related to the employer’s business or actual/expected R&D.
So even if your PIIAA reads “we own everything you ever think about,” state law can make those parts void and unenforceable for qualifying side projects.
🧮 Side Project Ownership Matrix
Here’s a visual decision matrix you can adapt. It assumes you’re in a state with a California-style statute; if not, the contract may have more reach.
| 🎯 Side Project Scenario | Own Time? | Employer Resources? | Related To Employer’s Business? | Who Likely Owns?* | Risk Level |
|---|---|---|---|---|---|
| Indie game, built on your own laptop at home, no overlap with employer’s business. | ✅ Yes | ❌ No | ❌ No | You by default. Employer has weak claim under CA/IL/WA/NY-type statutes. | 🟢 Low |
| SaaS tool solving the exact pain point your employer is working on, coded nights/weekends on your personal machine. | ✅ Yes | ❌ No | ✅ Yes | Employer may have strong assignment rights; at least arguable under PIIAA + 2870 exception. | 🟡/🔴 Medium–High |
| Open-source library for a general-purpose algorithm, using work laptop and VPN, partly during work hours. | ❌ Mixed | ✅ Yes | 🟡 Somewhat | Use of equipment plus overlap with your day job lets employer argue ownership or at least a license. | 🔴 High |
| Article or book about a hobby unrelated to work (e.g., cooking, travel). | ✅ Yes | ❌ No | ❌ No | You. Very hard for employer to claim. | 🟢 Low |
| AI tool that directly competes with employer’s future roadmap, drafted using employer’s confidential strategy deck. | ❌ No | ✅ Yes | ✅ Obvious | Employer likely owns or, at minimum, has strong claims (trade secrets, fiduciary duties). | 🔴 Very High |
* “Who owns” here is shorthand; real outcomes depend on jurisdiction, contract language, and evidence.
🧠 Employer vs Employee Expectations: The “Two Stories” Problem
Employees usually think:
- “I wrote this on my own time, so it’s mine.”
- “I didn’t use company code, so they have no rights.”
Employers often think:
- “If it’s in your field and we’re paying you to think about this space, we own it.”
- “If you used our laptop, GitHub account, or confidential info, it’s ours (or at least we get a license).”
Both sides are partially right.
Legally:
- Default patent rule: inventor owns rights unless there’s an assignment; employer may get an implied license for inventions created in the course of duties. (Sierra IP Law)
- Default copyright rule: creator owns, unless work-for-hire or assigned. (U.S. Copyright Office)
- Contract + state statutes then shift that default up to a point.
🧱 Practical Design Rules For “Clean” Side Projects
If you’re designing policies—or advising someone who wants their side project to stay theirs—these are the levers that actually matter.
Clean-Project Checklist (Employee View)
| ✅ Do This | 🚫 Avoid This |
|---|---|
| Build on your own equipment (laptop, cloud accounts) and pay for your own hosting/tooling where feasible. | Using employer-issued laptop, IDE, VPN, or paid SaaS accounts for side work. |
| Work on it outside of working hours, with time stamps that show clear separation. | Committing to your side repo during standup, sprint time, or while on-call. |
| Keep it outside the employer’s line of business and future roadmap as much as possible. | Building a “more modern version” of your employer’s core product and pitching it to the same customer segment. |
| Avoid using employer trade secrets (source code, internal docs, unreleased roadmaps). | Copying internal patterns, code snippets, pricing logic, or non-public data models into your project. |
| Keep written evidence of when you conceived and built the project (logs, notebooks, commit history). | Letting timelines blur so the employer can argue it developed as part of your work for them. |
In California and similar states, the more you can tick those boxes, the stronger your position under Labor Code 2870–style protections. (Justia Law)
🧾 Policy & Contract Tools For Employers
On the company side, you have to balance protecting core IP with not scaring off talent who want to tinker.
Common Tools
| 🛠️ Tool | What It Does | Pitfalls |
|---|---|---|
| Invention Assignment Agreement (PIIAA) | Grabs IP created within scope of employment, and anything related to the business or built with company resources. () | Overbroad drafting can collide with state statutes and be treated as an unlawful non-compete in some cases. () |
| Side-project disclosure / approval process | Lets employees pre-clear personal projects and, where appropriate, get something in writing that the company won’t claim them. | If too slow or heavy-handed, employees just stop disclosing and take everything underground. |
| Open-source contribution policy | Defines when employees can contribute to OSS in their own name, and whether the company claims any ownership. | If it’s “everything you code is ours,” you’ll lose people who care about OSS reputation. |
| Moonlighting policy | Clarifies which outside gigs are allowed (teaching, writing, hobby apps) vs disallowed (direct competitors, heavy time commitment). | Overly restrictive policies can be seen as non-competes in strict jurisdictions. |
For multi-state employers, you also have to bolt on state-specific notices (CA, IL, WA, MN, NY, etc.) to assignment clauses, or you risk parts of them being void.
🤖 What About AI-Built Side Projects?
Modern wrinkle: side projects now often rely on AI coding assistants and AI content models.
Key questions:
- If you use your employer’s enterprise AI tooling (e.g., code assistant tied to their repos), you’re implicitly pulling in their IP and training data. Expect them to argue that outputs are part of their ecosystem.
- If you use consumer AI tools on employer confidential information (internal docs, private code), you may both:
- Breach your PIIAA / confidentiality obligations, and
- Expose employer trade secrets into third-party AI logs or training corpora. (RPJ Law)
Practically, for “clean” side projects:
- Use personal AI accounts with no access to employer repos.
- Don’t feed in employer-confidential material as context.
- Treat AI suggestions like Stack Overflow code: review for license issues, provenance, and similarity to your employer’s IP.
🔚 Big Picture
“Who owns my side project?” is rarely answered by one magic clause or one statute. It’s a fact pattern:
- What you built,
- Where, when, and with whose tools,
- How closely it tracks your employer’s business, and
- What you signed—and where you work.
From a planning standpoint, the best outcomes come from designing side projects and policies to avoid ambiguity:
- Employees build on their own stack, on their own time, away from employer trade secrets.
- Employers use clear PIIAA + state-compliant notices, and a lightweight side-project disclosure path instead of “we own your brain” contracts.
That’s how you keep side projects as the creative outlet they’re meant to be—rather than the opening paragraph of the next IP lawsuit.