GitHub 上的开源许可

Ben Balter 是 GitHub 的政府布道师——他致力于在政府实体中推广开源理念。在加入 GitHub 之前，他曾在美国总统行政办公室的美国首席信息官办公室担任研究员，在那里他积极参与起草总统的数字战略和开放数据政策，参与软硬件自动化技术 (SWAT) 团队（白宫第一个也是唯一一个敏捷开发团队），并曾担任联邦通信委员会管理主任办公室的 新媒体研究员，他在塑造该机构的重新构想的网络形象方面发挥了核心作用。

他将在今年的 OSCON 大会上发表演讲，主题是 GitHub 上的开源许可数据分析，他的同事 Tal Niv 也将一同参与。我们联系了他，以便让您先睹为快，了解他的演讲内容。

开源许可对于 GitHub 及其用户有多重要？

如果没有开源许可，就不会有开源这种东西。我们有的只是已发布的代码。开源许可使代码从“可用”变为“开放”。正是这种自由支撑了人们使用和修改软件的能力。这是开源独有的特性，也是开源与其他所有软件的区别所在。虽然选择哪种许可的具体细节可能并不总是最重要的，但您为代码许可这一事实至关重要。

开源许可对于 GitHub 来说在两个方面很重要：首先，作为世界上最大的代码托管平台，我们有一个独特的机会——并且可以说基于这个机会，我们有义务——尽我们所能来支持开源社区，这显然包括开源许可。其次，作为一家建立在开源基础上的公司，我们所依赖的开源代码以及我们贡献给开源社区的代码都必须得到适当的许可，以便其他人可以使用它。毕竟，这就是开源的意义所在。

GitHub 用户最常用的许可是什么？

迄今为止最常见的许可证是 MIT 许可证，几乎一半的获得许可的存储库都选择了 MIT 许可证。我认为一个很大的原因是，今天的开发人员在一个开源已经获胜的世界中学习编码。与过去相比，闭源软件的摩擦已经不复存在，因此开发人员通常会选择实用性而不是纯粹性。开发人员为开源做贡献是因为他们想构建很酷的东西，并且他们认为这是构建软件的最佳（唯一？）方式。哲学动机虽然仍然是他们贡献的基础，但已不再像以前那样处于最前沿。

如果您查看 MIT 许可证，它会很简短明了。它告诉下游用户他们不能做什么，它包括版权（作者身份）声明，并且它放弃了默示担保（买者自负）。这显然是为开发人员优化的许可证。您不需要法学学位即可理解它，并且实施起来很简单。与 Apache 许可证之类的许可证相比，尽管在您可以做什么和不能做什么方面几乎相同，但它在法律上更加“严谨”，并且更加冗长。 实际上，仅解释如何应用许可证的附录就比整个 MIT 许可证还要长。这显然是为律师优化的许可证。

另一个流行的许可证是 GPL 系列许可证，作为一种反版权（传染性）许可证，它在类别上与 MIT 和 Apache 等许可证不同。您可以在这篇三月份的博文中看到许可证使用情况的相对细分。

GitHub 正在采取哪些措施来减少未许可存储库的数量？

从理论上讲，我们可以修改我们的界面，使开源许可成为“选择退出”而不是像今天这样“选择加入”，但开源许可的问题不在于许可项目太难，而在于对于许多开发人员来说，它非常令人生畏且极其令人困惑。这就是我们创建 choosealicense.com 的原因，旨在帮助揭开正确许可您的项目过程的神秘面纱。Choosealicense.com 本身是开源的，而 Choosealicense 存储库 为您在创建新存储库时看到的许可证下拉菜单提供支持。在我们推出该网站后，我们看到获得许可的存储库的百分比显着增加，包括新的和历史的。很明显，用户想要做正确的事情，但往往缺乏必要的资源。

我们还创建了 License API，以便大大小小的开源使用者都可以更轻松地以机器可读或自动化的方式了解项目在何种许可证下获得许可。这意味着关注许可证合规性的组织可以编写传统的手动流程脚本，这应该鼓励未许可或未正确许可的项目仔细查看它们的分发条款。License API 还返回有关每个单独许可证的信息，包括许可证文本以及下游用户可以使用代码做什么和不能做什么，再次，希望尽可能方便用户参与开源社区。

GitHub 员工如何与其社区互动？

与许多其他公司不同，在 GitHub，以个人身份参与开源社区和作为 GitHub 员工参与开源社区之间通常几乎没有区别（至少在实践中是这样）。GitHub 是一家拥有强大开源历史的公司，当发布、使用或维护开源项目时，开发人员被期望成为开源社区的正式成员，就像他们在周末从事一些有趣的事情一样。这关乎参与更广泛的对话，关乎人性。GitHub 的开发人员在开源项目和闭源项目之间来回切换是很常见的，甚至一天多次。 “互动”社区的最佳方式实际上是成为其中的一部分。

其中一个例子是，作为我们开源文化的一部分，每隔一个星期五，GitHub 员工（从开发人员到会计师）都被鼓励从日常工作中休息一天，花一天时间为开源做贡献。这可以是学习一个以前没有使用过的新开源项目、分类问题、贡献文档，当然也可以是编码，但重点是，您正在为开源社区做贡献。我们内部还有一个开源团队，专门帮助 GitHub 员工创建、发布和维护开源软件。

最后，如果我不提 GitHub 的定价模式，我就会感到有所疏忽。只要是开源的，您在 GitHub 上所做的一切都是完全免费的。您唯一需要支付项目托管费用的时候是当项目是闭源项目时，您可能会从中获利。在某种程度上，您可以说 GitHub 为了支持开源而“征收”专有软件的“税”。对此可以有很多解释，但作为一名软件开发人员，最让我产生共鸣的观点是，过去十年左右创建的所有开源软件都具有巨大的价值，如果我们因为维护者无法或不愿永久支付托管费用而失去其中一部分，那么软件开发领域的一部分经典之作将永远消失。

从这个意义上说，您可以说 GitHub 是建立在开源基础之上的，为开源做出贡献，并支持开源社区。

您（作为 GitHub 员工）多久为托管在您服务上的存储库做出贡献？

我使用了这个快速脚本来查看 GitHub 员工在典型的一周内的开源贡献，以及来自 GitHub 维护的项目的社区贡献。在本例中，这是 2015 年 6 月 15 日开始的那一周的情况。在那一周，有

• 创建了 33 个新的开源存储库
• 3 个存储库从闭源变为开源
• 1,173 条 issue 评论
• 打开了 118 个 issue
• 关闭了 316 个 issue
• 打开了 137 个 pull request
• 合并了 193 个 pull request
• 37 个发布版本
• 970 次推送
• 4,857 次提交
• 总共有 3,262 个开源“事件”（issue、评论、pull request 等）

还有许多 GitHub 维护的项目，以及由 GitHub 员工维护或大量贡献的项目，包括 Atom、Electron、Git LFS、Homebrew、Bootstrap、Hubot、Octokit、Git 和 Linguist，这些项目每周都会收到来自 GitHub 员工的数百个 issue、提交、评论和 pull request。

本文是 OSCON 2015 演讲者访谈系列的一部分。OSCON 涵盖所有开源内容——全栈，包括您每天工作中使用的所有语言、工具、框架和最佳实践。OSCON 2015 将于 7 月 20 日至 24 日在俄勒冈州波特兰举行。.