【开源合规】开源许可证基础知识与风险场景引入

什么是开源许可证(License)?

逛Github时经常看到项目README旁边，有个License tab，不知道大家是不是跟我一样，撇了一眼就过去了，不太清楚这个license具体作用，有点法律意识的朋友可能会意识到这个可能是版权声明，不过难免还是会有其他疑问：既然都开源了，怎么还有各种条件限制？除了GPL还有Apache、MIT等，这些"License"又有哪些区别呢？

很多朋友可能像之前的我一样，二开项目或者使用第三方组件时直接拿来就用了，没有考虑过其背后的"风险"……

开源许可证有什么用？

写在前面的一句话：开源 != 免费

首先来看一下关于开源和免费的定义：

开源： 1、一个源码开放的项目(个人或团队开发) 2、一个友好交流的社区(除了源码的开放，还有社区的开放，人人都可以提issue、pr等) 3、一个产品(好的项目同时也是一个好的产品，例如Linux的产品化，可以说，如果没有 Linux 的产品化，也不会有 Linux 开源的枝繁叶茂) 免费： 1、无任何使用费用 2、闭源或开源：免费软件可以是闭源的，也可以是开源的

互联网的发展离不开开源社区的建设，很多时候，开源发布的产品难以满足用户的需求。所以，==在不违反相关开源许可证 (License) 的条件下==，有些公司对其加以定制，就变身为自己的产品或解决方案。

很多开发同学都不清楚开源许可证的"存在"，更别提Boss有这方面的意识了

开源许可证是指用于授权他人使用、修改和分发软件的一种法律文件。它规定了软件的使用权利和义务，确保开发者和用户了解如何合法地使用软件。

这里可以将开源许可证作用总结为：

• 定义使用权限：明确规定用户在使用、修改和分发软件时的权利和限制，确保软件的使用符合开发者的意图。
• 保护开发者权益：通过许可证条款，保护开发者的知识产权，确保他们的贡献得到适当的认可，并明确他们在法律上的责任和义务。
• 著作权声明：保留原始版权声明和许可证文本，确保开发者的著作权得到尊重，同时为用户提供使用软件的法律依据。 可以简单理解为：开源许可证中规定了使用者可以做什么，不能做什么等一系列权利

开源许可证分类

下面对一些常见许可证进行整理分析

不同的许可证虽然属于同一类型，但是使用者所遵守的要求都是不同

开源许可证分类及描述

公共代码 (Public Domain)

公共领域代码放弃了所有版权和相关权利，允许任何人自由使用、修改和分发，没有任何限制。

CC0

• 允许开发者放弃版权，使作品进入公共领域，无任何限制。

无License

• 野生项目🤔️明确声明放弃所有版权和相关权利，允许自由使用、修改和分发。

宽松型许可证 (Permissive)

允许用户自由使用、修改和分发代码，包括将代码集成到闭源项目中。只需保留原始版权声明和许可证文本。

MIT

• 简单且宽松，允许几乎所有用途，只需保留版权声明和许可证文本。

Apache 2.0

• 允许闭源使用，提供专利权保护，需保留版权声明、许可证文本和NOTICE文件。

BSD

• 有三条款和两条款版本，允许闭源使用，需保留版权声明和免责声明。

弱互惠型许可证 (Weak Copyleft)

允许代码与闭源软件结合使用，但要求对许可证下的代码修改部分保持开源。

LGPL

• 允许在闭源项目中使用，但修改后的库本身必须开源，适用于库和框架。

MPL

• 允许闭源使用，但修改后的文件必须开源，适用于希望混合使用开源和闭源代码的项目。

EPL

• 允许闭源使用，但修改后的文件必须开源，提供商业友好性，适用于企业项目。

互惠型许可证 (Reciprocal)

要求任何基于原始代码的修改和扩展也必须以相同的许可证发布，确保衍生作品保持开源。

GPL

• 强制共享，要求衍生作品也必须以GPL许可证发布，适用于希望确保软件及其修改版本始终保持开源的项目。

EUPL

• 类似于GPL，要求任何衍生作品都必须以相同或兼容的许可证发布，特别强调与欧洲法律的兼容性。

强互惠许可证 (Strong Copyleft)

具有最严格的要求，任何基于原始代码的使用、修改和扩展都必须以相同的许可证发布，并且任何链接到这些代码的作品也必须开源。

AGPL

• 类似于GPL，但适用于网络服务，要求通过网络提供的修改版本的源代码也必须公开。

SSPL

• 要求任何基于SSPL许可的软件作为服务提供时，必须公开整个服务栈的源代码。

为项目选择一个许可证

个人开源项目维护者怎么选择一个合适的许可证呢？

这里借用一下阮一峰大佬整理的划分图，看起来一目了然。

Just Do It

这里以我自己的开源项目为例，使用Apache 2.0

下载License模版

访问：https://www.apache.org/licenses/LICENSE-2.0.txt

项目根目录，新建LICENSE文件，粘贴过去

修改版权内容

照着修改一下就行了

上传更新

简单push一下

Github会自动识别、排版

开源合规-企业开源许可证合规治理

对于个人和企业，我收集整理了需要关注许可证风险的几种场景

使用开源软件开发闭源产品

风险：某些开源许可证（如GPL、AGPL、SSPL）要求任何基于其代码的修改或扩展必须以相同的许可证发布。如果使用这些许可证的软件来开发闭源产品，可能需要公开源代码，影响商业机密和竞争优势。 建议：在选择开源软件时，仔细阅读并理解许可证条款，确保不会违反开源许可证的要求。

分发开源软件或包含开源组件的产品

风险：分发包含开源组件的软件时，必须遵守相应的许可证条款，例如保留版权声明、提供源代码等。未能遵守这些要求可能导致法律纠纷。 建议：确保分发的软件符合所有开源许可证的要求，并提供必要的文档和源代码。

修改开源软件并再发布

风险：修改开源软件并再发布时，需要遵守原始开源许可证的条款。例如，GPL要求修改后的软件也必须以GPL许可证发布。 建议：在修改开源软件时，保留原始版权声明，并遵循许可证的发布要求。

将开源软件作为服务提供（SaaS）

风险：强互惠型许可证（如AGPL、SSPL）要求如果通过网络提供服务，必须公开源代码。使用这些许可证的软件提供SaaS服务时，需要公开源代码，可能影响商业机密。 建议：评估开源软件的许可证类型，选择适合的许可证，避免使用强互惠型许可证的软件提供SaaS服务，除非愿意公开源代码。

组合使用不同许可证的开源软件

风险：不同开源许可证之间可能存在冲突，导致无法合法组合使用。例如，GPL和某些宽松型许可证之间的冲突。 建议：在组合使用开源软件时，确保不同许可证之间的兼容性，避免法律风险。

使用开源软件中的专利

风险：某些开源许可证（如Apache 2.0）包含专利授权条款，而其他许可证（如GPL）可能不包括。这可能导致专利侵权风险。 建议：了解开源软件的专利授权条款，确保不会侵犯第三方专利。

开源软件的合规性管理

风险：==缺乏开源软件合规性管理，可能导致违反许可证条款的风险，影响企业声誉和法律地位(开源社区谴责，舆论风险导致品牌形象受损，企业也会被行业或者地区监管处罚……)。== 建议：建立开源软件合规性管理流程，使用SCA工具检测和管理开源组件，确保合规性。

总结

对于开源许可证的基础内容，以及风险场景引入先写这么多，下一篇将对市场上主流SCA工具许可证风险识别功能进行相关"测评🤔️"(使用方法、接入场景……)