在GitHub项目中声明多个许可证

多年来，我一直非常热衷于为在线共享的内容添加许可证，以使其他人更容易确定是否以及如何重用这些内容。在GitHub开始轻轻地“推动”其用户在其存储库中包含LICENSE文件之前，我真的不知道如何用代码来做到最好，尤其是在GitHub上公开共享的代码！–但是从那时起，我一直在尝试充分利用LICENSE文件。

我现在处于与其他人一起从事一个小项目的情况下，这需要提及多个许可证（由于第三方代码和库以及非代码文件）。当我的合作伙伴相当“草率地”处理该问题时，有人建议我“将代码按原样联机，没人会在意”，但我宁愿做得很好。问题是：我不知道应该如何在GitHub上提到几个（不同的）许可证。

我在GitHub上看到了几种不同的解决方案，这就是为什么我很难判断这个稍有不同的问题的答案是否具有权威性。我想知道的是，以下哪个（如果有）是最常见的，或者是否还有其他其他方式可以做到这一点。

创建一个单独的LICENSE文件，并在其中放置所有不同许可证的描述。（问题：应该以特定的顺序放置它们吗？我是否要从文件开头提到其中包含的所有许可证的名称，以便进行更好的概述）？
创建每个许可证一个许可证文件使用，并为它们命名LICENSE.md，LICENSE.LibNameA.md，LICENSE.AssetsB.md等，建议在链接的答案。（问题：命名将基于项目名称？不是许可证名称？如果我对自费材料使用了多个许可证，我是否会在“主要”中提及所有许可证LICENSE.md？如果没有，我该怎么做？）
创建两个许可证文件：一个列出“主要”内容的许可证，即自己创建的所有代码/资产；一种用于所有第三方材料。（以上问题：是否会使用一种特定的命名方案，以及列出第三者资料的顺序？）

最后，如果我正确理解了有关其Licenses API 的各种GitHub说明和项目，那么在确定回购协议的许可证时，只会考虑“主” LICENSE文件（尽管我无法弄清楚会选择哪个许可证）如果提到了几个）。

licensing github

— y
source

因此，请准备一份自述文件和一个或多个许可文件。这不是火箭科学。

— 罗伯特·哈维

关于链接页面：它与许可证文件的分发无关，它与GitHub的Licenses API有关，后者确定/报告回购协议的许可证。正如我在特别询问有关在GitHub上进行许可/使用LICENSE文件（而不是一般而言是开放源代码或git）的问题一样，“描述”开放源代码项目并在其中进行许可的方式也很相关。顺便说一句，尤其是“这不是火箭科学”并不是特别有用。不在我针对GitHub的问题中。

— 凯

我可能会建议您的自述文件中有一个关于许可的部分，仅说明存在多个许可，并为每个许可通知其所在的许可文件的名称？

— Erik Eidt 2015年

@immibis我知道这一点，而这根本不是我的问题。我专门问一个关于“哪种方式对人类最有意义”的答案（在GitHub上）。

— 凯

@immibis：“没有编译器会读取它”-问题是严格来说，对于Github来说不是这样。Github确实使用自动工具来确定应用于存储库内容的“ the”许可证。这样确定的许可证名称将显示在存储库的标题栏中，以及一些更一般的信息，这些信息为访问者提供了对该项目的基本印象（例如，贡献者和发行者的数量）。

— OR Mapper

Answers:

您可以使用任何机制来包含所需的那些许可证，只要您的项目的访问者可以清楚地知道哪个许可证适用于项目的哪个部分。

我的偏好是：

将您使用的每个第三方库放在其自己的目录中。该目录应包含库分发中的所有文件，包括许可证和自述文件。
在您自己的许可证文件中，仅引用您自己代码的许可证
在项目的自述文件中，提及您使用的第三方库以及每个库的分发许可。有关完整许可证的详细信息，请参阅库目录中的许可证文件。

— 巴特·范·恩根·舍瑙
source

在这种情况下，如果对自己的内容进行双重许可，您将如何处理自己的许可文件？也就是说，如果您对项目的不同部分（代码与媒体文件）使用了不同的许可证，或者是否要在两个（或更多）不同的软件许可证下分发代码？在README中放入其他信息非常有意义，这也是我要做的事情，但是我对如何处理GitHub上的LICENSE文件特别感兴趣（在我看来，鼓励将LICENSE文件提供给访问者/查看者该项目的简要概述）。

— 凯

如果我自己的代码的（部分）许可证是双重许可的，我将向该项目添加两个（或多个）许可证文件，每个许可证一个。然后在自述文件中明确说明在这种情况下哪种许可证适用。

— Bart van Ingen Schenau 2015年

Bart，感谢您分享您的操作方式-比我收到的一些评论要有用的多。:)同时，我实际上已经联系了GitHub，并将暂时关闭该问题，以防万一。

— 凯

当您从Github获得答案时，请将该信息作为对此问题的自我解答。

— Bart van Ingen Schenau 2015年

我一定会同意的，因为对别人也很有趣！

— 凯

在SPDX创建者的演示文稿（幻灯片12）中，非常清楚：

内容LICENSE：

Apache-2.0 OR GPL-2.0-or-later

然后，您可以添加两个附加的LICENSE文件：LICENSE.Apache-2.0和LICENSE.GPL-2.0-or-later。

在所有情况下，README.md都应包含SPDX许可证标识符：

SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later

您可以这样做：

## License

This work is dual-licensed under Apache 2.0 and GPL 2.0 (or any later version).
You can choose between one of them if you use this work.

`SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later`

请注意，Apache-2.0 OR GPL-2.0-or-later并Apache-2.0 AND GPL-2.0-or-later产生很大的差别。前者意味着用户可以在两者之间进行选择（这是常规情况！），而后者则意味着用户必须遵守两个许可证。另请参阅Wikipedia上的多许可。

请注意，我使用的是新的（截至2017年12月28日）SPDX许可证清单3.0在这里。2017年的版本具有GPL-2.0GPL 2.0的标识符，但尚不清楚这是否意味着“仅GPL 2.0”或“ GPL 2.0或任何更高版本”。

— Koppor
source

最终，我确实直接与GitHub支持人员联系了我的问题，他们说，如果我明确表示他们的回答仅是建议而不是建议，可以引用它们。

目前，我们的团队没有任何特别的建议，但我们会确保向周围的人询问并向您更新，如果我们还有其他需要分享的信息！

他们的原始答复提供以下内容：

一种建议是为您的大部分代码提供一个LICENSE文件，然后在README文件中添加其余第三方材料的许可证文本。

另一种方法是在有意义的情况下，使每个路径都有其自己的LICENSE文件。因此，例如，如果您的存储库具有以下路径：libs / awesome-lib-v2 /，则可能具有libs / awesome-lib-v2 / LICENSE。

在后一种情况下，您可能想在根目录下的README文件和/或LICENSE文件中提及它。

您也可以考虑只在存储库的根目录中使用一个LICENSE文件，并为任何第三方材料，代码等添加小节。

— y
source