让你的工程师选择许可证：一份指南

假设你正在一家公司工作，该公司将启动一个新的开源社区项目。太棒了！你已经迈出了积极的第一步，回馈社会并启用开源社区开发模式提供的良性创新循环。

但是为你的项目选择一个开源许可证怎么样？你向你的经理寻求指导，她提供了一些见解，但很快意识到没有正式的公司政策或指南。正如任何明智的经理都会做的那样，她要求你制定正式的公司指南，以便为这些项目选择开源许可证。

很简单，对吧？ 你可能会惊讶地发现一些意想不到的挑战。本文将描述你可能遇到的一些复杂情况，以及基于我在 Red Hat 最近的类似项目中的一些看法。

快速回顾一些更常见的开源许可形式可能很有用。开源许可证通常可以分为两个主要类别，即著佐权（copyleft）和许可型（permissive）。

著佐权许可证（例如 GPL）允许访问源代码、修改源代码以及以其原始或修改的形式分发源代码或二进制版本。此外，著佐权还规定，对于该代码的任何接收者，都将允许并确保基本的软件自由（运行、学习、更改和分发）。著佐权许可证禁止对这些基本的软件自由施加限制。

与著佐权类似的许可型许可证通常也允许访问源代码、修改源代码以及以其原始或修改的形式分发源代码或二进制版本。但是，与著佐权许可证不同，这些许可形式可能包含其他限制，包括专有限制，例如禁止创建修改后的作品或进一步分发。

Red Hat 是领先的开源开发公司之一，拥有数千名开源开发人员不断进行上游工作并为各种开源项目做出贡献。当我加入 Red Hat 时，我对它的旗舰产品 Red Hat Enterprise Linux（通常称为 RHEL）非常熟悉。尽管我完全期望公司会根据项目要求在各种许可下做出贡献，但我认为我们对工程师的首选和最高推荐是 GPLv2，因为我们与 Linux 有着密切的联系。此外，GPL 是一种著佐权许可证，著佐权确保基本的软件自由（运行、学习、更改、分发）将扩展到该代码的任何接收者。对于维持开源生态系统来说，有什么比著佐权许可证更好的呢？

在为 Red Hat 制定内部许可选择指南的过程中，最终结果是根本没有任何许可偏好。相反，我们尽可能地将这种责任委托给我们的工程师。为什么？因为每个开源项目和社区都是独一无二的，并且这些社区的社会方面可能对各种许可理念（例如，著佐权或许可型）有偏好。在这些社区工作的工程师了解所有这些问题，并且最适合根据这些知识选择适当的许可证。强制某些许可证用于代码贡献通常会与这些社区规范相冲突，并导致贡献的内容减少或被禁止。

例如，也许你的组织认为最新的 GPL 许可证（GPLv3）因其更新的条款而最适合你的公司。如果你强制对所有未来的贡献使用 GPLv3 而不是 GPLv2，你将被禁止向 Linux 内核贡献代码，因为这是一个 GPLv2 项目，并且很可能在很长一段时间内保持这种状态。你的工程师作为该开源社区项目的一部分，会知道这一点，并且在没有此类强制的情况下会自动选择 GPLv2。

底线：让工程师做出这些决定是明智且高效的。

如果你的组织可能必须限制某些许可证的使用（例如，由于某些知识产权问题），这自然应该成为你的指南或政策的一部分。我认为最好尽可能地委托给那些了解这些不同社区的所有细微差别、政治和许可理念的人，并且仅在绝对必要时才限制许可证选择。即使偏爱某种许可证而不是另一种许可证也可能存在问题。开源工程师可能对著佐权有根深蒂固的感受（无论是赞成还是反对），并且强迫使用一种许可证而不是另一种许可证（除非绝对有业务原因）可能会导致不满，并疏远你组织中的工程师或工程部门。

总而言之，Red Hat 的指南非常简单，总结如下

1. 我们建议从一组 10 种不同的许可证中选择一个开源许可证，这些许可证非常常见并且可以满足大多数新开源项目的需求。

2. 我们允许使用其他许可证，但我们要求向开源法律团队提供理由，以便我们可以收集并更好地了解我们所服务的开源社区的一些新的和可能不断变化的需求。（如上所述，我们的工程师处于前线，并且最适合提供此类信息。）

3. 开源法律团队始终有权推翻一项决定，但这将非常罕见，并且仅当我们意识到有关特定许可证或项目的某些社区或法律问题时才会发生。

4. 未经许可发布源代码是永远不允许的。

总而言之，这些指南的优点是巨大的。它们非常高效，并在我们的组织内实现了非常低摩擦的开发和审批系统。