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

2022-03-22 11:19:34 +08:00
 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 两类常用编程语言的开源组件许可证分布进行统计,可以发现:

开源许可证在标准化

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

4018 次点击
所在节点    程序员
23 条回复
Mithril
2022-03-25 22:45:33 +08:00
@FrankHB 确实专利授权的限制比这些 license 更加严格。我之所以认为这个更为重要,是因为实践中这一点很难被法务审核出来。

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

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

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

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

角度不同结论肯定不同,特别是哪些点更重要这种问题,争执这些也没什么意义。
不过至少明白了一个点:遇事不决找法务,法务搞不明白出了问题那也不是码农的错。
FrankHB
2022-03-27 15:34:07 +08:00
@Mithril 关键问题是,“法务”不一定存在。不存在法务正是有必要了解这里的问题的主要原因。

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

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

剩下的一种情况才是下游开发者中的项目负责人,也就是你所谓的用户。这种用户身兼程序员和法务的职责,同时需要负担开发和决策任务,特别是对他人被动作出法律担保,所以非作者权显得更加重要。
但是,这样的用户一般都是从独立的作者升级上来的,自己会有清楚的理解,所以不太会有这里的问题。
chosen1cwp
2022-03-28 16:22:58 +08:00
挺好奇,有网友发现,是咋发现的?

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/842052

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX