开源项目办公室最重要的职责之一是确保您的组织在将开源代码和专有的第三方源代码集成到商业产品中时遵守其法律义务。

转载自：https://linuxfoundation.cn/using-open-source-code/

最大化在组织中运行开源计划或启动开源项目的实践。这些资源由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) 和下游供应商之间的合规性。

合规角色与责任

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

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

各个部门的其他人员也为开源合规工作提供持续的基础：文档、供应链、企业开发、IT、本地化以及监督整个开源战略的开源执行委员会(OSEC)。但与核心团队不同的是，这些扩展团队的成员仅根据开源审查委员会(OSRB) 分配的任务兼职工作。

开源审查委员会(OSRB) 负责创建开源合规策略和一组流程，以确定企业如何日常实施这些规则。该策略制定了确保合规性必须采取的步骤，并为员工如何与开源软件交互提供了一组关键原则。它包括批准、获取和使用开源的正式流程，以及开源软件或根据开源许可证授权的软件的发布。

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

使用程序是任何合规计划的重要组成部分。这套规则包含在你的开源策略文档中（你有开源策略文档，对吧？），并提供给所有人，以方便参考。

使用方法确保构成产品基础的任何软件（专有的、第三方的或开源的）都经过审查、审查和批准。这种方法还可以确保您的公司制定计划，在产品到达客户之前履行因使用各种软件组件而产生的许可义务。

无需创建冗长或复杂的文档。使用开源的好方法包括六个简单的规则：

在将开源代码集成到产品中之前，工程师必须获得开源审查委员会(OSRB) 的许可。从第三方收到的软件必须经过审查，以识别其包含的所有开源代码，从而确保在产品发货之前履行许可义务。所有软件都必须经过审查和审查，包括所有专有软件组件。产品在交付给客户之前必须履行开源许可义务。即使开源组件相同，在一个产品中使用给定开源组件的许可证并不等同于其他部署的许可证。任何更改的组件都必须经过批准流程。

代码审查过程的五个阶段

一旦开发了一种方法，就必须规划和创建一个流程，以便更容易地应用该方法的规定。你的工作是帮助开发者顺利实现开源应用程序并为开源项目做出贡献。

“如果你的代码审查过程过于繁琐，你就会放慢创新速度，或者给开发人员一个很好的借口来完全避免这个过程。”

Ibrahim Haddad 三星美国研究院研发副总裁兼开源小组负责人该流程首先扫描相关软件包的源代码，然后继续识别并解决发现的任何问题。它还进行法律和架构审查，并提供相关的使用许可来做出决策。

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

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

阶段 1：源代码扫描

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

此阶段通常在工程师提交在线使用表时开始。 （请参阅下面的示例使用表单和使用规则。）此表单包含有关相关开源组件的所有信息，并指定源代码在源代码存储库系统中的位置。

表单提交后，JIRA或Bugzilla等系统中将自动创建合规工单，并将源代码扫描请求发送给指定的审核员。还应每隔几周进行一次定期的全平台扫描，以确保没有相应形式的开源软件组件不会集成到平台中。如果发现任何问题，将自动发出JIRA 票证并分配给审核员。

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

传入的使用表格，通常由工程人员填写。定期安排全平台扫描。此类扫描对于发现隐藏在软件平台中的开源代码非常有用，而无需使用表单。对先前批准的软件组件的更改。在许多情况下，工程师使用特定版本的OSS 组件开始评估和测试工作，并在新版本可用时采用该组件。源代码是从第三方软件供应商那里获得的，他们可能会也可能不会公开开源。新的专有软件组件进入开发系统，在该系统中，工程人员可能会也可能不会借用开源代码并将其用于专有软件组件。扫描代码后，扫描工具会生成一份报告，其中提供以下信息：

已知正在使用的软件组件，也称为软件物料清单(BoM) 有效许可证、许可证文本和义务概述须遵守法律验证许可证冲突文件列表已识别的文件依赖项代码与要识别的文件的源相匹配代码匹配下载的开源软件包的待识别说明：

将从网页下载的开源软件包归档为其原始形式至关重要。这些包将在稍后阶段（分发阶段之前）使用，通过计算原始包和修改包之间的差异来验证和跟踪源代码中引入的所有更改。

如果第三方软件供应商使用开源软件，则将代码集成到产品中的产品团队必须提交一份开源使用表，描述所使用的开源代码。如果第三方软件供应商只提供二进制代码而不提供源代码，则负责管理第三方软件供应商关系的产品团队和/或软件供应商经理必须获得许可，以确保第三方软件供应商中不存在开源代码。由供应商提供的软件。确认（例如扫描报告）。

阶段 2 ：识别和解决

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

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

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

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

阶段 3：法律审查

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

访问许可证=独占许可证+许可证A+许可证B+许可证C

颁发许可证=?

问题：如果发现许可证问题，例如许可证不兼容的混合源代码，法律顾问将标记这些问题，并在JIRA 中重新分配合规票证给工程师重写代码。例如，法律审查可能会发现受到密切关注的知识产权已与开源代码包结合在一起。法律顾问将对此进行标记，并将合规票证重新分配给工程师，以从开源组件中删除专有源代码。如果工程师坚持将专有源代码保留在开源组件中，则开源执行委员会(OSEC) 将需要在开源许可证下发布专有源代码。不确定是否有问题：在某些情况下，如果许可证信息不清楚或不可用，法律顾问或工程人员可能需要联系项目维护人员或开发人员以澄清歧义并识别特定的软件组件。它是由哪个许可证授权的。

