理解LGPL协议
2013-05-26 07:09:06 
阿炯
LGPL(GNU Lesser General Public License)是GPL的一个为主要为类库使用设计的开源协议，被用于一些(但不是全部)GNU程序库。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。 LGPL 允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。但是如果修改LGPL协议的代码或者衍生，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。GPL/LGPL都保障原作者的知识产权，避免有人利用开源代码复制并开发类似的产品。
对于LGPL能否以及怎样用于开发闭源程序需要做重点分析。因为其他的开源许可协议在这点上很容易理解，而LGPL协议的条款本身则比较拗口。我们关心的是，如何使用LGPL协议开发商业程序。请注意这里所说的闭源程序，是指不以某种形式开放源代码，也就是说用户(包括其他开发者)不能获取其源代码的程序。首先说明一点，LGPL协议是一个商业友好的协议。这里的含义是，你可以用LGPL协议开发商业程序，当然也可以是非商业的闭源程序。但是，它仍有一些限制的。
既然我们已经对其定性，那么我们直接进入主题：使用LGPL协议开发闭源程序，如果你使用动态链接的形式，那么你可以以任何形式(商业的、非商业的、开源的、非开源的等等)发布你的应用程序。因为动态链接并没有把LGPL函数库的二进制内容包含到我们的应用程序可执行文件体中，严格地说这并非LGPL函数库的衍生作品，因而不在LGPL许可证的范围之内。对于二进制的LGPL动态链接库能否打包到闭源程序的安装包中一起发布(这对发布商业软件至关重要，否则程序根本就无法使用)，在LGPL协议中并没有做规定，这完全取决于函数库的官方。LGPL协议只涉及源代码的版权，并不针对编译好的.dll库(或.so库)。如果你要使用官方编译好的动态库，要确定它没有额外的版权或者版权允许你自由发布它。你也可以自行编译dll库来使用(不修改源码)，而不是使用官方编译好的。当然也要看官方的说明，但如果对自行编译的动态库官方都声称会带上额外的版权，那LGPL就没有存在的意义了。
通常很多LGPL库的官方并没有对编译好的动态库的分发做特别规定(除非是第三方编译的动态库，可能会有一些自行的规定)，你最好要先取得他们的分发授权。一般的原则是只要不修改源代码并且动态链接，你是完全可以发布编译好的库，也可以和你的闭源软件一同发布，这是没有问题的。在你的软件版权声明中说明使用了哪些LGPL库，并确保软件使用者了解这些库来自哪里，以便能获得LGPL库的源码。在发布的软件中也要包含函数库的原有LGPL版权声明(LGPL.txt)。注意对于库的分发，LGPL的重点在于不修改源码、动态链接、不修改原来LGPL库的分发版权，并提供原有的版权声明。
如果你因某种原因必须静态链接一个基于LGPL协议发布的库，这会在应用程序可执行文件中包含LGPL函数库的一部分内容，从而成为函数库的衍生作品。那么，你有义务进行下面的工作：
(1).你必须在你的文档中说明，你的程序中使用了LGPL库，并且说明这个库是基于LGPL发布的；
(2).你必须在你的应用程序发布中包含一份LGPL协议，通常就是那个文本文件；
(3).你必须开放使用了LGPL库代码的所有代码，例如某些封装器。但是其他使用这些封装器的代码就不需要开放了；
(4).你必须包含你的应用程序余下部分的目标文件(通常就是我们所说的.o，.obj等等)，或者是其他等价的文件。源代码并不是必须的。
是不是很难理解呢？我们来详细说明一下。第一条很容易理解；第二条也很容易理解，你可以在此处找到LGPL协议的内容，复制下来随你的程序一起发布就可以了。第三条就不那么好理解了。简单来说，LGPL协议要求，如果你的类使用了LGPL库的代码，那么必须把这个类开源。例如，如果程序app.exe每个源文件都使用了LGPL库的代码，那么所有源代码都要开源并遵守LGPL。为了避免这种情况，我们通常编写一个封装器，把LGPL库的代码封装起来，这样就只需要开放这个封装器的代码，而其他使用了这个封装器的代码就不需要开放。第四条是对第三条的一种补充：那些使用了封装器的程序不需要开源，但是你必须把你编译的那些中间文件开放出来，比如gcc编译器的那些.o目标文件。
为什么LGPL协议要这样规定呢？原来LGPL所做的工作是，它保证了库的使用者能够有这样一种能力：修改你使用LGPL库函数的方式(那些封装器就是你使用LGPL库的方式，现在已经开源了)，重新编译这些代码，然后重新对程序进行连接(连接所需要的目标文件也是包含了的，这是第四条规定的)，就可以得到一个新的可执行程序。
可见静态链接LGPL库时软件虽然可以只开放部分源代码，但其他用户仍然可以修改其中使用LGPL库的那部分代码。当LGPL库被重新设计或修复bug时，软件用户可以修改使用LGPL库的那部分代码，重新链接成新的程序。实际上，LGPL许可证的宗旨和精神是禁止将自由软件成为专用和独享的软件(GPL也是这样)，因此至少应该确保其他用户也能通过某种途径使用这个LGPL函数库的接口，在你的软件中开放使用了LGPL库的那部分代码就是为了做到这一点。LGPL也具有传染性，但限制在其基础上开发的库上，而并不限制使用它的程序本身，它的传染性远小于GPL。
以上这就是在使用LGPL库开发闭源程序所需要遵守的东西，建议大家能够遵守协议，尊重原作者的劳动成果。
与 GPL 有何不同
GNU Lesser General Public License（LGPL）它是自由软件基金会（FSF）为特定类型的自由软件（主要是库） 设计的一种开源许可证，比著名的 GPL（General Public License）更宽松。下面将用清晰、结构化的方式讲解它的核心内容和实际意义。
| 特性 | GPL（通用公共许可证） | LGPL（较宽松通用公共许可证） |
| 目标 | 保证所有衍生作品都保持自由（强传染性） | 允许非自由程序使用该库（弱传染性） |
| 链接影响 | 静态/动态链接 → 整个程序必须开源（GPL） | 动态链接 → 主程序可闭源；静态链接需提供重链接能力 |
| 适用对象 | 应用程序、完整软件 | 主要是库（libraries） |
| 用户自由 | 高（整个生态自由） | 中（仅库本身自由，主程序可专有） |
LGPL 的核心思想：“你可以把我们的自由库用在你的闭源商业软件里，但你必须保证用户能替换这个库的版本（比如修复 bug 或改进功能）。”
LGPL 的关键条款
1. 允许做什么？
自由复制、分发库的源代码或二进制。
修改库的源代码，并发布修改版（仍需 LGPL 授权）。
将库动态链接到你的闭源程序中（最常见场景）。
收取分发费用（但不能收“授权费”）。
2. 主要义务（如果你分发包含 LGPL 库的程序）
情况 A：你只是“使用”库（未修改）
例如：你的 Delphi 程序调用 iconv.dll（LGPL）
必须做到以下至少一项（来自第 6 条）：
| 选项 | 要求 | 实践建议 |
| 提供完整的库源码 + 你的程序的目标文件（.o / .obj），让用户能重链接 | 技术复杂，少用 | 不推荐 |
| 使用共享库机制（即动态链接 DLL / .so / .dylib） • 运行时加载系统已有的库 • 用户可替换新版库 | 最简单合规方式 | 强烈推荐！ |
| 提供书面承诺：三年内可索取源码 | 需法律文书 | 商业软件可用 |
| 用户已获得源码 | 特殊情况 | 较少见 |
结论：只要所生成的程序动态链接 LGPL 库（如 iconv.dll），并在文档中注明使用了 LGPL 库，就基本合规！
情况 B：你修改了 LGPL 库
必须开源你对库的修改（仍用 LGPL 发布）。
不能删除原作者的版权声明。
修改后的库仍必须是“库”（不能变成应用程序）。
3. 什么是“基于库的作品” vs “使用库的作品”？
这是 LGPL 的核心区分
| 类型 | 定义 | 是否受 LGPL 约束？ |
| “基于库的作品” （Work based on the Library） | 直接修改库代码，或包含库源码 | 是，必须 LGPL |
| “使用库的作品” （Work that uses the Library） | 仅通过 API 调用库（如 iconv_open()） | 否（主程序可闭源） |
注意：一旦把两者链接成一个可执行文件，整个可执行文件被视为“衍生作品”，需遵守第 6 条（即上述动态链接要求）。
对开发者（尤其是 Delphi / C++ 用户）的实际指导
假设在 Windows 上开发一个闭源商业软件，想用 libiconv（LGPL）做编码转换：
正确做法（完全合规）：
1）动态链接
使用 iconv.dll（而非静态链接 .lib 到你的 .exe 中）。
2）分发时
将 iconv.dll 和你的 .exe 放在同一目录。
在软件“关于”或文档中注明：“本程序使用 GNU libiconv 库，遵循 LGPL v2.1 许可证。源代码可从 https://www.gnu.org/software/libiconv/ 获取。”
3）不修改 libiconv 源码
（或修改后按 LGPL 开源）。
风险做法：
1）静态链接libiconv.lib
到生成的 .exe → 整个程序可能被视为“衍生作品”，需提供重链接能力（复杂且易违规）。
2）删除版权信息或声称自己拥有 libiconv 的版权。
4、为什么 FSF 要设计 LGPL？
FSF 在前言中明确说明：“我们希望某些库能被广泛采用，甚至被非自由软件使用，从而推动自由软件生态。例如：如果 GNU C 库（glibc）只允许自由软件使用，那么 GNU/Linux 就不会被广泛采用。”
所以 LGPL 是一种策略性妥协：
1）保护库本身的自由（用户可修改、替换）。
2）不强制主程序开源，促进 adoption（采用率）。
5、如何在项目中应用 LGPL
如果自己写了一个库，想用 LGPL 发布，在每个源文件开头加上：
MyLib - A useful library for XYZ
Copyright (C) 2022 Your Name
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public
License along with this library; if not, see <https://www.gnu.org/licenses/>.
小结：LGPL 2.1 的核心精神
“你可以闭源你的程序，但不能锁死我对库的控制权。”
允许商业软件使用自由库。
保障用户能替换、修改库（通过动态链接实现）。
不强迫主程序开源，但要求透明和可替换性。
对于 libiconv 这样的 LGPL 库，动态链接 + 注明来源 = 安全合规，可放心用于 Delphi、C++等任何闭源项目。