TODO指南：使用开源代码

这些开源指南是由TODO小组与Linux基金会和更大的开源社区合作开发的。他们从从事开放源码开发的领先公司收集最佳实践，旨在帮助你的组织成功地实现和运行开源计划办公室。我们期望这些指南通过社区贡献而发展的活文档。 对于针对个人贡献者定制的指南，我们推荐GitHub的社区指南（https://opensource.guide/zh-cn/）。

开源计划办公室最重要的责任之一，是要在整合开源代码与专有的、第三方的源代码到商业产品中时，确保您的组织符合其法定义务。

您需要制定有关开发人员如何使用开源代码，以及追踪开源代码的来源、授权方式及其最终结果的详细流程指南。本指南让您从一个基准的合规项目开始，来使用、发布和分发开源代码。

目录

• 为何追踪并审查代码
• 合规角色与责任
• 使用开源代码的一个简单的政策
• 代码审查过程的五个阶段
• 在1.0版本之后该做什么
• 开源使用请求表单
• 结语
• 架构图模板
• 鸣谢

为何追踪并审查代码

简单来说，如果您的公司没有追踪开发人员如何使用开源代码的方式和地点，那么您将面临不遵守适用开源许可证的风险 - 无论是在法律费用和修正错误所花费的工程时间两个方面都是一种昂贵的途径。忽视开源法律义务也会影响贵公司在开源社区的声誉。

开源计划办公室帮助集中制定围绕开源消费、分发和发布来集中制定方针和政策，追踪代码来源及其使用情况，并确保组织不违反其合规义务。

理想情况下，开源项目包含一个在法律顾问的帮助下开发的完整的合规项目。在本指南中，我们将介绍合规计划的一个重要方面：您关于使用、发布和分发开源代码的方针与流程。

“一个精心设计的开源合规流程应同时确保遵守开源许可证条款，并帮助企业保护自己的知识产权，以及第三方供应商免受意外披露和/或其他后果的影响。” Ibrahim Haddad – 三星美国研究院研发副总裁兼开源小组负责人

企业可以通过维护开源合规项目获得几点好处：

• 获得技术优势 - 因为兼容的软件组合更易于服务、测试、升级和维护。
• 识别开源代码部分 - 将发现在多个产品和组织的某些部分使用了哪些代码，且/或对开源战略是具有高度战略价值和益处。
• 说明与使用开源组件相关的成本与风险 - 当代码经过多轮审查时，这将是显而易见的。
• 建立社区信任 - 如果发生合规性挑战，这样的项目可以展示一个正在进行的善意行为模式。
• 为适合收购、销售或者新产品或服务的发布做好准备 - 这是一种罕见的好处，但在完成此类交易之前，合规性保证是强制性的。
• 建立供应链可信度 - 可以提高整个软件供应链的合规性，包括提升原始设备制造商（OEM）和下游供应商的合规性。

合规角色与责任

在开源计划中，需要创建一个特定的开源合规团队，该团队的任务是确保开源的合规性。

这个核心团队，通常被称为审计团队或开源审查委员会（OSRB），由来自工程团队和产品团队的代表，一名或多名法律顾问以及合规人员组成（合规人员通常是开源项目经理）。

各个部门中的其他人员也为开源合规工作提供源源不断的基础：文件、供应链、企业开发、IT、本地化和监督整个开源战略的开源执行委员会（OSEC）。但与核心团队不同，这些扩展团队的成员只是根据从开源审查委员会（OSRB）收到的任务，在兼职的基础上开展工作。

开源审查委员会（OSRB）负责创建开源合规战略和一套决定企业如何在日常基础上实施这些规则的流程。该战略确立了必须采取的措施来保证合规性，并为员工如何与开源软件进行互动提供了一套主要原则。它包括了开源的审批、获取与使用的正式流程，以及发布开源软件或经开源许可证授权的软件。

使用开源代码的一个简单政策

