最大限度优化组织中运行开源计划或启动开源项目的实践。这些资源由 Linux 基金会与 TODO Group 合作开发，代表了我们的员工、项目和成员的经验。

• 英文：https://todogroup.org/guides/using-open-source/
• 中文：https://linuxfoundation.cn/using-open-source-code/
• GitHub：https://github.com/todogroup/todogroup.github.io/blob/master/content/en/guides/using-open-source.md 

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

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

本指南的撰稿人

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

为何追踪并审查代码

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

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

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

“一个精心设计的开源合规流程应同时确保遵守开源许可证条款，并帮助企业保护自己的知识产权，以及第三方供应商免受意外披露和/或其他后果的影响。” 

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

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

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

合规角色与责任

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

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

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

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

使用开源代码的一个简单方针

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

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

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

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

代码审查过程的五个阶段

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

“如果您的代码审查过程过于繁琐，您将会放慢创新的进程，或是为开发人员完全规避流程提供好借口。“

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

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

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

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

阶段 1：源代码扫描

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

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

表单提交后会自动在JIRA或Bugzilla等系统中创建合规工单，并将源代码扫描请求发送给指定的审计人员。定期的全平台扫描也应该每几周进行一次，以确保无开源软件组件被整合到平台上却没有相应的表单。如果发现任何问题，那么JIRA工单将自动发出并分配给审计人员。

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

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

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

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

关于下载的开源软件包的说明：

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

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

阶段 2 ：识别和解决

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

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

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

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

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

阶段 3：法律审查

在法律审查期间，法律顾问需要决定出入许可证：

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

准出许可证 = ？

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

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

阶段 4 ：结构审查

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

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

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

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

阶段 5 ：最终审查

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

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

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

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

这份清单可以包括：

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

Steps accomplished after the OSRB approval

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

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

在 1.0 版本之后该做什么

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

“关键是要记住，开源合规性不会随着1.0版本的发布而停止。”

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

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

增量合规流程是当产品功能被添加到基准版本 1.0 时，合规性被维护所通过的流程。

增量合规

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

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

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

• 在1版本中添加的新软件组件的名称
• 更新软件组件名称
• 旧版软件组件名称

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

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

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

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

增量合规流程示例

开源使用请求表单

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

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

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

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

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

开源使用请求表单样表：

结语

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

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

架构图模板

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

• 模块依赖性
• 专有组件
• 开源组件（修改版与原版）
• 动态与静态链接
• 内核空间与用户空间
• 共享头文件
• 通信协议

问题软件组件相互作用或依赖的其他开源组件，特别是如果它由不同的开源许可证管理时。

此架构图模板适用于依赖 C 语言或 C++ 语言的嵌入式环境

这些资源是与 TODO（Talk Openly，Develop Openly）组织合作创建的， 该组织是 Linux 基金会中专业的开源网络组织。特别感谢奉献自己的时间和知识来制作这些综合指南的开源项目负责人。参与制作的公司包括 Autodesk、Comcast、Dropbox、Facebook、Google、Intel、Microsoft、Netflix、Oath（Yahoo + AOL）、Red Hat、Salesforce、Samsung 和 VMware。如想了解更多信息，请访问：todogroup.org