为什么必须将我的开源软件许可证保留在根目录下？

几乎所有开源软件许可证都要求（或者至少律师通常建议他们要求）用户将完整许可证包含在他们要保护的项目的根目录中。

与我交谈的一位律师建议，这是CD时代的遗产，当时有必要在珠宝盒中包括完整的许可证。

但是今天，我们生活在云时代。例如，为什么我不能简单地在我的网站上托管完整的许可证，而在源文件的标题中包含该许可证的标题+ URL？

奖励：如果大家普遍同意必须在根目录中保留完整的许可证，那么FSF的OSI为什么不批准您可以通过URL引用的许可证，这又是什么使某人无法创建该许可证？

通过GPL常见问题解答（但建议适用于所有许可）：

为什么GPL要求在程序的每个副本中都包含GPL副本？

在工作中包含许可证副本至关重要，这样，每个获得该程序副本的人都可以知道他的权利。

包含引用许可证的URL而不是许可证本身可能很吸引人。但是您不确定该URL从现在起五年或十年后仍然有效。从现在开始的20年后，如今我们所知道的URL可能不再存在。

确保拥有程序副本的人尽管网络中发生了所有更改，但仍然可以继续查看许可证的唯一方法是在程序中包含许可证的副本。

（强调我的）

托管您的许可证的站点关闭或更改其URL路径后，拥有您的软件副本的人将无法再验证他们可以安全行使的权利。甚至假设您可以某种方式保证确切的URL永远在线：用户验证其对您软件的使用合法的能力仍然取决于连接到该特定URL的能力。尽管此要求在您所在的城市/国家/地区可能并不繁重，但在其他地方可能繁重。您不应强加此要求，尤其是在变通办法（包括完整的许可证文本）不重要的情况下。

您可能会回答以下问题：“那该怎么办？如果URL确实出现故障或无法访问，那么像'GNU GPL v3'这样的明确描述符就足够了。GPL的全文本足够；用户可以查找许可证本身。” 马上想到一些问题：

1. 这不会泛化为不太清楚的许可证标识符（想到“ BSD许可证”一词）。

2. 对于不太常见或已定制的许可证，这不能很好地泛化（想到“带有链接例外的GPL”：哪个链接例外？）。在合理期望用户按名称可靠找到许可证之前，许可证需要有多普遍？

3. 这仍然要求用户具有Internet连接，即使在获得软件时就已经建立了连接，情况可能并非如此。（而且他们获得软件时可能还没有Internet访问权限：“ CD时代”在世界许多地方还没有结束。作为另外一种情况，请考虑具有广泛Internet访问权限但对大部分Internet进行审查的国民。）可自由分发的软件的后果是，收件人可能不会直接从您那里或通过您最初预期的分发渠道收到您的软件副本。

MichaelT在下面的评论中指出了最后一个反对许可证链接的论点：它可以让您动态，追溯地更改许可证。如果您在软件的两个版本之间更改了许可证，但是对于两个版本使用了相同的许可证链接，则这可能是有意为之的，这会使您的旧许可证不复存在。对于需要证明他们以与当前版本不同的许可证获得了较早版本的人来说，这样的转换将增加困难。

那么，为什么我必须将许可证保留在项目根目录中？

我不是律师，但是我从未见过任何令人信服的论点，即您确实需要将许可证保留在项目根目录中。甚至指定许可证必须随作品的每份副本一起发布的GPL，也没有对必须如何随作品进行沉默。（这可能是因为GPL可以应用于非软件上下文中，在这种情况下“根目录”的概念没有意义。）

将许可证保留在根目录中可能是一个好主意，因为它最大程度地增加了用户看到许可证的可能性，从而最大程度地减少了用户的挫败感以及针对试图将许可证隐藏在一些晦涩的目录中而引起投诉的可能性。如果您有许多许可证，则将它们全部放置在自己的文件夹中可能会更有意义，并包括一个显而易见的项目README，该自述文件包含用于查找每个组件的许可证的文件路径。

将许可证放置在目录根目录中也是一种有用的做法，因为它可以消除被许可的模块许可证与整个工作模块的歧义。假设我的项目FooProj使用独立模块BarMod。FooProj可能是GPL许可的，而独立模块可能是MIT许可的。当我第一次打开FooProj时，我在根目录中看到GPL的副本，并且了解整个工作都是GPL许可的。当我进入BarMod的文件夹时，在那里看到一个新的许可证文件，并且我知道此文件夹的内容是MIT许可的。当然，这只是有用的帮助。您应该始终在自述文件，通知或类似文件中明确指出模块的许可。

总之，使用文件根目录是为了方便和清楚。我还没有看到任何需要它的具有法律约束力的开放源代码许可证文本，也不知道为什么会有任何理由需要它。您的许可证应易于接收者发现；将许可证包括在项目根目录中足以满足此条件，但不是必需的。

但是今天，我们生活在云时代。例如，为什么我不能简单地在我的网站上托管完整的许可证，而在源文件的标题中包含该许可证的标题+ URL？

确实存在允许这样做的许可证。以Apache 2.0为例。Apache 2.0仅要求每个源文件都包含一个小的标头，该标头指向Apache 2.0 License的规范URL。无需在源代码树中复制完整许可证。

从Apache 2.0许可证本身开始：

APPENDIX: How to apply the Apache License to your work

To apply the Apache License to your work, attach the following boilerplate
notice, with the fields enclosed by brackets "[]" replaced with your own 
identifying information. (Don't include the brackets!) The text should be  
enclosed in the appropriate comment syntax for the file format. We also 
recommend that a file or class name and description of purpose be included 
on the same "printed page" as the copyright notice for easier identification 
within third-party archives.

    Copyright [yyyy] [name of copyright owner]

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.

没有要求它必须在项目的根目录中。这只是最常见的地方，因此人们将首先找到寻找许可证的地方。就这一点而言，即使这并不常见，人们仍然很可能会优先考虑。由于存在用于通知的许可证，因此隐藏信息没有多大意义。

如果将其隐藏在URL后面，则不能绝对保证该URL将始终可用。如果它是项目根目录中的文件，那么根据定义，它将始终可用。

简而言之，这是最有效，最人性化的地方。