开源文化与认知

第一节 - 开源软件的定义和它的发展历程

1.1 开源软件的三大组成要素

开源软件是一种源代码免费向公众开放的软件，任何团体和个人都可以在其 License 规定下对其进行使用、复制、传播及修改，并将修改形成的软件衍生版本再发布。（来源于 OSI 开源软件定义 [1]）

开源软件的六大特点：

  1. 有特定的 License
  2. 可获得源代码
  3. 无许可费
  4. 无任何担保
  5. 可自由使用
  6. 享有版权

目前较为活跃的开源维权组织：

  1. 开源促进委员会（Open Source Initiative，OSI）（https://opensource.org）

    OSI 一直致力于提高对开源软件的认识和采用，并在开源实践社区之间架起桥梁。作为一个全球性的非营利组织，OSI 通过教育、协作和基础设施，管理开源定义（OSD），并防止滥用开源运动固有的理想和精神，在社会中倡导软件自由；

  2. FSF 自由软件基金会（https://www.fsf.org）

    自由软件意味着用户可以自由地运行、编辑、贡献和共享软件；

  3. Software Freedom Law Center（https://softwarefreedom.org）

    软件自由法律中心为免费、自由和开源软件的开发者提供无偿的法律服务。

1.2 开源推动着各领域发展

  • 萌芽期（1969-1990）主要由个人和大学发起 [2]
  1. 1971 年，作为哈佛大学的新生，Stallman 就开始在麻省理工学院（MIT）的人工智能实验室（后来的计算机科学与人工智能实验室）工作，他和 James Gosling 一起用 C 语言编写了 Emacs 文本编辑器。
  2. C 语言是美国计算机科学家 Dennis M. Ritchie 在 1969 - 1973 年与 UNIX 操作系统的早期开发一起设计的 计算机编程语言。该语言基于 CPL（组合编程语言），由美国计算机科学家 Ritchie 及其同事 Ken Thompson 于 1969-1970 年创建，首先被浓缩成了精简的 B 编程语言。之后，Ritchie 重写并恢复了 CPL 的功能创建了 C 编程语言并重写了 UNIX 操作系统。
  3. 1984 年，因担心 MIT 软件版权发生规则变化，Stallman 离开了麻省理工学院，并于次年创建非营利性自由软件基金会，专注于为 GNU 项目提供支持。
  4. 1990 年，获得麦克阿瑟奖学金，被誉为“天才奖”。该奖项帮助 Stallman 为 GNU 项目编写各种实用程序，例如 GNU Emacs 编辑器、GNU 编译器和 GNU 调试器。这些工具后来与芬兰计算机科学专业学生 Linus Torvalds 开发的内核相结合，制作了 1994 年的操作系统 GNU/Linux。
  • 成型期（1990-2005）非盈利组织（基金会）
  1. Linux 基金会 [3] ：成立于 1991 年 10 月 5 日，是一个基于 Linux 内核的免费开源操作系统家族。基于 Linux 的操作系统被称为 Linux 发行版或发行版。
  2. Apache 软件基金会 [4] ：成立于 1999 年 3 月 25 日，是一个专注于支持开源软件项目的非营利性组织。在它所支持的 Apache 项目和子项目中，所发行的软件产品都遵循 Apache License。
  3. Eclipse 基金会 [5] ：成立于 2004 年 2 月 2 日，旨在为个人/组织的全球社区提供成熟、可伸缩、业务友好的开源软件协作和创新环境。
  • 快速发展期（2005-至今）
  1. 目前，各行各业的现代企业、大型 IT 企业都参与到开源中。Intel、IBM、Google 等企业均贡献了许多开源项目，如 OpenStack、Cloud Foundry、Kubernetes 等，包括华为的 openEuler、MindSpore 等项目都在创新引领着技术和商业的发展。现如今，开源软件已不再是单纯的个人业余爱好，而是企业间角逐商业利益和开放标准的战场。

第二节 - 开源不等于免费