使用办法是所有合规项目的重要组成部分。这套规则包含在您的开源策略文件中（您有一份开源战略文件，对吗？），并提供给所有人以便参考。

使用办法确保任何成为产品基础的（专有的、第三方的或开源的）软件都已经过审核、审查与审批。该办法还确保在产品送达客户之前，贵公司已经制定了一个计划来履行因使用各种软件组件所产生的许可证义务。

无需制作一份冗长或复杂的文件。一个优秀的开源使用办法包括六个简单规则：

• 在将开源代码整合到产品中之前，工程师必须获得开源审查委员会（OSRB）的许可。
• 从第三方接收的软件必须经过审核，以识别其包含的所有开源代码，这样可以确保在产品发货之前许可证的义务得以履行。
• 所有软件都必须经过审核和审查，包括所有的专有软件组件。
• 产品必须在客户收货前履行开源许可证义务。
• 即使开源组件是一样的，对于在一个产品中使用给定的开源组件的许可也不等于其他部署许可。
• 任何变更的组件都必须经过审批流程。

代码审查过程的五个阶段

一旦制定办法，就必须计划并创建一个更易于应用办法中规定的流程。您的工作是帮助开发人员顺利地进行开源应用并为开源项目做贡献。

“如果您的代码审查过程过于繁琐，您将会放慢创新的进程，或是为开发人员完全规避流程提供好借口。“ Ibrahim Haddad – 三星美国研究院研发副总裁兼开源小组负责人

该过程首先扫描有问题的软件包的源代码，然后继续识别并解决所有发现的问题，还进行法律和体系构架的审查，并就相关使用许可做出决定。

下图展示了一个合规使用过程的简单视图。实际上，这个过程本质上更具有迭代性。请记住，这些阶段仅适用于说明目的，可能需要根据公司自身需求和开源项目配置进行相应的修改。

让我们来看看这个过程中的每个阶段。

阶段 1：源代码扫描

在源代码扫描阶段，所有源代码都被专门的软件工具扫描（除了一些开源替代品之外，还有许多商业供应商提供这种工具）。

当工程师提交线上使用表单时，此阶段通常会启动。（请参阅下文的示例的使用表单和使用规则。）该表单包含了关于有问题的开源组件的所有信息，并指定了源代码在源代码库系统中的位置。

表单提交后会自动在JIRA或Bugzilla等系统中创建合规工单，并将源代码扫描请求发送给指定的审计人员。

定期的全平台扫描也应该每几周进行一次，以确保无开源软件组件被整合到平台上却没有相应的表单。如果发现任何问题，那么JIRA工单将自动发出并分配给审计人员。

可触发源代码扫描的因素包括：

• 一份传入的使用表单，通常是由工程人员填写的。
• 定期安排全平台扫描。这样的扫描对于发现隐藏在软件平台中而无使用表单的开源代码非常有用。
• 更改先前批准的软件组件。在很多情况下，工程师使用特定版本的OSS组件来开始评估和测试工作，并在新版本可用时采用该组件。
• 源代码是从第三方软件供应商处获得的，该供应商可能会也可能不会披露开源。
• 源代码是从未知作者和/或许可证的网页上下载的，它可能有也可能没有开源代码。
• 一个新的专有软件组件进入开发系统，在系统中工程可能有也可能没有借用开源代码并将其用于专有软件组件。

代码被扫描后，扫描工具会生成一份报告，其中提供以下列信息：

• 已知在用的软件组件，也被称为软件物料清单（BoM）
• 有效的许可证、许可证文本和义务概述
• 须经法律验证的许可证冲突
• 文件清单
• 识别的文件
• 依赖性
• 代码匹配
• 待识别文件
• 源代码匹配待定标识

关于下载的开源软件包的注意事项

将从网页上下载的开源软件包归档到原始表单中是至关重要的。这些软件包将被应用于之后阶段中（在分发阶段之前），通过计算原始软件包和修改后的软件包之间的差异，来验证并追踪引入源代码中的所有变更。

