总结了一下程序员们都应该知道的各类开源许可证及合规相关的知识

[ssltest]

因为我本身也在做开源，所以比较关注这个问题，最近因为工作需要，总结和分析了一下关于开源许可证相关的知识，也分享给大家一起讨论，希望得到大家的指导。

前言

2021 年 12 月，抖音海外版 TikTok 上线了一款名为 TikTok Live Studio 的 APP ，但不久其下载页面就被删除。TikTok 官方对此事做出回应，原因是该 APP 违反 GPL 许可证，其使用 GPL 许可证下的开源软件源码，却没有按照 GPL 许可证要求开源。

随着开源软件的发展，其数量和影响力在不断的上升。开源软件具有成本低、升级快的特点，因此越来越多的企业选择使用开源软件。但是“天下没有免费的午餐”，在开源许可证的约束下，开源软件的使用并非想象中的自由。不恰当地使用开源软件，可能会给企业造成负面舆论甚至经济损失的风险。

开源许可证（“Open Source License”）是什么

开源许可证是一种针对开源软件使用者的约束，目的在于规范受著作权保护的软件的使用或者分发行为。

常见许可证及其差异

常见的许可证主要有 GPL 、LGPL 、AGPL 、MPL 、MIT 、BSD 和 Apache ，各个许可证还包含不同版本。根据使用条件不同，可以将这些许可证大致分为两类：Copyleft 许可证和宽松许可证（ permissive license ），主要对使用、修改和分发的场景作出相应约束。

1.BSD 许可证——特点是可以自由使用、修改、再发布。但是在商用或者个人分发过程中必须带有原来代码的许可证，且不能用原作者相关信息去做宣传。

2.MIT 许可证——源自麻省理工学院（ Massachusetts Institute of Technology, MIT ），是使用最广泛的一种开源许可证。其特点和 BSD 许可证类似，只要在项目的所有副本中包含版权声明和许可声明，就无需承担任何责任。

3.Apache 许可证——作为 permissive license 中的一员，Apache 多了几个限制条件，禁止使用其商标与作者的相关信息进行商业行为，必须明确指出所有修改过的文件。

4.GPL 许可证—— GPL 和 BSD 区别还是很大的，GPL 主张代码及衍生代码的开源，不允许修改后和衍生的代码做为闭源的商业软件进行发布和出售。如果已发布商业软件源码里含有 GPL 开源软件源码，则必须对该商业软件进行开源或者下架处理。

5.AGPL 许可证—— AGPL 是 GPL 的一个补充, 在 GPL 的基础上加了一些限制。GPL 的约束生效前提是该软件"发布"，有的公司就使用 GPL 组件编写 web 系统，但是不发布系统，只用这个系统在线提供服务，这样就避免了开源系统代码。而 AGPL 要求如果云服务(即 saas)用到的代码是该许可证，那云服务的代码也必须开源。

6.LGPL 许可证—— LGPL 允许商业软件通过类库引用的方式使用 LGPL 类库，而不需要开源商业软件源码。

7.MPL 许可证——在商业软件中，如果含有 MPL 许可证的代码在单独的文件内，其他新增的文件就可以避免开源。

我们针对 C/C++、Java 两类常用编程语言的开源组件许可证分布进行统计，可以发现：

• C/C++ 中主要使用 MIT 、BSD 、Apache 许可证，GPL/LGPL 约占 16%，整体使用更严格
• Java 中主要使用 Apache 、MIT 许可证，GPL/LGPL 占比约 1%，整体使用更宽松

开源许可证在标准化

SPDX 是 Linux 基金会推出的用于交流软件材料清单信息的开放标准，SPDX 当前已经对超过 400 个开源许可证的名称、标识符等信息进行标准化，并在持续更新。 SPDX 还给出了开源许可证的匹配指南，鼓励开发者在代码中加入诸如 SPDX-License-Identifier: MIT 的简短标识。 可以预见，未来开源许可证将变得更标准，更容易被机器识别处理。

开源合规风险