2.1 开源≠免费

  • 经典案例：Cisco 产品因 GPL 传染遭开源维权诉讼！最终向 FSF 捐款数千万美金！[6]
  1. Broadcom 在其 802.11 芯片中使用了 GPL 的 GUN/Linux 系统，Linksys WRT 54G 无线路由器使用了 Broadcom 的芯片，2003 年 Cisco 收购 Linksys 但未按照 GPL 规定将使用了该芯片的产品代码开源。
  2. FSF 于 2003 年开始与思科就该问题进行沟通，并帮助该公司了解其许可义务。当时，思科承认了自己的错误并陆续开放了 116 个型号路由器的源代码，但仍未达到 FSF 的要求。
  3. 2008 年，FSF 与 Cisco 之间的谈判破裂，FSF 对该公司提起了 GPL 侵权诉讼。
  4. 截至 2008 年，Cisco 依然拒绝开放所有相关源代码，FSF 与 cisco 谈判破裂，FSF 于同年 12 月 12 日对该公司提起了 GPL 侵权诉讼，Cisco 作出让步并根据 GPL 规定对开放源码进行调整。
  5. 2009 年 5 月 20 日，FSF 与 Cisco 达成和解，使用 FSF 软件的 Linksys 产品开放全部源代码。
  • 虽然开源软件使用者享有自由使用的权利，但其必须按照 License 的规定履行相应的开源义务，否则即违反了开源 License
  1. 使用声明义务：在对外分发产品时，需附上声明文档，注明产品所使用的开源软件名称、版权、License 内容等信息。
  2. 代码开源义务：将一定范围内的代码对公众开放，开源范围视具体 License 的要求和产品具体使用方式而定。

第三节 - 开源 License 合规风险

3.1 不同 License 约束内容的区别

以下 8 种 License 覆盖了开源软件中 90% 以上的代码，采用这些 License 的开源软件在业界应用也最为广泛；其中 GPL V2 对于开发者和二次开发者的义务要求最多，在使用时需加以关注。

类别典型项目许可证注意事项应用建议
BSD类Apache V2.0ACE Tomcat1、允许各种链接，无开源义务 2、允许修改，无开源义务 3、软件所有人授予专利许可商业友好型许可证
BSD类BSDFreeBSD1、允许各种链接，无开源义务 2、允许修改，无开源义务 3、无专利规定商业友好型许可证
BSD类MITASN.11、允许各种链接，无开源义务 2、允许修改，无开源义务 3、无专利规定商业友好型许可证
MPL类CPL V1.0JUnit1、允许各种链接，无开源义务 2、允许修改，但修改部分需要开源 3、截取部分或全部开源代码与私有源代码混合将视为对原始软件的修改，从而导致私有代码开源 4、软件所有人授予专利许可需关注修改后对应的开源义务
MPL类MPL V1.0FireFox1、允许各种链接，无开源义务 2、允许修改，但修改部分需要开源 3、截取部分或全部开源代码与私有源代码混合将视为对原始软件的修改，从而导致私有代码开源 4、软件所有人授予专利许可需关注修改后对应的开源义务
MPL类CDDL V1.0OpenSolaris1、允许各种链接，无开源义务 2、允许修改，但修改部分需要开源 3、截取部分或全部开源代码与私有源代码混合将视为对原始软件的修改，从而导致私有代码开源 4、软件所有人授予专利许可需关注修改后对应的开源义务
GPL类LGPL V2Jboss ml、 OpenOffice、UcLibc、SDL1、允许各种链接，动态链接无开源义务，静态链接需要开放与之链接私有软件的 .o 文件和 makefile. 2、允许修改再链接到私有软件，但修改增加的功能实现不能依赖私有软件的数据或功能 3、允许不受限制的使用头文件中的 numerical parameters（数值参数）、data structure layouts（数据结构布局） and accessors（存取）、or small macros（小宏）、inline functions（内联参数） and templates (ten or fewer lines in length)（十行以内的模板） 4、仅原则性声明专利应免费许可，无详细规定只允许动态链接方式使用
GPL类GPL V2Linux1、允许各种链接，但被链接的整个产品需要开源 2、允许修改，但被修改部分及整个产品均需开源 3、通过 pipes、sockets 和命令行参数与 GPL 软件进行通信，不会导致私有软件被传染 4、仅原则性声明专利应免费许可，无详细规定可能导致产品整体负有开源义务

