GPLv3 compliance through the Luohe v Wanyou case: version, combination and evidence

Open-source software can be commercially used but requires compliance with the applicable license. The value of the Luo Box vs. YuFu case lies in demonstrating how courts review a project's versioning, licensing text, and actual dissemination behavior together rather than providing a simple conclusion for all GPL projects.

What the case examined

The publicly available first-instance judgment of Case No. 2019-SZ-00207 from the Intellectual Property Court of Guangdong Province (the highest court for intellectual property cases in China) addresses issues related to licensing obligations when VirtualApp code is used in relevant applications. The court reviewed the source of rights, applicable version of GPL v3, restrictions on commercial use, and evidence regarding the provision of source codes. Based on the relationship between the software's code, it made a determination.

When reading this case, one should distinguish between what parties have claimed, expert opinions, and court findings. The number of lines in the code, lists of contributors to repositories or statements on project homepages, need to be corroborated with other evidence rather than being summarized as universal rules for rights attribution.

Charging and source obligations are separate issues

GPL v3 Section 4 allows charging for copies of the licensed program, and also permits providing support or guarantees. Therefore, GPL cannot be summarized as 'only service fees can be charged, software must be free.' At the same time, dissemination of a work under license still requires compliance with corresponding declarations, licenses, and source code provision conditions; different delivery methods have distinct requirements.

Record the version and combination facts

A change in the license of a project does not automatically negate historical versions' authorization. It is important to retain the commit number, licensing documents, supplementary terms, and distribution records when obtaining code. Analyze these versions based on this information; if other versions or additional authorizations need to be arranged by an entity with sufficient rights, it should also be evaluated separately.

Similarly, whether a module is independent cannot solely rely on the names of 'plugins', 'interfaces,' or two processes. The team must provide information about build relationships, calling methods, shared data, and final distribution structures to explain which code was integrated into the combined program.

Four types of compliance evidence to retain

• Source Evidence: Download address, version, commit records, file hashes, and rights statements.
• License Evidence: The complete terms, exceptions, or commercial authorizations at the time of acquisition, avoiding only recording the license abbreviation.
• Engineering Evidence: Scope of copying and modification, dependencies, build and delivery content.
• Performance Evidence: Copyright notices, license copies, methods for obtaining source code, and validation records.

This case cannot be used to conclude that 'using GPL means losing proprietary code rights,' nor can it directly apply module boundaries from this case to other projects. Software composition analysis (SCA) can assist in inventorying, but dispute evaluation should still focus on specific code, license versions, and evidence.