【开源合规】开源许可证风险场景详细解读
文章目录
- 前言
- 关于BlackDuck许可证风险对比图
- 弱互惠型许可证
- 举个例子
- 具体示例
- LGPL系列
- LGPL-2.0-only
- LGPL-2.0-or-later
- LGPL-2.1-only
- LGPL-2.1-or-later
- LGPL-3.0-only
- LGPL-3.0-or-later
- MPL系列
- MPL-1.0
- MPL-1.1
- MPL-2.0
- EPL系列
- EPL-1.0
- EPL-2.0
- 互惠型许可证
- GPL系列
- GPL-1.0
- GPL-2.0
- GPL-3.0
- EUPL系列
- EUPL-1.0
- EUPL-1.1
- EUPL-1.2
- CECILL系列
- CeCILL 1.0
- CeCILL 2.0
- CeCILL-B
- CeCILL-C
- 强互惠型许可证
- AGPL系列
- AGPL 1.0
- AGPL 3.0
- SSPL系列
- SSPL 1.0
- 总结
前言
接上篇文章所讲，使用开源组件，忽略开源许可证问题是存在合规风险的，但是关于什么场景下真实存在风险，以及什么样的风险？很多文章也没有讲的很明白，这些内容大部分都隐藏在晦涩难懂的许可证原文里面。通过一段时间的接触，包括收集资料、翻译许可证原文等学习，特此整理了一部分……
关于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的第一个版本，旨在提供更宽松的条件，以促进自由软件库的使用。