开源常见的问题和解决流程方法当业务有国内、出海规范需求的时候一般会对开源组件有明确合规的要求,如文中所示: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的约束，因此即便被列入出口管制清单的主体也可以使用该等开源组件。详细请参考一下列表：类型开源软件需要支付许可费/许可密钥开源软件涉及加密（encryption）组件需遵循EAR审批流程被列入出口管制清单的主体能使用吗？免费下载的开源组件否 / 进行商业应用需要另行支付许可费）否不需要可以 是加密开源组件的许可方向美国商务部工业和安全局（BIS）和美国国家安全局（NSA）进行申报备案可以 (许可方根据EAR要求申报备案就可以)设置限制条件下载的开源组件是否不属于EAR定义的“公开发布软件”，仍受EAR约束。使用该等开源组件需要遵循EAR的审批流程 是不属于EAR定义的“公开发布软件”，仍受EAR约束。 加密开源组件的许可方向美国商务部工业和安全局（BIS）和美国国家安全局（NSA）进行申报备案 另外，即便被列入出口管制实体清单的主体可以使用“公开发布软件”，但针对该等公开发布软件的后续技术支持仍可被认为受EAR的约束，获取技术支持需要遵循EAR的审批流程。8、常见注意组件与依赖下列组件和库可能有多个版本的的开源协议，需要区分依赖于授权FFmpegMongoDBMariaDB和MySQLElasticsearch 和 KibanaFDK-AACijkPlayerQt组件ConfluentTimescaleDBCockroachDBGrafanaAirtake
最近在优化业务在国内外合规问题，并整理了所有依赖包的开源协议，顺便讲开源协议的规则共享一份。常见两类开源开源协议上百种。常见的开源许可协议主要有 Apache、MIT、BSD、GPL、LGPL、MPL等，可以大致分为两大类：宽松型开源许可协议和传染型开源许可协议。宽松型其中宽松型开源许可协议有Apache、MIT、BSD；协议说明1、BSD（二条款版）分发软件时，必须保留原始的许可证声明。2、BSD（三条款版）分发软件时，必须保留原始的许可证声明。不得使用原始作者的名字为软件促销。3、MIT 分发软件时，必须保留原始的许可证声明，与 BSD（二条款版）基本一致。4、Apache 2 分发软件时，必须保留原始的许可证声明。凡是修改过的文件，必须向用户说明该文件修改过；没有修改过的文件，必须保持许可证不变。基本特点:1、没有使用限制。用户可以使用代码，做任何想做的事情。2、没有担保。不保证代码质量，用户自担风险。3、披露要求（notice requirement）用户必须披露原始作者。传染型传染型开源许可协议有GPL 、LGPL、MPL。协议说明1、Affero GPL (AGPL) 如果云服务（即 SAAS）用到的代码是该许可证，那么云服务的代码也必须开源。2、GPL 如果项目包含了 GPL 许可证的代码，那么整个项目都必须使用 GPL 许可证。3、LGPL 如果项目采用动态链接调用该许可证的库，项目可以不用开源。4、Mozilla（MPL） 只要该许可证的代码在单独的文件中，新增的其他文件可以不用开源。区别：1、GPL 开源授权协议的库开发的软件，也必须要开源；GPL允许用户使用、修改和分发软件，只要他们提供访问源代码权限和他们所做的任何更改。 但是 GPL 并不要求仅通过网络与软件交互的用户共享其源代码。2、AGPL 是 GPL 的扩展，包括对与软件交互的用户的附加要求 通过网络软件。 这些用户还必须共享他们的源代码和他们对软件所做的任何更改。这意味着如果您使用 AGPL 许可的程序并在您的服务器上运行它并通过网络将其提供给其他人，您还必须 这些用户可用的源代码。 这在 GPL 下不是必需的。简而言之，AGPL 是比 GPL 更严格的许可，因为它要求用户在通过网络使用软件时共享他们的源代码。3、基于 LGPL 开源协议的库开发的软件，视是否只是调用来看，如果只是连接、调用，则可以封闭源代码，否则也必须要开源。其他类型此外如：SSPL等，还有存在目前无法分类的情况：SSPLMongoDB 再2018 年 10 月 16 日创建的一个新许可证SSPL。这个是官方修改开源协议（从 AGPL 到 SSPL，基于修改协议前的最后一个稳定版本4.0.3），存在较大争议，开放源代码促进会 OSI 甚至认为 SSPL 就不是开源许可协议。cc还有一类是 Creative Commons(CC)知识共享协议。严格意义上说该协议并不能说是真正的开源协议, 它们大多是被使用于设计类、在线文档、博客文章的工程上。CC 协议种类繁多, 每一种都授权特定的权利。主要包含：作者可声明得权益署名（Attribution，简写为by）：必须提到原作者;非商业用途（Noncommercial，简写为nc）：不得用于盈利性目的;禁止演绎（No Derivative Works，简写为nd）：不得修改原作品;相同方式共享（Share Alike，简写为sa）：如果允许修改原作品，那么必须使用相同的许可证发布;使用者可获得权益复制作品；散发作品；公开展示或表演作品；将作品完全一致地转化成另一种格式。阮一峰的博客文章对CC有更完善得说明。谈谈创作共用许可证（Creative Commons licenses）如果是大陆地区一般使用 CC 2.5 或 cc 3.0的声明开源协议选择1) 如果您想为GPL世界添砖加瓦，或者项目引用了GPL许可证的模块，那么当然得使用GPL许可证；2) 如果您想分享自己的编程心得，不想让许可证限制了知识的传播，这时可使用MIT许可证；3) 如果您想更强的控制源代码，或者考虑商业化，那么推荐Apache许可证。4) 如果是文章文档类一般选择cc协议MIT是约束最少的, GPL是约束最多的; 如果是个人随意作品，建议MIT许可; 如果是公司或者需要严格保护，建议 GPL。https://choosealicense.rustwiki.org/ 这个网站可以指导开发者选择一个适合的协议开源合规1、主要是开发者、企业在使用、修改、分发、商业化等方面了解各个软件的开源协议。2、避免开源软件不同开源协议带来的法律风险、公关危机与安全隐患等问题。3、了解开源风险的典型案例，对开源风险的防控措施能提前准备。开源协议相关事件1、mysql 被 Oracle 收购后变更开源协议，支持GPLv2 许可证 和 商业许可证，由此也衍生出了多个mysql版本：MariaDB (mysql 5.1的衍生)、Percona Server、MepSQL、Drizzle、OurDelta等。相关文章说明。2、core-js 决定更改开源协议. 2023-2-14 github readme3、ffmpeg 中的gpl、lgpl开关 编译参考ffmpeg 有大量可选依赖，很多依赖和 ffmpeg 的 lgpl 协议并不兼容，有的是 gpl ，有的甚至是 nonfree ，GPL版有x264和x265，LGPL版没有，按需选择。默认FFmpeg的configure编译是不带GPL部分代码的，我们可以基于FFmpeg的库进行第三方程序的开发而不需要开源。但是如果我们修改了FFmpeg的部分代码，则需要开源这部分代码。参考文献：《description software licenses》 https://paulmillr.com/media/posts/simple-description-of-popular-software-licenses/open-source-licenses-en.png《GNU General Public License (GPL)》. http://www.opensource.org/licenses/gpl-license《详细介绍 GPL 协议》. 红薯, 2009-11-30. http://www.oschina.net/question/12_2826《The MIT License (MIT)》. http://www.opensource.org/licenses/mit-license.php《详细介绍 MIT 协议》. 红薯, 2009-11-30. http://www.oschina.net/question/12_2829《Apache License, Version 2.0》. http://www.apache.org/licenses/LICENSE-2.0《详细介绍 Apache Licene 2.0 协议》. 红薯, 2009-11-30. http://www.oschina.net/question/12_2828《The BSD 3-Clause License》. http://opensource.org/licenses/BSD-3-Clause《The BSD 2-Clause License》. http://opensource.org/licenses/BSD-2-Clause《详细介绍 BSD 开源协议》. 红薯, 2009-11-30. http://www.oschina.net/question/12_2825《如何选择开源许可证？》. 阮一峰, 2011-05-02. http://www.ruanyifeng.com/blog/2011/05/how_to_choose_free_software_licenses.html《开源许可证教程》. 阮一峰, 2017-10-11. https://www.ruanyifeng.com/blog/2017/10/open-source-license-tutorial.html《9个主流的开源许可协议[整理]》. Univasity, 2011-12-05. http://univasity.iteye.com/blog/1292658