很少有人会否认，GitHub 作为软件项目的热门托管服务的崛起，是过去五年中影响开源的最重大发展之一。GitHub 的非凡成功是理解去年来自开源世界内部或接近开源世界的一些批评的必要背景。这些批评主要集中在许可上，或者更确切地说是缺乏许可：有人声称 GitHub 托管了大量没有明确软件许可的代码。一些批评者认为，这种情况是年轻开发人员对法律事务的无知和 GitHub 管理层有意不作为共同作用的结果。在后续文章中，我将讨论 GitHub 最近为解决这些问题而采取的措施；本文探讨了投诉本身的一些方面。
“POSS”的创造
去年九月，RedMonk 的 James Governor 发布了他著名的 推文，内容是关于年轻的 GitHub 用户开发人员“关于 POSS - 发布开源软件”，其特点是对许可和治理的蔑视或漠视。我不认为存在 Governor 表面上所指的“POSS”这种东西。然而，为了方便起见，在本文中，我将以 Donnie Berkholz（同样来自 RedMonk）在他最近对 Ohloh 数据的 分析 中所使用的方式使用术语“POSS”，指的是表面上是开源的项目，但似乎没有明确的许可。
Governor 的推文引发了一场有趣且大多是负面的关于 POSS 的讨论。Stephen Walli 称 GitHub 为“滥交的网站”，认为，如果不更加关注软件“卫生”，开发人员将面临失去参与的风险。Simon Phipps 断言，GitHub 没有认真对待开源，并且正在创造一个法律风险加剧的环境。Mark Radcliffe 称 POSS 为“令人不安的趋势”，并指出这将只会挫败开发人员广泛使用其代码的推定愿望。Phipps 和 Luis Villa 都认为 POSS 只会让律师受益。
没有明确许可 = “保留所有权利”？
许多 GitHub 的批评者指出，没有许可证的代码的状态是根本没有授予版权许可。这基本上是正确的，前提是代码本身具有版权，但这忽略了我认为相关的某些细节。
其中之一是一般历史观察。自由软件运动最初是由美国的黑客发起的，直到 1989 年 3 月 1 日，他们在一个法律制度下运作，该制度使得版权材料很容易进入公有领域（在非常精确的意义上）。1998 年后公共协作站点的先驱是 Usenet 新闻组，开发人员在 1980 年代到 1990 年代中期通常通过它共享源代码。对这些新闻组的存档进行粗略检查表明，即使在美国加入伯尔尼公约以及我们现在认为的 GPL、MIT 和 BSD 许可证系列的初步普及之后，此类代码通常也没有附带任何版权或许可证声明。在 Usenet 不再是软件共享的常用媒介，转而使用 FTP 存档站点以及后来的基于网络的项目协作站点之后，在社会意义上被认为是自由软件的代码上不包含明确许可的做法仍在继续。
事实上，在所有对 GitHub 和 POSS 的批评中，我都没有看到任何可复制的数据分析表明 POSS 随着 GitHub 的兴起而增加，更不用说开始。历史观点可能表明，通常被认为是自由软件的未明确许可代码的实践实际上是一种持久的传统，其根源早于美国的 1976 年版权法（该法确立了版权在固定而非在发布并带有适当通知时产生）。这种传统只是逐渐被 copyleft 和宽松的 FLOSS 许可证的使用所取代，其方式与美国版权法的变化并非完全同步。我一直在想，GitHub 的批评者是否可能倒过来看待这个问题，可能没有意识到 2008 年（GitHub 推出之年）之前开发者社区中法律上非正式的代码共享有多么普遍。
在考虑将 POSS 等同于“保留所有权利”时，另一个值得一提的细节是我在其他场合谈到过的。如果不假设存在稳健的默示版权许可原则，就无法正确理解开源开发（以及许多其他网络分发的免费数字内容领域）的法律运作。在美国版权法中，默示许可可能产生于因情况创造了合理的期望，即版权所有者打算将作品用于某种目的。对于没有明确许可的公共 GitHub 源代码存储库，根据美国法律，有充分的理由认为，考虑到项目作者理解 git 和 GitHub 的专有服务通过其设计促进了广泛的代码共享和代码改进，包括在 GitHub 本身之外的公共共享，因此默示产生了广泛的版权许可。
但对于 GitHub 而言，默示版权许可理论只能到此为止。很难看出，在没有特殊事实的情况下，公共 GitHub 存储库的默示许可将如何涵盖与开源规范相关的所有权限，特别是商业化和从事超出单纯开发用途的权利。同样无益的是，GitHub 告诉其批评者，它打算使用户存储库默认情况下“保留所有权利”，并且似乎将此视为保护法律知识有限的用户的一种方式。虽然 GitHub 的服务条款要求用户同意允许其他人“查看和 fork”他们的公共存储库，但这产生了一种许可，这种许可似乎比默示应该发生的许可更具限制性。
POSS 是超宽松许可的失败尝试吗？
具有启发意义的是，我们在讨论 POSS 现象时，不能轻易地不假设开发人员打算将其代码开源，尽管有“保留所有权利”的论点。但如果是这样，那么与此类代码相关的风险，特别是由于缺乏明确许可而产生的风险必然很低。忽略关于未来版权流氓的不切实际的恐怖游行式假设，人们可能会问，POSS 开发人员是否远非天真或不了解法律事务，而是在从事价格歧视的极端版本，而价格歧视是所谓的双重许可开源商业模式的基础。
部分基于非 POSS GitHub 代码特性的直觉表明并非如此。在明确许可的 GitHub 存储库中，非 copyleft 许可比 copyleft 许可更为普遍，其中最简约的 MIT 许可证是 最有可能最受欢迎的 许可证选择。此外，加上普遍认为正在发生的向非 copyleft 许可的转变，尤其是在那些似乎构成 GitHub 用户群重要核心的更年轻、面向网络的开发人员中，这表明如果 POSS 在 GitHub 上真的很普遍，那么它可能表明希望以尽可能宽松的条款共享代码——前提是开发人员考虑过这个问题。
因此，POSS 可以有效地被视为更大的当代文化现象的一部分。它包括 CC0 (2009) 和 Unlicense (2010) 的引入，以及普遍认为 copyleft 开源许可证市场份额的下降。Luis Villa 提出，应将 POSS 解释为开发人员幼稚地努力批评正统开源许可生态系统中的假设，即共享不能也不应该在没有明确许可的情况下完成。Villa 建议开源许可证的作者和评估者应该探索在法律上合理的方式来适应这种对 Lawrence Lessig 所谓的“许可文化”的反击。
GitHub 在法律上赋予用户权力
关于 POSS 和 GitHub 的讨论忽略了该现象的一个积极方面。GitHub 易于使用的后果之一是，提出和对 GitHub 托管的存储库进行法律改进变得容易。我观察到，许多 GitHub 用户正在提交“请添加许可证”的问题和 pull request。在某些情况下，这些来自企业用户的员工和来自像 Fedora 这样在法律上严谨的社区发行版的打包者。通常的结果是存储库所有者表示歉意的评论，询问关于选择哪个许可证的反馈以及关于如何处理机制的教育。在相当多的情况下，似乎问题不是缺乏许可，而是明确的许可对用户来说不明显（例如，因为没有使用独立的许可证文件，这几乎不是一种多数做法）。
在查看这些案例时，人们得到的印象与其说是没有发生明确的许可，不如说是许可正在公开地发生，比项目启动晚，并且在项目开始引起重大兴趣时发生。问题和 pull request 通常表达对特定许可证类型的先发制人的偏好（通常是非 copyleft）。这是一个非常重要的发展：对于自由软件用户来说，这可能是第一次参与许可证选择过程。
5 条评论