2018 年 12 月许可证审查列表摘要
我被要求提供许可证审查和许可证讨论邮件列表的月度摘要。
摘要也将发布在各自的列表上，尽管此博客版本包含指向列表存档的详细链接。
欢迎任何反馈，但关于内容的回复当然应该在原始主题下进行。
本月主题
* 许可证委员会报告和审查状态变更
* 服务器端公共许可证，版本 2 (SSPL v2)
* 支持 SSPL v2
* （新的许可证审查流程正在[许可证讨论列表上讨论][new-process]）
[new-process]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020157.html
许可证讨论摘要
## 许可证委员会报告和审查状态变更
[Richard Fontana 的报告][Report]
libpng 许可证：[Cosmin Truta] 撤回了该许可证。
SSPLv2：讨论将在修订版本上继续进行。
YetiForce 公共许可证 3.0：[已拒绝][YetiForce]。
License Zero 公共许可证 (L0-R)：[未做决定][L0-R]，因为它已被有效撤回。
可转换自由软件许可证，版本 1.1：[暂缓批准][C-FSL]，等待重新起草的版本。Elmar Stellnberger（许可证提交者）不确定哪些点需要更改。[Carlo Piana][Piana:convertible] 强调，给予原始作者特殊的重新许可权利是歧视性的，尤其是在分支的情况下。
[Report]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003869.html
[Cosmin Truta]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003874.html
[YetiForce]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003854.html
[L0-R]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003855.html
[C-FSL]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003856.html
[Piana:convertible]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003862.html
## 服务器端公共许可证，版本 2 (SSPL v2)
在 11 月 21 日，[SSPL v2] 已提交审查。
[SSPL v2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-November/003836.html
[Eric Schultz][Schultz] 认为修订版并非出于善意，并且没有发现实质性改进。Schultz 特别关注“第 13 节中代码包含的限制似乎实际上是无限的，因为服务未被定义。”
[Bruce Perens][BP:Deshpande] 链接到 [Sunil Deshpande 对 SSPL 的评论][Deshpande]，并认为“它表现出对开源的很多无知以及对我们社区的彻底蔑视。”[Eliot Horowitz (MongoDB)][Horowitz] 回应说 Deshpande 与 MongoDB 无关。相反，Horowitz 指向他[博客上的一篇文章][Horowitz:blog]。他还回应了个人问题
SSPL 扩展到其他软件是否是一个问题？Horowitz 认为“不是”：通过网络组合服务是新的动态链接，因此扩展 copyleft 是可以接受的。（注意：这没有考虑到版权的界限，并且 SSPL 不仅会影响其他服务，还会影响例如部署工具。）[McCoy Smith][Smith] 也担心 SSPL 可能会要求披露类似或反向工程的软件，即使它在版权意义上不是衍生作品。
什么构成将程序作为服务提供？Horowitz 声称 SSPL 的定义比 AGPL 中可比较的章节更容易理解，并表示许可证在保持技术中立和可理解性的同时，不能更具体。
[Florian Weimer][Weimer:service] 询问这是否包括提供预构建二进制文件之类的服务。[Horowitz (MongoDB) 回应][Horowitz:service] 说，涵盖二进制文件分发的条款与 GPL 相同。Horowitz 解释说，在此处将软件作为服务运行意味着代表其他人运行软件，并且这种含义是常见的且易于理解的。
（注意：我之前将 SSPL 理解为面向服务的架构中的服务，而不是清洁服务中的服务。显然，仅指 SaaS/PaaS 中的服务。无论是否常用，这都非常模棱两可。）
[Lawrence Rosen][LR:available] 对 SSPL 的“提供”定义提出异议：“服务”的“价值”无法计算，程序“为用户完成的事情”是主观的，并且受到营销的干扰。“你至少在部分程度上创建了一个无法执行的 FOSS 许可证，其对“程序即服务”的定义比 AGPL 更友好，但仍然没有太大帮助。 :-)”
尽管如此，Rosen 认为 SSPL 的缺陷并没有阻止它成为开源许可证，并投票赞成批准作为实验性许可证。
[Schultz]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003847.html
[BP:Deshpande]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003851.html
[Deshpande]: https://techcrunch.com/2018/11/29/the-crusade-against-open-source-abuse/
[Horowitz]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003863.html
[Horowitz:blog]: http://www.eliothorowitz.com/blog/2018/12/11/open-source-and-the-sspl/
[LR:available]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003864.html
[Smith]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003865.html
[Weimer:service]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003885.html
[Horowitz:service]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003889.html
## 支持 SSPL v2
[Greg Luck (Hazelcast)][Luck:support] 表示支持 SSPL v2。他认为，需要一个 OSI 批准的许可证来解决 Commons Clause 和 SSPL 提出的问题，以防止该领域出现开源式许可证的扩散。Luck 认为 [GPLv3 风格的 copyleft][Luck:gpl] 和 [甚至 AGPL][Luck:agpl] 在阻止云提供商的服务包装方面是不够的。在他的理解中，copyleft 应该阻止销售免费软件，或者原始开发者应该获得公平的利润分成。
[Luck:support]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003866.html
[Luck:gpl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003868.html
[Luck:agpl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003878.html
[Rob Landley][Landley] 回应说，Stallman 在创建 (A)GPLv3 许可证系列之前就充分意识到了“服务提供商漏洞”。“如果他和 Eben Moglen 一起工作了五年都无法解决这个问题，并且仍然称结果为“自由软件”，你凭什么认为你能做到？” Landley 指责 SSPL 支持者一厢情愿：“这不是版权法和开源的工作方式”。
[Carlo Piana][Piana:SSPL] 同情 Luck 的观点，但不认为 SSPL 应该是 OSI 为此目的批准的许可证。Piana 特别担心 SSPL 在如此多的场景中如此不明确，以至于大多数用户实际上被迫获得专有许可证。“这是类固醇上的双重许可模式”。[Nigel T][NigelT:1] 也表示同意，并建议启用特定商业模式不是开源的责任：“如果你不想让人们从你的代码库中获利，那就把它变成共享源代码，然后继续前进。”
[Bruce Perens][BP:special] 补充说，“OSI 不会阻止你使用任何许可证。只是不要称之为开源。” Perens 指出，OSD/DFSG 对使用限制的禁止排除了一些特殊利益，例如仅限教育用途的软件。这是必要的，以便开源系统可以合法确定地用于任何目的。但是，推广特殊非开源许可证的社区在哪里？“在我看来，一些拟议许可证的问题不是缺乏 OSI 的批准，而是缺乏兴趣。” [Nigel T][NigelT:2] 指出 CC-NC 是一个拥有庞大社区的非开源许可证。
Perens [还回应][BP:tent] 说，由于非 OSS 许可证的扩散造成的任何混乱“都不会是 OSI 或开源的问题。 你离开帐篷就会制造这个问题。”
[Brendan Hickey][Hickey:sspl] 指出 Luck 对自由软件的误解：它关于互惠，而不是阻碍商业利益。此外，Hickey 认为云提供商销售的是可靠性，而不是软件。因此，SSPL 不会阻止大型云提供商从托管开源软件中获利，而最多只会给用户带来不便。
[Landley]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003867.html
[Piana:SSPL]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003870.html
[NigelT:1]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003873.html
[NigelT:2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003876.html
[BP:special]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003875.html
[Hickey:sspl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003871.html
[BP:tent]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003879.html
Martin Verburg (jClarity) [[1][Verburg:1],[2][Verburg:2]] 插话说，他支持一个解决这些问题的通用许可证，但建议谨慎行事——接受这样的许可证，甚至更改 OSD 都会产生深远而持久的影响。相反，他建议成立一个基础设施许可证联盟，让供应商在其中开发一个通用的许可证，独立于可能的 OSI 批准。关于 SSPL，Verburg 建议等待并观察：其他供应商会采用这个许可证吗？
[Verburg:1]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003881.html
[Verburg:2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003883.html