Who Owns the Code You Write on Your Own Time?
Your employment agreement almost certainly claims more than it can enforce. Eleven states void the overreaching part by statute. What decides the question is not the contract language but a set of factual gates, and for software engineers most of that evidence is already sitting in your version control, written by you, without you thinking about it.
Almost every software employment agreement contains an invention assignment clause. Most engineers sign it during onboarding, in a stack of documents, and never read it again. Then, some evenings and weekends later, there is a side project that turns out to be worth something, and the question of who owns it becomes urgent and expensive.
The useful thing to know is that the clause is not the last word. A group of states, including most of the large technology employers' home states, have statutes that make part of the standard clause unenforceable. Those statutes do not turn on what you signed. They turn on facts.
Last updated: August 2026. Educational information about a statutory framework, not legal advice, and not an assessment of any particular agreement or project. State law varies, contracts differ, and the outcome is fact-specific. If something real is at stake, talk to an employment or IP attorney licensed in your state.
What the clause you signed actually claims
A typical pre-invention assignment provision, often part of a Proprietary Information and Inventions Agreement (PIIA), assigns to the employer any invention you conceive or reduce to practice during employment. The broad versions reach further: inventions made during the term of employment regardless of when or where, inventions relating to the employer's business, inventions that use employer resources, and sometimes a trailing period after you leave.
Read literally, the broadest of these would capture the app you built on a Saturday on your own laptop about a subject your employer has nothing to do with. That literal reading is precisely what several state legislatures decided was unacceptable.
The statute that overrides the contract
Eleven states now limit how far an invention assignment clause can reach: California, Delaware, Illinois, Kansas, Minnesota, Nevada, New Jersey, New York, North Carolina, Utah, and Washington. The California and Washington versions are the archetype and most of the others track them closely.
California Labor Code §2870 and Washington RCW 49.44.140 say, in substance, that an assignment provision does not apply to an invention that satisfies all of the following:
- It was developed entirely on your own time, and
- No equipment, supplies, facilities, or trade secret information of the employer was used, and
- It does not relate to the employer's business, or to its actual or demonstrably anticipated research or development, and
- It does not result from any work you performed for the employer.
Two structural points matter more than the wording. First, these are conjunctive. You need all of them. Failing any single gate puts the invention back inside the assignment clause. Second, Washington goes further than merely declining to apply the clause: under RCW 49.44.140(2), a provision purporting to require assignment of an excluded invention is void and unenforceable, and an employer may not require it as a condition of employment or continued employment.
New York joined this group recently. Senate Bill 5640, signed September 15, 2023 and effective immediately, added Labor Law §203-f and declares such over-broad provisions against the public policy of the state. The substantive test tracks the California and Washington model.
These statutes are shields, not swords
The statute does not grant you ownership of anything. It removes an over-broad contract provision from the picture for inventions that clear every gate. Ownership then falls back on ordinary principles, where the inventor generally starts as the owner. Nothing here overrides a specific, negotiated assignment of a specific invention that you actually made.
Every gate is an evidence question
This is the part that gets discussed as though it were about contract interpretation, when in practice it is about proof. Nobody is going to take your word for when you wrote the code. Each gate resolves into a factual question with a documentary answer:
| The statutory gate | The question actually being asked |
|---|---|
| Entirely your own time | When was this written? Not approximately. On what dates, at what hours, and can that be corroborated by something other than your recollection? |
| No employer equipment, supplies, or facilities | Which machine, which network, which accounts, which hosting, which paid tooling? Whose laptop was it compiled on? |
| No employer trade secret information | Did any internal knowledge, internal library, private package, or confidential architecture make its way in? |
| Unrelated to the employer's business or anticipated R&D | What does the project actually do, and how close is that to what your employer sells, builds, or has said it plans to build? |
| Not resulting from work performed for the employer | Did the idea come out of a problem you were assigned, a customer conversation, or an internal design discussion? |
Your version control is already the record
Here is what most advice on this topic misses. For a software side project, the evidence that answers those questions is not something you assemble later. It is being generated continuously, by your tools, as a byproduct of working, and it is far more specific than anything you will be able to reconstruct from memory two years afterward.
That cuts both ways, and it is worth understanding before you need it.
Commit metadata is good evidence, and less tidy than it looks. A git commit carries both an author date and a committer date, and they are frequently different. Rebasing, cherry-picking, amending, and squash merges all rewrite this history. A branch developed over six weekends can land as a single commit dated the day it merged. The timestamps are also written in the local timezone configured on the machine that made them. None of this is dishonest, it is just normal practice, and it means a commit log is a strong record only if nobody has flattened it.
The identity attached to each commit is doing more work than you realize. Your user.email in git config is stamped into every commit you author. If that is your work address, every commit in your personal project carries your employer's domain. Add a corporate SSO session on the hosting account, a machine enrolled in corporate MDM, or a push that went out over the company VPN, and the "no employer equipment or facilities" gate is being argued against a written record you created.
Dependencies leave fingerprints. A lockfile that references an internal registry, a vendored copy of an internal utility, or an import of a private package is direct evidence on the trade secret and supplies gates. It is also the failure mode engineers fall into most innocently, because reaching for the library you already know is the natural thing to do.
Your README argues the fourth gate for you. The "does it relate to the employer's business" question gets answered largely by the project's own description of itself. What you wrote to explain your project to strangers is what a reader will use to decide how close it sits to your employer's field.
The practical consequence
Hygiene here is cheap in advance and impossible to retrofit. A personal machine, a personal account, a personal email in your git config, personal hosting, and no internal dependencies will produce a clean record without any extra effort. Trying to establish the same facts after a dispute has started, from a squashed history authored under a work email, is a materially worse position.
"Relates to the business" is where most side projects actually fail
Engineers tend to focus on the time and equipment gates, because those feel controllable. In practice the subject-matter gate is the one that catches people, and it is drawn wider than most expect.
The statutory language does not just cover what your employer currently sells. It reaches the employer's business and its "actual or demonstrably anticipated research or development." A developer tools company that has publicly discussed moving into observability has arguably anticipated R&D in observability. If you work there and your weekend project is a tracing library, the gate is contested, no matter how carefully you kept it off the work laptop.
This gate is also the one where the ordinary trajectory of a side project works against you. Engineers build side projects in the domain they know, because that is where they see the problems. That domain is usually the employer's domain. The cleanest side projects, from this specific perspective, are the ones about something else entirely.
The notice requirement employers routinely miss
There is a procedural wrinkle worth knowing. Both California and Washington require the employer to tell employees about the carve-out. California Labor Code §2872 requires that an employment agreement containing an assignment provision give written notice that the agreement does not apply to inventions qualifying under §2870. Washington's RCW 49.44.140(3) imposes a parallel written-notification obligation for agreements entered into after September 1, 1979.
If you want to know whether your employer complied, look at your own PIIA for a paragraph quoting or referencing the statute. Many agreements have it, precisely because counsel drafting for multi-state employers knows the requirement. What follows from an omission is a legal question with more nuance than a web page can settle, and it is the kind of detail an attorney reviewing your specific agreement would want to see.
What to do about it
Before you start something you care about:
- Read the actual clause. Request a copy of the agreement you signed. Look for the assignment scope, any trailing post-employment period, any disclosure obligation, and whether the statutory notice is present.
- Separate the infrastructure completely. Personal device, personal accounts, personal email in
git config user.email, personal hosting, personal network, no internal packages. The cost of this is a few minutes of setup. - Pick the domain deliberately. The further your project sits from your employer's business and stated roadmap, the less contested the hardest gate becomes.
- Do not flatten your history. A granular commit log made under a personal identity is a contemporaneous record. A single squashed commit is not.
- Consider disclosing. Many agreements let you list pre-existing or excluded works. Some employers will sign a written acknowledgment for a specific side project. A clear answer in writing beats an argument later, and asking is usually less dangerous than engineers assume.
If you have already built it: the immediate priority is preserving the evidence rather than reasoning your way to a conclusion. Capture the repository history before anyone rewrites it, note which machines and accounts were used, identify every dependency, record when the project was first described publicly, and gather the agreement itself. Then take that to an attorney. Ownership questions are also joint-ownership questions if anyone else contributed, which is a separate trap covered in co-founder IP ownership.
If patent protection is on the table at all, note that the ownership question and the disclosure clock run independently. Publishing the project can start a one-year US clock and end foreign rights the same day, regardless of who ends up owning it. See building in public and patent rights.
Frequently Asked Questions
Does my employer own my side project?
Not automatically, and in eleven states not even if your contract says so. California, Delaware, Illinois, Kansas, Minnesota, Nevada, New Jersey, New York, North Carolina, Utah, and Washington have statutes making assignment clauses inapplicable to inventions developed entirely on your own time, without employer equipment, supplies, facilities, or trade secret information, that do not relate to the employer's business or anticipated research and development and do not result from work you performed for the employer. All of those conditions have to hold together. Outside those states, the contract language carries more weight, and the answer depends on what you signed.
I wrote it on my own laptop at night. Isn't that enough?
It clears two gates, not all of them. Own time and own equipment are necessary but not sufficient. The invention also has to be unrelated to your employer's business or demonstrably anticipated research and development, and it cannot result from work you performed for the employer. In practice the subject-matter gate is the one that most often fails, because engineers build side projects in the domain they work in.
What counts as using the employer's equipment?
The statutes list equipment, supplies, facilities, and trade secret information. For software that reaches further than a work laptop: corporate network or VPN, company-paid tooling and cloud accounts, internal libraries or private package registries, and confidential internal knowledge. Using an internal utility library because it was convenient can implicate both the supplies and the trade secret gates at once.
Does the invention have to be patentable for these statutes to matter?
The statutes are written in terms of inventions and assignment of rights in them, and they are the framework people reach for in patent disputes. Copyright in code raises related but distinct questions, including work-made-for-hire doctrine, which these statutes do not directly address. Whether a specific statute reaches a specific work product is exactly the kind of question to put to an attorney rather than infer from the general rule.
My employer never told me about the statutory exception. Does that void the clause?
California Labor Code §2872 and Washington RCW 49.44.140(3) both require employers to give written notice of the carve-out in agreements containing an assignment provision. Whether a failure to give that notice affects enforceability, and to what extent, is a legal question that depends on the state, the agreement, and the circumstances. It is a real point worth raising with counsel, not a guaranteed escape hatch.
Should I tell my employer about my side project?
Many agreements require disclosure of inventions, and many also provide a mechanism to list excluded or pre-existing works. A written acknowledgment that a specific project falls outside the assignment is far more valuable than an unrecorded assumption. Whether disclosure is advisable in your situation depends on your agreement and your relationship with your employer, which is a judgment worth making with advice rather than alone.