如果第三方软件供应商使用了开源软件，则将该代码整合到产品中的产品团队必须提交一个开源使用表单来说明所使用的开源代码。如果第三方软件供应商仅提供二进制代码，而不提供源代码，那么负责管理第三方软件供应商关系的产品团队和/或软件供应商经理必须取得在供应商所提供的软件中没有开源代码的确认（例如，扫描报告）。

阶段 2：识别和解决

在识别和解决阶段，审计团队需检查并解析由扫描工具标记的每个文件或摘录。

例如，扫描工具的报告可以标记诸如冲突和不兼容许可证等问题。如果没有问题，则合规办公室会将合规票据转移到法律审查阶段。

如果有问题需要解决，那么合规人员会在合规票据中创建子任务，并将其分配给相应的工程师来解决。在某些情况下，代码返工是必要的；在其他情况下，这可能只是一个澄清事宜。这些子任务应包括问题描述、由工程团队实施的建议解决方案，以及具体的完成时间表。

一旦所有问题都得到解决，合规人员可以简单地关闭子任务，然后将票据传至法律审查阶段。或者，他们可能会首先下令重新扫描源代码，并生成一份新的扫描报告，以确认之前的问题已不存在。一旦他们确信所有问题都已经得到解决，合规人员会将合规票据转发给法律部门的代表进行审查和批准。

在准备进行法律审查时，您应该将与开源软件相关的所有许可证信息添加到合规票据中，例如COPYING（复制文件）、README（自述文件）、LICENSE（许可证文件）等。

阶段 3：法律审查

在法律审查阶段，法律顾问（通常是开源审查委员会的成员或OSRB）审查扫描工具生成的报告，软件组件的许可证信息以及工程师和审计小组成员在合规工单中留下的任何评论 。

当合规工单到达法定审核阶段时，它已包含：

• 源代码扫描报告并确认已解决扫描阶段中确定的所有问题。
• 附加到故障单的许可证信息的副本：通常，合规职员将源代码包中可用的README，COPYING和AUTHORS文件附加到合规性故障单。除了许可证信息（通常在COPYING或LICENSE文件中提供OSS组件）之外，您还需要获取版权和归属通知。此信息将在您的产品文档中提供适当的归属信息。
• 合规职员关于合规工单的反馈（顾虑，其他问题等）。
• 审核小组或工程师（软件包所有者）的工程代表在内部跟踪/维护此包的反馈。

此阶段的目标是产生合规性的法律意见，以及对相关软件组件的导入和输出许可的决定。导入和输出许可证是复数形式，因为在某些情况下，软件组件可以包括在不同许可证下可用的源代码。在此阶段有三种可能的结果：

没有合规问题

如果许可没有问题，那么法律顾问将决定软件组件的导入和输出许可，并将合规工单在该过程中进一步转发到合规架构阶段。

导入许可证是您收到软件包的许可证。输出许可证是您授权软件包的许可证。在某些情况下，当导入许可证是允许重新许可的许可许可证（例如，BSD）时，公司将根据其自己的专有许可证重新许可该软件。一个更复杂的例子是软件组件，其中包括专有源代码，部分源代码使用许可证A，部分源代码使用许可证B，以及部分源代码使用许可证C。法律审查期间，法律顾问将需要决定导入和输出的许可证：

导入许可证=专有许可证 + 许可证A + 许可证B + 许可证C

输出许可证=？

有合规问题

如发现许可证有问题，例如具有不兼容许可证的混合源代码，法律顾问将标记这些问题并重新分配JIRA中的合规工单给工程师以重新编写代码。

例如，在法律审查中可能会发现，密切关注的知识产权已经与开源代码包相结合。法律顾问将对此进行标记，并将合规工单重新分配给工程师以从开源组件中移除专有源代码。如果工程师坚持将专有源代码保留在开源组件中，开源执行委员会（OSEC）将需要根据开源许可证来发布专有源代码。

