When a Departing Engineer Takes Source Code

A senior software engineer resigns from a Xi'an technology company. IT later discovers that, during the final week of employment, the engineer downloaded several repositories and copied technical documents. Four months later, a competitor releases software with a similar workflow and several functions that appear unusually close to the former employer's product. Management wants to sue immediately. The legal problem is not simply "software theft." China law can protect computer software under copyright law and the Computer Software Protection Regulations,^[1][2] while non-public source code and technical information can also qualify as trade secrets under Article 10 of the revised Anti-Unfair Competition Law if the statutory elements are satisfied.^[3] The same facts may support different claims, but each claim requires different proof.

The first task is therefore to decide what exactly was taken, what legal right protects it, and what evidence can prove copying or misappropriation without turning the case into an overbroad allegation that the competitor copied the entire business.

The specific problem#

Evidence preservation and rights identification#

Freeze evidence before confronting the employee. the first 72 hours should focus on preservation. Before interviewing the former engineer or contacting the competitor, preserve: The relevant items include source-code repositories, access logs, commit history, endpoint logs, email, cloud-storage records, USB events, download history, technical documents, and employment and confidentiality agreements. The company should create forensic copies and preserve original metadata. An immediate confrontation can cause deletion, account changes or coordination among potential defendants. The legal team should first determine whether access remains open and whether company credentials need to be disabled. Evidence collection should also comply with applicable personal-information and employment rules. A company device does not mean every personal communication can be collected without limitation. The investigation should be scoped to the suspected conduct and the systems relevant to it. The case will later be much stronger if the company can show a clean timeline: what the employee accessed, when, from which device and in what volume.

Identify the copyright work precisely. china's Copyright Law recognizes computer software as a protected category of work.^[1] The Computer Software Protection Regulations define software to include computer programs and related documentation and provide the specific legal framework for software copyright.^[2] The claimant should not plead "our platform" as one undifferentiated work. Identify: The relevant items include modules, source files, documentation, versions, release dates, authors, and ownership.

A modular claim allows the court and technical experts to compare specific protected expression. The company needs to also establish the ownership chain. If code was written by employees, contractors, founders or university collaborators, the relevant agreements and employment status should be reviewed. Software registration can be useful evidence, but it should not replace the underlying development history. Repository records showing who wrote and committed code at particular times can be more persuasive than a registration certificate that does not identify the disputed module in detail. Separate copyright copying from functional similarity. copyright protects expression, not every underlying function or idea. Two programs may perform the same business task without one infringing the other's copyright. The technical comparison should therefore distinguish: The relevant items include identical or highly similar source-code sequences, unique comments, naming structures, database schemas, error messages, architecture, user-interface elements, and general functional concepts.

A competitor's product may look similar because both products solve the same industry problem. The claimant needs evidence of copying of protectable expression or use of confidential information, not just market similarity. Where the defendant's source code is unavailable, the claimant may initially rely on access opportunity, unusual development speed, identical errors, technical behavior and other circumstantial evidence, but the litigation strategy should anticipate a need for technical inspection or expert analysis. Define the trade secret separately from the copyright work. article 10 of the 2025 Anti-Unfair Competition Law defines a trade secret as technical, business or other commercial information that is not known to the public, has commercial value and is subject to corresponding confidentiality measures.^[3] Source code can qualify, but not automatically. The claimant should define specific secret points such as: The relevant items include a non-public algorithm, process logic, source-code implementation, deployment architecture, test data, and proprietary technical documentation.

"All source code" may be too broad if large portions contain open-source or publicly known components. For each claimed secret, the company should explain: 1. why it was not public;

1. why it had commercial value;
2. what confidentiality measures protected it;
3. how the former employee accessed it. This secret-point schedule becomes the foundation for a trade-secret claim.

Copyright, trade-secret and unfair-competition theories#

Prove real confidentiality measures, not only an NDA. an NDA is useful but is rarely the whole confidentiality system. The company should preserve evidence of: The relevant items include role-based repository access, password controls, confidential labels, security policies, employee training, restrictions on personal storage, supplier confidentiality, and exit procedures. The revised Anti-Unfair Competition Law's trade-secret framework makes "corresponding confidentiality measures" a statutory element.^[3] If hundreds of employees could download the code without monitoring, the defendant may argue that the claimant did not actually protect it as a secret. The company needs to therefore be candid about weak controls. Litigation strategy should focus on the secret points that were genuinely protected rather than claim every internal file. Use Article 39's burden-shifting framework strategically. article 39 of the 2025 Anti-Unfair Competition Law contains important civil evidence rules for trade-secret cases.^[3]

