LGPL
LGPL 条款适用于 GNU C 库等其他作品，该条款有时候称为“弱 Copyleft”许可证，因为根据 LGPL 条款许可的代码可与非自由软件代码组合，这一用法并不少见。虽然当前使用的两种 LGPL 版本在内容和结构上都具有实质不同，但都属于强 Copyleft 许可证，只是在涉及链接时允许较多特例。这一区别经常遭到误解，而理解这一点就可确保恰当合规许可证条款了。当 LGPL 代码与非 Copyleft 许可证下的代码组合时，从不会将其置于新条款或替代条款下。虽然允许组合，但该程序的 LGPL 组件仍需合规版权持有人为其选择的条款。在文件级别上，这与 Eclipse 类许可证的性质并不相似。Eclipse 许可证只能保证按照 Copyleft 条款分发源码，而二进制代码则由再分发者自行决定适用何种许可条款。各版本 LGPL 均旨在确保下游用户享有组合作品中 LGPL 部分代码的相关权利，包括源码形式和非源码形式。
LGPLv2.1
LGPLv2.1 本身属于 Copyleft 许可证，§6 是 LGPLv2.1 允许非 Copyleft 组合的一项特例规定。从分析角度看，独特之处在于 LGPLv2.1 §6 这一特例导致此 Copyleft 许可不属于 GPL。LGPLv2.1 §§1-5 无论在哪方面都与 GPL 的任何版本不符。
第 0 节：定义和许可范围 LGPLv2 协议的第 0 节明确规定，将程序“直接”翻译为另一种 LGPL 程序或例程库的编程语言是对该许可程序进行修改，属于创建新的修改版本。GNU GPLv2 和 GNU GPLv3 中不包含该定义。
第 2 节 第 2(a) 节明确规定，如果被许可的作品是软件库（在 §0 中定义为“软件功能集和/或数据集，用于与使用这些功能和数据的应用程序相链接以形成可执行文件”），则仅在修改后的版本也为库的情况下，才可分发该修改版本。因此，LGPLv2.1 不允许将代码从库中改为放到非库的修改版本或基于该库的作品中。第 6 节未提供如下规则的特例规定：作品可由 LGPL 库的修改版本与其他代码组合而成，但 LGPL 代码必须继续构建为库，并且许可证条款继续适用于该库。
第 2(d) 节规定修改后的例程库版本无需与库函数无关的非参数全局数据便可实现库功能。这表示在修改库时，不得将密钥、令牌、表格或其他非函数性限定数据作为调用和接收库中程序服务的必要条件。第 6 节未将这些要求排除在外。实现合规要求避免此类伎俩，这一点自 1999 年发布 LGPLv2.1 以来已成为共识。
§2 的要求非常严格，单独来看会侵犯用户的自由权。但 LGPLv2.1 §3 允许用户将此许可证下的作品改为适用 GPLv2 及其后续版本的许可证。通过此方法，不想按照 LGPLv2.1 要求使用代码的用户有权自行决定适用 GPLv2 还是 GPLv3。
许可证第 6 节包含一项功能性的反锁定条款，要求任何作为私有或非 Copyleft 软件一部分的 LGPL 代码都必须能够与修改后的库再次链接，或允许重新安装修改后的库。
如 GPLv2 所述，第 2 节重申：
这些要求适用于修改后的整个作品。如果其中部分作品并非基于库衍生所得，且有合理理由认为该部分作品属于独立且分离的作品，则在您单独分发该部分作品时，本许可证不适用。但如果整个作品都是基于该库的衍生作品，且您将该部分纳入整个作品中进行分发，则整个作品的分发都必须适用本许可证，而且对其他被许可人的许可延伸至整个作品，无论每部分的代码是谁编写的。
鉴于 §2 的上下文，显然不能将此条款解读成：在任何情况下都限制 §6 下的代码组合特例，但 §2 中的此规定重申了 §6 不适用于修改后的 LGPL 作品本身。
第 4 节 第 4 节涉及分发非源码形式的未修改作品或 §2 允许的修改版作品。合规此节的要求与合规上述 GPLv2 的相应条款要求一致。
第 5 节 第 5 节讨论版权法应用于软件作品时所引起的模糊性问题：
如果某程序未包含库中任何部分的衍生作品，但该程序用于通过编译或与库链接而与库一起运行，则此类程序称为“使用库的作品”。单独来看，此类作品不属于库的衍生作品，因此不包含在此许可证范围内。
不过，“使用库的作品”与库链接后会创建一个可执行文件，由于此文件中包含库的部分内容，因此属于库的衍生作品，而不是“使用库的作品”。也就是说，该可执行文件受此许可证的约束。第 6 节正是适用于分发此类可执行文件的条款。
当“使用库的作品”使用库中标头文件的素材时，虽然源码不是库的衍生作品，但作品的目标代码可能是库的衍生作品。事实是否真时如此？在作品无需与库链接或作品本身就是库的情况下，理清此问题尤为重要。相关法律并未明确定义这一点。
相应地，为避免产生此类模糊性问题，§5 继续指明：
如果此目标文件只使用数字参数、数据结构布局和存取元、小型宏命令和小型内联函数（长度不超过十行），则使用此目标文件不受限制，无论在法律意义上此目标文件是否为衍生作品。（包含此目标代码和库内容的可执行文件仍受第 6 节条款的约束。）
如果作品为库的衍生作品，则可按照第 6 节的条款分发作品的目标代码。无论包含此作品的任何可执行文件是否与库本身直接链接，均受第 6 节条款的约束。
此条款的目的显然是为了在遇到模糊情况时放弃 Copyleft，同时允许 §6 下的组合作品特例。此规定允许用户按照 §6 中规定的例外情况组合作品，对 Copyleft 的界定十分模糊。据我们所知，目前还没有因第 5 节条款引发的公开 LGPLv2.1 维权行动。
第 6 节 §6 规定了组合作品的例外情况，此规定经常被误解为一项“弱Copyleft”许可，但实际上并非如此。此条款允许用户组合许可作品或基于该作品的作品：
以制作包含库部分的作品，并在分发该作品时自行选择适用的许可证条款，只要该许可证条款允许用户修改作品供自己使用，且允许通过反向工程定位修改内容。
这些针对组合作品的规定要求分发者所选择的许可证不能禁止用户修改整个作品，也不能禁止客户实施反向工程来定位修改内容。从过去维权的实际情况来看，这意味着分发者所选择的许可证不能禁止用户对组合作品中的 LGPL 代码进行修改或反向工程来定位修改内容。
§6 还规定：
分发的作品必须随附显著声明，以告知用户作品中包含 LGPL 库，且该库及其使用受此许可证约束，同时还必须提供此许可证文本。如果作品会在执行过程中显示版权声明，则必须在其中增加该库的版权声明，并提供链接，指引用户找到许可证文本。
此规定与 GPLv2 和 GPLv3 中的对应条款并不完全相同。合规此规定要求分发者在涉及“版权所有人”、“许可证”或“关于”的交互程序界面上采取略为不同的声明方式。
此外，§6 规定用户应提供或出示组合作品中 LGPL 部分的源码，或者利用“共享库”机制允许使用修改版本动态替换许可作品。
对于提供源码的情况，§6(a) 的规定与 GPLv2 和 GPLv3 不同：
（您必须）随作品分发机器可读的完整对应库源码，包括作品中使用的任何代码修改（按上面第 1 节和第 2 节的要求必须分发）。如果作品是与库链接的可执行文件，则必须以目标码和/或源码形式分发机器可读的整个“使用库的作品”，以便用户可以对库进行修改，然后再次链接来生成包含修改库的修改版可执行文件。（可以理解为，如果用户修改的是库中的定义文件内容，就不需要通过再次编译应用程序的方式使用修改后的定义。）
源码不仅应完整、对应，而且提供的方式必须实现以下结果：用修改后的 LGPL 作品替代之前提供给用户的版本，仍然可重新生成整个组合作品的修改版本。例如，当 LGPL 代码与非 Copyleft 可执行代码静态链接时，分发的源码必须也包括足够的信息，以便拆分可执行文件，并重新链接到库的修改版本。
§6(c) 规定源码可按书面要约的形式提供，而不一定要直接提供；也可按照 §6(d) 条款通过网络分发。此外，§6(e) 规定分发者可“核实”用户是否确实收到相关源码，或者至少可核实分发者是否已向特定用户发送相关源码。这样做显然是为了避免在“整体分发”情况下用户要求重复分发。
如果组合作品的分发者不打算分发或提供 LGPL 组件的源码，则 LGPL 作品必须以“共享库”机制单独打包分发（遵循单独分发条款中有关源码分发的要求），即：
(1) 软件在运行时使用已存在于用户计算机上的库的副本，而不是将库的功能复制到可执行文件中；(2) 在用户安装的库经过修改之后，软件仍然运行正常，只要修改后的库版本与原库版本接口兼容即可。
总而言之，这些条款指：
1.如果您创建的程序通过共享库机制链接到某个根据 LGPLv2.1 单独分发的作品，则可根据您选择的许可证条款分发该作品，而且无需发布 LGPL 作品的源码。如果您将该库与您的程序一起分发，或者在另一情况下将该作品单独分发或作为另一产品分发，则必须按照 LGPLv2.1 或 GPLv2+ 条款（可自行选择）分发对应源码。
2.如果您选择将自己的程序与一个 LGPL 作品静态链接或组合，仍可自行选择许可证，但必须满足 LGPL 许可证中有关用户修改、反向工程和调试的限制条款，并且 LGPL 组件本身仍受 LGPL 条款约束。您必须表示愿意提供或直接提供 LGPL 组件的完整对应源码。您所提供的源码必须足以让用户利用修改版 LGPL 组件重新生成组合作品。
LGPL 合规问题较为普遍，可能是因为 LGPL 条款易于误读的原因。在实际工作中，我们代表一些许可方以用户名义维权。公开的 LGPL 纠份并不多见，因为礼貌但坚决要求各方合规许可证条款时，各方都会选择合规。
LGPLv3
LGPLv3 Copyleft 许可证提供 GPLv3 组合作品特例，旨在修正 GNU 许可证家族的结构性计划。因此，LGPLv3 是针对上述 GPLv3 §7 的附加许可。
第 0 节：其他定义 第 0 节将适用的“库”定义为包含一个或多个接口的作品，对该作品的“使用”是通过“应用程序”实现的。子级别定义“视为”对接口的使用。“应用程序”是使用一个或多个“库”接口的其他程序代码，可与接口另一端的代码组合以生成“组合作品”。
第 1 节：GNU GPL 第 3 节的例外情况 第 1 节从限制访问其他 GPLv3 §3 版权作品的“有效技术措施”中排除了干扰使用 LGPLv3 代码的做法。
第 2 节：发布修改版本 第 2 节进一步规定不得将密钥、令牌、表格或其他与功能无关的非函数性限定数据作为修改库的必要条件。这被称为“善意努力”要求，但未按通知予以纠正会视为缺乏善意的有力证据。如 GPLv3 §7 所规定，通过删除附加许可来使用 GPLv3 条款是达到合规的另一方法。
第 3 节：目标码引入库头文件材料 第 3 节声明了适用于版权范围内所有此类使用的规则（用户拥有酌情决定权），完全摒弃有关使用 LGPLv2.1 §5 所涉头文件和其他此类库资料的含糊不清部分：明确声明程序中使用库，并随作品一起提供 GPLv3 和 LGPLv3 许可证文本。
第 4 节：组合作品 第 4 节是 LGPLv3 的核心条款，针对组合作品许可。本节重申了 LGPLv2.1 §2 的许可限制规定，旨在阐明有关组合作品的许可条款不得禁止用户更改库代码或借助任何必要反向工程手段来定位此类库代码更改。
第 4(d)(0) 节包含提供最少对应源码要求，最少对应源码指“排除组合作品源码中此类代码后的那部分代码：单独来看是基于应用程序而不是[库的]链接版本。”综合以上 LGPLv2.1 §6 所述，用户也可按照 §4(d)(1) 下的“共享库”机制来分发源码。
此外，§4(e) 要求向用户交付“安装信息”以便按照 GPLv3 §6 将库的修改版本安装在“用户产品”中。鉴于 §4(d)(1) 下未界定库的最少对应源码，§4(e) 重申仍需按照 GPLv3 §6 的条款交付“安装信息”。
如前所述，GPLv3 的所有其他条款均有效，且不因 LGPLv3 中的例外许可而排除在外。