点击查看目录

总体概述

开源软件合规（Compliance）实践，从狭义上讲就是企业使用开源软件许可证（License）的合规。Recommended Open Source Compliance Practices for the Enterprise 电子书（共 32 页）由 Ibrahim Haddad 博士撰写，本书从以下几个角度为你的公司的进行开源合规实践以指导：

• 创建开源审查委员会（Open Source Review Committee）
• 代码扫描
• 软件溯源（Software Sourcing）
• 开源法务支持（Open Source Legal Support）
• 流程中的合规检查（Compliance Checkpoints）
• 开发和部署检查器
• 合规事项看板

开源合规审查组

企业为了保证自己产品或软件的合规，通常会有一个许可证合规审查组，负责以下几项职责：

1. 遵守开源许可条款
2. 促进在产品和服务中使用开源
3. 遵守第三方商业软件的许可条款
4. 保护您的产品/服务差异化（知识产权/IP）

开源合规流程

图 2 是开源合规流程闭环。

该流程中分为以下三步：确认（Identify）、批准（Approve）和确知（Satisfy）。

确认（Identify）

此初始步骤的目标是监控软件组合中开源来源，无论该组合是作为独立软件包还是嵌入在第三方或公司开发的软件中。此步骤的输出是详细的软件物料清单（Bill of Materials），用于标识所有开源软件包（Package）和代码片段（Snippet）的来源（Origin）、许可证（License）以及由软件组合分析工具所识别的许可冲突。

批准（Approve）

这一步的目标是：

1. 查看上一步的输出，了解管理相关源代码的使用、修改和分发的许可证；
2. 根据其独特的背景（context），确定是否批准使用已识别的开源软件；

确知（Satisfy）

在最后一步中，准备好所有已批准的开源软件（整个组件和片段）的许可证、版权（copyright）和归属声明，并将其交给相关的部门，以包含在产品文档中。同样，已经确知和标记了许可义务的开源软件包，就可以在产品/服务上线时发布了。

对企业开源合规实践的建议

作者提出了企业可以实施的实践建议，以改进和加强其开源合规性计划：

• 成立开源审查委员会（Open Source Review Board，简称 OSRB）
• 建立自动化系统来识别开源软件
• 让软件供应商遵守开源许可证
• 扩展开源法律支持
• 在业务和开发过程中集成开源合规性检查点
• 提供各种开源合规性任务的清单（checklist）
• 开发和部署支持清单
• 建立开源合规活动基准（benchmark）
• 参与关键合规性开源合规性计划

成立开源审查委员会

除开源合规官或开源计划办公室的代表外，开源审查委员会（OSRB）由法律和产品/工程团队的代表组成。OSRB 的主要职责是审查和批准计划在产品和服务中使用开源软件。

下面是 OSRB 中每个参与者职责的宏观概述。

开源法律顾问（Open Source Legal Counsel）

• 审查和批准开源软件的使用、修改和分发。
• 提供与开源许可相关的法律指导。
• 为创建合规培训做出贡献。
• 有助于改进合规计划。
• 审查和批准与许可证合规性相关的 Web 门户的内容。
• 审核并批准使用的开源软件的义务列表。
• 从开源合规性角度签署产品发布。

产品/工程代表（Product / Engineering Representative）

• 在其组织内实施合规性政策（policy）和流程（process）。
• 在软件开发过程中集成合规性实践。
• 从工程角度为改进合规计划做出贡献。
• 遵循技术开源合规指南。
• 与 OSRB 成员协作以响应合规性查询。
• 进行设计、架构和代码审查。
• 准备用于出版物的开源软件包和通知。
• 从开源合规性角度签署产品发布。

开源计划办公室和合规官的代表（Representative of the Open Source Program Office or Compliance Officer）

• 推动开源合规活动。
• 协调源代码扫描和审核。
• 参与工程审查和分发准备评估。
• 协调开源软件包和通知的发布。
• 为培训工作和改进合规计划做出贡献。
• 有助于促进开源软件的自动化和发现。
• 从开源合规性角度签署产品发布。

除了 OSRB 的成员之外，实现开源合规是一项跨学科活动，涉及到组织内的各个部门和个人，如图 4 所示。

下面是对支持团队帮助 OSRB 确保开源合规性的核心职责的描述。

IT

• 创建/获取确保合规性所需的新工具
• 为合规计划使用的工具和自动化基础设施提供支持和维护

企业发展（Cooperate Development）

• 请求/监督开源合规性尽职调查在合并或收购之前完成
• 从外包开发中心接收源代码时确保合规性记录

