Linux基金会企业开源指南系列之八——公司如何正确的使用开源代码

法律在中国,就我个人的理解就是个玩笑,我意味Oracle CEO 近日在接受媒体的采访说的一点都不为过。全球化带来的技术红利让中国的山寨文化着实过了一把瘾。那么又如何了呢?我翻译本文的时候,都能感觉到周围人们那些无耻的嘴脸,看!他们还在笑。

特别声明

本文拥有创作共用授权之相同方式共享授权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 文件中提供)之外,还需要获取版权和归属通知。这些信息将会在最终的产品文档中提供。
  • 来自合规团队的反馈(相关或额外问题等)
  • 审核小组或工程师(软件包所有者)的工程代表在内部跟踪/维护该软件包的反馈。

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

<未完待续>

写在最后

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

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

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

架构模板图示

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

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

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

Acknowledgements

贡献者:

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

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