广州做外贸网站的公司,上海最近热点事件,商业网站开发文档,一个空间可以做两个网站吗文章目录 前言关于BlackDuck许可证风险对比图弱互惠型许可证举个例子具体示例LGPL系列LGPL-2.0-onlyLGPL-2.0-or-laterLGPL-2.1-onlyLGPL-2.1-or-laterLGPL-3.0-onlyLGPL-3.0-or-laterMPL系列MPL-1.0MPL-1.1MPL-2.0EPL系列EPL-1.0EPL-2.0互惠型许可证GPL系列GPL-1.0GPL-2.0GPL-… 文章目录 前言关于BlackDuck许可证风险对比图 弱互惠型许可证举个例子具体示例 LGPL系列LGPL-2.0-onlyLGPL-2.0-or-laterLGPL-2.1-onlyLGPL-2.1-or-laterLGPL-3.0-onlyLGPL-3.0-or-later MPL系列MPL-1.0MPL-1.1MPL-2.0 EPL系列EPL-1.0EPL-2.0 互惠型许可证GPL系列GPL-1.0GPL-2.0GPL-3.0 EUPL系列EUPL-1.0EUPL-1.1EUPL-1.2 CECILL系列CeCILL 1.0CeCILL 2.0CeCILL-BCeCILL-C 强互惠型许可证AGPL系列AGPL 1.0AGPL 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的第一个版本，旨在提供更宽松的条件，以促进自由软件库的使用。
LGPL-2.0-or-later
