2018 年 12 月 License-Discuss 邮件列表摘要
我被要求提供 license-review 和 license-discuss 邮件列表的月度摘要。
摘要也将发布在各自的列表中，尽管此博客版本包含指向列表存档的详细链接。
欢迎任何反馈，但对内容的回复当然应在原始帖子中进行。
本月主题
* 国际许可证重议
* 提议的许可证决策流程
* 开源许可证中的“对价”
* 带有展示署名义务的开源许可证？
* SSPL 遗留问题
License-Review 摘要
## 国际许可证重议
[Richard Fontana 建议][RF:international] 将“国际”[许可证类别][Categories] 从非英语语言许可证 (LiLiQ) 扩展到涵盖“针对特定语言和司法管辖区”的许可证，无论其语言如何（EUPL、CeCILL）。正如 [Mike Milinkovich][Milinkovich] 解释的那样，语言和司法管辖区是相互交织的：“按照惯例，OSS 期望英语作为许可证的语言，但在世界上某些地方，这在法律上是不可能的[由于法定的语言要求]。”
[RF:international]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020156.html
[Milinkovich]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020160.html
[Categories]: https://open-source.org.cn/licenses/category
## 提议的许可证决策流程
[Richard Fontana 发布了 OSI 董事会讨论的澄清许可证决策流程的[草案][RF:process]。该提案增加了一个明确的决策日期，即初始许可证提交后 60 天，在此之后，如果讨论仍在进行中，OSI 将推迟决策；如果讨论已得出结论，则批准或拒绝许可证；如果许可证可以修改，则暂缓批准。
[RF:process]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020157.html
[Bruce Perens][BP:freedom] 赞赏“软件自由”是提议的决策流程的明确目标，但指出该术语可能不明确。[Lawrence Rosen 认为][LR:freedom] 开源应基于[更务实的定义][LR:consideration]。
[BP:freedom]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020159.html
[LR:freedom]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020162.html
[LR:consideration]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020189.html
[Luis Villa 询问][LV:freedom] 关于软件自由的具体测试，以及许可证审查是否会与 FSF 协调。[Richard Fontana 回复][RF:freedom] 他认为 OSD 是对软件自由的定义的尝试，但 OSD 是有限的，不应被视为清单或过于字面地解释。关注软件自由作为实际目标将有助于避免这种情况。虽然 Fontana 希望看到 OSI 和 FSF 在边缘案例 FOSS 许可证的决策方面更加协调一致，但他认为他们截然不同的审查流程不应密切协调。
[LV:freedom]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020163.html
[RF:freedom]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020165.html
过去 OSI 接受的有害许可证呢？[Perens][BP:example] 特别考虑了 SIL Open Font License。[Rick Moen][Moen] 认为这些许可证是一个挥之不去但次要的问题，因为社区期望使用主要的许可证之一。[Luis Villa][LV:cleanup] 认为清理旧许可证可能是一个好主意，并且还可以为新的许可证审查流程提供“判例法”。[Nicholas Weinstock][Weinstock:consideration] 希望现有许可证能够被保留。
[BP:example]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020168.html
[Moen]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020170.html
[LV:cleanup]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020173.html
[Weinstock:consideration]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020172.html
## 开源许可证中的“对价”
作为比“软件自由”更务实的许可证审查流程基础，[Lawrence Rosen 提出][LR:consideration]
> “开源软件”是指实际按照以下条款分发的软件：授予所有贡献者对软件的版权和专利许可，允许每个被许可人访问和使用完整的源代码，制作软件或其衍生作品的副本，并且无需支付版税或其他对价，即可分发未修改或修改后的软件。
关于“无需对价”的讨论开始了。[Florian Weimer 指出][Weimer] 这个术语在普通法之外很难理解。例如，[Kevin P. Fleming][Fleming:consideration] 和 [Nicholas Weinstock][Weinstock:edgecase] 指出，分发源代码的 copyleft 要求可能被解释为一种对价。[Bruce Perens 回应][BP:consideration] Jacobsen v. Katzer 案例表明，开源许可证确实具有非货币对价。
[Lawrence Rosen 坚持认为][LR:condition] “对价”不应与“条件”混淆。Rosen 声称，没有开源许可证要求对价，但 OSI 接受某些许可证条件（例如 copyleft 条件）。Rosen 认为，创建开源软件或获得署名本身就是一种回报。（注意：Rosen 对对价和条件之间的区分似乎证明了 Weimer 的观点，而关于对价的说法直接与 Perens 相矛盾。）
[Nicholas Weinstock][Weinstock:consideration] 指出，许多 OSI 批准的许可证明确提到了对价和条件。也许可以通过权利是放弃还是获得来区分这些概念？[Rosen][LR:peppercorn] 同意这些术语可能具有“微妙的法律含义，包括在其他国家/地区”，但解释说，对价可以是许可方重视的任何东西，包括“[象征性对价]”。
[Nigel Tzeng][Tzeng:consideration] 指出，对于开源许可证而言，问题的关键恰恰在于可接受的对价水平：“某些形式的对价是可以接受的，甚至是好的。其他形式则变得过分。”[Rosen][LR:consideration] 承认这一点，并解释说他主要关心下游用户的对价。（注意：似乎 Rosen 对对价的不满与其说是对价本身，不如说是可能没有明确的对价接收者。）
关于“实际分发”部分，[Nicholas Weinstock][Weinstock:edgecase] 指出，BSD 许可证可能无法满足该标准，因为它没有明确的专利授权。[Lawrence Rosen][LR:condition] 同意，并且会反对没有明确专利授权的新许可证。事实上，明确排除专利授权的许可证已被拒绝。然而，Rosen 承认，特别是学术许可方可能只能提供有限的授权。Rosen 还指出了围绕开放标准的可能问题。
[Weimer]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020183.html
[Fleming:consideration]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020185.html
[Weinstock:edgecase]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020169.html
[BP:consideration]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020186.html
[Tzeng:consideration]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020188.html
[LR:condition]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020171.html
[LR:peppercorn]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020174.html
[Peppercorns]: https://en.wikipedia.org/wiki/Peppercorn_(legal)
## 带有展示署名义务的开源许可证？
Simon Cox 询问 [[1][Cox:1],[2][Cox:2],[3][Cox:3]] 是否有任何开源许可证要求公开署名作为感谢的姿态，例如在网站上放置徽标。正如 [Stephen Michael Kellat][Kellat] 所强调的那样，此类署名将更容易展示开源项目的影响，尤其是在公共部门/GOSS 中。
[Cox:1]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020123.html
[Cox:2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020127.html
[Cox:3]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020138.html
[Kellat]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020143.html
此类署名可能很棘手。[Danese Cooper 回忆][Cooper] OSI 批准的署名保证许可证 [AAL] 与 SugarCRM 之前要求在每个页面中间显示其徽标之间的紧张关系（参见 [ZDNet]），这被认为与 OSD 相悖。[David Woolley][Woolley] 提到了 4 条款 BSD 许可证中的广告条款的困难。
[Cooper]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020124.html
[AAL]: https://open-source.org.cn/licenses/AAL
[Woolley]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020125.html
[ZDNet]: https://www.zdnet.com/article/podcast-sugarcrm-ceo-says-attribution-in-open-source-licenses-is-about-fairness/
Antoine Thomas 指出 [[1][Thomas:1],[2][Thomas:2]] 署名通常不是问题，因为软件中的所有署名通常都收集在一个单独的页面上。[Thorsten Glaser 回应][Glaser:1] 这只有在许可证是技术中立的并且不规定特定的署名样式时才有可能。Glaser 还 [提出了问题][Glaser:2]，即公开署名的要求可能无法通过“异议者”或“荒岛”测试（参见 [DFSG]）。
[Thomas:1]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020126.html
[Thomas:2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020128.html
[Glaser:1]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020133.html
[Glaser:2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020134.html
[DFSG]: https://people.debian.org/~bap/dfsg-faq.html#testing
[Bruce Perens 提到][BP:badgeware] “徽章软件”的两个问题：它会在仅使用时触发要求，并且会使 Debian 等大型项目的合规性变得不可行。[Lawrence Rosen 指出][LR:badgeware] OSD #10 “许可证必须是技术中立的”阻止了一些徽章软件许可证。
[BP:badgeware]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020131.html
[LR:badgeware]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020132.html
Bruce Perens 指出，署名请求而不是要求是没有问题的。[Lawrence Rosen][LR:requirements] 认为温和的要求是完全合理的，例如：“被许可人必须以与被许可人展示其自身商标同样显眼的方式和位置展示嵌入式软件的名称和来源。”
Rosen 还表达了对许可证审查流程的有趣观点：“我们的工作是批准那些成功尝试（？）新许可证模型的许可证，而不是不断拒绝从软件中获取利润和认可的方式。只要它是‘开源软件’，就让市场来决定许可证的可接受性。”
[BP:requirements]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020139.html
[LR:requirements]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020140.html
Chris Lamb 建议 [[1][Lamb:1],[2][Lamb:2]] 向任何知名的许可证（例如 GPLv3）添加包含署名请求的附录。（注意：这可能是 GPLv3 的附加条款。）[Lawrence Rosen 声称][LR:GPL] GPLv3 “不保护衍生作品中的署名”。
[Lamb:1]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020141.html
[Lamb:2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020145.html
[LR:GPL]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020142.html
关于政府开源软件 (GOSS) 署名方面，[Nigel Tzeng][Tzeng:1] 对可用的开源许可证和开源社区表示相当失望。公共项目通常需要可见的署名来确保未来的资金。
[Jim Jagielski][JJ] 和 [Lawrence Rosen][LR:GOSS] 不同意 GOSS 在这方面与其他项目根本不同。然而，Rosen 同意当前的许可证（例如 GPLv3）未能确保充分的署名。
[Christopher Sean Morrison][Morrison] 列出了 GOSS 面临的一些美国特有的问题或未解决的法律问题。这限制了公共部门参与开源：“没有人想成为小白鼠。”[Tzeng][Tzeng:2] 指出 [NASA] 和 [ECL] 许可证是其他公共部门的需求已经使特定许可证成为必要的例子。
[Tzeng:1]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020146.html
[Tzeng:2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020152.html
[NASA]: https://open-source.org.cn/licenses/NASA-1.3
[ECL]: https://open-source.org.cn/licenses/ECL-2.0
[JJ]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020147.html
[LR:GOSS]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020150.html
[Morrison]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020151.html
## SSPL 遗留问题
SSPL 的提交引发了关于 copyleft 和总体审查流程的大量讨论。一些遗留问题
[Kyle Mitchell][Mitchell] 跟进了 11 月份的两个要点。针对较早的 [自由还是权力？] 文章，Mitchell 指出，不仅存在文章的生产者与用户之间的权力失衡，而且生产者之间也存在失衡。Mitchell 认为，有必要采用 SSPL 等非许可型许可证来保护生产者免受竞争对手的侵害。
SSPL 的支持者不多。Mitchell 指出，支持者的数量不应重要，以免许可证审查流程变成一场受欢迎程度竞赛。
[Mitchell]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020181.html
[Freedom or Power?]: https://gnu.ac.cn/philosophy/freedom-or-power.en.html
此前，Kyle Mitchell 曾指出，一些 OSI 批准的许可证会在使用时触发要求，而不仅仅是在复制时：OSL 和 AGPL。[Florian Weimer][Weimer:replication] 认为 AGPL 最初是为也提供源代码的服务器而设计的，而不是为开放核心商业模式而设计的。“我相信，尝试以这种方式使用 AGPL 的人们对效果感到失望。”Weimer 想知道此类商业模式是否是 OSL 的考虑因素。
[Weimer:replication]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2018-December/020184.html
许可证审查应侧重于许可证文本还是其潜在用途？[Florian Weimer][Weimer:opencore] 更倾向于文本审查，因为这避免了必须对开放核心商业模式采取立场。[Brendan Hickey][Hickey:opencore] 澄清说，2010 年 OSI 博客上关于此事的帖子是个人观点，而不是 OSI 的官方立场。
[Weimer:opencore]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003884.html
[Hickey:opencore]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2018-December/003886.html