提要：想要知道开源许可证对 Linux 容器有什么影响吗？以下问题您需要了解。

尽管目前开源软件已经成为主流，但是不断涌现的软件新技术以及重新流行的旧技术有时也会引发对开源许可证的强烈担忧。大多数情况下，大家关注的焦点是 GPL 许可证，特别是经常（有时是误导性的）被描述为 GPL 衍生作品问题的 左版 （ copyleft ） 范围问题。

将该问题结构化的一个不完美方式是：遵循 GPL 许可证的代码在某种意义上与专有代码相结合，形成一个单独的修改后作品，是否可以解释为该专有代码受到 GPL 许可证的约束？虽然我们还没有看到很多针对 Linux 容器的问题，但随着容器的采用持续增长，我们预计会有更多的问题提出来。不过，有相当简单的方式可以表明，容器不会引发新的或有关 GPL 范围的问题。

法规和判例在解释类似 GPL 这样的许可证方面几乎没有什么帮助。另一方面，即使是在自由软件基金会（FSF）不是相关软件版权持有者的典型情况下，我们中的许多人也重视 FSF 作为 GPL 起草者和管理者的解释性观点。除了作为许可证文本的作者之外，FSF 多年来一直致力于向社区提供有关许可证的评论和指导。基于自由软件政策的公共利益使命和领导力，FSF 的观点具有特殊的可信度和影响力。

FSF 关于 GPL 解释的现有指导，有助于理解在容器中将 GPL 代码和非 GPL 代码包含在内所产生的效果。FSF 在界定左版范围时重点考虑了进程的边界，以及多个软件组件之间的通信机制和语义，以确定它们的紧密集成程度是否足以被视为 GPL 意义下的单个程序。例如，GNU 许可证常见问题解答认为，在没有足够 “密切” （ intimate ） 通信的情况下，管道、套接字和命令行参数通常可以被隐含认为是具备独立性的机制。

考虑容器中有 GPL 代码和专有代码可能共存并执行的情况，实际上，容器是一个孤立的用户空间栈。在 OCI 容器映像格式中，代码被打包为一组文件系统的变更层，基本层通常是一个没有内核的精简传统 Linux 发行版。与非容器化的 Linux 发行版的用户空间一样，这些基本层包括许多遵循 GPL 许可证（GPL v2 以及 GPL v3）的软件包，以及许多遵循被认为与 GPL 不兼容许可证的软件包，并且通常作为专有以及开源应用的运行环境。GPL v2 中“ 单纯聚合 （ mere aggregation ） ”条款（以及 GPL v3 中有关“聚合”的条款）表明，这种组合通常是可以被接受的，在 GPL 中进行了特别考虑，如果不兼容的被许可组件是分离和独立的，就不会影响两个程序的许可。

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

因此，当考察运行在容器中的代码和运行在容器外面的代码之间的关系时，几乎肯定会满足“分离和独立”的标准。代码将作为单独的进程运行，使用容器的整个技术要点是与运行在系统上的其他软件隔离。

现在考虑两个组件的情况，其中一个遵循 GPL 许可证，另一个为专有软件，它们运行在分离但可能交互的容器中，也许作为使用微服务体系结构设计的应用程序的一部分。在没有特别不寻常事实的情况下，我们不应该期望看到左版的范围跨越多个容器。分离的容器涉及分离的进程。通过网络接口在容器之间进行通信类似于管道、套接字等机制，多容器微服务场景似乎排除了 FSF 所定义的“密切”通信。使用多个容器的应用程序的组成可能不是 GPL 范围问题的决定因素，但它使组件之间的技术边界更加明显，并为争论“分离性”提供了强有力的基础。这其中也没有容器的技术特征暗示对左版的范围分析应用不同或更严格的方法。

过度关心分发 GPL 代码潜在影响的企业可能会试图禁止其开发人员将任何此类代码添加到计划分发的容器映像中，目的就是为了避免依据 GPL 许可证分发代码，但这是一个容易受到质疑的策略。如上所述，常规容器映像的基础层将包含多个遵循 GPL 的组件。如果该公司将容器映像推送到注册表中，通常无法保证这其中不包含基础层，即使它被广泛共享。

另一方面，通过隔离 GPL 代码和专有代码，企业可能会决定采用容器化作为减少左版范围影响的一种手段，虽然人们希望基于技术上的益处，而不是莫须有的对 GPL 焦虑所带来的法律担忧来推动该决策。而在非容器化环境中，两个相互作用的软件组件之间的关系往往是单纯聚合，容器化所提供的“分离性”证据可能让那些担心 GPL 范围的人们感到安慰。

共享容器映像时，可能会出现开源许可证合规义务问题。但是，对于容器来说，没有什么技术上的不同或独一无二的东西可以改变这些义务的性质，或者使它们更难满足。关于左版的范围，容器化应该能够缓解过度的担忧。