开源软件许可协议_开源软件许可是否被破坏？

最新推荐文章于 2021-06-24 11:39:50 发布

cumj63710

最新推荐文章于 2021-06-24 11:39:50 发布

阅读量222

点赞数

文章标签： java 大数据 python 人工智能编程语言

原文链接：https://opensource.com/article/20/2/open-source-licensing

版权

开源软件许可协议

在面对开放源代码软件时，人们可能会在使用常规软件许可方面发展出的实践和期望可能会导致挫败感。可能会出现不满意的请求，即“请给我看一下许可证”。尽管有时响应非常简单，但开放源软件的许可信息通常更为复杂，与常规软件许可所设定的期望不符。

这是怎么回事？开源软件许可是否被破坏？不会。不仅是许可条款类型的差异，而且软件开发方式的差异也会导致软件许可证信息的传送方式不同。部分原因是律师便利与开发人员便利之间的权衡。

要说开放源代码软件可以“协作”开发，还没有开始抓住开放源代码开发活动与常规许可软件可能有所不同的程度。尽管有些开源项目像传统许可的软件一样由一个人或一小组固定的人来维护，但是在开源项目上的协作可能会在广泛的潜在贡献者之间进行。例如， GitHub的 2019年Octoverse年度报告称，有350,000人参与了前1000个项目。但是，与传统授权软件的开发不同的，不仅仅是贡献者的数量。为开源项目做出贡献的人们之间可能没有任何联系，除非他们发现了对该软件项目的某些共同兴趣。参与可能会随着时间而发展。原始开发人员可能会继续前进并离开其他人继续进行项目开发。所有这一切都可能在没有规划或总体治理组织的情况下发生。

开源协作活动不仅可以遵循规范性的治理规则，而且不仅轻量级，而且可以比常规许可软件更加灵敏地响应。有关开源许可证信息的实践适用于这种协作开发。

开源许可证中的术语通过提供所需的权限（包括复制，修改和分发），不仅针对二进制文件，而且还针对源代码，从而促进了协作开发。事实证明，开源定义有助于将注意力集中在满足其要求的许可证上。
开源软件的许可证信息嵌入在源代码中。当获得源代码时，便会接收到相应的许可证信息。想象一下，以每年数百万的捐款规模，单独的许可证管理是否完全可行？而且，通过将许可证信息嵌入源代码中，该许可证信息可以反映与许可证相关的详细信息，而这些细节在某些单独管理的许可证处理中不可行。例如，嵌入源代码使得指示哪些许可条款适用于软件的哪些部分变得切实可行。

为了说明开放源代码许可证实践可以实现的效果，请考虑以下示例软件项目：该项目始于5年前；如今已开始实施。到目前为止，已有50位贡献者做出了贡献；通过改编其他项目中的软件部分，增加了一些功能；原始代码的开发者在三年后继续前进；几家商业企业已经在其产品之一或内部依靠该软件；如果进行更新以考虑其他软件和计算机世界相关方面的变化，则该软件的未来可能会有5-10年的发展。

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

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

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

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

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

如果要进行将开放源代码软件集成到其他软件中的软件开发，则需要了解适用于要集成的软件的所有copyleft术语（例如著名的GPL系列许可）。

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

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

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

您想查看哪些许可证信息详细信息？软件开发具有丰富的工具。存在扫描，提取和报告许可证信息的工具是持续开发的活跃主题。现在，“许可证是什么？” 可能会改写为“向我显示许可证信息报告”，其中该报告可能包括一系列不同的详细信息，具体取决于对请求报告的人的重要影响。在最详细的级别上，源代码是许可证。

常规软件许可和开源软件许可针对不同的领域-以不同的方式构建软件。做好准备有不同的期望。