If a California job offer says you assign inventions or intellectual property to the employer, do not assume that it automatically captures every software project you built before joining. California Labor Code section 2870 limits the enforceability of certain employee invention-assignment terms for qualifying inventions developed entirely on the employee’s own time without the employer’s equipment, supplies, facilities or trade-secret information. But section 2870 has important exceptions tied to the employer’s business or actual or demonstrably anticipated research and development, and to work resulting from the employee’s work for the employer.
The key is to document what already exists and read the agreement’s exact scope before signing. Section 2870 is not a universal exemption for all copyright, code, product ideas or side businesses. It addresses inventions under employee invention-assignment agreements. Separate contract language, copyright ownership, confidential information, patent law, trade secrets and other state or federal rules may require separate analysis.
What California Labor Code section 2870 says
California Labor Code section 2870 provides that a provision in an employment agreement requiring an employee to assign rights in an invention to the employer does not apply to an invention that the employee developed entirely on their own time without using the employer’s equipment, supplies, facilities or trade-secret information. The statute then excludes inventions that either relate, at the time of conception or reduction to practice, to the employer’s business or actual or demonstrably anticipated research or development, or result from work performed by the employee for the employer.
Section 2870(b) says a term requiring assignment of an invention that is excluded under subsection (a) is against California public policy and unenforceable. Section 2872 requires an employer to provide written notification, at the time the agreement is made, that the agreement does not apply to an invention that qualifies fully under section 2870; it also places the burden of proof on the employee claiming the protection in a suit or action. The California Employment Development Department's guide reproduces these sections in its discussion of employee invention agreements. Read the statutory text and notice language with the actual offer, not a summary in a recruiter email.
These sections do not say that the employee can simply label a project “pre-existing” and be done. They address inventions developed by an employee and assignment provisions in an employment agreement; they do not by themselves resolve every agreement that purports to transfer an already-existing software asset, nor do they decide copyright in every file. Whether something is an invention, when it was conceived or reduced to practice, what resources were used, how it relates to the employer’s business, and whether it resulted from the employee’s work are factual questions. A startup product may overlap with a new employer’s field even if the code was written earlier. The relationship does not itself decide the answer, but it makes an itemized review important.
Separate the rights at issue
Software can involve more than one kind of intellectual property. Copyright may protect original code and documentation as expression; patent law can concern qualifying inventions; trade-secret law concerns information that meets statutory requirements and is protected as secret; contracts may define assignment, licences and confidentiality; and third-party or open-source licences can limit what the employee or employer can transfer. Section 2870 is not a blanket rule deciding all of those rights.
Existing code also has a chain of title. Did the employee write it alone? Did a former employer, university, client, cofounder or contractor contribute? Was it created under a grant, paid engagement, course, lab or previous employment agreement? Does it contain an open-source component? A person cannot promise an employer rights they do not own, and a schedule naming an asset cannot cure a missing assignment from a prior contributor.
Look for definitions such as “invention,” “developments,” “works of authorship,” “Company Inventions,” “related to the business,” “conceived,” “reduced to practice,” “used in the business” and “prior inventions.” Check whether the employee must list excluded inventions on an attachment, license any omitted item, or notify the company when using it. A clause may have a broad assignment mechanism alongside a statutory notice; those provisions need to be read together. Do not assume an attachment requirement necessarily waives statutory protection, or that a statutory notice automatically makes a broad clause harmless.
A pre-signing inventory that is useful later
Build a dated inventory with each project’s repository, commit history, author/contributor list, first public release, prior agreements, third-party dependencies, current status and intended use. Preserve source control history and release artifacts in their original form. For projects involving private code, record a secure hash or repository identifier rather than copying confidential material into an employer’s system.
For every item, answer: Was it created before the proposed start date? Was any part created on employer time or with employer resources? Does it overlap with the company’s products or research? Did the employee create it while performing work for the company? Who else contributed? Is the employee asking to continue maintaining or commercialising it? Would the new role require bringing any code or know-how into company work?
If an attachment requests prior inventions, describe assets accurately but avoid disclosing trade secrets or sensitive source code unnecessarily. A neutral description, repository name, creation date and concise scope may be sufficient for identifying an asset, subject to counsel’s advice and the form’s instructions. Ask for written acknowledgement of the schedule and a clear carve-out or licence if the project will be used in the new role.
Decision table
| Existing project facts | Section 2870 issue to test | Practical response |
|---|---|---|
| Built before the start date, on personal equipment, no employer information | Evidence of timing and resource independence; relationship to employer’s business still matters | Preserve history and disclose it on the requested schedule accurately |
| Built on weekends but using employer confidential information | Own-time element alone is insufficient | Stop disclosure or use; get counsel to assess confidential-information and assignment terms |
| Project relates to actual or demonstrably anticipated employer R&D | Statutory exception may be implicated | Identify the overlap and negotiate a precise written carve-out before signing |
| Work was created as part of assigned duties | Could result from work for employer, even if coding occurred at home | Map assignment, project scope, time and deliverables; seek specific advice |
| Open-source or former-client contributions appear in repository | Employee may not own all rights | Reconcile licences and prior assignments; do not promise unowned rights |
Worked hypothetical
Jordan built a small developer tool two years before applying to a California software company. The code is in a personal repository and has dated commits. The new offer contains a broad assignment of “all inventions, developments and works that relate to the Company’s business,” plus a schedule for prior inventions. The company also works in developer tooling.
Jordan should create a project inventory and preserve the history before signing. The facts that it predates employment and used personal equipment support part of the analysis, but the business overlap is relevant under section 2870’s exceptions. Jordan should ask California counsel to review the agreement and help negotiate a specific schedule entry describing the tool, the rights retained, any permitted company use and any restrictions on using company confidential information. Jordan should not upload the repository into company systems or assume that the statute resolves copyright, trade-secret or contract questions. This example illustrates issues, not a prediction of legal outcome.
When the project is already in the workplace
If the employee has already disclosed or used the tool at work, preserve the history and document what was provided, when, under what request and whether the company incorporated it into a product. Do not delete commits, rewrite history or move files to conceal evidence. Ask counsel to distinguish a licence to use a component from an assignment of ownership and to assess any employment agreement, confidentiality obligation or third-party licence.
If the company asserts ownership, request the specific agreement and facts it relies on. A measured response can identify the project’s chronology, repository and contributors while reserving legal positions. Avoid making a unilateral demand for an access change that could disrupt company operations or violate employment duties. If the person still works there, coordinate any technical separation with counsel and the employer’s authorised security process.
Common mistakes
- Treating section 2870 as covering every copyrightable work or every side project.
- Assuming own-time creation alone is conclusive without testing the statute’s business, research and employee-work exceptions.
- Assuming recruiter assurances modify a signed agreement.
- Listing a project without checking prior employers, collaborators, university terms or open-source licences.
- Uploading private source code to demonstrate ownership, thereby creating a new confidentiality risk.
- Failing to preserve original repository history and timestamps.
- Reading section 2872’s notice as a replacement for reviewing the assignment clause.
For related reading, see employment-related copyright ownership in England, our US copyright assignment-chain guide, and contract obligation tracking. These links are not California legal advice. You can contact us to organize a review or explore document workflows; these services do not determine invention ownership.
Questions people ask
Does California Labor Code section 2870 protect software I wrote before my first day?
It may be relevant if the software qualifies as an invention and the statutory conditions are met, but “before the start date” is not the whole test. Assess resources, employer trade secrets, business/R&D relationship and whether the project resulted from work performed for the employer. Copyright and other rights may need separate analysis.
Do I have to list an existing project in the prior-inventions schedule?
Follow the agreement’s instructions, but do not leave a potentially important project unidentified merely because you believe the statute protects it. Ask counsel how to describe it accurately without disclosing sensitive code, and request written confirmation of any agreed carve-out.
Does the statute cover open-source projects?
It can be part of the analysis if the project involves an invention, but open-source status does not decide ownership. Check contributors, licence obligations, employer overlap and the proposed agreement. The employee cannot assign third-party rights they do not hold.
Can the employer own my project if I used a company laptop once?
Section 2870’s “entirely on own time without use” language makes resource facts relevant, but a single fact does not automatically resolve ownership. What was used, whether company information was involved, what the agreement says and the project’s relationship to work all require review.
Does section 2870 mean my code is safe from a confidentiality claim?
No. Invention assignment and confidentiality are different obligations. Do not use, disclose or transfer confidential employer information based on an assumption that section 2870 protects the project.
What if the job agreement is already signed?
Preserve the signed version, notice and schedule, plus repository history and any communications about prior projects. Avoid altering the records. A California lawyer can assess the clause, statutory notice, project facts and available ways to document an agreed boundary.
Can I keep maintaining the project after joining?
That depends on the agreement, any conflict or outside-activity policy, confidential-information limits, and whether maintenance uses employer resources or overlaps with assigned work. Get written approval that addresses the specific activities and safeguards.
What evidence should I gather before the review?
Gather all agreement versions and attachments, project chronology, repository metadata, contributor records, equipment/resource facts, third-party licences, product overlap facts and any company disclosure or use. Keep confidential code secure and share it with counsel through an appropriate channel.
Pre-signature checklist
Before signing, identify each pre-existing repository and relevant contributor; preserve a dated source-control snapshot; review prior agreements and licences; compare the project with the employer’s business and known R&D; read sections 2870 and 2872 alongside the full invention and confidentiality provisions; accurately complete any schedule; negotiate a specific carve-out or limited licence where needed; obtain a signed acknowledgement; and get California counsel’s advice if the project has material commercial value or overlaps with the new role.
General information, not legal advice. California employee invention rules are fact-specific, and statutory protection is not a substitute for reviewing the proposed agreement, other IP rights and confidentiality duties. Have a California employment/IP lawyer review the actual terms before signing.
How Gotham researches and reviews field guides