2008 年，美国联邦巡回上诉法院首次在 Jacobsen v.Katzer 一案中主张了开源许可证的著作权效力。中国在 2019 年的「柚子案」中默认了 GPL 许可证的法律效力。相关判例的产生，意味着开源许可证不再是君子协定，违反开源许可证会对企业带来经济和声誉上的损失。 如 GPL 许可证和 MPL 许可证，GPL 许可证要求「用户使用该许可证下的源码，必须以 GPL 许可证的许可发布整个程序的源码」，而 MPL 则要求「 MPL 许可证的代码在单独的文件内，其他新增的文件就可以避免开源。」因此企业在使用同时附带 GPL 和 MPL 许可证的开源软件时，就可能因为开源许可证的冲突，面临违反其中之一的风险。

国内外的相关案例

一、2019 年，在数字天堂北京网络技术有限公司 诉 柚子北京科技有限公司的案件中，柚子北京 由于开发人员在 2015 年使用了 数字天堂 的 HBuilder 软件工具中三款插件的部分源代码，未遵守开源软件许可证，将具有开源要求的软件产品作为商业产品，被开源软件的著作权人诉请违约和侵权，故而承担法律责任。

二、2021 年 4 月 30 日，罗盒公司状告风灵公司侵权获赔 50 万元，同时要求风灵公司停止侵权行为。 在该案件中原告罗盒公司，独立开发“罗盒(Virtual App)插件化框架虚拟引擎系统 V1.0”（简称 VirtualApp V1.0 ），在 2016 年引入 GPL3.0 许可证，于 2017 年取得计算机软件著作权登记证书，且声明 用于商业用途请购买商业授权。 2018 年原告发现名为“点心桌面”的软件使用了 VirtualApp V1.0 的代码，经过源码分析对比，发现两者之间高度相似，遂起诉被告福建风灵公司。 经法院审判被告赔偿原告为制止侵权行为而支出的合理费用 50 万元。此次判决是中国首个明确 GPL3.0 许可证具有法律效力的案例。

三、2021 年 12 月中旬，抖音海外版 TikTok 上线一款名为 TikTok Live Studio 的 APP ，有网友发现，此软件违反 GPL 许可证，违规使用开源软件 OBS （一个免费的开源视频录制和视频实时流软件，且允许任何人免费应用和商用）的源代码，既然允许商用，但是为什么还会被曝违规呢？ 这里就需要再科普一下 GPL 许可证，GPL 许可证具有很强的传染性，如果一款软件使用 GPL 许可证的开源软件源码，那么该软件也必须采用 GPL 许可证，进行开源。 此事曝光之后，OBS 开发者证实此事，TikTok 也对此事进行了回应，并删除 TikTok Live Studio 的下载页面。

针对开发者 /企业的建议

温馨提醒：开源千万条，合规第一条

一、软件开发者使用开源软件时，需要谨慎选择开源软件，关注其开源许可证的内容及相关条件，避免潜在的法律风险。

二、企业应当建立一个完善机制，识别企业中所使用的开源软件清单，明确对应的开源许可证及权利约束，及时规避相关合规风险。

三、通过隔离机制避免开源许可证传染，如对于 MPL 许可证下代码的使用，应把该许可证的代码放在单独的文件内避免许可证传染； LGPL 下的代码，可采用动态链接调用该许可证的库实现隔离。

我们在开源工具里面集成了开源许可证的合规检测能力

开源项目地址：https://github.com/murphysecurity

一、使用 murphysec 开源工具扫描您的代码目录，它会帮您一键识别出来您的代码项目中使用的所有开源组件，包括直接依赖和间接依赖的组件清单，同时列出所有组件对应的开源许可证信息

二、查看报告，根据报告的提示可以明确看到对应组件的许可证在什么场景下存在许可证合规风险

三、您可以根据许可证的合规风险提示，来判断您的项目是否存在违反的可能性，并调整您所引入的组件，来解决这个风险。

一些可能你无意中踩到的坑：

1 ）有一些组件是存在多种许可证的，可能不同目录文件指定的许可证类型不一样，要特别注意，当然我们的开源软件也考虑到了这种情况

2 ）有些组件你没有直接依赖，但是可能存在间接依赖的情况，你需要特别注意查看相关组件的依赖关系