不确定是否有合规问题

在某些情况下，如果许可证信息是不清楚或者是无法获得的，法律顾问或工程人员要联系项目维护人员或开发人员，以澄清歧义之处并确认特定的软件组件是由哪个许可证所授权的。

阶段 4：架构审查

在架构审查中，合规人员和来自审计团队的工程代表或开源审查委员会对开源代码、专有代码和第三方代码之间的相互作用进行分析。这是通过测试识别以下内容的架构图（参见以下示例）来实现的：

• 开源组件（“按原样”使用或修改后使用）
• 专有组件
• 来自第三方软件供应商的组件
• 组件依赖性
• 通信协议
• 特定软件组件相互作用或取决其他开源代码包，尤其是当它由不同的开源许可证管理时

架构审查的结果是对许可证的责任分析，许可证义务范围可能从开源软件组件扩展到专有代码或是第三方软件组件（以及还有跨开源组件）。

如果合规人员发现任何问题，例如链接到GPL许可证组件的专有软件组件，那么他们会将合规工单转发给工程师们以解决相应问题。如果没有问题，合规人员则将审批过程中的票据转移到最后阶段。

阶段 5：最终审查

最终审查通常是审计团队或开源审查委员会（OSRB）的面谈会议，在会议期间，该团队批准或拒绝软件组件的使用。

该团队根据软件组件完整的合规记录来做决定，该记录包括以下内容：

• 一份由扫描工具生成的源代码报告。
• 发现问题清单，关于问题如何解决的答案，以及由谁验证解决了这些问题
• 架构图和关于软件组件如何与其他软件组件相互作用的信息。
• 关于合规性的法律意见，以及出入许可证决定。
• 如果适用于嵌入式环境（C语言/C++语言），则进行动态和静态链接分析。

在大多数情况下，如果一个软件组件到达最终审查阶段，它将被批准，除非特殊情况出现（例如不再使用该软件组件）。一旦获得批准，合格职员将为被批准的软件组件准备许可证义务清单，并将其交给合适的部门来履行义务。

这份清单可以包括：

• 更新软件清单，以此来反映特定的OSS软件组件版本x已被批准在产品y的版本z中使用。
• 向文件团队发出工单，让他们更新产品文件中的最终用户注意事项，以反映产品或服务正在应用开源代码。
• 在产品发货前触发分发流程。

合规人员监测所有开放工单，并确保在产品发货或服务发起时完成工单。

有关更详细的使用过程和可能场景，请参阅我们的电子书《企业中的开源合规性》。

在1.0版本之后该做什么

初始合规，也称基准合规，在开发伊始时发生，并一直持续到第一版产品的发布。合规团队识别软件基线中包含的所有开源代码，并通过前文概述的五阶段批准流程，驱动所有源组件。

“关键是要记住，开源合规性不会随着1.0版本的发布而停止。“ Ibrahim Haddad – 三星美国研究院研发副总裁兼开源小组负责人

一旦产品发货，您将还需要开发一个增量合规流程来检查源代码。当开发从包含附加功能和/或漏洞修复的新分支开始时，这个流程就开始了。

增量合规流程是当产品功能被添加到基准版本1.0时，合规性被维护所通过的流程。与建立基准合规性所需要的努力相反，增量合规性只需要相对相对简单的工作。但仍然可能出现一些挑战。您必须正确识别在版本1.0和版本1.1之间发生变更的源代码，并且验证版本之间的合规性增量：

• 已引进新软件组件。
• 已停用现有软件组件。
• 现有软件组件可能已升级到较新的版本。
• 软件组件许可证可能在不同版本间发生了变化。
• 现有的软件组件可能会有关于漏洞修复的代码变更，或功能和架构的变更。

