odis工程师许可证_让您的工程师选择许可证：指南

odis工程师许可证

想象一下，您正在为一家公司工作，该公司将开始一个新的开源社区项目。 大！ 您已迈出了积极的第一步，以回馈并实现基于开源社区的开发模型所提供的创新的良性循环。

但是，如何为您的项目选择开放源代码许可证呢？ 您要求您的经理提供指导，她提供了一些见解，但很快就意识到没有正式的公司政策或指南。 就像任何明智的经理一样，她要求您制定正式的公司准则，为此类项目选择开放源代码许可证。

简单吧？ 学习一些意想不到的挑战，您可能会感到惊讶。 本文将基于我最近在Red Hat进行的类似项目的经验，描述您可能会遇到的一些复杂性和一些观点。

快速查看一些更常见的开源许可形式可能会很有用。 开源许可证通常可以放在两个主要的存储桶中：copyleft和宽松。

Copyleft许可证（例如GPL）允许访问源代码，对源进行修改以及以原始或修改形式分发源或二进制版本。 Copyleft还提供了该代码的任何接收者都必须允许并确保基本的软件自由（运行，学习，更改和分发）。 Copyleft许可证禁止限制或限制这些基本软件自由。

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

红帽是领先的开源开发公司之一，成千上万的开源开发人员不断在上游工作，并为各种开源项目做出了贡献。 当我加入Red Hat时，我对它的旗舰Red Hat Enterprise Linux产品（通常称为RHEL）非常熟悉。 尽管我完全希望该公司根据项目要求提供各种各样的许可，但是我认为由于我们对Linux的大量参与，我们对工程师的首选和最高推荐将是GPLv2。 此外，GPL是Copyleft许可，Copyleft确保将基本软件自由（运行，学习，更改，分发）扩展到该代码的任何接收者。 在维护开源生态系统方面，有什么比版权左许可更好？

在我为Red Hat制定内部许可选择指南的过程中，我前进很快，最终结果是根本没有任何许可偏好。 相反，我们将这种责任最大程度地委托给我们的工程师。 为什么？ 因为每个开源项目和社区都是唯一的，并且这些社区在社会方面可能偏向于各种许可哲学（例如，copyleft或宽松的）。 在这些社区中工作的工程师了解所有这些问题，并且最有能力根据此知识选择适当的许可证。 授予某些代码贡献许可证通常会与这些社区规范相抵触，并导致减少或禁止贡献内容。

例如，也许您的组织认为，由于其最新规定，最新的GPL许可证（GPLv3）最适合您的公司。 如果您将GPLv3委托给将来的所有贡献（与GPLv2相比），那么您将被禁止向Linux内核贡献代码，因为那是一个GPLv2项目，并且很可能会保持很长时间。 作为该开源社区项目的一部分，您的工程师会知道这一点，并且在没有此类授权的情况下会自动选择GPLv2。

底线：使工程师能够做出这些决定是明智而有效的。

如果您的组织可能必须限制某些许可证的使用（例如，由于某些知识产权问题），这自然应该成为您的准则或政策的一部分。 我认为最好是最大程度地委派那些了解这些不同社区的所有细微差别，政治和许可哲学并仅在绝对必要时限制许可选择的人。 即使优先于某个许可证而不是另一个许可证也可能会出现问题。 开源工程师可能对版权左移（支持或反对）有根深蒂固的感觉，而将一个许可强加于另一个许可（除非出于业务原因绝对必要）可能会导致产生恶意并排斥组织内的工程师或工程部门

总之，红帽的准则非常简单，总结如下：

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

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

3. 开源法律团队始终有权推翻决定，但这是非常罕见的，只有在我们意识到有关特定许可或项目的某些社区或法律问题时，这种情况才会发生。

4. 禁止未经许可发布源代码。

总之，这些准则的优点是巨大的。 它们非常高效，并导致我们组织内部的摩擦开发和审批系统非常低。

翻译自: https://opensource.com/article/19/2/choose-open-source-license-engineers

odis工程师许可证