使用文档：https://www.murphysec.com/docs/

参考链接

https://spdx.org/licenses/

https://opensource.org/licenses/category

更新下 GPL 的理解：

如果你并没有修改 GPL 软件本身的代码，并且在你的商业行为中，该 GPL 软件是以一个独立的可分割的形式发布，那么他可以不影响你的软件的其它部分。你的其他软件不必遵循 GPL 协议。——否则你的其他部分软件就要受到 GPL 协议的传染，必须遵循 GPL ，也就必须开源。

至于是否可以商用，只要你遵循以上逻辑，是可以商用的。

[L4Linux]

对 GPL 的描述是错的。商业软件卖的时候和代码一起卖就行了。

[ersic]

之前在阮老师博客看到过开源协议的一张图

[GuangXiN]

BSD 协议有 4 句话版本、3 句话版本、2 句话版本、1 句话版本和 0 句话版本

[Mithril]

AGPL 的描述也是错的。。。。

[ssltest]

@Mithril 大佬，求指教

[ssltest]

@L4Linux 仔细研究了一下，您说的应该是对的，我更新下

[VchentozV]

这些许可有什么用？

[BrettD]

@VchentozV 作者声明了许可条款之后你才能用作者的代码

[Xhack]

总结了个寂寞，错了好多

[ssltest]

@Xhack 🤕

[Mithril]

@ssltest 首先，free 或者说 open source 的软件协议都不会“限制商业使用”。根据 GNU 的哲学，“自由”面对不管是大公司还是个人用户都是平等的。真正限制商业使用的，是商业公司不想让自己的客户获得源代码，和再分发的权力。这个决定是商业公司做的，而不是 license 限制的。
其次，对于 license 最重要的一部分，就是专利授权。你这个完全没说。。。
最后，关于 AGPL 。这个 license 设计的很差，不管对于开源库作者，还是使用者，都是很差的协议。
但就是这样，你的描述也是错的。。
AGPL 的核心在于，认定用户可以与你的系统交互，就认为是你在“分发”。跟你是不是云服务没关系。
AGPL 的问题在于“交互”的认定是很模糊的。对于作者来说，使用者很容易钻空子。对于使用者来说，这种边界界定不清的协议也是垃圾。这也是为什么 MongoDB 把 AGPL 切换成 SSPL 。
看你都挂了推广了，既然想赚这个钱，建议还是专业点。。。

[ssltest]

@Mithril 感谢大佬的解答啊，又学习到了。我迭代下

[FrankHB]

你漏了最原则性上的文献：怎么界定算开源。
opensource.org/osd-annotated
许可证可以自己写，你列不完。

[FrankHB]

@Mithril “限制商业使用”的内涵不只是你说的这些。限制下游销售作为软件组件集成的软件明确违反 OSD 第一条，直接就不是开源许可证。
相比之下，所谓专利授权，完全没同等排面。不授权专利的 permissive 许可证多得是，并不违反 OSD ，何来“最重要的一部分”？
顺便，也就是因为 SSPL 对 AGPL 修改的条款的模糊性，而不被认为是“开源”的：opensource.org/node/1099 ；这种修改涉及用途上的歧视，而被普遍抵制：www.infoq.cn/article/j8hogct5x_exxvf6cxve 。
到底是哪个垃圾碰瓷哪个就另说了。

[ssltest]

@FrankHB get #13

[Mithril]

@FrankHB 我想回答的是“这些常见的 License 是什么，有什么用”，并不关心某个 license 符合不符合 OSD 。
最常见的，在公司里，你去跟你司法务说专利授权不重要试试。
不是只有符合 OSD 的才是好东西，开源归开源，生意是生意。你想用人家的东西，就要遵守人家的 license 。不是说某个 license 不符合开源定义就可以不遵守的。

[FrankHB]