一个显而易见的问题是：我们该如何保持追踪这些变化？答案很简单：物料清单差异工具（BOM diff工具）。给定产品1.1版本的物料清单（BOM）和1.0版本的物料清单（BOM），我们计算增量而后工具的输出结果如下：

• 在1.1版本中添加的新软件组件的名称
• 更新软件组件名称
• 停用软件组件名称

掌握这些信息后，实现增量合规将成为一项相对容易的任务：

• 将新的软件组件输入到五阶段的使用审批过程中。
• 在变更的软件组件中逐行计算源代码差异，并决定您想要再次扫描源代码还是依赖先前的扫描结果。
• 通过移除不再使用的软件组件来更新软件注册表。

下面的图表提供了增量合规性流程的概述。每个产品版本的BOM（物料清单）文件都存储在构建服务器上。BOM（物料清单）差异工具将两个BOM（物料清单）文件作为输入，每个文件对应于不同的产品版本，并计算增量来生成如前所述的变更清单。

此时，合规人员将为该版本中所有新版软件组件创建新的合规工单，更新源代码发生变更的合规工单，并可能通过这一过程重新传送，最后更新软件注册表，从批准清单中删除已退休的软件组件。

开源使用请求表单

完成开源使用请求表单是开发人员将开源软件引入贵公司的重要步骤，应作严肃对待。

开发人员填写在线表单，请求批准使用既定的开源组件。该表单包含若干将为审计团队或开源审查委员会提供必要信息的问题，以让他们批准或不批准所提议的开源组件的使用。

下面的表单突出显示了开源使用请求表单中所要求的信息。这些数值通常是从下拉菜单中选择的，以使数据输入更高效。

管理OSRB（开源审查委员会）使用表单有几条规则，例如：

• 该表单仅适用于特定产品和环境的开源使用。这不是对于开源组件适用于所有产品中的所有用例的一般认可。
• 该表单是审计活动的基础，同时提供审查团队需要验证的信息，团队需要验证实际履行是否与表单中表述的使用计划一致，以及是否与审计和架构审查结果一致。
• 只要该特定开源组件的使用计划发生变化，就必须更新表单并重新提交。
• 在工程师们整合开源组件到产品开发之前，审计团队或审查委员会必须批准表单。
• 开源执行委员会必须批准任何许可证条款要求授予专利许可或专利非纠纷条款的开源软件包的使用。

结语

开源合规性是软件开发过程的重要组成部分。如果您在产品中使用开源软件，没有一个可信赖的合规项目，那么您应该将本指南视为行动的号召。

从它的核心来说，开源合规性包括一系列控制商业产品中使用的开源的准入与分发行为。合规尽职调查的结果是对产品中所使用的所有开源识别（组件和代码片段），以及满足许可证义务的计划。有关开源合规性的详细指南，请下载我们的免费电子书，由Ibrahim Haddad所著的《企业中的开源合规性》。

架构图模板

架构图用于开源流程的结构审查阶段，演示了示例平台中软件组件相互作用。这是一个示例架构图，展示如下：

• 模块依赖性
• 专有组件
• 开源组件（修改版与原版）
• 动态与静态链接
• 内核空间与用户空间
• 共享头文件
• 通信协议
• 问题软件组件相互作用或依赖的其他开源组件，特别是如果它由不同的开源许可证管理时

鸣谢

贡献者：

• Ibrahim Haddad，三星美国研究院研发副总裁兼开源小组负责人

这些资源是与TODO（公开对话，开放式开发）小组 – Linux基金会的专业开源程序网络小组合作创建的。 特别感谢那些贡献自己的时间和知识来制作这些综合指南的开源项目经理。 参与的公司包括Autodesk，Comcast，Dropbox，Facebook，Google，Intel，Microsoft，Netflix，Oath（Yahoo + AOL），Red Hat，Salesforce和Samsung。 要了解更多信息，请访问：todogroup.org。 我们邀请您在GitHub上下载或参与这些指南。所有内容使用CC-BY-SA 4.0授权。