开源软件许可出毛病了？

开源软件许可出毛病了？

对于让开源软件变得如此出色的协作开发来说，开源软件许可以其不同于常规软件许可的方式提供了诸多支持。

人们在使用常规软件许可时产生的实践和期望，也许会让他们在面对开源软件时感到沮丧。“请给我看下许可证”这种简单的要求，可能得不到令人满意的答复。尽管有的时候这种答复非常简单，但开源软件的许可信息通常更为复杂，达不到常规软件许可所设定的那种期望。

这是怎么回事儿呢？开源软件许可是否出毛病了？然而并没有。许可条款类型以及软件开发方式的差异，都会导致软件许可信息的传送方式不同。律师便利性和开发人员便利性之间的折衷是造成这种状况的部分原因。

如果只是说开源软件可以“协作”开发，那还没有弄清楚开源开发活动与常规许可软件之间可能存在的差别程度。尽管有像常规许可软件一样由一个人或一个固定的小团体来维护的开源项目，但是在开源项目上的协作可能会在广泛的潜在贡献者之间进行。例如，根据 GitHub 的“2019 年 Octoverse 报告” ，有超过 35 万人对前 1000 个项目做出了贡献。但是，开源软件开发与常规许可软件开发的不同之处不仅仅是贡献者数量。除了被发现对该开源项目拥有某些共同兴趣，为开源项目做出贡献的人们之间可能没有任何联系。人们的参与情况可能会随着时间的推移而变化。原始开发人员可能会离开，留下其他人继续进行项目开发。所有这一切都可能在没有规划或总体治理组织的情况下发生。

除了遵循规范性的治理规则，开源协作活动还是轻量级的，而且可以比常规许可软件更加灵敏地响应。有关开源许可信息的实践与这种协作开发方式相适应。

  1. 针对二进制文件以及源代码，开源许可中的条款通过提供所需的权限（包括复制、修改和分发）促进了协作开发。事实证明， “开源定义” （ Open Source Definition ） （OSD）有助于将注意力集中在满足其要求的许可上。
  2. 开源软件的许可信息嵌入在源代码中。当获得源代码时，就会接收到相应的许可信息。想象一下每年以百万计的贡献规模，单独的许可管理是否完全可行呢？同样，通过将许可信息嵌入源代码中，可以反映与许可相关的详细信息，而这些细节在某些单独管理的许可流程中不可行。例如，将许可信息嵌入源代码，使得指示哪些许可条款适用于软件的哪些部分变得切实可行。

为了说明开源许可实践所能实现的效果，请考虑以下示例性软件项目：

该项目始于 5 年前；到目前为止，已有 50 位贡献者做出了贡献；通过改编其他项目中的部分软件，增加了一些功能；原始代码的开发者在三年后离开；几家商业企业已经在其内部或一部分产品中依赖该软件；如果考虑到其他软件和计算机世界方面相关的变化，则该软件未来可能还会有 5-10 年的发展。

在开源项目中现有和常用的表示许可信息的方法，很容易适应这样一个项目的过程。没有预先规划，贡献者可以从项目中来来去去；项目的各个部分遵循不同的许可条款；如果与其他公司的合作破裂，商业企业可以继续以很少的管理开销成本分担软件维护工作，同时保持完全独立开发其软件分支的能力。

相反，传统的软件许可方法将如何支持这种开发呢？甚至这样的合作有可能发生吗？我们是否将拥有一个完整的许可基础结构来跟踪数千个“主软件开发和分发协议”的适用性？我们是否要通过让某些公司控制一切来简化许可？

让我们回到“是什么许可？”这个问题。我谈论开源开发特征的目的，是说明存在重要的影响开源许可信息如何表示的非法律因素。开源软件中许可信息的表示形式通常不符合常规软件许可的期望。但是，存在差异并不代表系统出毛病了。相反，对于支持过去二十年中已被证明有效的大规模协作开发这种软件构建方法来说，差异的作用非常强大。

开源许可信息是什么样的呢？

通常，人们会考虑每个“软件组件”的许可条款。软件组件可能作为应用程序对用户可见，或者对于用户来说可能不那么明显，例如与大型程序结合使用时可提供某些功能的库。

对于许多软件组件而言，许可很简单：组件中的所有软件适用数十种最常见的开源许可证中的一种。除了最常见的许可证之外，还有很多文本有所变动的不经常使用的许可证。但是，在“开源定义”的指导下，开源许可条款中的权限和限制仍保持在一定范围内。

如果要进行将开源软件集成到其他软件中的软件开发，那么你需要了解适用于所集成软件的所有 “左版” （ Copyleft ） 条款（例如著名的 GPL 系列许可证）。

由于从我对开源软件开发方式的讨论中揭示的显而易见的原因，许可信息可能比单个许可证更为复杂。

  1. 尽管一个软件组件可能有一个主要的“项目许可”，但可能有一部分软件遵循其他许可证。这可能会导致在源代码的各个部分中出现不同的许可声明。
  2. 一些项目的做法是在每个源文件中放置版权声明。其他项目主要依靠放置包含许可文本的一个或多个文件。
  3. 版权声明指示谁可能是该软件部分的版权拥有者（但是，鉴于版权声明实践的多样性，该指示的作用可能微不足道）。
  4. 用来构建软件组件的源代码可以包括未反映在所得组件中的软件，例如与测试或构建相关的文件。这对于使用无 GPL 规则（项目中可能包含遵循 GPL 许可证的文件，但用于生成可执行程序的文件不得包含遵循GPL许可证的文件）的人可能很重要。

因为许多细节都与某些许可信息涉及的软件部分有关，这种细粒度的许可信息在源代码中最有效地进行了传达。在最详细的级别上，源代码即许可证。当许可信息在源代码中时，可以用与源代码相同的方式（例如在版本控制系统中）来维护该许可信息，并且该信息固有地可用于获得源代码的任何人。

从源代码中提取许可信息并创建许可条款概要似乎很简单。但是，对于一个人或一个公司来说足够了的摘要，可能对于另一个人或公司是不足的。不同的人可能关注不同的许可信息细节。一些人可能想确切地知道该软件的哪些组件遵循“左版”条款。其他人可能并不关心所有组件的许可条款概要。还有的人可能需要包括每个不同的版权声明在内的所有许可声明。

你想查看哪些许可信息的细节呢？在软件开发中有大量的工具可以使用。扫描、提取和报告现有许可信息的工具是持续开发的活跃主题。现在，“是什么许可？”可能会改写为“向我显示许可信息报告”，该报告可能包括一系列程度不同的详细信息，具体取决于对请求报告的人的重要性。在最详细的级别上，源代码即许可证。

因为软件可以采用不同的方式构建出来，常规软件许可和开源软件许可分别适用于不同的领域。两者之间可能存在差异，对于这一点要做好准备。

作者简介：Scott Peterson 是红帽公司法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。

译者简介：薛亮，集慧智佳知识产权咨询公司互联网事业部总监，擅长专利检索、专利分析、竞争对手跟踪、FTO 分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。