3.2 “宽松”型 License ? 小心有坑！

  • 开源 License：所有开源软件都有其特定的 License，法律赋予用户相关权利和义务，任何开源应用行为都必须围绕此“游戏规则”进行。

    1. 权利：授予用户免费使用、修改、分发、商用等权利，包含版权授权，部分还有专利授权；
    2. 义务：规定用户在应用开源过程中必须履行的义务，如做出特定声明、开放特定代码等。

  • 案例：

    1. Facebook 在 Github 上发布了一系列开源项目，其中如 React（https://reactjs.org/）、Fresco （https://frescolib.org/）等，凭借先进的技术和宽松的 License（BSD），其项目广受用户欢迎；
    2. Facebook 除 BSD License 外，还额外增加了一份专利授权 License，将这些软件可能存在的 Facebook 专利授权给用户使用，但也正是这份专利 License，为这些软件的商业应用埋下了“地雷”，Apache 基金会甚至禁止 Facebook 的软件或代码进入 Apache 项目。

  • 解析：Facebook 的专利授权 License 除了授予用户使用其专利的权利外，还增加了对 Facebook 的专利保护条款，即如果 A 公司使用了该软件，如果 Facebook 在其业务范围内与 A 公司有任何其他专利冲突，A 公司均不得向 Facebook 发起诉讼保护自身的专利。[7]

  • 启示：

    1. 某些开源项目表面声明的 License 看似“宽松”，但可能潜藏风险，产品在引入开源软件时应获取其完整的 License；
    2. 若无法确定 License 风险，可先向企业法务部咨询，由法务部评估风险后再决定是否引入。

第四节 - 开源安全风险

4.1 开源社区安全

  • Linux [8]

  1. 项目诞生（1991）

  2. 支持 SELinux（2003）[9]

    安全增强型 Linux（SELinux）是一种采用安全架构的 Linux® 系统，它能够让管理员更好地管控访问系统的人员清单。最初由美国国家安全局（NSA）利用 Linux 安全模块（LSM）开发，用作 Linux 内核的一系列补丁。

  3. Syzkaller Fuzz关键（2016）[10]

    Syzkaller 是一个无监督的覆盖引导的内核模糊器。Linuxkernel fuzzing 的支持最多，akaros , freebsd , fuchsia , netbsd 得到 windows 不同程度的支持。

  4. KSPP 安全项目（2017）[11]

    为了让 Linux 内核本身具有对漏洞利用的防御能力，通过参考 PaX/Grsecurity 的实现来移植或重新实现类似的功能，并将其推进到 Linux 内核主线。

  5. Sigstore 签名服务（2021）[12]

    Sigstore 是由 Google，Red Hat 和 Purdue University 支持的 Linux 基金会项目，旨在通过便捷的加密软件签名提升软件供应链的安全性。

  • ASOP（https://asop.org/）
  1. 项目诞生（2008)
  2. 漏洞致谢（2009）
  3. 支持 SEAndroid（2014）
  4. 原生支持 Fuzzing（2017)
  5. 奖励开源软件安全研究（2019）

业界主流社区正逐步从单点安全特性向整体安全架构、供应链安全和安全基础设施等系统化建设方向发展。围绕开源件健康度和依赖度评估、漏洞感知与修复等系统化建设，是供应链安全发展的关键。

  • 开源软件存在的安全薄弱点：
  1. 缺少安全 Metadata（缺乏文档、LICENSE、反馈渠道、维护状况等）；
  2. 未做到默认安全（使用不安全的加密算法、协议、设计等）；
  3. 软件依赖链不明确（较难获知依赖链的安全状况）。
  • 开源软件漏洞风险：
  1. 漏洞库信息缺乏；
  2. 代码质量参差，存在漏洞风险。
  • Google 安全实践：
  1. 2020 年布局 OpenSSF 社区 [13]（https://openssf.org/），构建开源社区安全能力量化评估体系；
  2. 2021 年发布 OSI（Open Source Insights: https://deps.dev/）, 建立开源软件依赖链信息库；
  3. 2021 年发布 OSV（Open Source Vulnerabilities: https://osv.dev/），建立开源软件漏洞信息库，支持开源版本漏洞查询,开源的分布式漏洞数据库，一种用于生成和使用开源漏洞信息的开放、精确和分布式方法；
  4. 发布 OSS-Fuzz（https://github.com/google/oss-fuzz），平台及 Patch 奖励项目，提供 Fuzz 算力和修复资源，增强开源软件漏洞挖掘力量。

