开源常见的问题和解决流程方法

当业务有国内、出海规范需求的时候一般会对开源组件有明确合规的要求,如文中所示:

1、开源信息整理

对项目中使用的每一个开源组件名称、版本号、下载链接地址，并确认是否对开源软件做出修改，是否对开源软件进行分发。
一般情况需要尽量保证提供的信息准确，开源软件使用的许可协议可能因不同版本而存在类型差异，因此开发团队需要提供准确的版本号，准确的下载链接，明确开源软件许可协议文件，以免在审核过程中出现问题。

2、怎样判断是否对开源软件构成分发？

以任何方式对外（譬如用户）提供开源软件，例如通过邮件、U盘、云、私有部署等使外部能够获得开源软件，即构成分发。通过SaaS等仅提供服务，而不提供开源软件的，则不构成分发。以下表格列明的场景可供开发团队参考。

3、对外分发开源软件应注意什么

对外分发开源软件应遵循各开源软件配套的许可协议，该等许可协议中要求遵守的义务可能包括在产品中应包含一份attribution文件（此文件经审核后由开源软件审核法务团队准备），指明开源软件的著作权归属，列明各开源软件应分别遵循的许可协议，公开开源软件的源代码、公开被修改的开源软件的源代码等。

4、如何规避LGPL协议许可的开源软件风险？

首先，LGPL协议的触发点是分发。也就是说，被许可人使用LGPL开源软件，但不对外分发LGPL开源软件或其衍生作品的副本，则不需要受到LGPL协议的约束。
其次，如果必须分发LGPL协议许可的开源软件，可以考虑使用动态链接的形式将LGPL开源软件与其他项目代码隔离，以规避LGPL协议的开源风险。
“动态链接”是指编译系统在链接阶段并不把传染型开源软件和其他软件链接在一起，各自代码处于不同的文件中，而是等到程序在执行时（Runtime）须要使用时才链接传染型开源软件。

5、如何规避GPL协议许可的开源软件风险？

首先，GPL协议的触发点是“分发distribute（GPL v2.0协议）”或“输送convey（GPL v3.0协议）”。也就是说，被许可人使用GPL开源软件，但不对外分发或输送GPL开源软件或其衍生作品的副本，则不需要受到GPL协议的约束。
其次，GPL协议并不会“传染”仅仅与GPL开源软件聚合在一起的独立程序，只要该程序本质不属于GPL开源软件的衍生，也未与GPL开源软件结合成一个更大的程序。也就是说，可以考虑不要将GPL开源软件和商业软件产品存放于共享地址空间，而通过管道（pipes）、套接（sockets）和命令行参数等方式达成独立程序之间的通信或调用，以此实现商业软件产品与GPL开源软件的隔离，避免商业软件产品被GPL协议传染，被迫开放源代码。

6、为什么不推荐在公司产品中使用AGPL或SSPL协议许可的开源软件？

AGPL和SSPL属于传染性极强的开源软件协议，根据协议约定的具体情形，均存在不分发即可能触发公开源代码要求的条款，其中SSPL的传染性较AGPL更强。对于AGPL组件，以提供网络服务为主的Google公司在内部也同样推行禁用的原则（https://opensource.google.com/docs/using/agpl-policy/ ）。

7、被列入出口管制清单的主体是否能继续使用开源软件？

根据《美国出口管制条例》（“EAR”）的规定，已公开发布，可免费下载，无加密软件的开源组件属于EAR定义的“公开发布软件（published software）”，不受EAR的约束，因此即便被列入出口管制清单的主体也可以使用该等开源组件。详细请参考一下列表：

加密开源组件的许可方向美国商务部工业和安全局（BIS）和美国国家安全局（NSA）进行申报备案

另外，即便被列入出口管制实体清单的主体可以使用“公开发布软件”，但针对该等公开发布软件的后续技术支持仍可被认为受EAR的约束，获取技术支持需要遵循EAR的审批流程。

8、常见注意组件与依赖

下列组件和库可能有多个版本的的开源协议，需要区分依赖于授权
FFmpeg
MongoDB
MariaDB和MySQL
Elasticsearch 和 Kibana
FDK-AAC
ijkPlayer
Qt组件
Confluent
TimescaleDB
CockroachDB
Grafana
Airtake