Chinese copyright law protects original computer programs and related documentation. Source code and object code of the same program are treated as the same work, while the underlying ideas, algorithms, operational methods, mathematical concepts and general functionality are not protected merely as copyright.
Software disputes are usually won or lost on ownership and evidence rather than on a registration certificate alone. Developers, employers, customers and investors should document who created each component, what pre-existing and open-source materials were used, which rights were assigned or licensed, and how source-code versions can be compared.
1. Protected software materials
The Computer Software Protection Regulation defines software as computer programs and related documentation. A program is a coded instruction sequence, or a symbolic sequence or statements capable of being converted into such instructions, that can be executed by a device with information-processing capacity. Documentation can include program descriptions, design materials, functional specifications, development records, test results, flowcharts and user manuals.
Protection attaches to original expression. It can cover source code, object code, original structure or selection expressed in code, and qualifying documentation. The source and object versions of the same program are one work for this purpose.
2. Ideas and functionality are not enough
Copyright does not extend merely to ideas, processing methods, operating procedures, algorithms or mathematical concepts used in developing software. Similar business purpose, interface function or technical result does not by itself establish copying.
Preserve evidence of protectable expression and access. A comparison should separate common elements, technical constraints, public-domain material and third-party components from original similarities that support an inference of copying.
3. Developer and ownership
The person who actually organizes and carries out development and bears responsibility for the completed software is generally the developer. A legal person or organization may be the developer where the software is developed under its organization, reflects its will and it assumes responsibility.
Copyright ownership should be tested against the Copyright Law, Software Protection Regulation and the parties' contracts. Payment, product management or providing requirements does not automatically transfer all copyright.
4. Employee-developed software
Software developed by an employee in performing work duties may belong to the employer where it is developed for objectives expressly assigned in the employee's duties, is a foreseeable or natural result of those duties, or is developed mainly using the employer's funds, specialized equipment, undisclosed information or other material and technical conditions while the employer bears responsibility.
Employment and invention-assignment documents should define duties, repositories, third-party work, side projects, confidentiality, disclosure, handover and post-employment cooperation. Apply the facts; a broad clause cannot safely replace evidence of the actual development relationship.
5. Commissioned and cooperative development
For commissioned software, ownership should be set by a written agreement. If there is no written agreement or the agreement is unclear, the Regulation generally places copyright with the commissioned developer. A customer seeking ownership must obtain an express transfer of the relevant economic rights rather than rely on payment or delivery.
For cooperative development, the written agreement should allocate ownership and exercise of rights. Where the software can be divided into independently usable parts, contributors may hold rights in their parts without prejudicing the whole. Define enforcement, licensing, maintenance, exit and use of jointly developed components.
6. Registration and its evidentiary role
Software copyright registration is encouraged and may provide preliminary evidence of the registered matters. It is not the source of copyright and does not cure a defective chain of title or undisclosed third-party code.
An application generally includes the prescribed form, identification materials for the software and supporting ownership documents. Deposit requirements may involve source code and documentation, with permitted exceptional-deposit methods in specified cases. Keep the filed version, certificate, source repository and release records aligned.
7. Licensing, transfer and delivery
Identify the software, version and modules being licensed or transferred. State the specific rights, exclusivity, territory, users or systems, term, fees, reproduction, modification, adaptation, interface, backup, hosting, sublicensing and distribution permissions. Rights not clearly granted should not be assumed.
Separate copyright ownership from source-code delivery, deployment access, maintenance services, warranties and data rights. A perpetual object-code licence does not necessarily include source code or a right to create derivative versions. Exclusive-licence and transfer contracts can be registered under the Software Copyright Registration Measures.
8. Pre-existing and third-party components
A development contract should schedule background software, commercial libraries, open-source packages, fonts, datasets, models, APIs and developer tools. For each component, record the owner, version, licence, notices, source availability, modification status and distribution model.
Do not promise exclusive ownership of third-party materials. Define which components remain with the supplier, which are licensed to the customer, and whether replacements are required if a component cannot lawfully support the intended deployment.
9. Open-source compliance
Open-source software is copyrighted software supplied under licence conditions. Obligations vary and may include attribution, copyright notices, licence text, source-code offers, disclosure of modifications or licensing of derivative works under specified terms.
Build a software bill of materials, approval process and release gate. Review static and dynamic linking, modified files, container images, client-side bundles, firmware, SaaS deployment and onward distribution. A scanner result is a starting point, not a legal conclusion about licence compatibility.
10. Adaptation, interoperability and reverse engineering
Modification, adaptation and secondary development can implicate the owner's rights. The Copyright Law and Software Protection Regulation contain limited rules and exceptions, including certain study, research, compatibility and security contexts, but they should not be treated as a general permission to copy expression or bypass technical measures.
Define permitted interfaces, testing, benchmarking, decompilation, error correction and interoperability work contractually where possible. Preserve clean-room procedures and independent-development evidence when compatibility work creates meaningful infringement risk.
11. Evidence in a software dispute
Preserve repositories, commit history, access logs, issue trackers, build records, object files, release packages, developer accounts, design documents and employment or contractor agreements. Record hashes and timestamps for important versions and restrict administrator rights.
For suspected infringement, preserve the accused product and acquisition process, document access opportunities, and use a technically sound comparison. Courts may need expert or forensic assistance to filter unprotectable or third-party material and compare original expression.
12. Remedies and operational controls
Unauthorized reproduction, distribution, rental, network dissemination, alteration, translation or other restricted use may lead to civil remedies and, where public interests or criminal thresholds are implicated, administrative or criminal action. Remedies can include stopping infringement, corrective measures, damages and destruction or confiscation in applicable cases.
Registration, repository governance, access controls, source-code escrow, contractor onboarding and release compliance should work as one control system. Due diligence for an acquisition or investment should reconcile the product architecture with the ownership and licence schedule.
Software rights checklist
- Identify each program, module, version and document.
- Map employees, contractors and cooperative developers.
- Sign ownership and licence terms before development begins.
- Schedule background and third-party components.
- Maintain a software bill of materials and open-source approvals.
- Align registration deposits with the released version.
- Separate copyright, source delivery, support and data rights.
- Preserve repositories, builds, access and comparison evidence.
Primary sources and review date
- PRC Copyright Law, 2020 revision
- Computer Software Protection Regulation
- Computer Software Copyright Registration Measures
Reviewed 8 September 2026. General information only; ownership, open-source obligations and infringement analysis depend on the code, contracts, deployment and evidence.
Related guides: Copyright protection · GPL and secondary development · Intellectual property overview.
