【开源合规】开源许可证风险场景详细解读
原创
前言
接上篇文章所讲，使用开源组件，忽略开源许可证问题是存在合规风险的，但是关于什么场景下真实存在风险，以及什么样的风险？很多文章也没有讲的很明白，这些内容大部分都隐藏在晦涩难懂的许可证原文里面。通过一段时间的接触，包括收集资料、翻译许可证原文等学习，特此整理了一部分……
关于BlackDuck许可证风险对比图
不知道你是否跟我一样看到仅汇总、实施标准、先决条件……，是不是一脸懵😳，还是不清楚导致这是组件的什么用法，知名SCA工具对于许可证这一点做的似乎并不是特别友好，不知道扫出来一大堆许可证，安全部门或者法务(有些公司许可证合规问题是由法务部门处理)是不是也是一脸懵。
下面进行一些许可证风险场景整理，以及再总结一张较为口语化的风险对比图……
弱互惠型许可证
允许代码与闭源软件结合使用，但要求对许可证下的代码修改部分保持开源
即许可证允许你将开源代码与闭源代码一起使用，但如果你修改了开源部分的代码，那么你必须将这些修改也开源
举个例子
假设有一个闭源的图像处理软件，使用了一个LGPL许可的图像处理库（例如libpng）来处理PNG文件。有以下两种场景：
- 直接结合使用： 直接将libpng库集成到该闭源软件中，并发布软件，这种情况下不需要将整个软件开源。 只需在软件文档中包含libpng的LGPL许可证文本和版权声明。
- 修改部分保持开源： 如果你发现libpng库中有个错误或者你需要一个新的功能，你对libpng库进行了修改。 根据LGPL许可证，你必须将修改后的libpng代码开源，并以LGPL许可证发布。 这意味着你需要提供修改后的libpng源代码，并在文档中注明这些修改。
具体示例
假设你修改了libpng库中的一个函数，以提高它的性能：
// libpng 修改后的函数
void improved_png_function() {
// 改进的代码
}在这种情况下，你需要将修改后的libpng代码开源，并确保任何人都可以获得这些修改后的源代码。这可以通过在你的软件发布页面提供一个下载链接，或者将代码提交到公共代码库（如GitHub）上。同时，你的闭源图像处理软件依然可以保持闭源。
提供修改后的libpng库源代码 下载链接：<提供修改后的libpng库代码的链接>
修改说明：<简要说明你对libpng库所做的修改>
LGPL系列
LGPL（Lesser General Public License）是GNU许可证家族的一部分，旨在为开源软件提供一种更灵活的共享方式。不同版本和变体的LGPL许可证在细节和要求上有所不同。
运行环境：
LGPL 许可的核心要求在所有语言中都是一致的，即允许动态链接库而无需开源应用程序代码，但静态链接库时需要提供重新链接的机制和开源对库的修改部分。
LGPL-2.0-only
特点：
修改和分发：允许用户修改和分发修改后的版本，但必须以LGPL-2.0许可证发布。
链接要求：允许与闭源软件链接，但要求修改后的库本身必须开源。
分发源代码：在分发修改后的版本时，必须提供相应的源代码。
适用场景：适用于需要确保库保持开源，但允许其与闭源软件结合使用的项目。
版本变化：首次发布：这是LGPL的第一个版本，旨在提供更宽松的条件，以促进自由软件库的使用。
LGPL-2.0-or-later
特点：
与LGPL-2.0-only类似，但增加了一个灵活性选项：用户可以选择遵守LGPL-2.0或任何更新版本的条款。
提供向后兼容性，并允许未来的许可证版本引入改进和更改。
适用场景：适用于希望在当前许可证条款和未来改进之间保留灵活性的项目。
LGPL-2.1-only
特点：
是对LGPL-2.0的修订版，解决了一些法律和技术问题。
改进了许可证文本的清晰度和一致性，但核心要求与LGPL-2.0类似。
适用场景：适用于希望利用LGPL-2.1改进的项目，同时保持与LGPL-2.0的兼容性。
版本变化：更新的版本：LGPL 2.1是对LGPL 2.0的更新，主要增加了对某些法律条款的澄清和修订。
LGPL-2.1-or-later
特点：
与LGPL-2.1-only类似，但增加了一个灵活性选项：用户可以选择遵守LGPL-2.1或任何更新版本的条款。
提供向后兼容性，并允许未来的许可证版本引入改进和更改。
适用场景：适用于希望在当前许可证条款和未来改进之间保留灵活性的项目。
LGPL-3.0-only
特点：
是LGPL的最新版本，基于GPLv3。
改进了对软件专利、DRM（数字版权管理）等现代问题的处理。
更明确的国际化和法律术语，增强了许可证的适用性。
必须提供安装和运行修改版本所需的信息
适用场景：适用于需要处理现代软件开发和分发问题的项目。
版本变化：更严格的条款：增加了对专利的保护，要求提供安装信息。
LGPL-3.0-or-later
特点：
与LGPL-3.0-only类似，但增加了一个灵活性选项：用户可以选择遵守LGPL-3.0或任何更新版本的条款。
提供向后兼容性，并允许未来的许可证版本引入改进和更改。
适用场景：适用于希望在当前许可证条款和未来改进之间保留灵活性的项目。
MPL系列
Mozilla Public License (MPL) 系列是由 Mozilla Foundation 发布的开源许可证，主要用于保护开源项目的版权，同时允许灵活的商业使用。
MPL-1.0
特点:
文件级开源：要求对 MPL 许可的代码进行修改的文件必须保持开源，但不要求整个项目开源。这意味着可以将修改后的文件与闭源代码一起分发。
兼容性：相对较低的兼容性，不能直接与其他开源许可证（如 GPL）结合使用。
商业友好：允许将 MPL 许可的代码用于商业项目，只要遵循文件级开源的要求。
适用场景：适用于希望保护代码开源，但也允许与闭源代码结合使用的项目。
MPL-1.1
特点：
文件级开源：与 MPL 1.0 类似，要求对 MPL 许可的代码进行修改的文件保持开源，但不要求整个项目开源。
增强的兼容性：相对于 MPL 1.0，MPL 1.1 具有更好的兼容性，允许更灵活的代码组合。
商业友好：同样允许将 MPL 许可的代码用于商业项目，只要遵循文件级开源的要求。
适用场景：适用于希望在保护代码开源的同时，与其他开源项目进行更好兼容的项目。
MPL-2.0
特点：
MPL 2.0在设计时特别考虑了与其他常见开源许可证的兼容性，这使得开发者可以更自由地使用和组合不同许可证的代码。以下是MPL 2.0的一些兼容性特点：
与GPL兼容：MPL 2.0与GPL、LGPL和AGPL许可证兼容，允许将MPL 2.0代码与这些许可证的代码一起分发。
与Apache License兼容：MPL 2.0与Apache License 2.0兼容，允许代码混合使用。
与其他许可证兼容：MPL 2.0还考虑了与其他常见开源许可证（如BSD和MIT许可证）的兼容性。
EPL系列
EPL（Eclipse Public License）系列许可证是由Eclipse基金会发布的一系列开源许可证。
EPL-1.0
Eclipse Public License 1.0 是EPL的第一个版本，由Eclipse基金会在2004年发布。EPL 1.0 是一种宽松的开源许可证，允许修改和分发，但有一些特定的要求：
源代码分发：如果分发修改后的二进制文件，必须提供源代码或者提供获取源代码的方法。
版权声明：修改后的文件必须保留原始的版权声明和许可证文本。
利条款：EPL 1.0 包含一个专利条款，授予分发者和修改者在使用该软件时的专利许可。
EPL-2.0
Eclipse Public License 2.0 是EPL的最新版本，由Eclipse基金会在2017年发布。EPL 2.0 在EPL 1.0的基础上进行了改进，主要特点包括：
许可证兼容性：EPL 2.0 增强了与其他开源许可证（如GPL和Apache License）的兼容性。
简化的条款：EPL 2.0 对许可证条款进行了简化，使其更易于理解和应用。
专利条款：EPL 2.0 继续保留了EPL 1.0中的专利条款，提供专利保护。
互惠型许可证
GPL系列
GPL（GNU General Public License）系列是由自由软件基金会（Free Software Foundation, FSF）发布的一系列开源许可证。这些许可证旨在确保软件的自由使用、修改和分发权利。
GPL-1.0
特点：
使用者可以随意复制和发布软件
如果以二进制方式发布软件，就必须同时发布可读的源代码
要求所有基于GPL软件的衍生作品必须以相同的许可证发布。
GPL-2.0
特点：
引入了“病毒性”条款，即任何使用GPL代码的项目也必须以GPL发布。
增加了专利授权条款，确保用户拥有使用软件的专利权。
更详细地规定了源代码的分发要求。
GPL-3.0
特点：
增强了对专利诉讼的保护，防止专利流氓行为。
解决了与其他许可证（如Apache License 2.0）的兼容性问题。
引入了“反Tivo化”条款，防止硬件制造商通过硬件限制来规避GPL条款。
EUPL系列
EUPL（European Union Public License）是欧盟委员会发布的一系列开源许可证，旨在确保软件在欧洲范围内的自由使用、修改和分发。
EUPL-1.0
特点：
促进公共部门软件的共享和再利用。
与其他开源许可证（如GPL、LGPL、MPL）的兼容性有限。
强调软件的自由使用、修改和分发，但相对较新的许可证在社区中采用度较低。
EUPL-1.1
特点：
对EUPL 1.0进行了修订和改进。
增加了与更多开源许可证（如Apache、BSD）的兼容性。
进一步明确了法律术语和条件，增强了许可证的可操作性。
EUPL-1.2
特点：
进一步增强了与其他开源许可证的兼容性，包括GPLv3。
更加关注国际化和多语言支持，提供了多个语言版本。
保持了对软件自由使用、修改和分发的强调，并适应了更广泛的开源生态系统。
CECILL系列
CeCILL（CEA CNRS INRIA Logiciel Libre）系列是由法国原子能委员会（CEA）、国家科学研究中心（CNRS）和国家信息与自动化研究院（INRIA）联合发布的开源许可证，旨在提供符合法国法律的自由软件许可证。
CeCILL 1.0
特点：
确保软件在法国法律框架内的自由使用、修改和分发。
类似于GPL，但更加注重符合法国法律和规定。
鼓励软件开发者和用户遵守法国知识产权法。
CeCILL 2.0
特点：
对CeCILL 1.0进行改进，增加了与其他开源许可证的兼容性。
更加明确了责任和保证条款，适应更广泛的开源社区。
强调透明性和合作，促进自由软件的传播和使用。
CeCILL-B
特点：
类似于BSD许可证，提供了较为宽松的条款。
允许在更自由的环境中使用、修改和分发软件。
适用于希望最大化软件传播和使用的开发者。
CeCILL-C
特点：
类似于LGPL，允许软件库的链接和使用。
保持了对原始软件和修改部分的保护，同时允许与专有软件结合。
适用于希望在自由和专有软件环境中使用的库和组件。
强互惠型许可证
AGPL（Affero General Public License）是GNU GPL的变种，特别适用于网络服务器软件。
AGPL系列
AGPL 1.0
特点：
最初由Affero公司发布，基于GPL v2。
增加了网络交互条款，要求如果在网络服务器上使用软件，必须提供源代码。
主要用于确保用户通过网络服务使用软件时也能获取源代码。
AGPL 3.0
特点：
由自由软件基金会（FSF）发布，基于GPL v3。
保留了AGPL 1.0的网络交互条款，要求提供源代码。
增强了对专利诉讼的保护。
改进了许可证兼容性，解决了与其他许可证（如Apache License 2.0）的兼容性问题。
SSPL系列
SSPL（Server Side Public License）是MongoDB公司创建的一种许可证，旨在确保使用该软件提供云服务的公司也必须开源他们的服务代码。
SSPL 1.0
特点：
基于AGPL 3.0，但增加了更严格的条款。
要求如果使用SSPL软件提供云服务，不仅要公开SSPL软件的源代码，还要公开与服务一起运行的所有源代码。
强调保护开源软件在云计算环境中的自由使用。
总结
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
腾讯云开发者
