如何在你的开源项目中添加开源许可证

我们从假设你已经决定了你的项目将使用什么样的开源许可证来开始这篇文章，如果你还不清楚要使用哪种许可证，可以翻翻之前的文章，那里有每种类型许可证的详细介绍。接下来的问题是：如何将许可证分配给开源项目？

解决这个问题有时候很简单，例如添加一个README文档。但如果在一个项目的多个地方使用了多个许可证，这种偷懒的做法可能会带来一些问题。

比如说：如果使用了多个许可证，哪个许可证优先？

又比如说相关的版权问题。你需要在你的代码中添加版权信息吗？你需要注明“保留所有权利”吗？你是否有义务随着时间的推移不断更新授权？

种种之类的问题困扰着想投身开源的开发者们。风险时有发生，而且它可能发生在任何人身上。即使是最有才华的程序员，也需要提前做好准备，不为自己的开源项目中的错误承担责任。

一、选择开源许可证

之前发过不少关于选择开源许可证的文章与建议，所以为了避免重复，在这里就仅仅放一张简单的示意图。

 

二、添加开源许可证

普遍情况下，我们希望将一个名为LICENSE的文件放在项目的根目录下。你可以使用任何适当的文件扩展名来标识文件的tag，.md、.doc、.txt都可以。但考虑到该文件包含一些非常具体的法律术语，最好将其保留为纯文本，且仅命名为LICENSE，而不使用任何扩展名。

值得注意的是，请务必在文件名中使用大写字母，这是惯例。

1.向新项目添加开源许可证

现在大家使用的一些工具，如GitHub和GitLab，都允许你在首次创建库时选择许可证。这也是从一开始就确保项目包含正确的法律保护的最简单的办法。

一旦你启动了“创建新存储库”的工作流，GitHub将显示如下内容，其中包含一个相关的复选框。选中该复选框将打开下拉列表，其中有许多许可证选项可供选择。

 

2.向现有项目添加开源许可证

对于没有许可证的现有项目，只需要在库的顶部放置一个LICENSE文本文件，然后commit、push和cut一个新版本。

如果你的项目在此之前没有添加任何许可证，那么意味着没有人可以合法的使用它，即使它是公开且对全世界可见的。

理论上可以有人使用不含许可证的项目，但不会有公司或组织这样做，它们没必要冒如此大的法律风险。

为什么我们建议你cut一个新版本？因为大多数项目都支持一个功能——releases或tags。例如，GitHub同时支持releases和tags。即使上一个版本和这个版本之间唯一的区别就是存在该LICENSE文件，也有必要创建一个新版本，因为这样的操作可以告诉每一个浏览项目的人——从该版本开始，我的项目将在X许可证下发布。

3.其他地方也需要许可证吗？

事实上，是的。除了放置LICENSE文件之外，你的项目还可能受制于包装和分发格式所强加的规范要求。

例如，如果你正在编写一个Ruby库（被称为Ruby gem，并通过RubyGems.org网站发布），就需要有一个详细的规范来使文件被认为是一个有效的gem（否者RubyGems会拒绝它）。该规范的一部分是许可证名称，它必须与某几个许可证相匹配。目前所有流行的Ruby库都使用MIT许可证，只有极少数例外。

三、依赖链中的薄弱环节

很少有项目是没有引入依赖的，每个依赖可能又会有自己的依赖关系。以此类推，管理依赖关系是一个相当大的挑战。在本文中，我们关心的是依赖关系如何影响开源许可证。

简而言之，如果你的依赖关系是在开源许可下发布的，而是不在你自己的库中使用的。那么从法律角度来看，你的用户所承担的义务将由所有依赖关系及其依赖中最“强大”的许可证决定。

假设你选择了MIT来分发项目。一家公司的开发者发现了你的库，并认为这正是它们所需要想开源组件。于是他们将其集成到自己的项目中，一切看起来十分美好。

六个月后，该公司正在与一家规模大得多的科技巨头进行谈判，后者是一家强大的上市公司。这给小公司带来了额外的法律负担，其结果之一就是他们必须对自己的软件进行技术审计以确保合规性。

但事实往往不遂人愿，他们发现你的开源项目依赖于另一个库，这个库又依赖于另一个库，而这个库在更强的GPL许可证下发布。通常情况下，除非使用这些许可证的公司也发布过经过修改的源代码，否则不会使用这些许可证下发布的组件。这就意味着你必须替换或删除该依赖，以满足法律上的合规性，或者从GPL组件的作者那里获得一个单独的授权。

四、保障开源项目的合规性

合规性意味着满足开源许可证定义的所有法律义务。据OSI统计，目前至少有70个活跃的开源许可证正在广泛使用。除此之外还有几千个模糊的、衍生的或者自制的许可证没有被收录到OSI和FSF的目录中，这就使得开发者和企业的法律团队很难人工解决大量开源组件和依赖项中的合规性问题。

这就是像UniSCA这样的工具可以派上用场的地方——自动化合规性检测，

例如，UniSCA可以发现在项目的成千上万的依赖中有一个GPL许可证，这是一个风险系数非常高的许可证，而依靠人工几乎不可能完成此类任务。

五、版权和CLA

除了开源许可证，如果你查看了任何现有的流行开源项目的源代码，你会发现在大多数文件顶部的版权声明。例如，Ruby on Rails源代码中大多数Ruby文件的顶部都包含以下内容：

 

通常来说，即使使用开源许可证，作者仍然保留对软件的权利。这意味着作者可以选择使任何未来的版本不再开源。

然而，当你的项目接受其他人的贡献并将其纳入你的工作时会发生什么？那会改变版权吗？你是否应该将每个贡献者添加到每个文件不算增长的作者列表中？虽然这看起来很合理，但实际上并不可行，特别是如果这个项目在过去的几年里有数百个贡献者的话。

开源项目的管理者处理这种情况的方式主要有两种：

1.CLA（contributor licensing agreement）。贡献者必须同意CLA，然后才能提交贡献。例如，Google的开源项目（如Bazel Build Sysem）可能要求你阅读并同意Google的CLA的条款和条件。有些CLA甚至要求贡献者要么自动将版权转让给原始项目作者，要么事先同意主要作者在未来可能对许可证的任何更改。

2.每一个贡献者都是版权拥有者。这是应用于大多数项目的默认方法，没有像Google那样的显式CLA。许多项目采用了以下方法来处理版权声明：

此种声明意味着：

①这个项目是有版权的

②作者已经授权它在其他项目中的分发

③作者或项目贡献者希望保留版权的所有权

六、免责申明

大多数开源许可证的一个重要组成部分时免责条款，其内容通常如下所示：

“THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.”

这也是在项目中添加许可证的重要原因之一。它明确的免除了作者对自己的项目可能造成的任何损害的承担义务。

根据该许可条款，使用软件的开发者应该对生成中出现的新问题负责，而不是作者。

七、总结

总而言之，对于新项目，我们建议使用GitHub或GitLab的内置功能来为项目添加开源许可证。如果你想使用许可证，MIT是目前最流行的许可证之一，它允许任何人以任何形式使用你的项目，无论是商业的还是非商业的。

以下是BBAV抽样调查的项目中使用最多的10种许可证：

 最后，建议使用能够分析你的依赖关系和开源许可证的自动化安全检测工具。例如FOSSA、UniSCA Cloud等等。这些工具可以有效的检出项目中的依赖项、许可证信息、开源漏洞，帮助开发者规避潜在风险，更好的利用开源。