【开源合规】开源许可证风险场景详细解读

发布于:2024-07-11 ⋅ 阅读:(19) ⋅ 点赞:(0)

前言

接上篇文章所讲,使用开源组件,忽略开源许可证问题是存在合规风险的,但是关于什么场景下真实存在风险,以及什么样的风险?很多文章也没有讲的很明白,这些内容大部分都隐藏在晦涩难懂的许可证原文里面。通过一段时间的接触,包括收集资料、翻译许可证原文等学习,特此整理了一部分……

关于BlackDuck许可证风险对比图

在这里插入图片描述不知道你是否跟我一样看到仅汇总、实施标准、先决条件……,是不是一脸懵😳,还是不清楚导致这是组件的什么用法,知名SCA工具对于许可证这一点做的似乎并不是特别友好,不知道扫出来一大堆许可证,安全部门或者法务(有些公司许可证合规问题是由法务部门处理)是不是也是一脸懵。
下面进行一些许可证风险场景整理,以及再总结一张较为口语化的风险对比图……

弱互惠型许可证

允许代码与闭源软件结合使用,但要求对许可证下的代码修改部分保持开源
即许可证允许你将开源代码与闭源代码一起使用,但如果你修改了开源部分的代码,那么你必须将这些修改也开源

举个例子

假设有一个闭源的图像处理软件,使用了一个LGPL许可的图像处理库(例如libpng)来处理PNG文件。有以下两种场景:

  1. 直接结合使用:
    直接将libpng库集成到该闭源软件中,并发布软件,这种情况下不需要将整个软件开源。
    只需在软件文档中包含libpng的LGPL许可证文本和版权声明。
  2. 修改部分保持开源:
    如果你发现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