特别声明

本文拥有创作共用授权之相同方式共享授权4.0版国际许可协议（Creative Commons Attribution ShareAlike 4.0 International License）授权许可。 开源之道独立精心翻译分享，欢迎同道中人商讨。

高效而正确的使用开源代码

作为开源项目办公室其中最重要的责任就是确保贵司是合法合规的集成开源代码的，无论这些代码是商业专有的，还是第三方整合的。

作为开源项目办公室的负责人，你需要为开发者们创立相应的向导和指南，告诉他们该如何使用开源代码，更要非常细节的跟踪开源代码来自哪里、使用的何种许可证书、最终用到了哪里？等等。

本指南会提供使用、发布、分发开源代码的合规性程序的基本要素。

为什么要跟踪和审核代码?

简单点讲，如果贵司没有去告诉开发者们如何及在哪里使用开源代码的话，那么贵司可能面临开源许可证是否遵守合规的问题 —— 无论是从法律的开销上来看，还是所耗费的时间，都是非常昂贵的代价。另外，无视开源的法律义务，也会让贵司在开源社区的声誉大大的折扣。

那么作为开源项目办公室，就是帮助公司集中的制定围绕开源合规、分发、软件发布来相应的规则和决策，并追踪代码的来源和使用，以及确保公司不会违背相应的合规义务。

理想的情况下，贵司的开源项目拥有一套在法律顾问的帮助下开发的完整的合规程序，在本指南中，会涵盖到公司合规程序中重要的方面：使用、发布和分发开源代码的规则和流程。

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

企业可以通过维护开源合规项目获得如下益处：

• 获得技术优势。 因为合规的软件组合更易于服务、测试、升级和维护。
• 确定开源代码的关键部分 帮助贵司跨多个产品和部门，使用了那些代码，对于开源战略很有益处。
• 充分说明使用开源组件的代价和风险 当代码经过多轮审查时，这是显而易见的事情。
• 获得社区的信任。 当遇到有人质疑合规性的问题时，因为贵司已经做好了准备，根本不怕这些。
• 为适合收购、销售或者新产品或服务的发布做好准备 这种情况不是太常见，但不是不会发生，一旦发生，那么在完成此类交易之前，合规性保证是强制性的。
• 在供应链当中赢得信任。 可以提高整个软件供应链的合规性，包括提升原始设备制造商（OEMs）和下游供应商的合规性。

合规性角色和相应的责任

在开源项目办公室内部，需要创建一个专门的开源合规团队，他们的任务就是来确保开源的合规。

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

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

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

使用开源代码的简易规则

规则的执行在任何的合规性项目中都是基础组件。这组规则的集合是包含在贵司的开源战略文档中的（你一定撰写了开源战略文档，对不对？如果没有的话，先放下合规性这事，赶紧去写。），而且谨记要把这些能够让每个人都可以看到。

规则的执行是为了确保任何的软件（专有的、第三方的、或者是开源的）在整合到最终的产品之前能够被进行审计、审核以及批准。当然还有，能够确保在产品交付客户之前，贵司已经制定了一个计划来履行因使用各种软件组件所产生的许可证义务。

其实没有必要制作一份冗长而复杂的文档，一份好的开源使用规则包含下面六条就足够了：

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

代码审核流程5步走

一旦有了上述的规则之后，接下来就该规划和建立一些流程，从而让这些规则能够顺利的执行下去。那么开源项目办公室的工作就是让开源者们顺利的使用开源，并能够为开源项目做出应有的贡献。

“如果贵司的审核流程过于繁琐，那么就会妨碍团队的创新，或者是给开发者找到不遵循流程的借口。” – Ibrahim Haddad，三星美国研究院研发副总裁兼开源小组负责人

流程始于有需求的软件包的源代码，然后是识别并解决任何可能发现的问题，接着是相应的法律、架构审核，最后是就相关的使用许可做出决定。

下图向各位看官展示了合规流程简单的视图，在现实中，这些过程不会这么死板，而是需要不断的迭代完善。请记住，这些阶段仅适用于说明目的，可能需要根据公司自身需求和开源项目配置进行相应的修改。

接下来，就让我们深入到整个过程的每个阶段。

第一阶段: 源代码扫描

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

该阶段典型的启动方式，只要是工程师使用表单线上提交就算是开始了。（请参阅下文的示例的使用表单和使用规则。）其中表单包含了关于有需求的开源组件的所有信息，并指定了源代码在源码库系统中的具体位置。

