在上一篇文章中，我讨论了过去一年半以来针对 GitHub 提出的投诉，这些投诉涉及看似 FLOSS 代码仓库公开但没有明确许可的问题。在此，我将讨论 GitHub 在 7 月份采取的行动，这无疑是对这种批评的回应。
GitHub 指出“分享你的代码并非一切……重要的是告诉人们他们如何使用这些代码”，并且“选择开源许可证可能会令人困惑”，因此创建了一个信息网站来帮助开发者：choosealicense.com。与此同时，GitHub 在使用 README 文件初始化新仓库的用户体验中添加了一个新的许可证选择器。用户会看到一个包含 10 个左右开源许可证的下拉列表（默认或顶部元素为“无”）。如果用户从列表中选择特定的许可证，则新仓库将填充相应许可证文本的副本。
虽然我对 choosealicense.com 有一些批评，但我首先要赞扬 GitHub 将其设为一个开源、可 fork 的 GitHub 托管项目。
choosealicense.com 并非什么新类型。它显示了早期 tl;drLegal 的影响。知识共享引入了“deeds”的概念，据说它是“人类可读的”，旨在帮助理解许可证的实际“法律代码”。知识共享还在一段时间内提供了一个简单的网络服务，以帮助内容作者选择合适的 CC 许可证。John Cowan 长期维护着一个 FLOSS 许可证选择向导。多年来还有其他类似的努力。
对于那些不了解的人来说，GitHub 发布的大部分开源软件都已置于 MIT 许可证之下。考虑到该许可证在 Rails 社区中的流行程度（GitHub 就源于该社区），这并不令人意外。但这并非没有经过深思熟虑或仅仅是追随潮流的许可证选择。GitHub 的 CEO 兼联合创始人 Tom Preston-Werner 在他 2011 年具有影响力的文章开源（几乎）一切中，就他为何偏爱 MIT 许可证给出了充分的理由。
Preston-Werner 的文章很好地洞察了专有 Web 应用程序开发者的世界观，他们积极发布在宽松开源许可证下的库、工具和框架。（有关此现象的批判性分析，请参阅 Chris Webber 的 Copyleft 视角指南。）Preston-Werner 在他最近的 OSCON 主题演讲中重复了他对 MIT 许可证的推销（以及对 GPL 的批评），其中还涵盖了 choosealicense.com 的发布。我在红帽的许多同事都会质疑 Preston-Werner 的假设，即如果代码是“核心业务价值”，那么将其开源是不明智的。我个人认为 GitHub 对开源的参与，包括其许可证方法，与现在正在消亡的、以愤世嫉俗的 copyleft 为基础的商业模式（许多早期的 Web 服务初创公司都尝试过这种模式）相比，是一种令人耳目一新的变化。
然而，Preston-Werner 所阐述的观点是一种政治偏好。了解了这种观点后，很难不认为 choosealicense.com 上信息的呈现反映了这种意识形态。在该网站的首页上，有一个三列的特色许可证选择展示，与某些“最能描述您的情况”的政策相关联，自然是从左到右查看。第一个选择是 MIT 许可证。奇怪的是，Apache License 2.0，最宽松的开源许可证之一，却被呈现为一种中间立场选择（而像 EPL、MPL 或 LGPL 这样的弱 copyleft 许可证可能更合理地被包含在内）。然后 GPL 被放在右边，也许是为了强制提供平衡，或者因为不突出 GPL 会降低该网站的可信度。
choosealicense.com 首页的一个令人困惑的方面是，建议那些“关注专利”的人使用 Apache License。虽然 Apache License 的专利条款很重要且具有特色，但还有一些 copyleft 开源许可证在解决专利问题方面做得更多（尤其是 MPL 和 GPLv3 系列）。我并不是说 Apache License 是一个糟糕的选择——相反，我在红帽工作的这些年里，我们选择在该许可证下发布了大量的代码。我只是认为，如果开源法律新手最关心的是专利，那么将其单独挑出来作为该许可证来看待是很奇怪的。
choosealicense.com 首页包含几个因试图概括而引入错误的例子。被偏爱的 MIT 许可证据说要求“归功于您”，但实际上它要求保留版权声明，这两者不是一回事。更令人困扰的是，GPLv3 与 GPLv2 的不同之处在于“进一步限制在禁止软件修改的硬件中使用”，短语“进一步限制”呼应了两个 GPL 版本的关键条件。GPLv3 并没有做出任何此类使用限制；相反，GPLv3 要求某些类型硬件的分销商在某些情况下向用户提供某些信息，以使其能够安装修改后的软件。
从首页链接到的页面提供了关于三个“特色”许可证（GPL 指定为 GPLv2）的摘要信息，随后是一个看似任意顺序排列的各种其他开源许可证列表，其中大多数都是相当主流的。此列表还包括“无许可证”，就好像它是要选择的一种许可证一样。每个许可证都有一个或两个句子的摘要、一个指向完整许可证文本的链接，以及为三个信息类别（“必需”、“允许”和“禁止”）列出的一些项目符号。在这个列表中也可以发现错误。对于 GitHub 坚持将其作为首选选项呈现的“无许可证”案例，这一点最为明显。摘要句子准确地给出了 GitHub 对无许可证代码仓库在法律上应该意味着什么的看法。然而，随附的项目符号表明，使用“无许可证”必须保留（不存在的）许可证和（对于 GitHub 仓库，很可能不存在的）版权声明，但私人和商业用途在某种程度上是被允许的。
我对 GitHub 新仓库初始化的许可证选择器不太挑剔，特别是考虑到它目前提供了广泛的许可证选择。所选许可证可能被证明与仓库中随着时间推移演变的代码相冲突（例如，如果它包含了第三方代码），但这在开发者在项目开发的最早期阶段指定特定许可证的任何情况下都可能发生。
看看许可证选择器会对 GitHub 托管项目的许可产生什么影响将会很有趣。如果我们看到新 GitHub 仓库的“POSS”显著减少，并且有证据表明对像 MIT 许可证这样的简单宽松许可证的偏好持续或增加，这将支持这样一种观点，即 GitHub 上无许可证的代码通常是对最大限度宽松的开源许可的天真尝试。“无许可证”选项的广泛使用将表明开发者在有意识地避免明确许可，尽管其意义可能仍然不清楚。
3 条评论