Computer software can be protected through several intellectual-property regimes. Computer programs and related documentation may receive software-copyright protection; program-related technical solutions may qualify for invention patents; and graphical user interfaces (GUIs) with distinctive visual effects may qualify for design protection. Software copyright is especially closely connected with the developer's actual product and has therefore become one of the most common means by which enterprises protect software. This article analyses the adjudicative path and rules of proof in software-copyright infringement cases.
I. Overview of computer-software copyright The principal legislation includes the Copyright Law and the Regulations on Computer Software Protection. Software copyright protects expression contained in computer programs and documentation; it does not extend to ideas, processing procedures, operating methods or mathematical concepts used to develop software. A computer program is a coded sequence of instructions capable of execution by a computer or other information-processing device to obtain a result, or a symbolic instruction or statement sequence capable of automatic conversion into coded instructions. The source program and object program of the same program are treated as the same work. Object code is the machine-readable result of compilation, while source code is the human-readable program written in a programming language. Computer documentation includes written materials and diagrams describing program content, composition, design, functional specifications, development, test results and methods of use, such as design specifications, flowcharts and user manuals. In litigation, however, the program itself is the central object of copyright protection and infringement comparison. Similarity of documentation alone will ordinarily be insufficient if the claimant provides no source program, object program, running interface or other material capable of technical comparison.
II. Adjudicative standards for software-copyright infringement Because software is a protected category of work, courts generally apply the copyright framework of “access + substantial similarity.” (1) Access. Access means actual study or copying of the protected software, or an opportunity to do so. Public release ordinarily exposes object code, not the right holder's source code, and code obtained through disassembly or decompilation is not the same as the original source code. Public release therefore does not automatically prove access to source code. Access may be shown directly or inferred from circumstances such as striking similarities excluding coincidence, identical errors unnecessary to functionality, a defendant's former role as a core technical employee, cooperation between the parties, software-acquisition channels and development timing. In the Shenyang/Dalian dispute discussed in the article, access was established where the individual developer had been a core employee and development manager, admitted exposure to the source program and had represented the claimant in negotiations concerning upgrades to the relevant seal-system software. (2) Substantial similarity. Substantial similarity concerns the protected program and related documentation. Courts use textual comparison of identical or similar code and non-textual comparison of organisational structure, processing flow, data structures, interfaces and other overall features. Source code is human-readable code before compilation; object code is the executable machine-readable result. The primary method is source-code comparison. Public-domain material should first be excluded, followed by analysis of file names, file contents, functions, variables and other elements. The claimant commonly submits its source program and seeks expert examination; the court may order the defendant to produce source code and may appoint forensic experts or technical investigation officers. In one case involving approximately 500 pages of source code, the parties selected the first and last five pages and twenty randomly sampled core-module pages. Thirty pages containing 2,152 Java lines were compared, of which 1,735 were identical, producing similarity of about 80.6%; the court ordered cessation and awarded RMB 120,000. When source code cannot be obtained, substitute technical paths are available. If a defendant refuses to provide source code, object programs may be compared. The Beijing High People's Court guidelines provide that source programs should ordinarily be compared, but if the defendant refuses production, object programs may be used and identical or similar object programs may support a finding of substantial similarity. Because different source programs can sometimes compile into the same or similar object code, object-code similarity alone does not normally prove infringement. But unjustified refusal to produce controlled source code can trigger obstruction-of-proof principles and, together with identical or substantially similar object code, support an adverse inference. Courts have used technical object-code analysis in practice. Decompilation can also be combined with static and dynamic comparison. Static analysis may cover software names, directory structures, file names, rights-management information and data structures. Dynamic analysis may compare installation and operation, interfaces, operating steps, configuration, operating modes and results. In Synopsys v. Wuhan Xindong, the Supreme People's Court recognised that infringement may be established through identical or substantially similar program code or through substantial similarity in organisational structure, data structure and input/output format. In another Nanjing case, decompiled object-code analysis showed substantial similarity in program logic and structure, function and variable naming, extensive identical code, distinctive protected content, common file names and similar interface layout and functionality; the defendants offered no reasonable explanation, and substantial similarity was found. A third route is inference from distinctive infringement indicators. Distinctive content, design defects, redundant design, identical GUIDs, file information containing the right holder's name or marks, highly similar operation and results, identical rights-management information and characteristic defects can satisfy an initial burden and shift the burden to the defendant. The Supreme People's Court has stressed that source-code comparison is not the sole criterion and that courts should consider the parties' ability to produce evidence. Guiding Case No. 279 states that identical distinctive information such as software name, version number and right-holder information, or highly similar interface design, can allow a finding of substantial similarity without code comparison unless rebutted. Obstruction of evidence preservation, including cutting power or refusing to turn on a computer, may justify adverse factual inferences and may be considered in damages. The 2025 annual IP case report similarly recognises an inference of identity or substantial similarity where operational information is highly consistent and the defendant cannot reasonably explain it. The article also discusses cases in which clusters of improbable similarities carried strong evidentiary weight. In one dispute, the defendant claimed its source program had been lost because of hard-drive damage. Experts decompiled the object programs and found roughly 300 identical string resources, eighteen identical class names or global variable names, and two identical erroneous textual expressions. The chance of this combination in independently developed programs was considered extremely low, and the court found substantial similarity. In the Beijing Zhiheng NetSecurity dispute, similarities in core structure and configuration, proprietary naming, development tools, error information, redundant design and performance-test results—especially use of the protected software's former and erroneous names—were sufficient to shift the burden to the defendant. Guiding Case No. 49 likewise reasoned that independently designed programs are very unlikely to share the same system defects; common defects, together with other facts, can satisfy the high-probability standard. (3) Coordinated assessment of access and similarity. Access and substantial similarity are distinct elements, but evidence of one affects evaluation of the other. Strong access evidence increases the probative force of unusual common errors, distinctive naming and redundant design. In the Jiafeng Yongdao/Zhangyou Tianxia dispute, the court stated that reliable proof of actual access to source code can reduce the evidentiary demand for substantial similarity and affect the allocation of the burden. In the Beijing LongRuan-related dispute, unreasonable similarities in functional interfaces, data processing, database information and characteristic vulnerabilities were combined with refusal to produce source code and development timing close to employees' departure from the claimant; the evidence together supported substantial identity. Access cannot replace proof of similarity, but it can form part of a mutually corroborating chain. Where access evidence is lacking, general similarity in function, interface or operating result usually cannot exclude independent development. The claimant then needs stronger source-code, object-program or other technical proof showing highly consistent internal expression. Lack of access evidence does not automatically defeat the claim, but it raises the burden to exclude reasonable explanations based on independent development, public code or limited expression.
III. Principal defences Defendants commonly invoke limited expression, fair use, lawful source, good-faith possession and open-source agreements. (1) Limited expression. Where a software function can be implemented in only one or very few ways, expression effectively merges with the idea or function and lacks protectable originality. Material commonly excluded from comparison includes expression dictated by fixed programming-language syntax; repeated function names, definitions and variable assignments attributable to the same programmer's habits; non-original third-party open-source code or pre-existing source code and their combinations; and simple non-original combinations of those elements. (2) Fair use. Article 17 of the Regulations permits installation, display, transmission or storage of software for learning and studying the ideas and principles embodied in its design without permission or payment. Reverse engineering—analysing executables, operation or communications without source code to understand functionality, structure and operating principles—may be fair use when undertaken within a necessary scope for interoperability, error diagnosis or investigation of possible infringement. Copyright Law Article 50 also permits circumvention of technological measures in specified situations, including limited teaching and research, accessible use, official procedures, security testing, encryption research and software reverse-engineering research, while prohibiting broader circumvention assistance or infringement of other rights. (3) Lawful source. Copyright Law Article 59 allocates proof duties to publishers, producers, distributors and lessors of infringing copies. Those unable to prove lawful authorisation or lawful source bear the prescribed legal responsibility, balancing right-holder protection with circulation of software copies. (4) Good-faith possessor. Article 30 of the Regulations exempts from damages a possessor who did not know and had no reasonable grounds to know that a software copy was infringing, but the possessor must stop use and destroy the copy. If this would cause major loss, continued use is possible after payment of a reasonable fee. (5) Open-source agreement. A defendant relying on an open-source licence must prove that the disputed code is governed by that licence, that the accused copying, modification or distribution falls within the licence grant and that the licence conditions were satisfied. The case reported as (2024) Su Min Zhong No. 581 in the 2025 annual IP report makes clear that a defendant generally cannot defeat infringement merely because the claimant itself failed to release source code required by an open-source agreement; the claimant's noncompliance may instead be considered in damages. The right holder's own compliance and the defendant's authorisation are separate issues.
IV. Proof in different infringement scenarios Different forms of software infringement require different objects and structures of proof. (1) Direct reproduction and dissemination. Where a person directly reproduces, distributes or communicates the protected software to the public without permission, proof centres on identity of the software, the act of dissemination and absence of authorisation rather than difficult similarity analysis. Useful evidence includes installation packages, download links, version numbers, digital signatures, hash values, distribution pages and transaction records, with notarisation, trusted timestamps or other electronic preservation where necessary. Merely providing a download link does not automatically establish direct communication of the software file; possible contributory infringement requires separate analysis of the link source, control over files and transmission, fault and response to notice. (2) Commercial end-user use. Unlicensed or over-scope installation, copying or use in business may infringe the reproduction right. Proof focuses on actual installation and use, licence scope and quantity, and whether the user knew or should have known of unlawful source. Procurement contracts, licence materials, equipment lists, software-asset management records and supplier delivery materials may be relevant where installation by a supplier or third party is asserted. A good-faith user may avoid damages but may still have to stop use, destroy the infringing copy or pay a reasonable fee for continued use. (3) Copying, modification and adaptation. Where the defendant modifies or adapts protected software and markets it as its own, the case generally follows “access + substantial similarity.” Source-code comparison should be prioritised where possible after excluding public code, fixed syntax, third-party material and limited expression. If source code is unavailable, object code, decompilation, directory and data structures, input/output formats, interfaces, operating parameters, common errors, distinctive naming and redundant design may be assessed together. Unjustified refusal to provide controlled source code may trigger obstruction-of-proof rules and require an explanation or rebuttal. (4) Circumvention or destruction of technological measures. The claimant must first establish that the relevant mechanism is a technological measure protected by copyright law and then prove unauthorised circumvention or destruction. Evidence should fix the normal authorisation mechanism, the function of the measure, the cracking tool or circumvention steps, and how circumvention produced access, operation or copying capability. Statutory exceptions for security testing, encryption research and software reverse engineering must also be considered. The classification of conduct is therefore important not merely for legal characterisation but for choosing the correct evidentiary route. Direct dissemination focuses on identity, transmission and authorisation; commercial use on actual installation, licence scope and knowledge; copying or modification on source-code or substitute technical comparison and burden allocation; and circumvention on the legal nature of the measure, the circumvention act and statutory exceptions. V. Conclusion Adjudicating computer-software copyright infringement requires assessment of code, structure, operating characteristics and the parties' evidentiary conduct to determine whether protected expression was copied. Source-program comparison is important, but where source code cannot be obtained, object programs, decompilation results, interfaces, data structures, distinctive information and adverse inferences from obstruction of proof may also establish infringement. The proof route should correspond to the particular challenged conduct, while access, similarity indicators and the parties' explanations should be evaluated together. The purpose of this article is to organise these adjudicative rules and representative cases as a practical reference for enterprises and legal practitioners handling software-copyright disputes.