在表单提交之后，工单系统（如 JIRA 或 Bugzilla）会自动的创建一个关于合规性的工单。然后请求源代码扫描会发送给指定的审计人员。

全部平台的扫描也要定期的如每隔几周就要执行，要确保没有开源软件组件整合了却没有相应的表单这样的情况发生，如果发现任何问题，那么 JIRA 工单将自动发出并分配给审计人员。

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

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

在代码被扫描完成之后，由扫描工具生成的报告应该提供如下信息：

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

针对下载开源软件包的提示

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

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

Stage 2: 识别和解决方式

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

举例来说，扫描工具的报告会为诸如许可证冲突或不兼容打上标记，如果没有类似的问题，则合规团队会将该工单移交至法律审核阶段。

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

一旦所有问题都得到了解决，合规团队就会将子任务关闭，并将原工单传递到法律审核团队。否则的话，就可能会重新过一遍流程，重新扫描代码，在生成一份新的扫描报告，以确认之前的问题不复存在。一旦确定了所有的问题均得到了解决，合规团队就会将工单传递到法律团队，以进行下一步的审核和批准。

在准备法律审核中，需要将所有的开源软件相关的许可证信息附加到合规工单，诸如 COPYING, README, LICENSE 之类的。

Stage 3: 法律审核

在法律审核阶段，法律顾问（一般也是开源审查委员会 OSRB 的成员）会审核由扫描工具所生成的报告、软件组件的许可证信息、以及合规工单中任何由工程师或审计团队留下的记录。

一个常规的合规工单到达法律审核阶段，应包含如下内容：

• 一份源代码扫描报告，并确认扫描阶段确定的所有问题都已得到解决。
• 复制工单所附加的许可证信息：典型的在源代码包中有 README、 COPYING、 AUTHORS 等文件，除了许可证信息（ OSS 组件通常在 COPYING 或 LICENSE 文件中提供）之外，还需要获取版权和归属通知。这些信息将会在最终的产品文档中提供。
• 来自合规团队的反馈（相关或额外问题等）
• 审核小组或工程师（软件包所有者）的工程代表在内部跟踪/维护该软件包的反馈。

本阶段的目标是产生合规的法律属性，且要对有问题的软件组件的加入和产出许可的决定。加入和产出许可证均是可能多次使用到的，因为即使是在相同的情况下，一个软件组件可以包含不同许可证的源代码。那么就可能会有如下三种情况的最终结果出现：

没有合规性问题

如果许可协议中没有什么合规性的问题，那么合规人员会在合规工单中创建子任务，并将其分配给相应的工程师来解决。

所谓的 incoming 许可证，是指那些贵司所使用到的外部的软件包许可证。所谓的 outgoing 许可证，则是指贵司自己发布的软件包许可证。在某些情况下，当 incoming 许可证还授权允许二次授权（如，BSD 协议），那么公司就可以将这些软件重新以私有的协议来二次许可。一种更为复杂的例子是，某款软件组件其中包含专有的代码、源代码是基于 A 许可证、源代码同时基于 B 许可证、源代码同时基于 C 许可证，那么在法律审查期间，法律顾问就需要需要决定出入许可证：

incoming 许可证= 专有许可证 + 许可证A + 许可证B + 许可证C

outgoing 许可证=？

有合规性问题

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

举例来说，在法律审核中，发现了一直以来所关注的知识产权内容已经和开源的代码打包在了一起，法律顾问就会对此进行标记，然后将该合规的工单重新分配给工程师，从而从开源的代码中移走专有的组件。此时若发生工程师坚持将专有源代码留在开源组件中的话，开源执行委员会（OSEC）则来决定是否将专有的源代码基于开源协议来发布。

无法确认是否有合规性问题

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

Stage 4: 架构审核

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

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

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

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

Stage 5: 终审

最后一步的审核通常都是面对面的会议了，参与会议的有审计团队、开源审核委员会（OSRB），通过会议来决定接受和拒绝使用某软件组件。

团队做决策的依据是软件组件的完整合规记录，其中包含的内容有：

• 一份由扫描工具所生成的源代码扫描报告。
• 一份关于所发现问题的清单，其中包含的信息有：如何被解决的信息、是谁验证过该问题被成功解决的。
• 架构示意图，以及这些软件组件是如何和其它软件组件进行交互的信息。
• 关于合格的法律选项，以及所定下来的 incoming 和 outgoing 许可证。
• 如果应用是嵌入式环境的话(C/C++)，还要考虑动静态的链接分析。

