It happens more than anyone admits. A senior engineer gives two weeks' notice, and by the time IT reviews the access logs, they have already downloaded the repository. A former employee shows up at a competitor with your crown jewels — the sensitive code that gives your product its edge. A contractor finishes an engagement and starts building a suspiciously similar product six months later. In each case, the founder is left asking the same question: what can I actually do when someone steals your source code?
The answer depends almost entirely on what you had in place before it happened. If you have the right agreements, security measures, and documentation, you may have three or four independent legal claims and the ability to move fast with an injunction. If you have nothing — no invention assignment agreement, no NDA, no access logs — your options narrow dramatically. This article is both a response playbook for when source code walks out the door and a prevention checklist for making sure it does not happen again. Whether you are dealing with a disgruntled employee, a former engineer who jumped to a rival, or a full-blown case of corporate espionage, the framework is the same.
The Three Legal Claims You Probably Have (If You Planned Ahead)
When an employee or contractor takes your source code, the law gives you several potential theories of recovery. The strongest cases stack multiple claims together, because each claim covers a different aspect of the misconduct and each has different evidentiary requirements.
Trade secret misappropriation. Under both federal law (the Defend Trade Secrets Act) and state trade secret statutes, you can bring a claim if the employee took information that qualifies as a trade secret and did so through improper means — theft, breach of a duty of confidentiality, or unauthorized access. Your source code almost certainly qualifies as a trade secret if it provides economic value and you took reasonable measures to keep it confidential. The critical phrase is "reasonable measures." Courts will evaluate whether you had confidentiality agreements, access controls, encryption standards, and internal policies governing the handling of proprietary information. If you did, your trade secret claim is strong. If you did not, a court may find that you failed to protect the trade secrets and the protection does not apply. The landmark prosecution of a former Google engineer for stealing AI-related trade secrets illustrates just how seriously federal courts treat this — that case involved allegations of economic espionage and resulted in criminal charges.
Breach of contract. If the employee signed a confidentiality agreement, a non-disclosure agreement, a non-compete, or an invention assignment agreement that prohibited them from taking or using the company's proprietary information, taking source code is a straightforward breach of contract. The contract claim is valuable because it does not require you to prove that the information qualifies as a trade secret — only that the employee agreed not to take it and then did. This is why having signed agreements in place before the employee starts work is so important. The contract creates an independent basis for recovery that does not depend on the technical requirements of trade secret law. If the agreement also included a non-compete clause, you may be able to prevent the former employee from working at the competitor entirely — at least for a defined period.
Copyright infringement. Source code is protected by copyright from the moment it is written. If the employee copied your code — literally reproduced it or created a derivative work — that is copyright infringement. The strength of this claim depends on whether you can show that the employee's new product contains your code, which may require forensic analysis of the competing codebase. If you registered your copyright with the U.S. Copyright Office before the infringement occurred (or within three months of publication), you can pursue statutory damages and attorneys' fees, which dramatically increases your leverage.
Moving Fast: Emergency Injunctive Relief
In most source code theft situations, the priority is stopping the bleeding — preventing the employee from using, sharing, or commercializing your code while the case proceeds. A temporary restraining order or preliminary injunction can do this, but courts require you to show that you are likely to succeed on the merits, that you will suffer irreparable harm without the injunction, that the balance of hardships favors you, and that the injunction serves the public interest.
Trade secret cases are particularly well-suited to emergency relief because the harm from disclosure is often irreversible. Once your source code is shared with a competitor or incorporated into a competing product, no amount of money damages can undo the damage to your competitive position. Courts understand this, and they are generally receptive to injunction requests in trade secret cases — provided you can demonstrate that you acted quickly (delay undermines the "irreparable harm" argument) and that your protections were in place before the theft occurred.
The practical lesson: if you discover that source code has been taken, do not wait. Contact legal counsel immediately. Preserve all evidence — access logs, download records, email communications, the employee's devices if you still have them. The faster you move, the stronger your position. Every day you delay is a day the attacker has to cover their tracks, distribute the code, or embed it into a competing product.
What If You Don't Have Agreements in Place?
This is the nightmare scenario, and it is more common than it should be. A startup hires engineers, builds a product, and never gets around to having anyone sign an invention assignment agreement or an NDA. When someone leaves and takes the code, the founder discovers that their legal position is far weaker than they assumed.
Without a confidentiality agreement, you lose the breach of contract claim entirely. You are left with trade secret misappropriation and copyright infringement — both of which are viable but harder to prove without the contractual foundation. The trade secret claim requires you to demonstrate that you took "reasonable measures" to maintain secrecy, and the absence of written agreements is a significant negative factor in that analysis. Courts have repeatedly found that companies that fail to require confidentiality agreements cannot credibly claim they treated their information as confidential.
Without an invention assignment agreement, you may face an even more fundamental problem: you might not own the code. Under federal copyright law, the default rule is that the person who writes the code owns the copyright — unless the work qualifies as a "work made for hire" or the creator has assigned the rights in writing. For employees working within the scope of their employment, the work-for-hire doctrine usually applies. But for contractors, independent developers, and co-founders, there is no automatic assignment. If you did not get a written assignment, you may not own the code that walked out the door — which means you may not have standing to bring a copyright claim at all.
The Prevention Checklist: What to Have in Place Before Day One
The best time to prevent source code theft is before you hire your first engineer. The second best time is now. Here is what every software company should have in place:
Invention assignment and confidentiality agreement. Every employee and every contractor should sign an agreement that assigns all intellectual property created during the engagement to the company and imposes confidentiality obligations that survive termination. This should be signed before the person writes a single line of code. Not after. Not "when we get around to it." Before.
Non-disclosure agreements with specific scope. For contractors, advisors, and anyone who accesses your codebase, a standalone NDA that specifically identifies the types of information covered — source code, algorithms, database architectures, customer data, business strategies — is essential. Generic NDAs that cover "confidential information" without specificity are harder to enforce.
Access controls, monitoring, and cybersecurity infrastructure. Restrict access to source code repositories on a need-to-know basis. Not every employee needs permission to access every repository. Use role-based access controls, require multi-factor authentication, and log all access and download activity. Deploy data loss prevention (DLP) tools that flag unusual download volumes or transfers to personal storage. Implement token-based authentication for API access and enforce encryption at rest and in transit. These security measures — and the logs they generate — become critical evidence if you need to prove what was taken, when, and by whom.
Offboarding procedures. When an employee or contractor departs, immediately revoke all system access, recover all company devices and materials, conduct an exit interview that addresses IP obligations, and send a written reminder of ongoing confidentiality duties. Document everything. The offboarding process is your last opportunity to create a record that the departing individual understood and acknowledged their obligations.
Copyright registration. Register your software's copyright with the U.S. Copyright Office. Registration is inexpensive and creates substantial legal advantages: the ability to pursue statutory damages (up to $150,000 per work for willful infringement), the ability to recover attorneys' fees, and a legal presumption of ownership. If you do not register, you are limited to actual damages, which in a source code case can be difficult to prove.
Open source audit and code hygiene. If your codebase includes open-source components, make sure your licensing obligations are documented and your proprietary code is clearly separated. When someone steals code that is intermingled with open-source libraries, it can create confusion about what is actually proprietary and what is freely available. An attacker — or their lawyer — will exploit any vulnerability in your ownership chain. Maintaining a clear boundary between your proprietary code and any open-source dependencies strengthens both your legal position and your cybersecurity posture.
The Co-Founder Problem
The hardest version of this scenario involves a co-founder. When a co-founder leaves a company and takes code with them, the legal analysis gets complicated fast. Who owns the code? It depends on the operating agreement, the founder's employment agreement (if one exists), and the terms of any IP assignment. If the founders never formalized IP ownership — which happens with alarming frequency — the departing co-founder may have a legitimate claim to the code they wrote.
This is why every co-founder relationship should start with a written agreement that addresses IP ownership. Whether it is embedded in the operating agreement, a separate IP assignment, or a founders' agreement, the document should make clear that all intellectual property created for the company belongs to the company, not to any individual founder. It should also address what happens to IP rights if a founder departs — including a confirmation that the departing founder retains no rights in the company's codebase.
If you are past the point of prevention — the co-founder is gone and the agreements were never signed — the situation is not hopeless, but it is significantly more complicated. You may have arguments based on the work-for-hire doctrine, implied assignment, unjust enrichment, or the terms of the company's formation documents. But each of these arguments is uncertain, fact-dependent, and expensive to litigate. The cost of drafting a proper founders' agreement at the outset is a rounding error compared to the cost of litigating IP ownership after a falling out.
Forensic Evidence and Proving What Was Taken
In any source code theft case, you will need to prove what was taken and that the former employee actually used it. This typically requires digital forensics — an analysis of the employee's access logs, download history, email and messaging records, and, if available, a comparison of your codebase against the competitor's product.
Code comparison analysis can identify matching code segments, identical variable names, replicated bugs, and structural similarities that would be statistically improbable in independently written code. If the employee was sloppy — copying files directly, emailing sensitive code to personal accounts, pushing commits to a personal repository — the evidence may be straightforward. If they were more careful, the analysis becomes more complex but is often still productive. Forensic experts can also trace whether stolen code was used to steal code from additional systems or escalate access to other proprietary assets.
Preserving evidence is essential. As soon as you suspect source code has been taken, preserve the employee's access logs, email archives, and any company devices. If you have the right to inspect the employee's personal devices (which should be addressed in your employment agreement), exercise that right immediately. Evidence that is lost or destroyed cannot be recovered, and a court will draw negative inferences from a party's failure to preserve relevant documents.
The Bottom Line
Source code theft is a predictable risk with a known set of preventive measures. Whether the threat comes from disgruntled employees, a former engineer recruited by a competitor, or a sophisticated act of corporate espionage, the companies that get hurt worst are the ones that treated IP protection as something they would get to later. The companies that are best positioned to respond — with injunctive relief, strong legal claims, and clear evidence — are the ones that built the foundation before they needed it.
At Turley Law, we help software companies and technology founders across Connecticut, New York, and Massachusetts protect their intellectual property, draft employment and contractor agreements, and respond to IP theft when it occurs. If you need to strengthen your IP protections or respond to a source code theft, we are available to help.
Schedule a free assessment to discuss how this applies to your business.
