您可以通过查看源代码找到开源软件的许可信息。可以生成关于该许可信息的不同视图或报告，以满足不同的需求。
虽然直接在源代码中提供许可信息不是开源软件的必要条件，但这样做的好处很快就显现出来。由于开源许可证促进了软件的传播，随代码一同传播的许可信息通过使权限声明易于获得（即使是间接获得代码的人），从而简化了管理。
许可条款是什么？
将许可信息嵌入到源代码树中的价值被低估了。让我们暂停一下，反思一下这种常见做法有多么有用 [此处请默哀片刻]。
许可条款是什么？对于大多数开源软件，答案很简单：单个许可文本包含整个软件的所有许可信息。但是，开源的力量在于它促进了其他开发者在此基础上进行构建，而这个过程可能会使许可信息变得复杂。
开源软件可以被扩展、重新利用并与其他软件组合。与机械设备不同，在机械设备上，多元化群体的协作更具挑战性，而对于复杂的软件来说，从多人的工作中获益是切实可行的。开源许可证提供了促进这种开发动态的许可。具有复杂历史的软件也可能具有复杂的许可信息。
考虑以下示例：某人编写了一个新程序，在每个源文件中都包含版权声明，声明该软件根据 Apache License 2.0 版获得许可，并在源代码树的根目录中包含 Apache License 文本的副本。之后，添加了一个文件，其中包含不同的版权声明和 BSD 2-clause 许可证的副本。然后添加了一个新的子目录，其中的文件具有 Apache 许可证声明，但版权声明标识了不同的版权所有者。然后将 MIT 许可证的副本添加到新的子目录中，该子目录包含的文件的版权声明与 MIT 许可证文件中的相同，但没有任何其他许可证指示。
这个例子表明，嵌入在源代码树中的许可信息可能既复杂又详细。根目录和/或各个子目录中可能存在许可文本。一些源文件可能带有许可声明；另一些可能没有。可能存在标识不同版权持有者的版权声明。将看似法律性的部分与代码分离可能会导致信息丢失。因此，源代码即许可。
在源代码树的上下文中看待，上面示例中许可信息的解释相当直接。然而，要用一个简单且明确的独立声明来概括这些许可信息将是具有挑战性的。一个概括源代码中所有许可信息的许可声明会比源代码短，但会很笨拙——谁会想要这样一个高度详细的独立声明呢？大多数用户可能更喜欢摘要，尽管摘要可能不完整，但它捕捉到了符合他们自身特定兴趣和敏感性的要素。
总结许可信息：视图
用整个源代码树的副本回复“许可条款是什么？”可能不会被认为是很有帮助的，因为它既庞大又分散。大多数人想要摘要。但存在一个挑战：当许可信息复杂时，人们想要不同的摘要，因为他们对什么是重要的有不同的看法。
对于某些人来说，对以下问题回答“是”可能就足够了：软件是否 1) 根据一个或多个开源许可证获得许可，以及 2) 其组装和许可方式是否使其分发和使用与所有这些许可证一致？其他人可能想要所有许可证的列表，或者他们可能想查看哪个软件组件对应于哪个许可证。还有一些人可能想要一个逐个组件的列表，其中标识了任何 copyleft 许可证（可能为了深入研究 copyleft 合规性）。还有一些人可能对查看所有版权声明和相关的软件组件列表感兴趣。
单个摘要很可能无法满足所有人的兴趣。简单地使摘要更详细可能会降低其对某些人的效用，同时对其他人来说仍然不足。因此，需要对源代码中表达的许可信息进行不同的“视图”呈现。可以将这里的视图一词理解为类似于数据库中使用的含义。或者，您可以将视图视为“报告”。
将 (a) 源代码视为许可，以及 (b) 可以从中提取多个不同视图的想法是有优势的。
您可能会尝试创建一个“万能”摘要，可以从中创建其他更短的摘要。但是，许可信息的中间表示至少有三个缺点
- 时间：该主摘要的维护者可能不会按照您的计划进行更新。
- 版本：主摘要可能基于与您使用的软件不同的版本。
- 质量：您的视图继承了主视图的错误和判断特征。
因此，按需直接从您使用的源代码树版本生成您首选的视图是有价值的。
工具可以生成视图。按需视图生成取决于工具。工具的有效性受到许可信息表示方式的清晰程度（或混乱程度）的影响（或阻碍）。我们不需要特定于机器的许可信息编码，但我们应该利用许多表示信息的经验来源，使其既可由人读取又可由机器提取。
在他的文章《开源软件许可证合规性的经济高效模型》中，Jeff Kaufman 提出了一个相关的观点：由于源代码包含许可信息，因此分发源代码可能是满足某些许可证要求的有效方法。
将所有许可信息嵌入到源代码树中是一种最佳实践。如果您发现许可信息未在源代码树中表示，请考虑提交错误报告，建议将该信息添加到源代码树中，从而改进项目。
源代码即许可。从这个完整的记录中，可以生成许可信息的视图。工具可以将许可信息提取到各种报告中，以满足特定的需求或敏感性。
为了充分利用这一愿景，我们还有工作要做。您如何看待工具和许可信息表示的现状？
1 条评论