4.2 网络安全：OpenSSL 心脏滴血事件影响之大！

  • 心脏滴血已经是过去式了吗？NO！

    尽管许多网民在漏洞披露后都纷纷更新软件以修复该漏洞，但事隔一年多，臭名昭著的“心脏滴血安全漏洞”并未完全消失，其仍对近 20 万台网络设备存在安全威胁。大量设备未更新补丁，仍可被攻击！ Shodan 创始人 John Matherly 在 Twitter 上发布了一张地图，上面列出了全球范围内仍受到该安全问题影响的国家：美国有 57272 台存在心脏滴血漏洞的设备，位居第一；德国 21060 台；中国 11300 台；法国 10094 台；英国 9125 台。

    安全顾问 Graham Cluley 指出：“很显然，有些制造商和 IT 团队并没有更新存在漏洞的系统。我敢打赌，肯定有些联网设备存在心脏滴血漏洞。” Matherly 指出，管理员们可以利用 Shodan 搜索工具检查它们的联网设备是否仍然存在心脏滴血漏洞。除了更新 OpenSSL 之外，管理员们还可以采取更进一步的安全措施：更改密钥、转储会话 cookies。

  • 开源安全漏洞传播速度快、影响大，快速排查并修复受影响的产品是降低影响的关键。

  • HeartBleed 漏洞概括：

  1. 2014 年，心脏滴血首次被发现，由于该漏洞允许攻击者利用 OpenSSL 软件库中的安全漏洞窃取目标设备上的密码等敏感信息，引发诸多恐慌。
  2. Heartbleed 漏洞是由于在 memcpy () 调用受害用户输入内容作为长度参数之前，未能正确进行边界检查，攻击者通过追踪 OpenSSL 所分配的 64 KB 缓存，将超出必要范围的字节信息复制到缓存中，再返回到缓存内容，从而使受害者的内存内容以 64 KB/次的速度进行泄露。

4.3 网络安全： Log4Shell漏洞影响面之广！

  • 案例：2021 年 11 月 24 日，在 Web 服务器软件阿帕奇（Apache）下的开源日志组件 Log4j 2.x 内发现漏洞，这个后来编号为 CVE-2021-4428 的漏洞花名为 Log4Shell。这一漏洞的存在，可以让网络攻击者无需密码就能访问网络服务器。网络安全管理公司 Cloudflare 首席安全官乔·沙利文（Joe Sullivan）表示，该漏洞允许恶意攻击者“远程执行代码”以获取对其他系统的访问，鉴于 Log4j 软件被广泛使用，这可能是迄今为止“最大的漏洞”。

  • 启示：

  1. 识别产品中正在使用的关键开源项目；
  2. 大规模使用开源软件的公司对开源软件要谨慎选择、持续维护。

第五节 - 开源治理构建基础能力

5.1 开源治理方法论

5.1.1 开源应用不当会导致的问题

主要考虑开源软件特点会带来的问题
License部分开源软件 License 强调回馈社区不遵守其 License 会被投诉甚至起诉。迄今相关纠纷超过百起，最严重的情况为侵权方被判停止销售侵权产品。
安全部分开源软件存在安全漏洞开源软件安全漏洞相对透明，传播快，影响大。
专利权开源软件的合作开发模式需要处理好不同开发者的知识产权问题开源软件领域知识产权纠纷的频频发生，如果将一些流行的私有软件代码公开，追溯知识产权的归属，也一定难逃诉讼。
采购开源软件应用十分广泛，外购软件也可能应用开源软件产品外购软件可能存在违规使用开源软件的风险，采购时需加于关注。
维护成本活跃开源软件更新很快，且将代码放入主版本需要技巧若自行修改了开源软件，就可能形成“私有开源代码”，需自行维护全部开源代码，成本极高。
保障社区不承诺技术支持职责需有外部或者内部团队掌握相关关键技术及获取社区技术支持的技能，否则将面临缺乏技术支撑保障的风险。

5.1.2 使用开源最基本要求：安全可信、合法合规

  1. 开源软件获取来源可信
    • 开源软件获取到来源需要从社区官网、供应商官网或开发商官网
    • 由供应商或合作企业提供的开源软件需要确认来源、版本、更新频率和更新方式等
    • 开源软件有明确的许可证或和供应商、合作企业签订有相关使用协议以及其他相关协议，确保软件使用的责任和权利是合法的
  2. 开源软件的网络安全可靠
    • 对开源软件的网络安全进行充分的评估，确认其安全性是在企业、产品的可控范围内
    • 对开源软件的漏洞处理能力进行评估
    • 对开源软件的漏洞收集、分发、处理、预警设计完整的流程
  3. 使用开源软件合法合规
    • 按照开源软件使用按许可要求，避免知识产权、License 带来法律风险
    • 如果使用供应商或合作伙伴提供的开源软件，要在合同上具有明确的授权才能使用，避免合同上没有明确授权，导致软件使用风险
  4. 企业内部使用开源软件过程透明
    • 使用开源软件化的企业，都应该在使用过程中明确告知开发商、供应商、合作伙伴等相关人员，避免使用开源软件的风险
    • 所有使用开源软件化的企业，需要在企业内部建立完整的使用流程，包括开源软件中央仓库，对于开源软件的使用需要管理，有修改记录可查
    • 对于开源软件的漏洞 E2E 需要 E2E 闭环管理