阶段 4 ：结构审查

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

开源组件（“按原样”使用或经过修改） 专有组件来自第三方软件供应商的组件组件依赖性通信协议特定软件组件与其他开源代码包交互或依赖其他开源代码包，尤其是当它由不同的开源代码包许可时许可管理结构审查的结果是对许可义务的分析，许可义务可能从开源软件组件扩展到专有代码或第三方软件组件（以及跨开源组件）。

阶段 5 ：最终审查

最终审查通常是与审计团队或开源审查委员会(OSRB) 举行的会议，会议期间团队批准或拒绝使用软件组件。

团队的决策基于软件组件的完整合规性记录，其中包括以下内容：

由扫描工具生成的源代码报告。发现问题列表、有关如何解决问题的答案以及谁验证了问题已解决。有关软件组件如何与其他软件组件交互的架构图和信息。有关合规性和访问许可决策的法律建议。动态和静态链接分析（如果适用于嵌入式环境（C/C++））。在大多数情况下，如果软件组件到达最终审查阶段，除非出现特殊情况（例如软件组件不再使用），否则它将获得批准。一旦获得批准，合格的工作人员将为批准的软件组件准备一份许可义务清单，并将其提交给适当的部门以履行义务。

该列表可以包括：

更新软件清单以反映特定OSS 软件组件版本x 已被批准在产品y 的版本z 中使用。向文档团队发出票证，以更新产品文档中的最终用户注释，以反映产品或服务正在利用开源代码。在产品发货前触发分销流程。

OSRB 批准后完成的步骤

合规人员监控所有未完成的工作订单，并确保在产品发货或启动服务时完成工作订单。

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

在 1.0 版本之后该做什么

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

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

Ibrahim Haddad 三星美国研究院研发副总裁兼开源小组负责人产品发货后，您还需要开发增量合规流程来检查源代码。当开发从包含附加功能和/或错误修复的新分支开始时，此过程就开始了。

增量合规流程是在将产品功能添加到基线版本1.0 时维持合规性的流程。

增量合规性

与建立基线合规性所需的工作相比，增量合规性需要相对简单的工作。但仍然可能会出现一些挑战。您必须正确识别版本1.0 和版本1.1 之间更改的源代码，并验证版本之间的合规性增量：

引入了新的软件组件。现有的软件组件已被停用。现有的软件组件可能已升级到较新的版本。软件组件许可证可能在版本之间发生变化。现有软件组件可能具有与漏洞修复相关的代码更改，或功能和架构更改。一个明显的问题是：我们如何跟踪这些变化？答案很简单：物料清单(BOM) 差异工具。给定产品1.1 版本的BOM 和1.0 版本的BOM，我们计算增量，工具的输出如下：

版本1 中添加的新软件组件的名称更新的软件组件名称旧软件组件名称有了这些信息，实现增量合规性将是一项相对容易的任务：

将新软件组件输入五阶段的使用审批流程。逐行计算更改的软件组件中的源代码差异，并决定是要再次扫描源代码还是依赖上次扫描的结果。通过删除不再使用的软件组件来更新软件注册表。下图概述了增量合规流程。每个产品版本的物料清单文件都存储在构建服务器上。 BOM 差异工具将两个BOM 文件作为输入，每个文件对应不同的产品版本，并计算增量以生成更改列表，如前所述。

此时，合规人员将为该版本中的所有新版本的软件组件创建新的合规票证，使用源代码更改更新合规票证，并可能通过此过程重新路由它们，最后更新软件注册表，从删除退役的软件组件批准名单。

增量合规流程示例

开源使用请求表单

填写开源使用申请表是开发人员向贵公司引入开源软件的重要一步，应认真对待。

开发人员填写在线表格以请求批准使用给定的开源组件。该表格包含几个问题，将为审计团队或开源审查委员会提供必要的信息，以批准或拒绝开源组件的拟议使用。

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

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

此表单仅适用于特定产品和环境中的开源使用。这并不是普遍认可开源组件适用于所有产品的所有用例。该表单是审核活动的基础，提供审核团队所需的信息，以验证实际性能与表单中表达的使用计划一致，并与审核和架构审核结果一致。每当该特定开源组件的计划使用发生变化时，就必须更新并重新提交表单。在工程师将开源组件集成到产品开发中之前，审计团队或审查委员会必须批准该表格。开源执行委员会必须批准使用其许可条款要求授予专利许可或专利无争议条款的任何开源软件包。开源使用请求表示例：

结语

开源合规性是软件开发过程的重要组成部分。如果您在产品中使用开源软件，并且没有制定值得信赖的合规计划，那么您应该将此指南视为行动号召。

从本质上讲，开源合规性由一组控制商业产品中使用的开源的访问和分发的行为组成。合规尽职调查的结果是识别产品中使用的所有开源（组件和代码片段），以及履行许可义务的计划。有关开源合规性的详细指南，请下载我们的免费电子书，作者Ibrahim Haddad 的《企业中的开源合规性》。

架构图模板

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

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

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