@Mithril OP 一开始就没说这个话题有意只关心具体许可证的作用。（看上去是无意遗漏的，所以我指出了这个问题。）
就常识来讲“程序员们都应该知道的各类开源许可证”的“知道”的前提首先是清楚“开源”，而不是“许可证”，后者是实现前者的手段。
如果要点如何实现事务性地合法，不需要加“开源”修饰。这样，分析具体开源许可证就不是重点了。即便如此，关注专利仍然不会比版权问题更重要，因为外行最常出现的只管拿来用的情况下，后者的问题几乎百分之百存在，而前者很大程度没有争议。
这些常识合格的法务也都清楚；如果你不确定，可以咨询你司法务。
所以，关于专利这样的其它问题，和 OP 说的内容没有直接关系。

即便有的开源许可证一并捆绑附带专利许可，这也只是一种补充。但须知，这也就是可选项，还不是业界一致同意的做法。
使用许可证捆绑权利声明的做法流行于美国。而在欧陆传统中，版权和其它专有权利向来就是分离授权的，所以有的作者甚至明确反对“许可证”这个形式本身，以避免暗示的适用法律错误： https://marc.info/?l=openbsd-misc&m=120618313520730&w=2 。
法务可没有理由因为自己只习惯美式风格，反对这种分离许可的实践而不干活。

[Mithril]

@FrankHB 就常识来讲，特别是你口中的“外行最常出现的只管拿来用的情况下”，是否符合纯粹的“开源”定义，并没有“许可”本身重要。
关注专利确实不会比版权问题更重要，在你考虑引入 FOSS 的时候，它们是同等重要的。如果你不确定，可以咨你司法务。
专利和 OP 说的内容直接相关，是因为有些许可证涵盖了专利授权，但大多数都没有。所以你在使用可能包含专利的第三方代码的时候，更要小心检查它的许可证。

[FrankHB]

@Mithril 在外行直接拿来用的情况下，版权法和专利法的默认条款会同等地自动生效而发生侵权风险。对这些法律的用户来讲，最优先了解的应该是这种机制，然后才能评估风险，保护自己和相关涉众的合法权益。

在 FOSS 的实践中，一般意义的许可是重要的，但是否涵盖在开源许可证中而不是单独的其它法律文件，是另一回事。即便不算侵权风险的相对多少，专利许可的必要性也不可能和版权许可相提并论。因为：
1.专利法的特性决定了它的适用情形严格比版权更加受限。例如，版权的授予基本是自动的，而不需要申请，而专利需要到专门机构申请公示。
2.专利在大多数人有生之年可以过期还可能被宣告无效，指望版权不起作用现在基本就得医学进步了。所以遗漏专利许可在时效上的负面影响比较短。
3.关于软件的专利先天有一些法理争议，保护的法益也不够明确。这导致专利的国际认可程度较版权低。有的管辖区（如新西兰）压根就不承认软件专利，法律适用时是不是有授权一个样。
4.专利授权的条款技术上比版权远远更麻烦。FOSS 中大量的缺乏专利授权的许可证大行其道甚至越来越流行，比如所谓的 MIT （不管是 X11 还是 expat flavor ），在微软等大型实体中都是首选，这是个重要原因。

这些问题不表示了解专利不重要，但也说明专利授权的实践被相当多数涉众认为不值得和以授予版权相关为主要目的的许可证的捆绑。
有趣的是，除了许可证条款技术复杂开销，一部分用户除了看来是为了排斥软件专利而故意忽略了专利许可，显示出一副爱用用不用润，专利问题与我无关的态度；至少在没有 DMCA 这样允许强制下架的法令下，这实际上仍然相当有效。这和 FSF 为了规避法律风险在 GPL 里的繁文缛节这样完全相反的实践出发点却可以说是相同的：否认软件专利的普遍合理性。

当然，也有相反的做法，比如 LLVM 切换许可证正是为了 Apache 的专利条款。不过并非所有人认为值得这样做，所以是否合适在普遍上仍然是个有争议的话题：
https://news.ycombinator.com/item?id=12617881

另一方面，仍有其它专有权利习惯上总是不被开源许可证捆绑，不论是否在美国。例如，许多 Linux 发行版的厂商（如红帽）通过单独的 EULA 等其它形式明确用户不得未授权使用商标。
这进一步说明，把版权捆绑在开源许可证上是个次要的实现问题。