5.1.3 来源可信：植入木马案例

  • 案例：非官方 Xcode 被植入恶意代码

    这是一起发生于 2015 年 9 月的事件，起初大家以为只是个别开发者使用了非官方渠道下载的 Xcode，导致开发的应用编译出来含有恶意代码，并未引起大家的注意。 然而，事情绝非大家想象的那么简单。Appstore 中的很多应用相继检测出了恶意代码，其中包含：微信、网易、12306 等。虽然恶意代码的行为并不复杂，但其传播方式却非常独特。

    图灵奖获得者 Keen Thompson 一语成谶：看你还敢用网盘上共享的编译器！

  • 启示： 必须从官方渠道获取开源版本，使用前确保其来源可靠。

5.2 选择开源软件需要的考虑的因素

如何选择开源软件以满足企业的开发产品和平台需求？可以从以下几个方面加以考虑：

  1. 开源项目的功能是否满足产品的需求满足度
  2. 开源许可证是否满足产品分发和销售的要求
  3. 开源项目的技术是否领先
  4. 开源项目的软件成熟度如何（可参考 CHAOSS https://chaoss.community 基金会对开源项目的评估）
  5. 开源项目的运维能力，如何保证项目的可用性？
  6. 开源项目是否存在商业支持
  7. 开源项目的社区活跃度
  8. 开源项目对 Issue、CVE 的响应时间
  9. 开源项目是否存在健康的软件生态
  10. 是否需要对开业软件的社区旅行贡献义务
  11. 开源软件是否有第三方服务商提供商业支持

5.2.1 优选引入：以 XML 类软件选型为例

  • 从官网获取软件版本基本信息

    注意：是官网，不是代码托管网站（Maven/Pypi/Cargo 等代码托管网站并不是官网）

软件名称tinyxml2libxml2PugiXMLXerces-C++
语言C++CC++C++
最新版本7.0.12.9.9v1.93.2.2
最新版本发布时间2018/11/182019/1/42018/4/42018/3/14
官网http://leethomason.github.io/tinyxml2/http://xmlsoft.org/http://pugixml.org/http://xerces.apache.org/
Github/代码库https://github.com/leethomason/tinyxml2https://github.com/GNOME/libxml2https://github.com/zeux/pugixmlhttp://svn.apache.org/viewvc/xerces/c/?root=Apache-SVN
  • 分析开源软件 License
  1. 如果遇到 GPL 等高危 License，优先找商业友好 License 的替代软件
  2. 对于多 License 软件，需要解包进行 License 分析
  • 从漏洞、补丁的可获得性分析软件网络安全特征
  1. 从 NVD 漏洞库查询软件版本历史漏洞信息，检查备选版本是否有未修复的高危漏洞
  2. 看官网是否给出漏洞披露渠道，漏洞披露渠道不明确的不建议引入

  • Libxml2 提供完整的 bug 及漏洞披露跟踪页面

  • TinyXML2 仍有未修复的漏洞

  • 从软件活跃度看生命周期

  1. 处于研发衰退的阶段：
    • 无新 LTS 版本，或 2 个 minor 历史发布周期内无新 minor 版本发布
    • 代码几乎无增长，仅有少量开发者，没有新的 Maintainer 加入社区维护版本

5.3 License 遵从

5.3.1 开源使用声明义务

在对外分发或销售产品时，需附上声明文档，注明产品所使用的开源软件名称、版权、License 内容等信息。

  • 开源使用声明内容
    1. Software: 软件名称+软件版本号
    2. Copyright notice: 软件版权信息 （软件包中版权或说明文件/官网/代码文件头）
    3. License: 软件 License 信息（包含具体内容）

开源软件声明

  • 发布原则：随外软件的分发， 且显而易见。必须遵守“易于获取”原则，即能够让用户较为容易地获取查看声明文档的全量内容，实际发布方式由产品根据自身情况确定。

  • 代码要约文本（Written offer）：若产品涉及代码对外开源义务的履行（如使用了 GPL、LGPL 等具有对外开源义务的软件），必须在使用声明中附上代码要约文本。

  • 软件版权信息 Copyright notice: Copyright© 1999-2004 busybox project. Copyright (c)

5.3.2 代码对外开源义务

常见 License 代码开源要求：