Where the rights holder provides preliminary evidence that confidentiality measures were taken and reasonably indicates infringement, the alleged infringer bears the burden of proving that the claimed information is not a trade secret. The article also addresses circumstances where preliminary evidence of access or opportunity combined with substantial similarity or other infringement indicators can shift the burden on infringement issues.^[3] This makes the first evidence package critical. The claimant should aim to establish: The relevant items include defined secret, confidentiality measures, employee access, suspicious download, competitor opportunity, and technical similarity.

The case should be designed around the statutory evidentiary pathway, not around the hope that discovery will reveal everything later. Copyright and trade-secret claims should support, not contradict, each other. the same code can have both copyright value and secrecy value, but the pleadings should explain the distinction. Copyright claim: the defendant copied protected software expression. Trade-secret claim: the defendant improperly obtained or used non-public technical information protected as a trade secret. A claimant should avoid arguing that a source-code element is widely distributed and publicly established when proving copyright originality, then simultaneously claiming that the same information is secret without explanation. The strongest litigation plan may assign different modules to different legal theories. For example: The relevant items are public-facing UI code: copyright, private optimization algorithm: trade secret, and copied documentation and product presentation: copyright/unfair competition.

A coherent rights map is more persuasive than stacking every available cause of action on the same facts. Investigate the competitor's independent-development defense. the new employer may argue that its software was independently developed. The claimant should examine the timeline. Questions include: The relevant items include When did the competitor start the project?, How many engineers worked on it?, What prior code base existed?, Was the former employee hired before or after architecture decisions?, and Did product features change immediately after the hire?.

A four-month development of a complex system may look suspicious if comparable work normally takes two years, but timing alone does not prove copying. If litigation permits technical comparison, the defendant's repository history may become central. The claimant should also expect the competitor to argue that any similarities result from standard libraries, open-source code or common industry requirements. Technical experts should isolate genuinely distinctive similarities.

Burden shifting and technical proof#

Preserve open-source evidence so the defendant cannot collapse the claim. modern software contains open-source components. A defendant may respond to a similarity allegation by showing that the identical code came from a public library. The claimant should therefore create an SBOM or dependency inventory for the disputed product and separate: The relevant items include company-written code, open-source code, licensed third-party code, and generated code. Claiming open-source code as proprietary can damage credibility. The company should preserve license files and upstream versions so the expert can exclude public components from the comparison. This also matters for damages. The commercial value of the claimed secret or copied expression should be tied to the company's proprietary contribution, not to code freely available to everyone. Case study: industrial software engineer. assume a Xi'an industrial automation company develops proprietary control software. A senior engineer with repository access resigns. Logs show a 12GB download two days before resignation. The engineer joins a competitor, which releases a similar controller within five months. The claimant identifies:

The relevant items include proprietary scheduling module, configuration parser, test database, and internal deployment manual. A weak complaint says the competitor "copied the whole platform." A stronger case: 1. identifies copyright ownership in the scheduling and parser code;

1. defines the test database and deployment process as separate trade secrets if statutory conditions are met;
2. proves the engineer accessed each item;
3. documents confidentiality measures;
4. compares the competitor's executable behavior and available code;
5. excludes open-source libraries. The court can then evaluate concrete rights and evidence rather than a generalized allegation. Remedies should match the business objective. the company should decide what it actually wants. Possible objectives include: The relevant items include stop use of code, stop disclosure of secrets, preserve evidence, recover damages, require return or deletion, and prevent a customer migration based on misappropriated technology.

The revised Anti-Unfair Competition Law provides civil remedies and, for qualifying serious intentional trade-secret infringement, enhanced damages mechanisms.^[3] Copyright law also provides remedies for infringement.^[1] The litigation team should build damages evidence early: The relevant items include R&D cost, lost contracts, licensing value, defendant sales, and saved development time. Do not wait until liability is established to begin quantification. Build the prevention system from the litigation lessons. after the incident, the company should remediate: The relevant items include repository permissions, download monitoring, contractor assignments, employee confidentiality, offboarding, device controls, and trade-secret register.

