[author: Min Yao]
GPL (General Public License) is one of the widely used licenses for open-source software. GPL requires derivative code based on GPL open-source code to also be distributed under GPL, ensuring open-source availability. This characteristic of GPL is referred to as "infectiousness" and has a significant impact on the distribution of software created using GPL open-source code, gaining attention from software developers. This article aims to explore and summarize the judicial rules for determining "infectiousness" of GPL, based on case studies, hoping to provide some ideas for software developers on compliant use of GPL open-source software and adoption of reasonable means to block proprietary code from being infected.
- The rules for determination of "infectiousness" of GPL in earlier cases were relatively simple.
In the case of (2015) Jing IP Civil First No.631, the plaintiff Digital Heaven (Beijing) Network Technology Co., Ltd, the copyright owner of the HBuilder development tool software, claimed that the defendant's APICloud software copied the source code of three plugins from their proprietary software. The plaintiff claimed that the defendant's acts infringed upon their software copyright. The defendant made defense by arguing that the plaintiff's software used GPL (V3) open-source code, and therefore, their software as a whole was bound by the GPL, thus their use of the plaintiff's open-source code did not constitute infringement. After hearing the case, the Beijing Intellectual Property Court determined that the three plugins of the plaintiff's software were deployed in separate folders, could operate independently, and constituted separate works not bound by the GPL. Based on this, the court found that the defendant's defense was not valid, and their acts constituted infringement. The Beijing Higher People's Court affirmed the judgment of the first-instance court in the second instance judgment (2018) Jing Civil Final No.471.
In the case of (2016) Jing 73 Civil First No.1111, the plaintiff Buwanmai e-commerce (Beijing) Co., Ltd. owned copyright to "Buwanmai Fashion Overseas Shopping Software" which consists of both front-end and back-end code. The plaintiff made it clear that the code it claimed right in this case was the back-end code. The defendant argued that the plaintiff's software used open-source code under the GPL, and therefore the plaintiff had no right to claim copyright over the entire software. After hearing the case, the Beijing Intellectual Property Court found that the front-end code of the plaintiff's software did indeed use GPL open-source code, but the back-end code did not. The court held that the front-end code development mainly refers to the implementation of visible user interface operations, such as page layouts, interactive effects, and other page designs. On the other hand, the back-end code development mainly refers to the implementation of server-side related logic functions and other modules that are not visible to the back-end users. The two are different in display methods, technologies, and division of work for which they are considered as independent programs. The back-end code, which the plaintiff claimed copyright over, did not use open-source code and was not a derivative or revision of the front-end program according to the relevant provisions of the GPL. Therefore, the court ruled that the defendant's defense was not established, and their acts constituted infringement. The Supreme Court affirmed the judgment of the first-instance court in the second instance judgment (2019) SPC IP Civil Final No.663 and pointed out that there were significant differences between the front-end and back-end codes in terms of the way they are displayed, the technology used, and the function and division of work, etc., and that the two cannot be determined one work only because there is interaction between the front-end code and the back-end code.
In the above two cases, the court considered mainly the way of deployment, displaying, function and use, etc. between the software modules in order to determine whether the proprietary code constituted independent work or derivative work to the open source code, without much consideration and ascertainment on the interaction mechanism and communication content between the modules.
- The rules for determination of "infectiousness" of GPL in later case become stricter.
In the case (2021) Su 01 Civil First No.3229, the plaintiff, Nanjing Weilai Hi-tech Co., Ltd., claimed copyright over their proprietary code which is a part of the code of the "Future Online Bidding Document Production Tool Software". The plaintiff alleged that the defendant, Jiangsu Cloud Dragonfly Information Technology Co., Ltd., infringed their copyright by using their proprietary code in the accused infringing software, "Cloud Dragonfly Software-Bidding Document Production Tool". The defendant argued that the plaintiff's software used GPL open-source code, and therefore, their software as a whole is bound by the GPLv2. Since the plaintiff did not open-source their code, it is a violation of good faith, and their claims of infringement should not be supported.
Through trial, Nanjing Intermediate People's Court ascertained the plaintiff's software as follows:
(1) The plaintiff's software consists of two parts: the main program (FutureTBTool.exe) and the preview program (ViewnNTF.exe). The main program is used for creating bidding documents, while the preview program is used for viewing bidding documents.
(2) The plaintiff compiled their proprietary code, FutureZR.cs (which includes the CompressZip() function), together with the open-source software SharpZipLib (licensed under GPL v2.0 or later versions with Classpath Exception) into the FZR.dll file. The main program calls the CompressZip() function, which in turn calls the open-source code to achieve the file compression function. The compression function is essential for uploading bidding documents.
(3) The preview program is independent of the main program and does not call the open-source software SharpZipLib.
The relationship between the plaintiff's software and the open source software is summarized as follows:
In this case, the court provided detailed exposition and reasoning of the determination on the "infectiousness" of the GPL. The court firstly summarized its view on the "infectiousness" of the GPL as a whole. It stated that if a derivative work that is logically related to open source code and is distributed as a whole, as long as any part of it is distributed under the GPL, the entire derivative work must be bound by the GPL and open-sourced. However, if it can be ascertained that a certain portion of the work is not a derivative of the program but is independent, then that independent portion can be distributed without being bound by the GPL. The determination of which derivative software or revised versions is be infected by the GPL, distinguishing between open source code and proprietary code, relies on establishing how proprietary code is combined or interacts with open source code. Additionally, the usage scenario of the code is used, including the functionality of the code and its role in the software should be considered when to make decision. Ultimately, the infected part determined should be a program which has intimate communication with the original open-source software, making the two highly connected and integrated into one entire program, rather than that the proprietary code is being infected as long as there is data exchange.
In order to ascertain the interaction between the plaintiff's proprietary code and the GPL open-source code, the plaintiff provided processing flowchart of the software involved in the case and function call relationship diagram by using programming tools under the request of the court. The court discussed respectively whether the main program and the preview tool of the software in question were infected by the GPL.
- Regarding the main program
The plaintiff argued that the main program of their software in question can run independently without FZR.dll (which contains the open-source code), and there is only a simple one-way function call between them, returning only a value of true/false. Therefore, the main program and FZR.dll are two separate programs. The open-source code involved in the case is distributed under the GPL with a Classpath Exception. FutureZR is linked to the main program as an independent module of the software in question, thus Classpath Exception shall be applied, for which the main program is blocked from being infected by the GPL open-source code. Therefore, the software in question is not bound by the GPL.
The court acknowledged that the main file, RibbonMainForm.cs, in the main program of the software in question, only calls the CompressZip() function in FutureZR.cs once. The data structure passing between the main program and the CompressZip() function is also relatively simple. However, the court held that since there is a function call relationship between the main program and the GPL open-source code, the compressing functionality implemented by the GPL open-source code is an indispensable feature for uploading biding documents. Therefore, the main program constituted a derivative work of the GPL open-source code and is bound by the GPL.
Regarding the plaintiff's claim that the main program’s calling to open-source code complies with the Classpath Exception, the court held that the plaintiff's method of compiling the proprietary FutureZR.cs file together with the SharpZipLib open-source code into the FZR.dll file, which is then called by the main program, does not comply with the provision of “independent module” in the Classpath Exception that provides "an independent module is a module which is not derived from or based on this library" (i.e., the FZR.dll file compiled by the plaintiff is a derivative work of the open-source code, rather than an independent module). Therefore, the court held Classpath Exception does not apply to it, and the plaintiff's aforementioned claim is not admitted.
- Regarding the preview program
The court found that the preview program has an independent functionality to view bidding documents, which is not necessary for users to create and upload bidding documents. The preview program file can run independently in a new directory when separated from the main program. Additionally, the main program can run independently even after the removal of the preview program file from its directory. Based on the above, the court determined that the preview program is not a derivative work of the GPL open-source code involved in this case and is not infected by the GPL open-source code. Therefore, the preview program is not bound by the GPL.
In the above case, the court's judgment on whether the proprietary code is "infected" by the GPL open-source code can be summarized in two aspects: first, determining whether there is interaction between the proprietary code and the open-source code and the content of their interaction so as to confirm if there is intimate communication between them; second, determining the role played by the open-source code in the overall software. Based on the court's reasoning, it is acknowledged that the interaction and communication between the main program (proprietary code) and the open-source code are relatively simple. From this respect, it seems that the court recognized that although there is interaction between the proprietary code and the open-source code, there is no intimate communication. However, the court further explained given interaction between the main program (proprietary code) and the open-source code, to determine whether the two constitute two separate programs or two parts of a single program, it is also necessary to consider the functionality and role played by the open-source code in the entire software. Since the file compression functionality implemented by the open-source code is an indispensable feature of the software in question, the court determined that the main program constitutes a derivative work of the open-source code and is bound by the GPL. On the other hand, the preview program (proprietary code) does not call the open-source code, and it operates independently from the main program. The court determined that the preview program does not constitute a derivative work of the open-source code and is not bound by the GPL.
The determination rules used by the court in the above case are generally consistent with the viewpoint held by the Free Software Foundation (FSF). Where's the line between two separate programs, and one program with two parts? FSF provides an answer in its Frequently Asked Questions (FAQ) section: This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
Currently, no second-instance judgment for the above case has been found and it is unknown whether the defendant has filed an appeal. Based on the content of the first-instance judgment in this case, the court's determination rules set higher requirements on software developers for compliant use of open-source software.
One particular aspect of this case is that the plaintiff had previously filed a software copyright infringement lawsuit against the same defendant for the same allegedly infringing software in the same first-instance court, Nanjing Intermediate People's Court (Case No.: (2018) Su 01 Civil First No.2523; Second-instance Case No.: (2021) Supreme Court IP Civil Final No.406). However, in the previous case, the defendant did not make defense based on the plaintiff's use of GPL open-source code, and the first-instance court Nanjing Intermediate Court and the second-instance Supreme Court did not proactively ascertain whether the plaintiff's software used GPL open-source code. On the other hand, in this case, the defendant made defense that the plaintiff's software used GPL open-source code, and the court supported part of the defendant's defense arguments. In cases involving software using GPL open-source code, both the software copyright owner and the alleged infringer should assess the potential impact of the GPL open-source code on the case and conduct a comprehensive evaluation before initiating a software copyright infringement lawsuit or defending against one.
- Summary
At present, the number of civil lawsuits involving determination of "infectiousness" of GPL is no more than 10, and the rules of determination are still in the process of being established and perfected. The case (2021) Su 01 Civil First No.3229 is the latest judgment involving the issue of "infectiousness" of GPL, and the court's judgment sets higher requirements on software developers for compliant use of open-source software. Deploying software modules in different folders or separately registering copyright for each module may be difficult to effectively block "infectiousness" of the GPL. If software developers do not want their proprietary code to be bound the GPL, they need to thoroughly research at the beginning of software development whether it is possible to avoid such "infectiousness" through reasonable technical means. Reasonable technical means should go beyond independently packaging and deploying software modules, but also fully consider the ways and content of interaction between proprietary code and open-source code.