文档（Documentation）

• 在产品文档中包含开源许可证信息和通知（notice）

开源执行委员会（Open Source Executive Committee）

• 审查并批准在开源许可下发布专有源代码的提议

软件采购（Software Procurement）

• 授权第三方软件提供商在许可或购买的软件组件中披露开源
• 协助引入包含（或不包含）开源软件的第三方软件

开源代码审查

开源合规性工作的核心是识别开源代码及其各自的许可证，以便组织可以满足适用的许可证义务。开源策略和流程指导此核心活动。合规性政策和流程管理开源软件的使用、贡献、审核和发布的各个方面。如果我们采用下图 5 所示的基本流程并对其进行扩展，我们将考虑端到端的合规流程。下图显示了这样一个流程，它具有源自多个源的源代码输入。源代码经过一系列步骤，流程的最终输出包括书面报价、通知列表（版权、归属、许可证），以及为履行许可义务而发布的源代码包。

图 5 提供了端到端合规流程的详细示例，其中包括软件组件被 OSRB 批准在构建系统中与软件产品集成之前经历的各个步骤。

图 6 简要描述了每个步骤中发生的情况。

开源代码溯源

让您的软件提供商参与开源合规中至关重要。软件提供商必须披露其可交付成果中包含的开源代码，并提供包括适用源代码在内的所有通知（notice）。

图 7 描绘了多源开发模型和传入源代码的各种源组合。在此模型下，产品或软件堆栈可以包含专有软件、第三方商业和第三方开源软件的任意组合。例如，除了第三方专有源代码之外，软件组件 A 可以包括专有源代码，而软件组件 B 除了可以包含来自开源项目的源代码之外还可以包括专有源代码。

当今的公司处于必须更新其供应链（软件采购）程序以解决获取和使用开源软件的状态。通常会有供应链人员参与将软件从供应商转移到贵公司。他们可以通过两种主要方式支持开源合规性活动：

• 要求第三方软件提供商披露他们在其可交付成果中使用的任何开源，以及
• 协助许可与开源软件包捆绑在一起或与之集成的第三方软件。

此领域的推荐做法是强制第三方软件提供商披露其产品中使用的所有开源组件，并声明他们计划如何满足适用的开源许可证义务。如果第三方软件包含开源，供应链必须确保在初始入口后满足开源许可证义务——您作为提供开源产品或服务的分销商将承担这些义务和责任。

提供便捷的法务支持

大多数组织都会创建开源合规性计划并建立核心团队以确保合规性。大多数公司往往会会遇到开源法律支持的瓶颈，因为您公司里可能有成百上千的使用和集成开源代码的开发人员，而很少有法务人员提供所需的法律支持。扩展开源法律支持需要一些开箱即用的思考，但可以借助以下实用方法实现。

许可证手册（License Playbooks）

提供面向软件开发人员的易于阅读和摘要的开源许可证摘要。提供有关这些许可证的易于理解的信息，例如许可证授予、限制、义务、专利影响等。使用开源软件许可证手册可以大量减少发送给法律顾问的基本问题的数量，并为开发人员提供了对常见查询的即时指导、信息和答案。

许可证兼容性矩阵（License Compatibility Matrix）

许可证兼容性是指确定某个许可证是否与另一个许可证兼容。GPL 兼容性是指确定某个许可证是否与 GPL 条款兼容。当合并源自不兼容许可下软件组件的源代码时，开发团队经常会遇到许可兼容性问题。当开发团队将不同许可证下的代码组合在一起时，可以参考许可证兼容性矩阵来验证在单个软件组件中是否存在加入源代码的许可冲突。如果开发团队使用的许可证源不在矩阵中，则可以后续获得法律顾问的建议。

许可证分类

为了减少开源法律顾问收到的问题数量并增加许可和合规流程教育，一些公司选择在几个类别下对其产品中最常用的许可进行分类。图 11 显示了许可证分类系统的一个简单示例，其中大多数使用的开源许可证分为四类。

上述许可证类别是对许可证进行分类的简单方法，使开发人员在根据这些许可证集成代码时更容易了解操作过程。下面这个例子是开发人员想要使用在以下许可下的开源软件包的：

• License A - Action：尽管用，没有什么问题
• License E - Action：获得工程经理的批准
• License I - Action：获得法律顾问的批准
• License M - Action：根据政策禁止适用该 License
• 其他 - Action：向经理询问行动方案

