导语

自由软件基金会（FSF）自1989年发布GPL-1.0，历经1991年的GPL-2.0、1999年的LGPL-2.1，再到2007年的GPL-3.0、LGPL-3.0和AGPL-3.0，FSF最终构建了完整的自由软件许可证矩阵，为自由软件文化的传播与发展作出了卓越贡献。其中，LGPL-2.1以其重要性及复杂性广受业界关注，并在库、框架等软件上广泛应用（如：glibc，FFmpeg）。 

开放原子开源基金会发起的源译识（Contransus）项目以“在共译中凝聚开源共识”为宗旨，对开源相关许可证、域内外司法判决、专业书籍、重点报告等内容进行专业可信的翻译。本次，本项目通过公开投稿、多方检视的方式推出LGPL-2.1许可证的中译本并解读合规要点。至此，GPL系列许可证已经翻译完毕。

 

01. 中译本

 

LGPL-2.1 中译本请见主流许可证中译本合辑：标签 · license-translation · AtomGit

在此，我们对参与以上许可证翻译和检视工作的贡献者致以诚挚感谢：

• 翻译：臧秀涛、薛杨洁、赵振华
• 检视：陶冶（国浩律所）、徐美玲（对外经济贸易大学）

 

02. 评述

LGPL-2.1合规解读

 

一、实际开发中的LGPL-2.1合规

         在开发实践中，许多人将LGPL-2.1视为“动态链接”版的GPL-2.0，这种简化的理解方式虽然有助于开发者迅速解决问题，但也可能导致开发者忽视对LGPL-2.1条款细节的深入了解，进而减少向法务部门求助的需求。

        针对将“使用本库的作品”与本库链接后所创建的可执行文件，LGPL-2.1通过第6条提供了两个分发选择：

（一）路径一

        LGPL-2.1第6a条要求，分发者须提供LGPL-2.1库的完整源代码，并在“使用本库的作品”是可执行文件的情况下提供“使用本库的作品”的完整目标代码或源代码。分发者提供的目标代码或源代码应足以使用户能够修改本库并重新链接，以生成包含经修改的本库的可执行文件。

        举个例子，假设某项目使用了基于LGPL-2.1发布的库X.c，编写了自有代码Y.c，并将两者（X.c和Y.c）编译为单个可执行文件Z进行分发。此时，分发Z时需要提供X的源代码（若X修改，则提供修改后的X的源代码）以及Y的目标代码或源代码。需要注意的是，在C语言环境中，Y的“目标代码”指的是编译过程中生成的可供链接的Y.o文件。可见，即使后续开发者不以动态链接方式使用本库，也不必在分发时将其全部自有代码开源。

（二）路径二

        LGPL-2.1第6b条要求，分发者须使用合适的共享库机制与本库进行链接。所谓“合适的机制”是指：（1）在运行时使用用户计算机系统中已有的库副本，而不是将库函数直接复制到可执行文件中；（2）如果用户安装了该库的修改版本，只要修改后的版本与构建该作品时使用的版本接口兼容，则该作品可与修改后的库正常运行。

        举例来说，假设用户使用了基于LGPL-2.1发布的库X.c，编译为X.so文件，并编写了自有代码Y.c，编译为可执行文件Y。在运行时，Y动态调用X.so。分发者将Y与X.so一并分发。如果用户在其计算机上有X.so或修改后的X’.so文件，则可以将接收到的软件中的X.so替换为其自备的X’.so版本，只要Y+X.so在替换为Y+X’.so后仍能正常运行，即满足LGPL-2.1第6b条第（2）款关于分发方式的要求，当然，因为最终用户修改X.so库导致的不兼容与分发人无关。

        可见，动态链接是满足该第6b条要求的最简单有效方式，这也是LGPL-2.1被开源圈视为“动态链接版GPL”的一个重要原因。在C/C++语言中，动态链接和静态链接容易区分，但在JavaScript、Python、Java等语言中，由于默认采用运行时链接策略，通常不涉及明确的动态或静态链接概念。因此，强行使用“动态链接”的定义可能会引起混淆。 此时，对于描述分发方式应具备的效果而言，使用“可替换”的概念或许更为简便。即，如果软件的分发方式允许用户替换其中的LGPL组件，那么便符合条款要求；如果不允许，即便使用了动态链接，也可能违反LGPL的相关规定。

        当然，以上只是最基础的一般情形，实践中需要结合实际业务情况具体判断，例如，在嵌入式系统或者iOS软件中，可能会给LGPL-2.1前述“可替换”的要求带来挑战。比如在iOS系统中，因为系统的限制，所有应用必须从App Store里安装，用户无法将修改后的程序重新打包为安装包并装回原系统中，因此客观上使前述“可替换”要求变得不可行。

