Kevin Jun Lin, Corporate Lawyer

In-Depth Practice of Source Code Co-Management and Escrow Clauses

In the investment and financing practice of the software industry, we repeatedly witness an unsettling reality: the core code of the vast majority of startups is actually controlled by only one or two people. A CTA (Chief Technical Architect) leaving, co-founders falling out, or a founder “slacking off”—any of these scenarios can sink the investors’ money. How to use legal means to make the code truly the “company’s code” rather than the “individual’s code” is the core question this article answers.

I. Case Introduction: Overnight, the Company Lost All Its Code

At the end of 2023, a SaaS company that had raised RMB 50 million in Series B financing encountered an operational crisis of “disaster-level” proportions. After a fierce disagreement with the CEO, the company’s CTO (also one of the co-founders) deleted his personal private Git repository in a fit of anger on a Friday and took away all the local code on his laptop.

Even more shocking, the company only discovered afterward: although the company had a nominal “company Git repository,” all key components—core architecture code, deployment scripts, database schemas—were hosted in that CTO’s personal private GitHub repository (registered with his personal email), and no other employee of the company had administrator access to the repository. It took the company more than three months and several million RMB to rebuild the code before it could barely restore the product’s basic operating capability.

The RMB 50 million invested by investors was, at that moment, almost entirely exposed to the huge risk of “single-point loss of control over source code.” This real case (the parties’ information has been anonymized) reveals a cruel truth: that you “own” the company in the legal sense does not mean you truly “control” the company’s core asset—the source code.

II. Interpretation of Legal Provisions: Contractual Obligations and Source Code Delivery

(1) Article 509 of the Civil Code: The Principle of Full Performance

Article 509 of the Civil Code of the People’s Republic of China
The parties shall fully perform their obligations in accordance with the agreement.
The parties shall, in accordance with the principle of good faith, perform such obligations as notice, assistance, and confidentiality in light of the nature and purpose of the contract and the course of dealing.

If a founder undertakes in a shareholders’ agreement or capital contribution agreement to deliver the source code to the company, this delivery obligation should be “fully performed”—not only the delivery of the code files themselves, but also the delivery of necessary ancillary materials such as the complete development environment configuration, technical documentation, and deployment instructions, so that the company can truly use and maintain the code independently.

(2) Article 563 of the Civil Code: Statutory Grounds for Rescission of a Contract

Article 563 of the Civil Code of the People’s Republic of China
The parties may rescind the contract under any of the following circumstances:
(1) the purpose of the contract cannot be achieved due to force majeure;
(2) before the expiration of the performance period, one party expressly states or indicates by its conduct that it will not perform its principal obligation;
(3) one party delays performance of its principal obligation and, after being demanded, still fails to perform within a reasonable period;
(4) one party delays performance of its obligation or commits other breaches that make the purpose of the contract impossible to achieve;
(5) other circumstances provided by law.

In the context of source code co-management, if the technical founder refuses or delays delivering the source code, causing the company to be unable to operate the product normally, the investor may, under the contract, claim that the founder has committed a fundamental breach, thereby triggering remedies such as contract rescission and equity repurchase. However, note that even if the law gives you the right, if clear source code delivery standards and time limits are not agreed in the contract in advance, the rights-protection process will be long and difficult.

III. Practical Points: A Four-Layer Defense System for Source Code Control

(1) Layer One: Git Repository Co-Management Mechanism

Core principle: control over the code repository must not be concentrated in one person. It is recommended to establish the following co-management rules from the very inception of the company:

It is particularly worth noting that, with the development of the domestic open-source ecosystem, besides GitHub, domestic platforms such as Gitee (Maoyun) and Coding.net also provide similar organization management functions and may have advantages in cross-border compliance and data security. The specific choice should be comprehensively determined in light of the company’s business scenario and financing background.

(2) Layer Two: Tiered Permission Management—Preventing Anyone from Being “Omnipotent”

The core logic of permission management is: allow people to work efficiently, but do not let anyone exclusively control. It is recommended to establish the following separation-of-powers mechanism in the day-to-day management of the technical team:

1. Separation of code read/write: all developers have write access only on development branches, and merge requests to the main branch must be approved by at least one non-direct developer.
2. Separation of deployment and development: production environment deployment keys and CI/CD pipeline configurations are separated from daily development permissions; only designated operations or DevOps personnel may access them.
3. Tiered management of secrets: sensitive information such as database passwords, API keys, and cloud service credentials is centrally managed using the company’s secrets management service (e.g., Vault, AWS Secrets Manager) and does not appear in plaintext in the code repository.
4. Third-party service accounts belong to the company: all code-related third-party services (Docker Hub, npm Registry, PyPI, etc.) must be registered with the company email and not a personal email.

(3) Layer Three: Third-Party Source Code Escrow

Source Code Escrow (third-party source code escrow) is a risk-mitigation mechanism widely used in international software transactions. Its basic operation model is as follows:

In shareholders’ agreements in the software industry, the triggering conditions for Source Code Escrow typically include:

• The technical founder dies, loses capacity, or is declared missing
• The technical founder is lawfully dismissed by the company or removed for serious breach
• The company enters bankruptcy or liquidation proceedings
• The technical founder fails to perform code maintenance obligations for X consecutive months
• The technical founder licenses or authorizes the code to a third party without the company’s consent