有关此话题的进一步阅读，我们建议阅读**扩展开源法律支持的实用建议 **。本文探讨了法律顾问在确保开源合规方面的作用，并为法律顾问提供了可以为软件开发团队提供的实用建议。这些实用建议将使软件开发人员能够做出与开源许可相关的日常决策，而无需再去找负责每个问题的法律顾问。

开源合规流程中的检查点及发布清单

有必要将合规性实践纳入开发流程，以确保开源合规工作的成功。您可以通过多种方式实现这一目标。

1. 每个内部版本的合规性：更新流程管理，以确保在产品开发周期中尽早包含开源合规性活动，以使组织能够满足其发布时间表。遵循此模型，未来版本的增量合规性也变得简单明了。
2. 更新供应链程序：定制供应链的供应商选择程序，以确保在对供应商及其可交付成果进行尽职调查（Due Diligence）时考虑开源合规性要求。
3. 执行验证：使用验证步骤确保在发生发行外部版本之前满足所有合规性要求。
4. 培训员工：为所有员工提供开源合规培训。
5. 采用 SPDX 报告许可证信息：以 SDPX 格式提供许可证信息，以尽量减少任何可能的错误，并标准化报告信息的方式。

SPDX

SPDX® （Software Package Data Exchange®）是用于传达软件物料清单信息（包括组件、许可证、版权和安全参考）的开放标准。

SPDX 通过为公司和社区提供共享格式来共享软件许可、版权和安全参考的重要数据，从而简化和改进合规性，从而减少冗余工作。

SPDX 规范由 SPDX 工作组开发，该工作组由 Linux 基金会托管。基层工作包括来自 20 多个组织的代表——软件、系统和工具供应商、基金会和系统集成商——都致力于为软件包数据交换格式创建标准。

开发和部署清单

清单很有用，可确保执行合规性任务的一致性和完整性。强烈建议根据员工职责建立合规里程碑清单和目标清单。

清单的示例包括：

• 批准将传入代码集成到产品的源代码存储库之前的核对表
• 确保履行义务的清单
• 开发人员的清单
• 工程经理的清单
• 合规人员清单
• 开源法律人员的清单
• 软件采购人员清单

为了说明这一点，我们提供了一个示例清单，展示了在组织发布源代码包之前必须检查的各种任务，以履行在交付产品中包含的开源代码的许可义务：

预发行清单（Pre-Distribution Checklist）

• 验证引入开源软件包的修改是否已记录，并作为更改日志的一部分包含在开源发行说明中。
• 确保每个修改后的源代码文件都包含版权声明，免责声明和通用“更改日志”（Changelog）条目的附加条目。
• 确认源代码包的所有内容均已由工程团队审核并由 OSRB 确认。
• 确保在非公司标准 Linux 计算机上编译开源软件包。此步骤的目标是确保您要发布的开源软件包在通用最终用户系统上进行编译。
• 将产品手册更新为：
  • 提及该产品包含开源软件。
  • 包括与产品中包含的不同开源软件相对应的所有许可证的列表。
  • 提供适当的版权和归属通知。
  • 通过网页下载或通过产品手册中提供的指定地址通过电子邮件或邮寄方式与贵公司联系，说明如何访问开源软件包的代码（书面提供）。
• 执行语言检查（linguistic review）以确保源代码中没有任何不适当的注释。
  • 注意：有些公司忘记进行语言检查，当代码发布时，他们会因源代码中留下的不当注释而尴尬。执行语言检查的另一个重要原因是确保源代码和注释不涉及未来的产品代码名称或功能。
• 确保现有许可、版权和归属通知不受干扰。
  • 验证要分发的源代码是否与产品一起使用的二进制文件对应，源代码构建到与产品一起分发的同一个库中，并且源代码分发中包含适当的指令（除时间/日期戳外派生的二进制文件通常是相同的）。
  • 验证包是否遵循开源策略中定义的链接关系和交互。
  • 确保在开源软件包的根文件夹中的 LICENSE 文件中包含许可证文本的副本（如果尚未存在）。
  • 如果源代码包需要特殊的构建工具或环境设置，则将详细信息包含在 README 文件或类似文件中。 这些清单，特别是在实现自动化并与业务和开发流程集成时，可以提醒您必须完成的所有事项，以确保合规性并减少发生错误的几率。

最后

本书中的最后还推广了波 OpenChain 项目，该项目提供了一组自我认证的选项，由该领域的利益相关者创建，用于合规性规范，该规范允许给定的组织进行自我测试并声明其遵守特定的合规级别。您可以访问 https://www.openchainproject.org/conformance 了解更多信息。