常见许可证类型典型软件触发代码开源义务前提条件开源要求和范围
BSD 类 如：Apache/BSD/MIT 等Tomcat、OpenSSL无无
MPL 类 如：MPL/EPL 等FireFox、Eclipse1、产品集成使用该软件，并对外分发或销售 2、产品对该软件进行了修改1、若无修改，则无需开源； 2、若对其进行了修改，需将修改的部分开源。
LGPLHibernate、glibc产品集成使用该软件，并对外分发或销售1、软件本身须开源； 2、具有传染性，静态链接部分的代码必须以 LGPL 许可开源，动态链接不被传染； 3、若对其进行修改，修改后增加的功能实现依赖于产品软件的数据或功能，则产品代码也会被传染。
GPL（GPLV2，GPLV3）Busybox、linux kernel产品集成使用该软件，并对外分发或销售1、软件本身须开源； 2、具有传染性，与其有链接关系的代码都必须以 GPL 许可对外开源，即与该软件在同一进程中运行的代码都必须开源。
AGPLBerkeley_DB产品集成使用该软件即便不对外分发，只要在网络服务器上使用 AGPL 软件提供网络服务，就需要履行相关开源义务。 例如：Berkeley_DB，即使没有“分发”动作，通过 WEB 形式为用户提供服务，也要履行对外开源义务。

  • 除 AGPL License 外，是否履行代码开源义务均与产品是否对外分发强相关。若产品需对外分发，则必须履行开源义务，反之亦然。

  • 部分产品中还集成了来自供应商的软件，若供应商软件中也使用了开源软件，产品应向供应商获取相应开源软件清单以及相关代码，以确保产品能对下游用户履行代码义务。

5.3.3 开源多 License 分析

  • 文件 LICENSE.txt 明确 License 可二选一：如 SJCL
  • 官网 LICENSE.txt 明确 License 唯一：如 cJson
  • License 文件明确不同的文件夹使用不同的 License：如 e2fsprogs，产品仅使用了 libdw 和 libelf，所以 License 是 GPL 2.0。

5.3.4 开源使用声明义务案例

  • **案例：**2015 年，德国开源维权人 McHardy 向多家 Android 手机厂商发起开源维权，涉案企业包括三星、MOTO、中兴等，赔款金额达数百万欧元，维权理由之一就是以上厂商销售产品时没有正确履行使用声明义务。[14]

  • **解析：**涉案的 Android 手机都使用了 Iptables 软件，其 License（GPL）明确要求分发者履行使用声明义务，但涉案手机的使用声明文档中并没有包含 Iptables 的声明。

  • 启示：

  1. 几乎所有可商用的开源软件 License 都具有开源使用声明义务要求。
  2. 涉及对外分发销售的产品中若使用了开源软件，必须在分发时使用声明文档中全量声明，不得缺失。

5.3.5 代码对外开源义务案例

  • **案例 1 ：**2009 年，SFC 代理 busybox 社区起诉三星、百思买等 14 家公司，指控其生产的电视、DVD 播放器等产品违反了 GPL 协议，法院首次下达开源软件禁令，涉案产品被禁售。[15]

  • **解析：**涉案产品都使用了 Busybox 软件，但企业并没有按照 GPL 义务要求开放相应源代码，因此违反了 GPL v2 协议。

  • 启示：

  1. 产品在引入开源软件时，应明确其是否有开源义务要求，评估产品履行能力后再使用，并在发布前做好开源准备；
  2. 一旦发生开源维权诉讼，企业往往是弱势方，多为败诉/赔款和解收场，甚至会导致产品被禁售。

  • **案例 2 ：**2016 年，著名开源维权人 Harald Welte 向某公司索取某产品的开源代码，但该产品自身并未引入任何开源软件。经排查发现，该产品集成的某供应商软件中使用了 GPL 开源软件，经过一系列交涉，花费了大量的时间、人力，才从供应商处获取到相应的代码提供给维权人。

  • **解析：**若产品集成的供应商软件中包含了开源软件，产品作为再次分发方，也必须履行相应开源义务。

  • 启示：

  1. 产品在引入供应商软件时，在合同中需明确开源义务履行保障条款（对于免费软件则推动供应商签署补充协议），确保供应商能够履行开源义务。
  2. 产品在发布前应向供应商索取开源软件清单与相应代码（若有强制开源义务），保证产品能够完整履行开源义务。

5.4 过程透明

5.4.1 建立结构化开源软件 SwBOM 是解决来源可靠、可追溯和漏洞管理的基础

通过软件的 BOM（Bill of Material），也就是软件清单（SBOM）。

