2019 年 3 月 License-Discuss 摘要
在三月份，License-Discuss 邮件列表讨论了
* 密码自主许可证
* 它与 GDPR 的交互
* 公开表演如何适用于软件
* 许可证审查流程
* 关于列表的语气和行为的观点
* 列表在许可证审查流程中的作用
* 电子邮件的问题，以及替代工具
* PEP 风格的流程是否有帮助
* 是否应该在没有法律援助的情况下起草许可证
* 以及更多
相应的 License-Review 摘要已在线发布
于
并涵盖了 SSPL 从审查中撤回，
以及关于一组 GPLv3 附加条款的讨论。
[License-Review]: https://open-source.org.cn/LicenseReview032019
[License-Discuss-2019-01]: https://open-source.org.cn/LicenseDiscuss012019
## 密码自主许可证 {#cal}
[Van Lindberg][vanl_cfc]
请求对他的密码自主许可证 (CAL) 发表评论，
这是一种受区块链软件驱动的网络 copyleft 许可证。
他还写了一篇 [博客文章][vanl_blog]
详细解释了许可证的背景和理由。
[vanl_cfc]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020278.html
[vanl_blog]: https://www.processmechanics.com/2019/03/15/the-cryptographic-autonomy-license/
### 用户数据和 GDPR {#cal-gdpr}
CAL 具有确保用户访问其数据的条款，
这与欧盟的 GDPR 方向相似
– 它甚至在解释条款中引用了 GDPR。
CAL 定义了合法利益的概念
作为用户访问权限的触发器。
[Henrik Ingo][ingo] 指出
这授予了第三方权利，
这相当新颖，可能会引发 OSD 问题。
[Van Lindberg][vanl_ingo] 说
这些只是第三方受益人
除了
访问源代码和他们自己的用户数据外，不获得其他权利。
CAL 中的数据保护不是授予第三方权利，
而是对被许可人的授权的限制，
类似于 GPLv3 的反 Tivoization 条款。
Henrik Ingo [[1][ingo],[2][ingo_gdpr]]
更深入地研究了 CAL ↔ GDPR 关系，
并发现 CAL 用户数据与 GDPR 个人数据概念不一致。
[Van Lindberg][vanl_ingo] 回应说
CAL 和 GDPR 有不同的角度
GDPR 主要关注隐私，
CAL 主要关注用户自主权。
合法利益旨在
不仅通过所有权或 GDPR 捕捉权利，
还包括用户拥有或已获得许可的电子书的权利。
CAL 的用户数据概念比 GDPR 的个人数据更广泛。
基于 Ingo 的反馈，
[Lindberg][vanl_gdpr] 更新了 CAL 的措辞
以澄清其与 GDPR 的关系。
[ingo]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020310.html
[vanl_ingo]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020324.html
[ingo_gdpr]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020339.html
[vanl_gdpr]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020350.html
### 公开表演 {#cal-public-performance}
CAL 在“公开表演”时触发一些许可证义务，
这是现有开源许可证未明确讨论的版权方面。
这旨在创建像 AGPL 这样的网络 copyleft 许可证，
同时减少对媒介或技术的具体性。
Henrik Ingo [[1][ingo],[2][ingo_gdpr]] 对这个不寻常的术语有点反感，
类似于 GPLv3 中“传播”的用法。
CAL 也没有明确说明
“公开表演接口”是什么意思。
是否有将公开表演应用于软件的先例？
什么是接口？
这将如何应用于库 API？
Ingo 还担心公开表演可能过于宽泛
以至于它将涵盖远超 SaaS 风格的用途。
[Van Lindberg][vanl_ingo] 指出
公开表演是版权法中一个成熟的术语，
但 [承认][vanl_gdpr] 其在软件中的应用
不太明确。
Lindberg 打算将“接口”广泛解释，从 GUI 到 API
– 只要它可以受到知识产权法的保护。
这绝对应该涵盖不仅仅是 SaaS 用途。
毕竟，CAL 试图确保
分布式软件系统中的用户自主权。
[Henrik Ingo][ingo_undefined] 认为
围绕公开表演缺乏清晰度
是 CAL 的一个主要弱点
– 也许应该始终允许特定用途，
类似于 GPL 如何给予无限许可
来运行未修改的程序？
[ingo_undefined]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020368.html
Bruce Perens [[1][perens_oppress],[2][perens_literary]]
不确定美国版权法
是否为 CAL 的运作提供了足够的公开表演权，
特别是软件是否属于文学作品。
[Van Lindberg][lindberg_copyright]
为美国和国际法提供了大量参考文献
表明软件被视为文学作品。
(注意：另见 WIPO 版权条约。)
由此可见，文学作品的表演权也必须适用于软件。
[perens_oppress]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020314.html
[perens_literary]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020316.html
[lindberg_copyright]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020325.html
### 其他注意事项 {#cal-other}
[Henrik Ingo][ingo]
“兼容的开源许可证”是否只是任何 OSI 批准的许可证？
Van Lindberg [[1][vanl_ingo],[2][vanl_gdpr]] 回应说
CAL 将开源许可证定义为 OSI 和 FSF 批准的，
但兼容性由其他许可证的条款决定。
CAL 允许添加一个简单的类似 LGPL 的例外。
[Henrik Ingo][ingo] 希望它是
一个具有自己名称的明确独立的许可证。
[Van Lindberg][vanl_ingo] 认为这不是问题，
就像不同的 GPL 例外（如 Classpath）没有问题一样。
CAL 显着扩展了 copyleft 许可的范围，
特别是公开表演。
[Henrik Ingo][ingo_undefined] 认为
这种“版权最大化主义”态度令人遗憾，
并呼应了 [Bruce Peren’s][perens_jan_extension] 的观点，即
“版权的扩展对开源不利”。
[Van Lindberg][vanl_maximalist] 回应说
CAL 尽力适应既定的知识产权法范围。
[perens_jan_extension]: https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-January/020261.html
[vanl_maximalist]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020376.html
[Bruce Perens][perens_oppress] 认为
将许可证授权限制为版权和专利
对于承认额外权利的司法管辖区来说可能过于狭窄。
Perens 建议许可证应授予所有必要的权利，
并且仅排除商标。
[Van Lindberg][lindberg_copyright] 考虑扩大授权范围。
Bruce Perens [[1][perens_oppress],[2][perens_osd6]]
认为 CAL 的反 DRM 条款过于狭窄
因为它专注于加密密钥等特定技术。
这甚至可以被理解为 OSD #6 使用限制。
Van Lindberg [[1][lindberg_copyright],[2][vanl_osd6]]
同意单独来看可能过于狭窄，
但该许可证还包含更一般的反 DRM 条款。
提及特定技术是他的客户要求的。
这与其说是一种用户限制，不如说是一种反 Tivoization 条款
这是许可证正在开发的环境所必需的。
[perens_osd6]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020332.html
[vanl_osd6]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020338.html
## 许可证审查流程讨论 {#process}
在 SSPL 从 OSI 审查中撤回的背景下
（参见 [License-Review] 摘要），
[Josh Berkus][berkus_disappointed]
对许可证审查流程表示失望
Berkus 看到的是人身攻击，而不是关于许可证内容的法律讨论。
Berkus 看到的是人身攻击。
> [这] 是许可证审查流程的戏剧性失败，
> 我认为这表明这个小组需要重组。 […]
> 我们需要围绕许可证批准的真实流程，而不是
> “用最多空闲时间熬过许可证专家”。
这引发了关于
是否存在问题，
SSPL 审查应该如何进行，
审查如何运作，
电子邮件列表的问题是什么，
以及是否可能有替代方案（Discourse？）。
[berkus_disappointed]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-March/003992.html
[smith_what]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-March/003993.html
[fontana_puzzled]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-March/003994.html
[berkus_wtf]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-March/003995.html
[smith_presentation]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-March/003996.html
[fontana_lists]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-March/003997.html
[CopyleftConf]: https://2019.copyleftconf.org/
[perens_civil]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020309.html
[rosen_repetitious]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020312.html
[demarsh_repetitious]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020329.html
### 关于列表的语气和行为的观点 {#process-conduct}
[McCoy Smith][smith_what]
和 Richard Fontana [[1][fontana_puzzled],[2][fontana_branch]]
不认同 Berkus 的观点。
关于 MongoDB 商业模式的讨论不是人身攻击，
而是与许可证的实际效果密切相关。
总的来说，它仍然相当文明。
Fontana 看到“充满活力和认真的讨论 […]
来自异常广泛的评论员”，
并担心限制“固执己见、充满激情”的讨论
“可能会起到扼杀辩论和表达的作用。”
[Bruce Perens][perens_civil]
认为讨论仍然是文明的，
但他不能回应某些人
而不会被视为“争吵”。
[Josh Berkus][berkus_wtf]
报告说“外部”人士对 SSPL 讨论的行为感到困惑和震惊。
对 SSPL 讨论的行为感到困惑和震惊。
> OSI 的权威仅限于
> 我们被广泛认为是公正的仲裁者
> 关于什么是和什么不是开源。
> 这很重要。
> 在 SSPL 上，我们 *没有* 被广泛认为是公平或公正的。
[Richard Fontana][fontana_lists] 指出
License-Review 是一个公共列表
不应与 OSI 混淆。
OSI 没有成为 SSPL 的仲裁者
因为许可证是自愿撤回的。
然而
> License-Review 的参与者应遵守行为准则，
> 但他们不应保持中立或不表达意见[。]
[Rick Moen][moen_discourse_review]
怀疑对列表讨论文化的不满
只是“被动攻击性的反击
反对他们不喜欢的许可证委员会的决定”。
Richard Fontana [[1][fontana_suspicion],[2][fontana_lists]]
也认同这种怀疑：“在我看来，这听起来像是抱怨
SSPL 上许可证审查线程的大多数积极参与者
都对 SSPL 持有敌意。”
[Perens][perens_civil]
认为问题是讨论变得重复。
[Lawrence Rosen][rosen_repetitious]
用包含他最常重复的观点的 8 点宣言回应。
Luis Villa [[1][villa_screaming],[2][villa_nope]]
抱怨讨论的数量和质量。
辩论是
“只有在它们有帮助的情况下才有价值 [并且]
当前讨论的质量和性质并没有很好地做到这一点”
> 在某个时候我查看了一下 […]
> 看到该线程 *字面上有 100 封电子邮件*，
> 考虑到早期部分的负面性（且常常是循环论证），
> 并说“不，生命太短暂了”。
[fontana_branch]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020307.html
[villa_nope]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020345.html
### SSPL 审查是否应该有不同的重点？ {#process-sspl}
[Josh Berkus][berkus_wtf] 希望看到
关于 copyleft 和 OSD 的一般性讨论，
[Richard Fontana][fontana_puzzled] 提醒说，许可证审查不是进行此类讨论的地方。
审查应仅检查许可证是否
“符合开放源代码定义并提供软件自由。”
但对于 Berkus 来说，这些是不可分割的
OSD 合规性问题
直接关系到
copyleft 可以且应该扩展到多远的问题。
令 Berkus 失望的是，最近的 [CopyleftConf] 没有看到太多关于
专门关于 SSPL 的讨论。
[McCoy Smith][smith_presentation]
总结了他在会议上的演讲中的一些观点
其中提到了该许可证
并讨论了一个假设的极端 Copyleft 公共许可证作为思想实验。
Smith 还指出 AGPL 解决了 SaaS 商业模式，
因此 OSI 并非对 SaaS 持有偏见。
Smith 认为社区不会对
将 copyleft 扩展到 AGPLv3 之外持有根本性的反对意见。
### 列表在许可证审查流程中的作用 {#process-list}
[Rick Moen][moen_discourse_review] 提出，如果
根本问题在于
License-Review 讨论被误认为是 OSI 的官方立场，
那么如果官方发言的人更好地自我识别身份，就可以解决这个问题。
[McCoy Smith][smith_process] 认为此处提出了以下批评，
并更详细地讨论了它们
1. 少数大声的声音对审查决定产生了不当影响
2. 这些声音缺乏多样性，或者未能反映“沉默的大多数”
3. 审查决定如何考虑电子邮件讨论尚不清楚
[Bruce Perens][perens_vote] 在后一点上指出
这些列表仅供参考，
决定由 OSI 董事会投票做出。
但是，董事会如何做出决定缺乏透明度。
董事会成员甚至阅读 License-Review 列表吗？
哪位董事投了什么票？
[Mike Milinkovich][milinkovich_vote]
分享了他作为前董事会成员的经验
几乎所有许可证批准投票都是一致通过的。
董事会的作用不仅仅是许可证投票，
因此不应期望每位董事会成员都是许可专家。
Richard Fontana [[1][fontana_process],[2][fontana_lists]] 补充说
大多数许可证提交者在
不确定许可证是否会被批准的情况下会撤回许可证。
本月对 CFSL 的投票可能是第一次拒绝。
从这个意义上说，问题不在于大声的声音
是否对 OSI 产生不当影响，
而在于它们对提交者的影响。
MongoDB 在董事会投票前几天撤回了 SSPL，
理由是未能就许可证达成社区共识
（这不仅仅是许可证审查讨论）。
[Ben Hilburn][hilburn_process]
认为 Fontana 的区分
即对 OSI 的影响与对许可证提交者的影响之间的区分
非常重要。
但是，虽然一些分歧是正常且预期的，
但保护提交者和辩论
免受负面行为的影响也很重要。
Hilburn 警告说
> *特别是* 对于 License-Review 建议拒绝的许可证，
> 我们的流程和辩论真的需要被信任。
[perens_vote]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020285.html
[milinkovich_vote]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020290.html
[fontana_process]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020294.html
[hilburn_process]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020303.html
### 电子邮件的问题，以及替代方案 {#process-tools}
[Bruce Perens][perens_civil] 提到讨论变得重复。
[Andrew DeMarsh][demarsh_repetitious] 也
认为邮件列表的媒介
使得再次又一次地讨论相同的主题变得容易，
而无法轻松参考它们之前的出现。
这对列表参与者来说是无聊且令人厌倦的。
也许邮件列表的更好前端会有所帮助。
Luis Villa [[1][villa_screaming],[2][villa_nope]]
突出了当前基于电子邮件的审查流程
存在许多问题或限制
* 从外部对流程的可见性有限
* 太容易产生大量的讨论
* 这些月度摘要太不频繁，无法指导讨论
* 未列出或跟踪特定问题
* 外来者难以建设性地加入，
而不仅仅是发表随意评论
* 无法静默表示同意
* [McCoy Smith][smith_process] 补充说：存档难以搜索
Villa 建议 Discourse 软件可能提供更好的平台，
但实际上任何其他工具都比电子邮件有所改进。
任何工具都会有 *一些* 缺点，
但 Villa 认为
Discourse 将降低参与讨论的门槛。
[villa_screaming]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020279.html
[smith_process]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020284.html
[Rick Moen][moen_discourse_review]
提供了他对 Discourse 经验的批判性总结，
例如提到缺乏线程讨论。
相比之下，[John Sullivan][sullivan_caretaker] 指出
FSF 正在愉快地使用 Discourse。
[moen_discourse_review]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020293.html
[fontana_suspicion]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020308.html
[Richard Fontana][fontana_branch] 认为 Discourse 值得尝试，
尽管它可能更适合不同类型的讨论。
Fontana 不认为
“新工具将解决根本上的社会或政治问题。”
[Villa][villa_nope] 回应说，工具确实可以缓解症状。
Rick Moen 和 Thorsten Glaser
[[1][moen_contract],[2][moen_contract2],[3][glaser_contract]]
担心使用 Discourse
将要求讨论参与者与第三方托管公司签订合同。
与第三方托管公司签订合同。
[Kevin Fleming][fleming_contract] 和 [Michael Downey][downey_contract]
回应说情况并非如此。
[Bruce Perens][perens_mail] 建议至少，
列表存档软件可以升级到比 Pipermail 更好的东西，
Pipermail 仅支持纯文本电子邮件。
在回应随意提及的 Bugzilla 或 GitHub 时，
[Fontana][fontana_branch] 认为它们
将是精英主义的，并将非技术人员拒之门外。
“几年前，我曾考虑过
对于许可证起草而言，采用开发人员首选的工具显然是有益的。 […]
对于许可证起草而言，采用开发人员首选的工具显然是有益的。 […]
我现在看到 […] 涉及到很多对
开发人员和开源开发的浪漫化。”
[Ben Hilburn][hilburn_email] 同意关于电子邮件的一些问题，
但赞赏电子邮件允许用户选择他们的客户端和工作流程。
一些基于 Web 的工具可以与基于电子邮件的工作流程集成，
这可能是 desirable。
[hilburn_email]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020335.html
### PEP 风格的流程是否有帮助？ {#process-pep}
[John Sullivan][sullivan_caretaker]
建议可以在不更改工具的情况下改进流程。
例如，可以为每个许可证申请分配一名（志愿者）管理员
管理员维护一份包含讨论要点的档案。
最终，任何流程都将依赖于个人，
并且没有流程能够阻止
更大的声音或有议程的个人。
[Chris Jerdonek][jerdonek_pep]
将 Python 的 PEP 模型进行了比较
（[Python 增强提案][pep]）
其中讨论总结在中心文档中。
这样的文档对于进一步参考也很有用。
[Van Lindberg][vanl_pep] 和 [Ben Hilburn][hilburn_process] 同意。
[Bruce Perens][perens_mail] 和 [Jerdonek][jerdonek_pep2]
警告说 PEP 流程中的讨论
仍然基于邮件列表，具有媒介的所有缺点。
[John Sullivan][sullivan_pep] 和 [Jerdonek][jerdonek_pep2]
解释说拥有中心 PEP 文档
有助于使讨论保持在正轨上
并使以后更容易加入对话。
[Bruce Perens][perens_consensus]
担心类似 PEP 的流程
可能难以就许可证批准等政治决策达成共识
对于许可证批准等政治决策达成共识。
Perens 指出 W3C 过去常常做出共识决定
直到专利政策问题导致无法克服的分歧。
[Chris Jerdonek][jerdonek_consensus]
将 PEP 更多地视为文档工作，
而不是作为建立共识的过程。
批准决定是在外部做出的
（注意：比较 OSI 董事会的作用）。
[Van Lindberg][vanl_pep] 说明了 PEP 流程如何
与其 CAL 许可证的审查相关（见下文）。
在这里，Lindberg 在一篇类似 PEP 的博客文章中跟踪了各种论点。
谁应该维护 PEP 摘要？
Pamela Chestek [[1][chestek_pep],[2][chestek_editor]]
建议可以委托许可证提交者执行此操作
以避免增加志愿者的负担。
[Luis Villa][villa_pep] 认为提交者可能很难
确定摘要中应涵盖的有用且重要的论点。
确定摘要中应涵盖的有用且重要的论点。
Bruce Perens [[1][perens_pep],[2][perens_editor]]
认为流程编辑（或编辑组）可能很有用。
这可能是法律专业人员的工作，
而不是列表上可能有利益关系的志愿者的工作。
Richard Fontana [[1][fontana_editor],[2][fontana_editor2]]
担心摘要中可能存在的偏见，
无论是志愿者编辑维护的摘要，
还是特别是许可证提交者负责的摘要。
但是，拥有一个编辑组可能会有所帮助。
[Perens][perens_editor2]
认为提交者编写的摘要可以工作
如果摘要文档有清晰的版本历史记录，
并且提交者与一位不相关的编辑配对。
Luis Villa [[1][villa_pep],[2][villa_editor]]
建议采用更协作的 Wiki 式方法，
或者摘要的修订
必须由独立人员批准。
[Villa][villa_editor2] 不太担心偏见，
更担心是否写出有用的摘要。
[Chris Jerdonek][jerdonek_editor]
解释说，提交者编写的摘要可以工作
如果糟糕/有偏见的摘要将导致许可证被拒绝。
版本控制等很重要。
[pep]: https://pythonlang.cn/dev/peps/pep-0001/
[sullivan_caretaker]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020296.html
[jerdonek_pep]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020298.html
[moen_contract]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020346.html
[moen_contract2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020353.html
[fleming_contract]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020347.html
[glaser_contract]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020354.html
[downey_contract]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020378.html
[perens_mail]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020323.html
[sullivan_pep]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020344.html
[chestek_pep]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020349.html
[vanl_pep]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020352.html
[jerdonek_pep2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020357.html
[villa_pep]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020361.html
[perens_pep]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020362.html
[perens_consensus]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020358.html
[jerdonek_consensus]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020359.html
[fontana_editor]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020370.html
[perens_editor]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020371.html
[fontana_editor2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020382.html
[perens_editor2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020383.html
[villa_editor]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020390.html
[chestek_editor]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020372.html
[villa_editor2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020375.html
[jerdonek_editor]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020373.html
## Pro-se 许可证构建者 {#pro-se}
License-Review 列表收到了一份许可证提交，
该许可证之前没有经过法律审查。
这提出了一个问题，即对于非律师而言，创建和提交许可证是否安全且可接受。
创建和提交许可证是否安全且可接受。
Bruce Perens [[1][perens_crayon],[2][perens_crayon2]] 认为
推广“蜡笔许可证”是危险的。
在没有法律审查的情况下，该许可证的实际效果是未知的。
“因此，我认为所有此类事物都应被拒绝，
尽管原因完全在 OSD 之外。”
作为一个例子，Perens [指向][perens_artisic] 关于 Artistic License 的 Jacobsen v Katzer 案例，
Larry Wall 曾亲自起草过 Artistic License。
该案例可能已经设定了
“一个绝对可怕的先例 […]
> 该许可证等同于对公共领域的奉献。”
[McCoy Smith][smith_barriers] 警告说，要求事先进行法律审查
将成为进入门槛，
可能导致审查讨论由律师主导，
并且不能保证许可证的质量。
[Perens][perens_defender] 建议，如果 OSI 分配一位像“公设辩护人”一样的律师，则可以避免门槛。
[Perens][perens_defender] 建议，如果 OSI 分配一位像“公设辩护人”一样的律师，则可以避免门槛。
[Henrik Ingo][ingo_cost] 认为进入门槛不是问题
已经有很多已批准的许可证可用。
许可证审查流程也不是零成本，
成本由 OSI 承担。（注意：还有社区！）
[Brendan Hickey][hickey_barriers]
深入探讨了门槛和法律审查的目的。
Hickey 不认为法律审查
适用于保护许可证的最终用户。
法律可能不应该是第一步
“没有人应该聘请律师
来起草一份会被断然拒绝的许可证。”
[perens_crayon]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-March/004001.html
[perens_crayon2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020289.html
[perens_artisic]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020317.html
[smith_barriers]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020291.html
[perens_defender]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020297.html
[hickey_barriers]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020302.html
[ingo_cost]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020311.html
Nigel Tzeng [[1][tzeng_nosa],[2][tzeng_nosa2]]
声称律师的建议无论如何都会被忽略，
这似乎引用了 NOSA 审查。
[John Cowan][cowan_nosa] 指出，许可证可能是一份精细的法律文件
但仍然不符合 OSD。
[Tzeng][tzeng_nosa2] 和 Bruce Perens [[1][perens_nosa],[2][perens_nosa2]]
重新讨论了围绕 NOSA 的一些讨论。
过了一会儿，该论点流入了更一般的讨论中
关于许可证审查流程，如上所述。
[tzeng_nosa]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020320.html
[tzeng_nosa2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020333.html
[cowan_nosa]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020328.html
[perens_nosa]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020334.html
[perens_nosa2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020321.html
[Van Lindberg][vanl_review]
讨论了许可证审查的不同方面。
一方面，存在政策选择和社区考虑因素，
但确定许可证是否在法律上健全并符合 OSD
是“强烈地受法律影响的”。
[Richard Fontana][fontana_lawyering] 对此提出异议
OSD 不是法律文件，而是
“一项针对非律师的哲学和政策声明。”
确定 OSD 合规性可能需要律师式的思维，
但“一位精通自由/开源法律政策的非律师 […]
可能更适合解释 OSD”。
律师也可能有偏见，例如当他们代表客户时。
虽然关于许可证法律健全性的意见
很有价值并且需要法律专家，
例如，在 SSPL 的案例中，政策论证最终更为重要。
[vanl_review]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020327.html
[fontana_lawyering]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020336.html
## 遗留问题 {#leftovers}
[Thorsten Glaser][glaser_motif]
从 Fedora-Legal 列表交叉发布了一个讨论
关于 Open Motif 许可证是否可以被视为开源。
Open Motif 具有不寻常的许可证
该许可证将其使用限制为“开源”操作系统。
[Bruce Perens][perens_motif] 认为这违反了 OSD #9 和 #10。
[Florian Weimer][weimer_motif]
指出 RHEL 仍然发布 Open Motif，
并且他不认为这种限制会有问题。
[glaser_motif]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020342.html
[weimer_motif]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020366.html
[perens_motif]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020367.html
GPLv3 允许附加条款
禁止虚假陈述或拒绝商标。
[Patrick Schleizer][schleizer_gpl_misrepresentation] 询问
这是否意味着 GPL 默认授予此类权利？
[John Cowan][cowan_gpl_misrepresentation]
认为未能禁止某事并不等于许可。
同样，[Bruce Perens][perens_gpl_misrepresentation]
指出缺乏肯定声明来授予这些权利。
许可证不必详细涵盖所有内容
它们嵌入在更广泛的法律环境中。
[schleizer_gpl_misrepresentation]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020377.html
[cowan_gpl_misrepresentation]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020379.html
[perens_gpl_misrepresentation]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020381.html
开源许可证的最终用户
通常不会明确接受许可证。
Patrick Schleizer [[1][schleizer_clickwrap],[2][schleizer_gpl_disclaimer]] 提问
这是否意味着任何责任限制都无效
因为最终用户从未*放弃*他们的权利？
或者作者可以单方面*免除*担保吗？
这在普通法和民法法系之间有区别吗？
[Thorsten Glaser][glaser_clickwrap]
认为免责声明是版权许可的一个条件。
[Van Lindberg][vanl_gpl_disclaimer]
指出了许可和合同之间的区别
（注意：这可能是一个以美国为中心的观点）。
[schleizer_clickwrap]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020385.html
[glaser_clickwrap]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020386.html
[schleizer_gpl_disclaimer]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020387.html
[vanl_gpl_disclaimer]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020391.html
[Chris Lamb][lamb_parallel]
链接到[Debian 错误跟踪器上的讨论][debian_parallel]
关于 Ole Tange 的 GNU Parallel 实用程序的 “citationware” 要求
该实用程序打印出要求引用该软件
或向作者支付一笔总款。
[Jonathon][jonathon_parallel] 将学术界关于引用的惯例与
该要求的措辞进行了对比。
[Bruce Perens][perens_parallel] 指出，与此同时，
引用要求已降低为非强制性请求。
[debian_parallel]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905674
[lamb_parallel]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020277.html
[jonathon_parallel]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020280.html
[perens_parallel]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020283.html
回应 [一月份的讨论][License-Discuss-2019-01]
关于 “亲密关系”，[Florian Weimer][weimer_intimacy] 补充说
对于可以提供自身源代码的类似 quine 的程序，AGPL 合规性尤其不成问题。
对于可以提供自身源代码的类似 quine 的程序，AGPL 合规性尤其不成问题。
[weimer_intimacy]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-March/020364.html