Domestic practice: Because mature commercial Escrow service providers are lacking domestically, practice more often adopts alternative approaches—for example, a law firm or notary office designated by the company acts as the intermediate custodian, with both parties’ lawyers jointly drafting the Escrow agreement, specifying the deposited content (source code + technical documentation + deployment manual), update frequency, release conditions, and release procedure.

(4) Layer Four: Offboarding Code Handover—Plugging the Biggest “Human Vulnerability”

Employee departure is the most common and most easily overlooked scenario for loss of control over source code. It is recommended to establish the following institutional arrangements:

IV. Risk Warning: Four Major Legal Consequences of Loss of Control Over Source Code

Risk One: The company loses control over its core asset

From a legal perspective, the company “holding” the code and “controlling” the code are two completely different concepts. Without an effective co-management mechanism, the company is the legal owner of the code but, in substance, is wholly unable to use, maintain, and iterate the code independently. In financing due diligence, this is usually regarded as a major corporate governance defect and will seriously affect valuation and investment decisions.

Risk Two: The risk of intellectual property infringement surges

A departing employee may take the company’s code to a competitor or use it in his own new startup. Without a sound permission audit and offboarding recovery mechanism, the company will find it hard to prove when and how the infringement occurred, placing it in a disadvantageous position of proof in subsequent litigation.

Risk Three: Triggering a major breach leading to financing failure

A common condition precedent to closing in an investment agreement is that “the company has established a sound source code management and backup mechanism.” If the investor discovers before closing that the code is under “personal control,” it may, at best, require remediation and delay closing, or, at worst, terminate the investment directly.

Risk Four: The founder bears personal liability for compensation

If the investor has stipulated a source code delivery obligation and corresponding liability for breach (such as liquidated damages, equity reversal, and damages) in the shareholders’ agreement, and the founder fails to perform, the founder will face significant risk to his personal property. Especially against the backdrop of the new Company Law strengthening capital contribution obligations, the delivery of technology contributions is not only a contractual obligation but may also be characterized as a statutory capital contribution obligation.

V. Action Recommendations: A Practical Checklist for Source Code Co-Management

For the technical founder:

1. Register the code hosting service under the company domain from day one of company registration: this is the lowest-cost yet most effective “protective wall.” Make it a habit; do not wait until financing to migrate the code.
2. Proactively propose establishing a co-management mechanism: do not wait for the investor to raise it before responding passively. Taking the lead in establishing a standardized code management system precisely reflects the founder’s professionalism and attention to corporate governance.
3. Separate personal projects from company projects: maintain clear project boundaries—personal projects use personal accounts, company projects use company accounts, never mixed. This protects both the company and your own personal creations.
4. Actively participate in Escrow clause negotiation: Source Code Escrow is essentially an endorsement of the founder’s credit, not a sign of distrust. Set reasonable triggering conditions to avoid overly broad release conditions causing unnecessary disruption to company operations.

For investors:

1. Make code co-management a condition precedent to investment closing: raise technical governance requirements such as repository ownership, permission allocation, and backup mechanisms at the term sheet stage.
2. Insert a dedicated “source code clause” in the shareholders’ agreement: expressly stipulate the code delivery list, delivery time limit, acceptance criteria, copyright ownership, co-management mechanism, Escrow arrangement, and liability for breach.
3. Engage technical personnel in legal due diligence: traditional legal due diligence cannot adequately assess the technical risks of code control. Technical personnel are needed to examine technical details such as permission settings, audit logs, and backup strategies—the investor’s judgment on code “security” should not rest on the technical team’s verbal assurances.
4. Set a “red-flag clause” for source code control: if after investment it is found that the source code co-management mechanism is destroyed (e.g., key personnel privately delete repositories or transfer code to personal accounts), a special protection mechanism for investors should be triggered, such as an upgraded veto right, accelerated repurchase, or forced exit.
5. Conduct periodic post-investment audits of code control status: investment closing is not the endpoint. It is recommended that technical personnel conduct a routine check of the company’s code repository permission settings, audit logs, and backup integrity every six months, and incorporate the findings into the board report.
   

Conclusion

In the software industry, code is the “means of production.” Making the code truly a core asset that the company can independently control is not only the investor’s demand but also the inevitable path for the company to move toward standardized governance.

A good source code co-management mechanism should let founders create freely, let investors entrust with peace of mind, and let the company operate steadily. It is not a shackle but a safety net—catching everyone when there is wind and rain. The rigor of legal clauses is precisely the best guardian of commercial trust.

Disclaimer: This article represents only the author’s personal views and does not constitute legal opinion or investment advice in any form. For specific legal issues, please consult a professional lawyer.

Lawyer Kevin Jun Lin

Senior Corporate Lawyer · Industry Legal Practice Expert

💬 Welcome to leave your comments and reasons in the comment section

Further Reading

• IP Contribution in the Software Industry: A Founder Contributes Code at a 10 Million Valuation? Investors Go Silent After Due Diligence
• When a Founder Suddenly Dies, Who Gets the Equity? Without This Clause in the Charter, Everything Changes
• Non-Compete Clauses: What Can You Do When a Partner Starts a Rival Business?
• Profit Distribution: How to Divide Profits? No Agreement Means Disaster
• Equity Vesting: What Happens to Equity When a Founder Leaves Early?
• Redemption Rights: What Must Founders Repay When Investors Withdraw?

If you need professional support in shareholders’ agreements, investment term sheet review, or shareholder disputes, please contact Lawyer Kevin Jun Lin (Shenzhen Corporate Lawyer) for one-on-one consultation.