SBOM：软件中的组件列表。软件供应商通常通过组装开源和商业软件组件来创建产品。SBOM 描述了产品中的组件，类似于食品包装上的成分清单，通过一整套可追溯缺陷跟踪系统来实现。

  1. 跟踪软件或开源组件里的漏洞：哪个产品使用了开源软件、哪些漏洞影响了产品，甚至哪些客户感受到了漏洞。整个链条上的元素都可以在该追踪系统里展现，帮助开发者快速、及时地修复漏洞，识别合规风险；
  2. 分析软件嵌套：通过软件分析有多少包以及包与包之间的依赖关系，并反推出它是怎样的软件。

5.4.2 建立从开源漏洞发现到客户升级的漏洞E2E处理流程机制，确保漏洞及时被修复

通过漏洞追踪系统，包括舆情感知系统帮助发现漏洞。发现漏洞后，应急响应团队应第一时间在满足 SLA 的情况下修补漏洞，并和客户一起发布漏洞处理方案及影响范围，帮助客户尽快解决相应的安全风险。

5.4.3 企业如何修复开源软件漏洞

开源软件漏洞通过缺陷单跟踪处理，根据漏洞的风险等级，企业依据合同对漏洞修复的相应 SLA 要求进行修复。

  1. 基于对客户的承诺，企业产品在研发阶段需划分漏洞风险等级，便于漏洞管理策略的制定。例如，企业可以要求高风险开源软件漏洞（CVSS>=7）必须在产品版本发布前修复；中低风险漏洞（CVSS<7）经风险评估后，可以遗留到下个补丁或版本修复，但修复时间必须符合漏洞相应 SLA 要求。

    1. 通用漏洞评分系统（CVSS）是一个用于传达软件漏洞特征和严重性的开放框架。CVSS 由三个度量组成：基本、时间、环境。基本指标产生 0-10 的分数，通过对时间和环境指标的评分修改该分数。CVSS 分数也表示为向量字符串，即用于导出分数的值的压缩文本表示。因此，CVSS 非常适合作为需要准确且一致的漏洞严重性评分的行业、组织和政府的标准测量系统。
    2. CVSS 的两个常见用途：
    • 计算在一个系统上发现的漏洞的严重性
    • 作为漏洞修复活动优先级的一个因素

  2. 进入维护阶段后，所有开源软件漏洞都必须依据合同对漏洞修复的相应 SLA 要求进行修复。

  3. 对于开源软件漏洞的修复，更倾向于跟随社区，与社区保持同步。

5.5 生命周期维护

5.5.1 产品研发注意事项：避免“自维护成本陷阱”

自维护成本陷阱是我们在使用开源软件时，希望将开源软件中植入一些产品的竞争力而导致的。植入产品竞争力必然会对开源软件拉分支，甚至于大量的修改。修改前期可将开源软件的维护能力和功能特性迅速拉升一个档次，随着版本的不断更新，拉的分支越来越多，每个不同的分支都要进行相应的回复。

5.5.2 案例分析

  • 案例：产品团队 A 负责维护 OpenSSL 历史版本 1.1.1a/1.1.1b/1.1.1c 以及社区最新版本 OpenSSL 1.1.1d；产品团队从社区官网发现 OpenSSL 1.1.1d 版本存在漏洞 CVE-2019-1551，则产品团队通过官网或 NVD 披露的漏洞影响版本范围分析漏洞 CVE-2019-1551 是否也影响 OpenSSL 1.1.1a/1.1.1b/1.1.1c。如受影响，则需将漏洞影响开源软件的版本刷新至漏洞库，同时修补 OpenSSL 1.1.1a/1.1.1b/1.1.1c 版本的漏洞。

  • 产品团队自行搭建构建环境，至少确保社区提供的构建方案能够编译通过。

  • 产品团队需不断审视社区当前所有软件新版本中的漏洞是否在维护版本存在且受影响，同时产品团队启动对所有受漏洞影响的选型引入的维护版本的漏洞修补。

5.6 开源软件生态

5.6.1 什么是开源软件生态

  • 基金会的两项重要工作：
  1. 中立协调：厂商与厂商之间是有竞争关系的，但在有基金会的中立场合下，厂商之间可以针对某个问题进行讨论。
  2. 赋予目标，维护项目：仅靠一家企业的力量长期维护一个开源项目是很难的。基金会赞助开源项目的方式会产生很多新的问题，例如 Linux Foundation 支撑 Linux，逻辑上可能是可行的，但在其之后，没有任何一个项目以同样的方式成功。
  • 项目成功的核心：
  1. 技术价值
  2. 商业生态价值
  • 金字塔型
  • 沙漏模型