当然，你可以说，OP 在《常见许可证及其差异》这里表述确实不充分，因为专利条款一些许可证之间的确实是一个比较显著的普遍差异。
但是，即便是评估 OP 的重要遗漏，技术（法律意义上）上仍然还有更优先的问题，这至少包括许可证兼容性和再许可(relicensing)。实践中这里的问题甚至经常比专利侵权的成本还大（毕竟大部分 FOSS 项目还不会有价值被盯上而不得不去应诉）。这些恰好又是开发者相对法务更容易解决的问题。
所以，以上种种问题说明，即便排除版权和专利侵权风险问题的差异，单就许可证来说，专利也难以称为“最重要的”事项。而特定于 FOSS 的个人贡献者，签署 CLA 之类的许可证以外的文件的意义往往是更加需要了解而时常被忽视的；不过这就似乎更加离题了。

[FrankHB]

typo：把版权捆绑在开源许可证上是个次要的实现问题→把专利权捆绑在开源许可证上是个次要的实现问题。

[Mithril]

@FrankHB 确实专利授权的限制比这些 license 更加严格。我之所以认为这个更为重要，是因为实践中这一点很难被法务审核出来。

现实中有 FOSSA 这类工具，可以提供兼容性审查，也可以提供列表给法务。只要法务定义好哪些能用，哪些不能用就可以审核出来了。对于决定引入 FOSS 的码农来说，即使遗漏某些内容也只是导致产品无法发布。

但某个开源库是否可能包含专利技术，引入这个库的码农比法务会更可能搞明白。比如一些复杂算法库，编码解码器，会比一个 log 工具库更可能触及专利问题。

另外如果你是个贡献者，那么当你给开源库贡献包含公司专利算法的代码的时候，Apache 和 MIT 还是有本质区别的。
这就是我为什么认为实践中，专利授权是在你引入 FOSS ，考虑其 license 时最重要的一点。确实你说的许可证兼容和再许可也很重要。

我发现了争执的点在哪里。
我是从一个 FOSS 使用者的角度考虑的，引入 FOSS 并使用，作品作为闭源软件或者服务分发。而你的角度是一个开源软件的开发者，所以你会优先考虑自己的开源作品使用的 License 是不是真的符合“开源”定义，引入 FOSS 的 License 是否兼容，是否能再分发。同时专利授权并不是很重要，大部分情况下即使你实现了专利保护的算法，也是你的用户需要考虑是否侵权。比如 FFMPEG 。

角度不同结论肯定不同，特别是哪些点更重要这种问题，争执这些也没什么意义。
不过至少明白了一个点：遇事不决找法务，法务搞不明白出了问题那也不是码农的错。

[FrankHB]

@Mithril 关键问题是，“法务”不一定存在。不存在法务正是有必要了解这里的问题的主要原因。

许可证首先为可能有权决策使用许可证的用户服务，最主要的就是版权持有者。
最常见的情况是版权持有者就是作者，能完全清楚自己决定什么权利。
这里还没有“法务”，于是作者自己就得全权负责。这种用户一般也不会得到外部的法律援助，因此是最需要清楚这里的问题的。
而首要问题是作为作者行使的权利。很少作者会同时具有申请专利的标的，也不会成为专利诉讼的目标，所以这不会是首要的问题。
虽然这些作者迟早需要理解专利问题，但这里有个先来后到。

法务是较大的版权持有者的代表，和其他大多数用户都不属于 OP 标题的“程序员”，因此我没有在这个角度上展开问题。
对受雇完成职业作品的程序员，首先应该了解雇主的政策。就行业惯例来讲，遵守专业法律人员参与制订的规则就已经足够。专利风险的审查由专人自上而下负责，基本不会由程序员兼职。除非有明确约定，汇报专利风险对程序员来讲不是职责更不是义务。

剩下的一种情况才是下游开发者中的项目负责人，也就是你所谓的用户。这种用户身兼程序员和法务的职责，同时需要负担开发和决策任务，特别是对他人被动作出法律担保，所以非作者权显得更加重要。
但是，这样的用户一般都是从独立的作者升级上来的，自己会有清楚的理解，所以不太会有这里的问题。

[chosen1cwp]

挺好奇，有网友发现，是咋发现的？