容器、GPL 和著作权：无需担忧

尽管开源已完全成为主流，但新的软件技术和重新普及的旧技术有时会引发人们对开源许可的担忧。 最常见的担忧是关于 GNU 通用公共许可证 (GPL)，特别是其著作权要求的范围，这通常被描述为（有些误导性地）GPL 的衍生作品问题。

一种不完善的提出问题的方式是，GPL 许可的代码在某种意义上与专有代码结合时，是否会形成一个修改后的作品，以至于专有代码可能被解释为受 GPL 条款的约束。 虽然我们尚未看到太多针对 Linux 容器的担忧，但我们预计随着容器采用率的持续增长，将会有更多问题被提出。 但相当容易证明，容器没有引发新的或令人担忧的 GPL 范围问题。

法规和判例法在解释像 GPL 这样的许可证方面提供的帮助很少。 另一方面，我们许多人非常重视自由软件基金会 (FSF) 的解释性观点，FSF 是 GPL 的起草者和管理者，即使在 FSF 不是相关软件的版权持有人的典型情况下也是如此。 除了是许可证文本的作者之外，FSF 多年来一直致力于为社区提供有关其许可证的评论和指导。 其观点基于其公共利益使命和在自由软件政策方面的领导地位，具有特殊的信誉和影响力。

FSF 关于 GPL 解释的现有指南与理解在容器中包含 GPL 和非 GPL 代码的效果有关。 FSF 在考虑著作权范围时强调了进程边界，以及多个软件组件之间通信的机制和语义，以确定它们是否足够紧密地集成在一起，以被视为 GPL 目的的单个程序。 例如，GNU 许可证常见问题解答 认为管道、套接字和命令行参数是通常暗示分离的机制（在没有足够“紧密”通信的情况下）。

考虑容器中 GPL 代码和专有代码可能共存并执行的情况。 容器本质上是一个隔离的用户空间堆栈。 在 OCI 容器镜像格式 中，代码被打包为一组文件系统变更集层，其中基础层通常是一个精简的传统 Linux 发行版，没有内核。 与非容器化 Linux 发行版的用户空间一样，这些基础层总是包含许多 GPL 许可的软件包（GPLv2 和 GPLv3），以及根据被认为与 GPL 不兼容的许可证许可的软件包，并且通常充当专有应用程序以及开源应用程序的运行时。 GPLv2 中的 “纯粹聚合”条款（以及其在 “聚合” 上的 GPLv3 对应条款）表明，这种类型的组合通常是可以接受的，在 GPL 下是专门考虑的，并且对两个程序的许可没有影响，假设不兼容许可的组件是独立的。

当然，在给定的情况下，两个组件之间的关系可能不是“纯粹聚合”，但这对于在 Linux 系统上的非容器化用户空间中运行的软件也是如此。 容器或容器镜像的技术构成中没有任何内容表明需要应用特殊形式的著作权范围分析。

由此可见，当查看在容器中运行的代码与在容器外运行的代码之间的关系时，“分离且独立”的标准几乎肯定得到满足。 代码将作为单独的进程运行，并且使用容器的整个技术要点是与其他在系统上运行的软件隔离。

现在考虑两个组件（一个 GPL 许可的和一个专有的）在单独但可能相互作用的容器中运行的情况，可能是作为使用 微服务 架构设计的应用程序的一部分。 在没有非常不寻常的事实的情况下，我们不应期望看到著作权范围扩展到多个容器。 单独的容器涉及单独的进程。 容器之间通过网络接口进行的通信类似于管道和套接字等机制，多容器微服务场景似乎排除了 FSF 所谓的“紧密”通信的定义。 使用多个容器的应用程序的组成可能不是 GPL 范围问题的决定性因素，但它使组件之间的技术边界更加明显，并为论证分离性提供了强有力的基础。 在这里，容器也没有任何技术特征表明需要应用不同且更严格的著作权范围分析方法。

一家过度担心分发 GPL 许可代码的潜在影响的公司可能会尝试禁止其开发人员将任何此类代码添加到计划分发的容器镜像中。 就避免根据 GPL 分发代码的目的而言，这是一种值得怀疑的策略。 如上所述，传统容器镜像的基础层将包含多个 GPL 许可的组件。 如果公司将容器镜像推送到注册表，通常无法保证这不会包括基础层，即使它是广泛共享的。

另一方面，该公司可能会决定采用容器化作为限制著作权范围问题的一种手段，通过隔离 GPL 和专有代码——尽管人们会希望技术优势能够推动这一决策，而不是可能基于对 GPL 的毫无根据的焦虑的法律担忧。 虽然在非容器化环境中，两个交互式软件组件之间的关系通常只是纯粹的聚合，但容器提供的分离性证据可能会让那些担心 GPL 范围的人感到安慰。

共享容器镜像时可能会出现开源许可证合规义务。 但容器在技术上没有什么不同或独特之处会改变这些义务的性质或使其更难满足。 关于著作权范围，容器化如果有什么作用的话，应该可以缓解格外谨慎的人的担忧。