2019年1月许可证审查摘要
一月份，许可证审查邮件列表讨论了
* 新的许可证审查流程
* 服务器端公共许可证，版本 2 (SSPL v2)
* 可转换自由软件许可证，版本 1.3 (C-FSL v1.3)
* 原始作者的问题是什么？
* C-FSL 与 CLA 或宽松许可证有何不同？
* 为什么发布要求是个问题？
* C-FSL 可以获得 OSI 批准吗？
* 可转换自由软件许可证，版本 1.4 (C-FSL v1.4)
相应的许可证讨论摘要已在线发布
于
并涵盖了关于以下内容的讨论
opensource.dev 信息网站，
开放数据，
开源许可证中的“亲密性”，
重新许可和维护者-社区动态，
以及 VanL 即将发布的许可证。
## 许可证委员会报告
Richard Fontana 提供了许可证委员会报告
[[1][fontana-report],[2][fontana-process]]。
新的许可证审查流程已被采纳，
并将适用于正在进行的审查。
[Simon Phipps][phipps-process] 澄清说
OSI 董事会将像处理任何其他董事会投票一样处理审查决定，
但会考虑到建议和讨论
在许可证审查邮件列表上
[Phipps 确认][phipps-process2] 这个新流程意味着
“Stallman 的四个自由是评估的假定前提。”
OSI 批准的许可证应该适用于一般用途，
并确保公平的竞争环境。
SSPL v2：讨论正在进行中。
董事会将于 2019-02-18 做出决定。
C-FSL v1.3：先前版本的批准被搁置，
并且提交了 1.3 版本。
董事会将于 2019-02-18 做出决定。
[Bruce Perens][perens-report] 建议
这两个许可证都应该被拒绝
新版本的 C-FSL
似乎只是用不同的词语包装了相同的歧视性条款。
用不同的词语包装了相同的歧视性条款。
而 SSPL 只收到
关于它如何与开源原则冲突的评论
或认为这种许可证是必要的评论，
但没有提出解决这些冲突的方案。
[fontana-report]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003904.html
[fontana-process]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003926.html
[fontana-report2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003927.html
[phipps-process]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003930.html
[phipps-process2]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003924.html
[perens-report]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003905.html
## 服务器端公共许可证，版本 2
[Eliot Horowitz (MongoDB)][horowitz-ann] 宣布
MongoDB 正在致力于 SSPL 的新修订版。
Horowitz 澄清说，“服务”的重点
旨在涵盖多个方面
不仅提供网络服务，
还提供从软件中获得*价值*的服务
或提供软件功能的服务。
Horowitz 声称，SSPL 下的源代码披露要求
比 AGPL 更窄
（仅当将软件作为服务提供时）
比 AGPL 更窄
（当用户与软件的修改版本交互时）
因为他认为
确定软件的使用目的是
比确定软件是否已被修改更容易
（注：嗯）。
[Gil Yehuda][yehuda-sspl]
赞赏 SSPL 对 AGPL 的澄清，
但指出 SSPL 似乎仅对大多数用户符合 OSD 标准
——但并非所有人。
[Bruce Perens][perens-osd9] 认为 SSPL 与
OSD #9 “许可证不得限制其他软件”不兼容
因为 SSPL 要求披露与
但不是 SSPL 涵盖软件的衍生或一部分的聚合软件。
但不是 SSPL 涵盖软件的衍生或一部分的聚合软件。
“我将 #9 写入 OSD 以禁止*完全*这种行为。
完全正确。文本非常清楚。”
Horowitz 断言 SSPL 的目标
不是为了销售企业许可证而阻止商业用途，
而仅仅是为了保护“创新的开源软件”
（解读：MongoDB 自己的托管产品）
免受大型云供应商的剥削（解读：竞争）。
[John Cowan][cowan-value] 觉得这很令人困惑：为什么 MongoDB
可以接受用户在云服务器上安装 MongoDB，
但不接受云提供商提供托管服务？
无论如何，云提供商都会获得报酬。
[Vadim Tkachenko][tkachenko-sspl] 认为 MongoDB 的立场是虚伪的
他们想抑制其商业模式的竞争对手，
同时仍然将自己描绘成一家开源公司
因为这推动了开发人员对 MongoDB 的采用。
[Rob Landley][landley-sspl]
指出许可证或治理变更
通常会导致更成功的分支，如 XFree86/X.Org 的案例所示。
MongoDB 将许可证更改为 SSPL
已经导致它被 Linux 发行版删除，
并且兼容的替代品（例如来自 Amazon）
或维护的分支（例如来自 Percona）
已经可用。
“暂且不提 OSI，社区似乎已经非常明确地表态了。”
然而，[Nigel Tzeng][tzeng-sspl] 提醒说
这是一个长期投资的问题。
MongoDB 肯定会继续投资于其核心产品，
而分支可能看不到相当的努力。
[Carlo Piana][piana-sspl] 坚持认为
审查应侧重于具有法律约束力的许可证文本，
而不是 MongoDB 的意图。
然而，这也意味着 Horowitz 的澄清是无关紧要的
除非它们成为许可证的一部分。
[horowitz-ann]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003933.html
[yehuda-sspl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003934.html
[perens-osd9]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003935.html
[cowan-value]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003936.html
[tkachenko-sspl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003938.html
[landley-sspl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003939.html
[tzeng-sspl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003941.html
[piana-sspl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003940.html
## 可转换自由软件许可证，版本 1.3
Elmar Stellnberger 提交了许可证的完全重写版本
[[1](http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003891.html),[2](http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003892.html)]。
此许可证的目标是开源项目的维护者
可以自由更改项目的许可证，
并且可以集成任何下游修改。
如果没有 C-FSL，项目许可证只能更改
如果项目使用宽松许可证，
如果所有版权持有人都同意，
或者如果所有贡献者都签署了贡献者许可协议 (CLA)
——但这些都不能确保
下游修改以相同的许可证提供。
因此，C-FSL 是一个著作权许可证
贡献者在此许可证中授予指定的“原始作者”
特殊的重新许可权利。
此许可证的一般想法
以及第三版的重写
在邮件列表中受到了相当严厉的批评。
[Carlo Piana][piana-reaction] 承认“实质性的努力
克服了对原始版本的大部分批评”
但 [对][piana-cfsl] Stellnberger 对这些批评
表现出的明显缺乏理解感到沮丧。
[Bruce Perens][perens-reaction] 完全不满意
“当你请求“重写”许可证时
其*根本目标*与 OSD 冲突，
你很可能会得到一个重写的许可证
与原始许可证具有相同的问题。
在这种情况下，我们确实得到了。”
同样，[Brendan Hickey][hickey-cla] 发现重写
“没有解决上一个版本中提出的根本性异议。
[…] 专有软件没有错，
只是不要称其为开源。”
对 C-FSL 的主要批评有三点
1) 原始作者的特殊角色具有歧视性，
[Brendan Hickey][hickey-oa-copyright] 论证道
“这在概念上与 OSD 不兼容。
任何实施此项的许可证都是非自由的。”
2) C-FSL 试图伪装成版权转让。
3) 该许可证对所有更改都施加了繁重的发布要求。
[Carlo Piana][piana-cfsl]
对许可证的最大问题提供了出色的分析。
[piana-reaction]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003894.html
[stellnberger-oa-copyright]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003908.html
[hickey-oa-copyright]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003910.html
[piana-cfsl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003911.html
[phipps-asymmetric]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003924.html
[stellnberger-65]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003909.html
[landley-65]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003896.html
[landley-joint]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003919.html
[cowan-joint]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003920.html
[rosen-joint]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003921.html
[stellnberger-implicit]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003922.html
[hickey-cla]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003897.html
### 原始作者的问题是什么？
根据 C-FSL，可以指定原始作者
充当“[有效版权持有人][stellnberger-implicit]”。
他们可以自行重新许可软件，
无需获得所有版权持有人的个别同意
——贡献者已事先给予默示同意。
目前[尚不清楚][piana-reaction]
原始作者之间达成共识的规则是什么（多数票？）。
这些原始作者[只是一部分][hickey-oa-copyright]
的所有版权持有人，
[这剥夺了][piana-cfsl] 其他贡献者的权利。
[Simon Phipps][phipps-asymmetric] 指出
虽然不对称许可证有先例，
但每一半都必须有效地成为 OSI 批准的许可证。
（注：不对称性在 [上游兼容性许可证][ucl-submission]
的 [审批过程中][ucl-submission]
在 2016-2017 年期间进行了辩论，但最终被删除。）
在 2016-2017 年期间进行了辩论，但最终被删除。
[ucl-submission]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2016-October/002856.html {.no-elide}
分支可以指定自己的原始作者
仅当分支至少有 65% 的不同时
——一个[非常高的门槛][piana-reaction]。
这剥夺了分支项目在代码中的权利。
[Stellnberger 对此障碍的意图][stellnberger-65]
是为了防止出现两个并发的原始作者组。
但自由分叉正是开源的意义所在！
[Rob Landley][landley-xfree86]
写了一封长邮件，追溯了 xfree96 和早期 Linux 的历史，
强调了项目分支和社区分支之间的差异
以及为什么分支对社区有好处
“这个许可证试图用其“原始开发者”的胡说八道来做的事情
与现实不符，即使是一点点也不符。[…] 它在*概念上*是坏的。”
[Bruce Perens][perens-cfsl-community] 同意
C-FSL 不仅违反了 OSD，而且对社区也不利。
随之而来的是另一个主题，其中包含大量关于
重新许可、分支和维护者-社区动态的示例
（注：在许可证讨论摘要中介绍）。
原始作者始终可以指定更多原始作者。
但这[不能保证][piana-reaction]
原始作者在作品中持有重要的版权股份。
当包含来自另一个项目的代码时，作者身份的概念也[变得模糊不清][landley-65]。
当包含来自另一个项目的代码时，作者身份的概念也[变得模糊不清][landley-65]。
[Brendan Hickey][hickey-cla] 注意到
这允许规避 65% 规则，
例如，通过包含一个庞大的第三方库，
或者仅包含 C-FSL 涵盖代码的一小部分。
[Rob Landley][landley-joint] 指出
许可证不决定谁是版权持有人，
而是版权持有人允许*其他人*做什么。
这引发了一场关于
开源中*共同作者身份*作用的小讨论
[[1][cowan-joint],[2][rosen-joint]]。
[landley-xfree86]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003900.html
[perens-cfsl-community]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003901.html
### C-FSL 与 CLA 或宽松许可证有何不同？
此许可证的目标是
维护者可以轻松地重新许可项目，
而无需处理 CLA。
如果 CLA 和 C-FSL 受到如此多的批评
为什么不批评宽松许可证呢，
[Stellnberger 问道][stellnberger-oa-copyright]？
宽松许可证实际上允许任何人重新许可代码，
而 C-FSL 将此权利分配给原始作者
（参见上述批评）。
[Carlo Piana][piana-cfsl] 指出
贡献者可以拒绝签署 CLA
在这种情况下，他们的更改无法合并到上游项目中，
但贡献者不能拒绝 C-FSL
因为它在更改发生后立即隐式适用。
Brendan Hickey [[1][hickey-oa-copyright],[2][hickey-cla]] 指出
[Project Harmony](http://www.harmonyagreements.org/)
可用于标准的 CLA 模板。
无论如何，允许维护团队进行任意重新许可
并不是开源需要解决的问题。
注：允许任意重新许可的另一个问题
是贡献者事先不知道哪些权利可以被许可。
因此，贡献者必须假定他们不保留任何权利
，除非通过 C-FSL 明确许可回来的权利。
CLA 至少明确列出了哪些权利被许可，
并说明它们是否被独家许可。
如果某个司法管辖区的版权法
要求这些权利转让采用特定的合同形式，
则 C-FSL 的隐式性可能会成为问题。
### 为什么发布要求是个问题？
[Carlo Piana][piana-cfsl] 注意到，对 C-FSL 涵盖作品的任何更改
都必须在一个月内发布，即使是不完整或有缺陷的更改。
这侵犯了作者决定是否发布的权利。
> 这是盗用，明目张胆的盗用。
> 因此，我所做的任何更改，无论是否向公众发布，
> 都是以相当于转让的方式贡献的，
> 授予对衍生代码的权利，
> 包括开发者的版权，
> 开发者无法获得这些权利
> 并且无法避免。
[Elmar Stellnberger][stellnberger-publication] 回应说
对有缺陷的更改的发布要求并非有意为之。
这种发布义务难道不
类似于 Vim 或 Affero 许可证吗？
（注：不是。
虽然 Vim 有发布要求，
但它也有替代的 GPLv2+ 重新许可条款。
而 AGPL 不需要发布
，除非在通过网络传播软件
或向用户提供软件时。）
[Nigel Tzeng][tzeng-obligation]
认为此发布要求是交易破坏者。
所有更改都必须在公共存储库中。
并且由于非常容易不合规，
C-FSL 是一个许可证陷阱。
[stellnberger-publication]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003913.html
[tzeng-obligation]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003918.html
### C-FSL 可以获得 OSI 批准吗？
[Brendan Hickey][hickey-oa-copyright] 指出
Debian 项目[长期以来一直认为][debian-cfsl]
C-FSL 违反了 DFSG，
因此 OSI 希望不会做出不同的决定。
[Carlo Piana][piana-cfsl] 建议
如果类似 CLA 的方面
仅在上游项目做出贡献时触发，
而不是在代码被修改后立即触发，则许可证可能符合 OSD 标准。
“我期望在新许可证中看到这方面的改进，
相反，我只看到顽固的措辞修改
，这使得外行人更难发现
该许可证在实践中是如何运作的。”
[Elmar Stellnberger][stellnberger-improvements] 拒绝了这个建议
“这将使原始作者的整个条款变得荒谬”
，并使其他人太容易重新许可该项目。
[debian-cfsl]: https://lists.debian.org/debian-legal/2016/01/msg00023.html
[piana-reaction]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003894.html
[piana-cfsl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003911.html
[perens-reaction]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003895.html
[hickey-oa-copyright]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003910.html
[landley-65]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003896.html
[fleming-cfsl]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003923.html
[stellnberger-improvements]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003914.html
## 可转换自由软件许可证，版本 1.4
[Elmar Stellnberger][stellnberger-cfsl14]
提交了 C-FSL 的下一个修订版。
[Lukas Atkinson][atkinson-cfsl14]
总结了更改：细微的澄清和一个封闭的漏洞。
但关于根本性批评没有取得任何进展，
因此进一步审查似乎毫无意义。
[stellnberger-cfsl14]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003928.html
[atkinson-cfsl14]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-January/003931.html