Open-source software has become deeply embedded in the development of commercial software, mobile applications, cloud services and intelligent terminals. Making code public expands the scope of collaboration, but it also makes the relationship among copyright, licence conditions and commercial use more complex. In disputes arising from the GNU General Public License (GPL), courts usually confront three concrete questions: where code has been contributed continuously by many people, who is entitled to assert the project's rights; when a user breaches licence conditions, how the resulting licence status connects with copyright infringement; and when the right holder itself has failed to perform open-source obligations, whether the defendant may rely on that failure to exclude infringement liability. Recent representative cases have developed a comparatively clear judicial approach to these issues.
I. GPL licence: openness rests on copyright GPL stands for the GNU General Public License. It is a free and open-source licence formulated and continually revised by the Free Software Foundation for the GNU Project. GPL permits users to run, copy, modify and distribute licensed programs. When a user distributes the original program, a modified program or corresponding object code to another person, the user must also comply with the applicable version's requirements, such as retaining copyright and licence notices, providing corresponding source code and continuing to apply GPL where required. Open source therefore does not place software in the public domain. Copyright remains the legal foundation that enables the licence to define the boundaries of permitted use and to constrain subsequent distribution. In practice, the continuing-open-source requirement of GPL is often described as its “viral” effect. That description helps explain the difference between GPL and permissive licences such as MIT or Apache, but it cannot resolve a particular case by itself. Whether GPL obligations have been triggered still requires examination of the applicable licence version, whether the challenged conduct constitutes distribution, whether the disputed code is a work subject to GPL, and the relationship between that code and the other parts of the software. The mere presence of a GPL component does not automatically mean that the entire project must disclose all of its source code; such a conclusion may exceed both the licence text and the facts. Accordingly, adjudication of a GPL dispute ordinarily follows a concrete sequence: identify the source of the code and the right holder; determine whether the challenged software actually uses the relevant code; examine whether the challenged conduct was licensed and whether the licence conditions were performed; and only then decide copyright infringement and liability. The three issues discussed below are manifestations of that rights structure in litigation.
II. Standing in multi-contributor collaboration: may the project manager assert rights independently? Open-source projects are often completed jointly by an initiator, project managers and numerous outside contributors. Contributors may submit code continuously, while project managers review and merge contributions and release versions from the main branch. This form of collaboration creates a practical problem for traditional proof of title: when code in the main branch is infringed, must the project manager obtain authorisation from every contributor before filing suit? In the computer-software copyright dispute involving Fujian Fengling Chuangjing Technology Co., Ltd. and Jining Luohe Network Technology Co., Ltd., Luohe created and managed the VirtualApp project and published its initial source code on GitHub. User modifications first existed on personal branches; they entered the main branch and became part of a new version only after the project manager reviewed and merged them. The court therefore distinguished the legal status of personal branches from the main branch. Unmerged contributions did not affect the ownership status of the main-branch code. After contributions were merged into the main branch, the contributors' licences under GPLv3 also allowed the project manager to continue managing and using the code. In light of the large and continually changing contributor base, the court recognised Luohe's ability to assert rights independently in the main-branch source code without obtaining authorisation from every contributor. The significance of the case is not that every open-source project manager automatically has standing. Rather, where governance is clear, the main branch is continuously controlled by a particular entity, and contributed code is merged under established rules, the formation and management of the repository may be important evidence of title. Project-initiation records, Git commit and merge histories, version tags, licence files and contributor agreements may together form an evidentiary chain proving rights in an open-source project. Open collaboration does not eliminate the right holder; it expands proof of title from a single registration document to the full process by which code is formed and the project is governed.
III. Liability after breach of licence conditions: from termination of authorisation to infringement GPL authorises users to copy, modify and distribute code while defining the scope of authorisation through conditions. When a user distributes GPL-governed software without fulfilling an obligation such as providing source code, whether the licence can continue to legalise that conduct becomes a preliminary question in the infringement analysis. In the VirtualApp case described above, the accused software Dianxin Desktop used VirtualApp source code but did not provide corresponding source code to the public as required by GPLv3. Relying on the termination provision in section 8 of GPLv3, the court held that the relevant licence rights had terminated. At the same time, expert evidence showed numerous identical or highly similar features between the accused software and VirtualApp in directory structure, code files and the naming of key directories, sufficient to exclude independent development. After determining that the licence foundation had been lost, the court relied on the code-comparison evidence to find copyright infringement. This process shows that breach of GPL conditions and copyright infringement are connected, but the intermediate steps cannot be omitted. The court must still determine whether the accused software actually used the protected code, whether the challenged act was a reproduction, modification or distribution requiring the copyright owner's permission, and whether the particular condition breached was capable of affecting the licence status. Section 8 of GPLv3 also provides mechanisms for restoration after the violation ceases, so licence status may change depending on remediation, timing of notice and whether the violation is a first violation. The licence version, manner of distribution, provision of source code and records of remediation therefore all belong in the evidentiary review. Nor does the fact that the code at issue constitutes only a small proportion of the accused program automatically exclude infringement. Proportion may affect the consequences of harm and the amount of damages, but liability turns on whether the copied portion is original, whether it is protected expression, and the substantive relationship between the protected portion and the accused software. Licence provisions define the boundary of authorisation; code comparison answers whether protected expression was actually used. Both are required for the infringement determination.
IV. Defence based on the right holder's own failure to comply with open-source obligations: separate review of the rights foundation and the defendant's liability A more controversial situation arises when the right holder's own software uses GPL code but the right holder has not released the corresponding source code as GPL requires, and the defendant argues after being sued that the right holder's software should therefore receive no protection. Existing cases have reached different outcomes, but those outcomes are not simply contradictory; the objects of review and the judicial focus differ. (1) Nanjing case: reviewing the scope of protection from the right holder's own licence foundation. In the Nanjing dispute involving a technology company and a Jiangsu information-technology company, the software consisted of a main program and a preview program. The court found that the main program was a derivative work based on GPL code. Because the right holder had not fulfilled the continuing-open-source obligation, the GPL authorisation on which it relied had terminated, and the court did not support its copyright claim to the main program. The preview program, which was separable and not affected by GPL, continued to receive copyright protection. The court was therefore reviewing the plaintiff's legal foundation for asserting rights in particular program components. The relationship between the main program and GPL code, whether the right holder owed and breached open-source duties, and whether the main and preview programs could be separated together determined the scope of protection. The result applies only to the specific portions affected by GPL status; it cannot be generalised into a rule that any open-source noncompliance by a right holder destroys all rights in all of its software. (2) Supreme People's Court cases: another person's open-source noncompliance does not automatically become the defendant's licence. In the copyright dispute between a Zhejiang communications technology company and an online technology company in Suzhou, the accused infringer argued non-infringement because the right holder had not complied with GPLv2. The Supreme People's Court held that whether a software developer breached GPLv2 and whether that developer owns copyright in its original contributions are separate questions requiring separate evaluation. A right holder may incur liability to relevant open-source right holders for violating an open-source agreement, but an accused infringer does not thereby acquire permission to copy, modify or distribute the software. The 2025 Annual Report on the Application of Law in Intellectual Property Cases of Courts Nationwide likewise states, in its item concerning an open-source-agreement defence, that a defendant's assertion that infringement is absent merely because the right holder did not release source code as required by an open-source agreement will generally not be supported; the right holder's noncompliance may, however, be considered when determining damages. Thus, a defendant invoking GPL should do more than submit an open-source project page or show that the claimant's software contains open-source code. At a minimum, the defendant should identify the applicable licence version, the concrete obligations borne by the right holder, the relationship between those obligations and the particular part for which protection is claimed, and the effect of the noncompliance on the rights foundation, liability or damages. The right holder's violation may be an important fact in the case, but it does not automatically operate as a licence authorising the defendant to use the software.
V. Conclusion The openness, licensing and rights protection of open-source software form an integrated legal structure. Existing decisions analyse that structure from the perspectives of project governance, performance of licence conditions and infringement defences. Standing returns to the process by which code is created, merged and controlled; licence review returns to the particular licence version, act of distribution and performance status; and an open-source defence requires the court to distinguish a defect in the right holder's own licence compliance from the separate question whether the defendant itself obtained authorisation. For open-source cases, labels such as “viral effect” are only a starting point. What ultimately matters in adjudication is where the particular code came from, how it entered the main branch, how it was distributed, which licence conditions the relevant parties performed, and what protected expression the accused software actually copied. Only by matching those technical facts accurately to the licence provisions can courts draw a clear boundary between open sharing and copyright protection.