在大多数的情况下，如果一个软件组件合规流程到此终审阶段，其实基本上已经定下来了，除非出现特殊情况（如软件组件不再打算使用）。当最终终审完成通过以后，合规成员就会为该组件准备一份关于许可证义务的清单，并将该清单交付给相应的部门来履行，清单的内容包括：

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

OSRB 批准之后的步骤示意图

合规人员会监测所有处于开放状态的工单，而且要确保在产品交付或服务发起时，所有的工单都要处于关闭（完成）状态。

更多关于使用流程和可能的场景细节，请移步下载企业中的开源合规免费电子书。

v1.0 之后的事项

首次合规性的建立，其实也称之为基本的合规性创建，在开发开始的阶段进行，一直到产品的第一个版本发布。合规团队会验证所有的开源代码，合规团队识别软件基线中包含的所有开源代码，并通过前文概述的五个阶段审核流程，来实现覆盖所有的源组件。

“重要的是要牢记，开源合规性不会随着1.0版本的发布而万事大吉。” – Ibrahim Haddad，三星美国研究院研发副总裁兼开源小组负责人

在产品交付之后，还需要开发一个增量合规流程来检查源代码，当开发开始一个新的分支的时候，如增加新的功能或修复缺陷，就意味着该流程开始执行。

所谓的增量开发流程，是指产品在基准版本1.0之后增加新功能，合规处于维护状态。

和当初建立基准合规所非常不一样的地方在于，增量合规所需要做的工作要简单的多。但是仍然要重视起来，不可忽略。必须正确识别源代码在版本1.0和版本1.1之间所发生的变更，且验证版本之间的合规性增量：

• 新的软件组件被引进。
• 有旧的软件组件已经淘汰。
• 已有的软件组件可能已经更新到了更新的版本。
• 软件组件的许可证随着版本的更新也发生了变化。
• 已有的软件所发生的代码变化，从而引入漏洞修复、功能变化、乃至架构的变化。

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

• 在版本 v1.1中所新增的软件组件的名称
• 所更新的软件组件名称
• 已废弃的软件组件名称

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

• 将新的软件组件输入到以上5步使用批准流程。
• 所变更的软件要逐行比较源代码，然后决定是打算重新扫描一次源代码还是依赖上次所扫描的结果。
• 通过移除不再使用的软件组件来更新软件注册表。

增量合规流程示例

以上示意图描述了增量合规流程的宏观视角。每次产品发布的 BOM 文件均存储在构建服务器上，BOM（物料清单）差异工具将两个BOM（物料清单）文件作为输入，每个文件对应于不同的产品版本，并计算增量来生成如前所述的变更清单。

当走到此时，合规人员将为该版本中所有新版软件组件创建新的合规工单，更新源代码发生变更的合规工单，且可能的话重新走一遍流程，最后要更新软件注册表，将废弃的软件从批准的列表中删除。

开源使用请求表格

请认真严肃的完成开源使用请求表格的填写，这是开发者将开源软件带入贵司重要的一步。

开发人员填写在线表单，请求批准使用给定的开源组件。 该表单包含几个问题，这些问题将为审计团队或开源审查委员会提供必要的信息，从而允许其批准或不批准使用提议的开源组件。

开源使用请求表格 PDF 版见本节末尾，其中有一些是高亮显示的。通常情况下，我们还为大家提供了下拉列表式的选项，从而让数据更加的有效。

有兴趣的同仁，可以从以下链接下载 PDF 打印版。

写在最后

开源合规性在软件开发的流程当中是一个非常基础的部分，如果贵司在产品（无论单个还是多款）当中使用了开源软件，还没有来得及打造一个靠谱的合规团队的话，那么本文可以帮助贵司来应急。

就开源合规性的本质来讲，即是对一系列的行为进行控制的结果，如在商业产品中使用了开源之后的准入和分发。合规尽职调查的结果就是对产品中所使用的所有开源软件进行识别（组件和代码片段），且要满足相应的许可证义务。

更多开源合规性的详细内容，请移步下载由 Ibrahim Haddad 先生所写的免费的电子书：企业中的开源合规性。

架构模板图示

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

• 模块依赖
• 专有组件
• 开源组件（修改版与原生）
• 动态和静态链接
• 内核空间和用户空间
• 共享的头文件
• 通信协议
• 其它开源组件，尤指那些和软件有交互或依赖的部分，特别是使用了不同许可证书的开源组件。

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

感谢！

贡献者:

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

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