The goal is not to make every internal file secret. It is to identify the technology that truly matters and protect it consistently. High-risk employee exits should trigger enhanced preservation based on access and destination, not indiscriminate forensic review of every departing employee. A company that can define its secret, show ownership and produce access evidence within 24 hours is far better positioned than one that begins inventing the definition after litigation starts.

Independent development, open source and damages#

Employee and contractor ownership documents should be tested against the actual development history. software companies often use standard IP clauses, but the disputed code may predate the current employment contract. The company should reconstruct: The relevant items include when each module was created, who created it, employment or contractor status at that time, whether the creator worked for another affiliate, and whether third-party code was incorporated.

If a founder wrote key code before incorporation, the company should verify assignment to the company. If a contractor wrote part of the system, review the services agreement for ownership and delivery of source materials. The defendant can exploit gaps in title. A claimant who cannot prove ownership may still have a trade-secret interest in some information, but the copyright claim can become unnecessarily complicated. Ownership cleanup should therefore be part of ordinary software governance, not an emergency step after misappropriation. The claimant should plan for technical expert evidence from the beginning. judges should not be asked to infer source-code copying from marketing screenshots. Counsel should engage a technical expert to define: The relevant items include comparison methodology, relevant code base, public/open-source exclusions, version control evidence, distinctive structures, and statistical significance of similarities.

The expert should work from preserved originals. If the claimant modifies the repository after the incident without retaining the historical version, later comparison can become disputed. The expert can also help distinguish literal copying from independent implementation of the same functionality. A clear expert report can make the legal theories narrower and stronger. Preliminary relief and evidence preservation should be evaluated separately. the company may want an immediate injunction, but the evidentiary threshold and urgency should be assessed realistically. Possible early objectives include: The relevant items include preserve defendant evidence, stop further disclosure, secure devices or repositories through lawful process, and prevent imminent product release.

The legal team should identify the harm that cannot easily be repaired by damages. At the same time, an aggressive application based on a poorly defined trade secret can expose weaknesses early. The claimant should therefore prepare the secret-point schedule and technical evidence before seeking emergency relief where possible. The strongest emergency application is usually focused on a small number of well-proven assets, not the entire product platform. Settlement design should include technical verification. a software dispute may settle before judgment. Useful settlement terms can include: The relevant items include deletion or return of specified source code, independent forensic certification, no use of defined trade secrets, limits on specific modules, damages, confidentiality, and audit or verification mechanisms.

A settlement that merely states "do not infringe IP" may be too vague to enforce. The company needs to define exactly what technical material must be removed and how compliance will be verified. This is especially important when the competitor has already incorporated some code into a larger product and complete product withdrawal is commercially unrealistic.

Employee ownership, expert evidence and interim relief#

The incident should trigger a targeted governance remediation. after the case begins, management should identify why the employee could take the code. Possible causes include: The relevant items include overly broad repository access, shared credentials, no download alerts, uncontrolled personal devices, and incomplete exit process. The company should fix those controls while preserving evidence of the historical system. Remediation should not rewrite the past. If access was broad at the time, the claimant should not create backdated policies. It should accurately document the controls that existed and improve them prospectively. A credible claimant is one that can distinguish its actual historical protections from later improvements. Cross-border reporting of the investigation should be controlled. a multinational technology company may need to report the incident to an overseas parent, insurer or board. The investigation team should decide which personal information and technical data actually need to leave China. Where possible, management reports can summarize findings without exporting full employee mailboxes or entire repositories. Technical data may itself be sensitive for commercial or regulatory reasons. The legal team should therefore coordinate IP protection, personal-information compliance and any export-control issues before transferring evidence overseas.

A litigation hold should not become an uncontrolled cross-border data dump. Criminal referral should be evaluated only on established facts. serious trade-secret theft or related conduct can potentially raise criminal issues depending on the evidence and legal thresholds. The company needs to not use a criminal accusation simply as settlement pressure. If referral is considered, counsel should first establish: The relevant items include defined secret, ownership, confidentiality measures, access, evidence of acquisition or use, and loss or other relevant consequences. Civil and criminal strategies should be coordinated because inconsistent descriptions of the secret or loss can damage credibility. The company should preserve original forensic evidence and maintain a clear chain of custody. The board should distinguish containment from litigation victory. the immediate business goal may be preventing further disclosure rather than maximizing damages. Management should decide whether success means:

The relevant items include stopping a product launch, removing copied code, preventing customer solicitation using confidential materials, recovering money, and obtaining a public judgment. That objective should shape the litigation and settlement strategy. A technically perfect copyright case that takes years may not solve an urgent competitive threat. Conversely, a rushed injunction application with weak evidence can reveal the claimant's weaknesses. Counsel should therefore match remedy, evidence and business urgency from the outset.

Cross-border reporting, settlement and governance remediation#

Customer evidence can corroborate technical misappropriation. customers may observe unusual similarities before the claimant can inspect the defendant's source code. Useful evidence may include: The relevant items include identical configuration errors, copied technical language, matching undocumented features, and customer statements about the former employee's role. The claimant should preserve this evidence carefully and avoid encouraging customers to speculate. A customer's observation is not a substitute for technical proof, but it can help establish chronology, access opportunity and commercial harm. Damages analysis should distinguish development cost from market loss. software cases often present several possible measures of harm. The claimant may examine: The relevant items include lost sales, reduced licensing revenue, defendant gain, reasonable license value, and R&D cost.

These measures are not interchangeable. If the defendant saved two years of development by copying code, avoided development cost may help explain commercial benefit, but the legal damages calculation must follow the applicable statutory and evidentiary framework. The finance and technical teams should therefore begin collecting sales, margin, license and development records early. A software incident should be rehearsed before it happens. high-value software businesses should run a tabletop exercise. The scenario should ask: The relevant items include who freezes accounts, who preserves repositories, who instructs forensic experts, who defines the secret, who decides on employee contact, and who approves litigation.

The exercise often reveals that legal, HR and IT have inconsistent assumptions. A rehearsed response reduces the risk of losing evidence during the first 24 hours. Final litigation architecture. before filing, counsel should reduce the case to a rights-and-evidence matrix. Each claimed software work or trade secret should have a separate row showing ownership, confidentiality, employee access, defendant conduct, proof source and requested remedy. If a row cannot be supported, it should be narrowed or removed rather than hidden inside a broad complaint. Repository architecture can help prove both access and separation of proprietary work. a mature company should be able to identify which repositories contained the disputed modules, which teams had access, and whether public or open-source dependencies were stored separately. That architecture can help demonstrate confidentiality while also making technical comparison more efficient.

If the employee had access only to one repository, the claimant should be cautious about alleging theft of unrelated products. Narrow claims tied to actual permissions are generally more credible than enterprise-wide accusations. Product-release evidence should be preserved from the competitor's public materials. before websites, download links or technical documentation change, the claimant should preserve lawful public evidence of the competing release. Version numbers, release notes, documentation and demonstrations can help establish chronology and identify which functions deserve deeper technical comparison. Public evidence should be collected systematically rather than through isolated screenshots with no date or context.

Conclusion#

A departing-engineer software dispute should not be pleaded as one vague allegation of "technology theft." Chinese law provides different but complementary tools: copyright protection for computer software,^[1][2] and trade-secret and unfair-competition protection under the revised Anti-Unfair Competition Law.^[3] The strongest case begins by freezing evidence, defining the protected code or secret precisely, proving ownership and confidentiality, and using Article 39's evidentiary framework intentionally. The practical rule is: identify the right before accusing the defendant, and preserve the evidence before confronting the employee.

Legal and regulatory sources#

^[1] Copyright Law of the People's Republic of China (2020 Revision): https://www.npc.gov.cn/c2/c30834/202011/t20201119_308796.html ^[2] State Council, Regulations on Computer Software Protection: https://www.cac.gov.cn/2013-02/08/c_126468744.htm ^[3] Anti-Unfair Competition Law of the People's Republic of China (2025 Revision), especially Articles 10, 22, 26 and 39: https://www.npc.gov.cn/npc/c2/c30834/202506/t20250627_446247.html

General legal information only; not legal advice for a specific dispute.