二、关于治愈条款

       LGPL-2.1/GPL-2.0 与 LGPL-3.0/GPL-3.0 之间的一个非常重要的区别在于终止后的治愈条款。四个版本的许可证中，都设置有自动终止条款，即在被许可方违反许可证要求后，许可会自动终止。但在 LGPL-2.1/GPL-2.0 中，并未明确规定许可恢复条款－治愈条款。这意味着，理论上在许可自动终止后，被许可方若想恢复许可，必须获得所有权利人的明确同意，这对于一些涉及大量贡献者的项目来说，几乎是不可能实现的。

       相比之下，LGPL-3.0/GPL-3.0 明确设置了治愈条款，规定被许可方在首次收到违约通知后的30天内，如果能够纠正所有违约事项，许可将自动恢复。此外，即便被许可方错过了这30天的“窗口期”，只要其仍自行纠正了所有违约事项，许可也能暂时恢复。如果权利人在60天内未明确通知被许可方，其许可将永久恢复。^[1]

       可以看出，LGPL-3.0/GPL-3.0 相比于 LGPL-2.1/GPL-2.0 在许可恢复方面要宽松得多。然而，许多基于 LGPL-2.1/GPL-2.0 的项目，出于对软件自由的维护考虑，主动发起了 GPL Cooperation Commitment (GPL-CC)，即在原许可证之外做出额外声明，将 LGPL-3.0/GPL-3.0 的治愈条款政策适用于 LGPL-2.1/GPL-2.0 项目。包括 Linux Kernel在内的多个项目已经作出此类声明。^[2]

       因此，在开展开源合规工作时，如果不慎违反了 LGPL-2.1/GPL-2.0 并收到权利人的侵权通知，务必第一时间检查相关项目是否已作出 GPL Cooperation Commitment 声明。如果有前述声明，则需要特别关注30天和60天“窗口期”，尽快纠正违约行为，以确保许可恢复。

 

• [1] 各法域在个案中对此类条款的解读可能会有所不同，可延伸阅读德国案例：LG Halle, Urteil v. 27.07.2015, Az. 4 O 133/15, https://openjur.de/u/857711.html
• [2] 2017年10月，近100名Linux Kernel开发者联合发布《Linux Kernel 维权声明》，支持Linux Kernel在其适用许可证GPL-2.0第4节的基础上适用GPL-3.0第8节关于治愈条款的规定。请见：https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git/tree/Documentation/process/kernel-enforcement-statement.rst

 

 

 

 ================================  拓展阅读  ================================

• • LGPL-2.1: https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html
  • GPL FAQ: https://www.gnu.org/licenses/gpl-faq.html
  • Copyleft and the GNU General Public License: a Comprehensive Tutorial and Guide, https://copyleft.org/guide/ 
  • 《商业开源：开源软件许可实用指南（第三版）》，刘伟（译）https://atomgit.com/translation/Contransus
  • 《开源规则——案例、许可证及开源组织》，张平（主编）、徐美玲（执行主编），知识产权出版社
  • 常涉司法纠纷？快来补上GPL-2.0中译本和McHardy案件解读！
  • 开放原子与Eclipse两基金会联合发布EPL-2.0许可证中译本
  • SPDX v3.0解读与中译本