提要：对于开源软件来说，其许可证信息内嵌在源代码中。为了降低复杂性，您可以生成不同的视图。
您可以通过查看源代码找到开源软件的许可证信息。为了满足不同的需求，可以生成关于该许可证信息的不同视图或报告。
尽管直接在源代码中提供许可证信息并不是开源软件的必要条件，但是这样做的实际好处显而易见。由于开源许可证促进了软件的传播，与代码一起传输的许可证信息简化了管理过程，即使代码接收人通过间接方式获得代码，也可以使他随时可以获得权限声明。
什么是许可证条款？
在源码树中嵌入许可证信息的价值被低估了。让我们暂停一下，反思一下这种常见做法是多么有用。
什么是许可证条款呢？ 对于许多开源软件来说，有一个简单的答案：一个许可证文本包含整个软件的所有许可证信息。但是开源的力量在于，它推动了其他开发者在这个起点之上进行构建，而这个过程会使许可证信息复杂化。
开源软件可以被扩展、再利用，或者与其他软件结合使用。与机械设备不同，不同群体之间的合作更具挑战性，复杂软件从许多人的工作中受益是切实可行的。开源许可证提供了促进这种开发动态的权限。具有复杂历史的软件也可能具有复杂的许可证信息。
考虑下面的例子：有人写了一个新的程序，在每个源文件中包含一个版权声明，声明该软件根据 Apache 2.0 版许可证进行许可，并且在源码树的根目录中包含 Apache 许可证文本。之后，添加了一个具有不同的版权声明的文件，以及一个 BSD 2 句版许可证副本的文件。然后，添加了一个新的子目录，其中文件具有 Apache 许可证声明，但具有标识不同版权所有者的版权声明。再之后，一个 MIT 许可证的副本添加到了新的子目录中，该子目录包含了版权声明与 MIT 许可证文件中相同的文件，但没有任何其他许可证指示信息。
这个例子表明，嵌入在源码树中的许可证信息可能很复杂而且很详细。根目录和/或各个子目录中都可能有许可证文本。一些源文件可能有许可证通知；其他源文件可能不会有。也许会有版权声明来识别各种版权所有者。但是，在不丢失信息的前提下将法律文本从代码中分离出来似乎是不可能的。因此，源代码即是许可证。
从源码树的角度来看，上面例子中对许可证信息的解释是非常简单的。但是，要在简单、明确的独立声明中获取许可证信息将是一件困难的事情。截取了源代码中所有许可证信息的许可证声明会比源代码更短，但这将是不方便的——谁会希望得到如此高度详细的单独声明？大多数用户可能会更喜欢一个概要，虽然不完整，但其获取的关键点符合自己的特定意图和敏感性要求。
用视图来概括许可证信息
对于“许可证条款是什么”这个问题，用整个源码树副本来回答可能没什么用，因为它过于庞杂和分散。大多数人只想要一个概要。但这面临一个挑战：当许可证信息比较复杂时，人们需要不同的概要，因为他们对于什么是重要的有不同的定义。
对于某些人来说，对以下问题回答“是”可能是足够的：该软件 1）是否根据一个或多个开源许可证获得许可，2）其被组装和许可后是否使得其分发和使用与所有这些许可证一致？ 其他人可能需要所有许可证的列表，或者他们可能想要查看哪个软件组件对应于哪个许可证。还有一些人可能想要一个逐个组件的列表来标识任何 左版 （ copyleft ） 许可证（也许自己要做深入的左版合规研究）。 有些人可能有兴趣看到所有版权声明和软件组件的相关列表。
单一的概要可能不会满足所有人的利益。简单地将概要具体化可能会减少它对一些人的效用，而对其他人则显得不足。因此，需要将源代码中包含的许可证信息展现为不同的 “视图” （ views ） 。这里使用的“视图”术语可以视为与在数据库中使用它相似。或者，您也可以将“视图”看作是 “报告” （ reports ） 。
考虑将源代码作为许可证有一个优势，并且可以从中提取多个不同的视图。
您可能会尝试创建一个“全能”概要，从中可以创建其他较短的概要。但是以中间状态表达许可证信息至少有三个缺点：
因此，根据需要直接从您使用的源码树版本生成您的首选视图是有价值的。
有工具可以生成视图。按需视图的生成取决于工具。许可证信息展示的清晰（或混乱）程度会促进（或妨碍）该工具的功效。我们不需要许可证信息的特定机器编码，但是我们应该充分利用众多经验来源，以既可以被人读取，也可以被机器提取的方式来表达信息。
Jeff Kaufman 在他的文章《开源软件许可证合规的经济高效模型》中指出：由于源代码包含许可证信息，因此分发源代码是满足某些许可证要求的有效方式。
将所有许可证信息嵌入到源码树中是最佳实践。如果您发现源码树中没有显示许可证信息，请考虑通过提交错误报告来改进该项目，建议将该信息添加到源码树中。
源代码即是许可证。从完整的记录中，可以生成许可证信息的视图。工具可以将许可证信息提取到各种报告中，以满足特定需求或敏感性要求。
为了获得这个愿景的全部好处，我们还有工作要做。您对工具状态以及许可证信息展现有什么看法呢？
作者简介：Scott Peterson 是红帽公司法律团队成员。很久以前，一位工程师就一个叫做 GPL 的奇怪文件向 Scott 征询法律建议，这个致命的问题让 Scott 走上了探索包括技术标准和开源软件在内的协同开发法律问题的纠结之路。
译者简介：薛亮，集慧智佳知识产权咨询公司高级咨询师，擅长专利检索、专利分析、竞争对手跟踪、FTO分析、开源软件知识产权风险分析，致力于为互联网企业、高科技公司提供知识产权咨询服务。
