Open‑source Is Not a Law‑free Zone: Licenses Are Contracts You May Skip‑read, yet Courts Will Enforce Them
2026-10-29   |   发布于:赛立信

On April 20, 2026, under the promotion of the Guangdong Higher People’s Court, 24 leading enterprises in the AI industrial chain, industry associations and open‑source foundations jointly released China’s first Consensus on Strengthening Collaborative Innovation and Promoting the Prosperity of the AI Open‑source Ecosystem. One sentence carries great weight: all participants recognize the legal validity of open‑source licenses and commit to using, modifying and commercializing open‑source works within licensing frameworks. The consensus also calls for resisting the unhealthy mindset of “whoever invests loses out” and safeguarding the huge investment of foundational large‑model open‑source parties in computing power, data and R&D.

More signals have emerged. In January 2026, the Supreme People’s Court included “Research on Legal Issues of Intellectual Property Rights for Open‑source Technologies” in its annual major judicial research project. Article 13 of the Opinions on Hearing Cases Involving Artificial Intelligence Disputes in Accordance with Law, issued in September 2026, sets special provisions on liabilities of parties related to AI open‑source software. Industry consensus represents self‑regulation; research projects prepare regulatory foundations; judicial opinions deliver enforceable rulings. These three lines point to one conclusion: the “rule‑awakening” of the open‑source ecosystem has moved from advocacy into practical implementation.

One Landmark Judgment Makes It Clear: GPL Is a Contract, Breach Constitutes Infringement

Many developers still hold the misconception that “open‑source equals free‑for‑all use”. Judicial practice has long moved beyond this view.

The Luohe v Wanyou case heard by the Guangzhou Intellectual Property Court is China’s landmark judgment confirming the contractual nature of open‑source agreements. The involved software adopted the GPLv3 license. The defendant reused the code but failed to release corresponding source code in compliance with the license terms. The court held that GPLv3 “is contractual in nature” and constitutes a “copyright contract subject to condition subsequent”. If open‑source obligations are fulfilled, the license remains valid; upon breach, the license terminates automatically. Continued use after license termination amounts to unauthorized use and constitutes copyright infringement. The defendant was finally ordered to cease infringement and pay damages of RMB 500,000.

This logic deserves close attention from developers: GPL derives binding force not from moral appeal, but from contract law. Incorporating GPL‑licensed code into commercial products while evading open‑source obligations is legally equivalent to using others’ works without authorization, producing essentially the same consequence as pirated software.

Three Types of Licenses, Three Sets of Invisible Obligations

MIT / BSD: Permissive, but “preserve notices” are mandatory rather than optional. MIT permits commercial use, modification and closed‑source distribution, with seemingly lightweight obligations: only retain original copyright and license statements. Yet the Rockchip‑FFmpeg incident offers a warning. After reusing LGPL‑licensed FFmpeg code within its MPP software, relevant personnel replaced the LGPL license with Apache for “unified license terms” and removed original license notices. Consequently its GitHub repository received a DMCA takedown notice from the FFmpeg project. The listed company had to issue a public apology and fully replace the code. Removing copyright notices or altering license terms constitutes copyright infringement.

GPL: Its core restriction is not “ban commercial use”, but that derivative works must likewise be open‑sourced. Real risks lie within boundary judgment: does dynamic linking create derivative works? Will inter‑process communication trigger GPL “copyleft” effect? In the “Luan Bu Mai” case, the SPC offered a practical standard: when front‑end code uses GPL components, whether back‑end code becomes bound shall be judged according to technical relationships between programs. Mere interaction shall not automatically impose overall open‑source obligations. Conversely, if commercial software functionally depends substantially on GPL‑licensed programs, there is very limited room for closed‑source release.

Apache 2.0: Additional patent‑related game‑changing clauses. Apache grants explicit patent licenses to contributors, subject to a “patent retaliation clause”: if you file patent‑infringement lawsuits targeting this open‑source software, all patent rights you obtained under this license terminate automatically. In short, you may build products based on Apache‑licensed code, yet you cannot turn open‑source‑derived technology into patent weapons against the open‑source community — otherwise your licensing basis will be revoked.

Three Practical Actions for R&D Workflows

First, embed license review at the dependency‑introduction stage. Do not leave compliance checks solely for legal teams right before product launch. Mark license types for every third‑party component during technical selection. A single GPL / AGPL component in dependency chains may change the whole product distribution strategy.

Second, distinguish compliance costs between “permissive” and “copyleft‑infected” licenses. MIT / Apache compliance mainly consists of preserving notices and managing NOTICE files with manageable overhead. GPL / AGPL require assessment of derivative‑work boundaries and distribution modes, bringing substantially higher compliance burdens. For products centered on closed‑source commercialization, special caution shall be exercised regarding AGPL components under SaaS scenarios: AGPL obligations are triggered by “providing services over network”, rather than traditional software distribution.

Third, treat license texts as formal contracts instead of casually skimming README documents. Chinese courts are resolving open‑source disputes under contract‑law frameworks, and enterprise risk‑control logic should keep pace. Open‑source communities grant usage subject to conditions, not unconditional gifts. Reading license terms before adoption represents lowest‑cost compliance within open‑source ecosystems.

分享
赛立信集团总部

地址:广州市天河区体育东路116号财富广场东塔18楼

电话:020-22263200,020-22263284

传真:020-22263218

E-mail:smr@smr.com.cn



                
赛立信旗下网站
关注赛立信
免费咨询顾问一对一服务
请留下您的电话,我们的咨询顾问会在当天(工作时间)直接和您取得联系。