5.6.2 开源软件商业模式

开源软件商业变现模式说明典型案例
企业版开源版本免费，企业版获得许可和支持服务收入；通过开源向商业版引流MySQL，Docker，Cloudera
高级功能收费对面向规模使用的的可靠性、安全、管理等进阶功能和工具软件收费Redis 核心部分的组件是开源的，但工具类软件和进阶功能（如多租户，无共享分布式架构等）是收费的
订阅服务开源许可证免除了开源社区对软件质量与缺陷修复的责任，由 OSS 厂商提供软件订阅服务Red Hat, Hortonworks
开源软件集成服务通过软件实施等技术服务收费SourceLabs 和 SpikeSource 不主推自己的产品品牌，而是与多方开源软件厂商或社区合作
云服务在公有云上提供基于开源软件的云服务；可通过开源向云服务引流MongoDB, Databricks, Elastic Search 等提供基于 Azure 和 AWS 上的云服务收费
通过硬件盈利提供开源软件 + 硬件的一体化方案，通过硬件变现Intel/NVidia/AMD
SaaS服务开源核心平台，对接更广泛的应用生态，通过 SaaS 服务变现GitLab 提供开源代码托管服务，开源本身平台以对接更多应用；Salesforce 等
应用和流量变现通过开源促成应用，形成行业事实标准，并与应用生态形成绑定进行变现，如广告或 Marketplace 等Google 基于 Android 生态的广告收入每年超百亿美元

5.6.3 微软围绕 Azure，通过持续投资和并购布局开源

  • 加入开源专利联盟 OIN（open invention network: https://openinventionnetwork.com/），同意向所有 OIN 成员开放其所有专利，包括 IDE Visual Studio Code、开源 JavaScript 扩展，.Net 开源核心类库，开源 Linux 环境 BashOnWindows 等； [16]

  • 面向开发者打通 To B、To C 平台，通过周期管理方式多路径做大开发者生态，建立完整渠道覆盖各级伙伴资源；

  • 加大对开源厂商扶持力度，包括云上部署及提供销售变现通道。

5.6.4 亚马逊：从开源业务收割者到新领域贡献者

  • 最大化利用开源价值为自身业务创收
  1. 大规模促进开源软件的云服务化（计费、监控、超卖等）
  2. 补齐开源软件应用的最后一公里（工具、文档、北向接口等）
  • 新领域贡献者
  1. Neo 作为 Apache 软件许可下的开源代码发布，支持广泛的框架和算法以及多样化的硬件架构；
  2. AWS 通过开源打通自家 MXnet->Neo->Inferentia 软硬件全栈，通过软件适配硬件、云服务释放算力应对来自 Google 和 NVIDIA 的竞争。

参考资料

[1] OSI 开源软件定义 https://opensource.org/

[2] Richard Stallman：American computer programmer https://www.britannica.com/biography/Richard-Stallman

[3] Linux 基金会 Linux.org

[4] Apache 软件基金会 https://www.apache.org/

[5] Eclipse 基金会 https://www.eclipse.org/

[6] Cisco settles FSF GPL lawsuit, appoints compliance officer https://arstechnica.com/information-technology/2009/05/cisco-settles-fsf-gpl-lawsuit-appoints-compliance-officer/

[7] Apache disallows the Facebook BSD+patent license https://lwn.net/Articles/728178/

[8] The History of Linux https://linuxhint.com/history-of-linux/

[9] SELinux是什么？ https://www.redhat.com/zh/topics/linux/what-is-selinux

[10] syzkaller - kernel fuzzer https://fuchsia.googlesource.com/third_party/syzkaller/+/usb-fuzzer/README.md

[11] Linux 内核自防护项目 KSPP https://linux.cn/article-7411-1.html

[12] ABOUT SIGSTORE https://docs.sigstore.dev/#about-the-project

[13] OpenSSH Project History https://www.openssh.com/history.html

[14] Patrick McHardy 事件对开源社区的影响 https://mp.weixin.qq.com/s?__biz=Mzg4NDcyNjEwNw==&mid=2247484568&idx=1&sn=82e1d1cc11f90a0d8851bcfd6bff5b74&chksm=cfb284acf8c50dba38a92d13e64aa84fbc2d5be7c131788007e2de7f19105fd3595daa678827&token=1720883671&lang=zh_CN#rd

[15] Best Buy, Samsung, And Westinghouse Named In SFLC Suit Today https://lwn.net/Articles/366467/

[16] The History of OpenInventionNetwork https://en.wikipedia.org/wiki/Open_Invention_Network#History