2019 年 5 月 License-Discuss 摘要
五月份，License-Discuss 邮件列表讨论了
* License-Review 邮件列表和许可证委员会之间的关系
* 许可证审查流程的演变
* 已批准许可证列表的全面性
* 许可证的许可证
* 三个许可证就足够了吗？
* 电子邮件线程
相应的 License-Review 摘要已在线发布
于
并涵盖了关于加密自治许可证的广泛辩论，
以及关于 BSD 许可证变体的讨论。
## License-Review / 委员会关系 {#decision}
在 CAL 的审查中，
一个小问题是 License Zero 的审查
是否应被定性为“拒绝”。
[Luis Villa][villa:rel:history]
谈到了 License-Review 列表的历史，
该列表有时*是* OSI 委员会，
但任何决策权都完全在于 OSI 董事会。
[Richard Fontana][fontana:rel:community]
认为社区在列表中的参与度下降了，
使得 OSI 更难辩称
审查决定反映了社区共识。
[Luis Villa][villa:rel:engagement]
不确定参与度是否下降了，
但认为参与程度绝对是不健康的
– 100 多个电子邮件线程吓跑了潜在的提交者。
[Henrik Ingo][ingo:rel:jury] 将列表参与比作陪审义务。
Ingo 还指出，没有必要插话
来重复共识意见。
[Christopher Sean Morrison][morrison:rel:fatigue]
同意 Ingo 的观点，即邮件列表规定了“有效的沉默”，
但没有以沉默方式表示同意的机制。
但参与度也受到“重复话题疲劳”的影响。
[Pamela Chestek][chestek:rel:silence]
看到列表上有一些欺凌者。
有人可能保持沉默不是出于同意，
而是为了避免冲突。
[Nigel Tzeng][tzeng:rel:voting] 建议 OSI 成员进行匿名投票。
（注意：但这无助于讨论。）
[Fontana][fontana:rel:voting] 认为这将很容易被滥用。
[Tzeng][tzeng:rel:abuse] 认为当前的系统也可能被滥用，
大概指的是 NOSA 审查。
[Scott Peterson][peterson:rel:precise]
反对最大程度精确的规则，
无论是关于审查流程还是可能的 OSD 修订。
[McCoy Smith][smith:rel:elections]
将董事会选举视为一种间接投票。
[Henrik Ingo][ingo:rel:direct]
警告说，直接民主可能会扭曲投票。
OSI 董事会必须自行负责做出决定。
[villa:rel:history]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020418.html
[fontana:rel:community]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020422.html
[villa:rel:engagement]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020424.html
[ingo:rel:jury]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020427.html
[morrison:rel:fatigue]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020429.html
[chestek:rel:silence]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020430.html
[tzeng:rel:voting]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020431.html
[fontana:rel:voting]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020433.html
[peterson:rel:precise]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020435.html
[tzeng:rel:abuse]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020449.html
[smith:rel:elections]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020438.html
[ingo:rel:direct]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020451.html
## 许可证审查流程的演变 {#evolve}
[Pamela Chestek][chestek:evolve:ann]
宣布了新的 OSI 许可证审查委员会，
由 Pamela Chestek（主席）、
Elana Hashman、Chris Lamb 和 Simon Phipps 组成。
他们认识到需要改进审查流程，
以便在讨论中代表所有观点。
作为第一步，他们澄清了
* License-Review 列表收集公众对拟议许可证的反馈。
委员会在向 OSI 董事会提出批准建议时
会考虑这些回复。
如果许可证尚未准备好，主持人可以将讨论移至 License-Discuss。
* License-Discuss 用于讨论关于开源许可证的一般问题，
以及处于早期开发阶段的许可证。
建议在公开场合开发新许可证，
并定期向 License-Discuss 寻求反馈。
* 将努力加强主持工作，
以确保适当的对话和良好的讨论节奏，
并鼓励更广泛的参与。
这包括限制恶意、频繁和重复消息的规则，
包括主持人对未解答问题的跟进，
并包括执行现有的行为准则。
* 网站现在澄清了许可证审查流程，
社区共识不再是先决条件。
相反，董事会在做出决定时会考虑社区讨论。
为其决定。
[Simon Phipps][phipps:evolve:authority]
澄清 Chestek 的声明
代表了 OSI 董事会的决定。
[Bruce Perens][perens:evolve:adhom]
认为这一变化直接针对他。
“我和其他人今天已被逐出许可证委员会。”
（注意：这假设列表成员*是*委员会的观点。）
Perens 不认为消息数量本身会成为问题
– 它们对于澄清重要问题是必要的。
Perens 不明白为什么要迁就那些
（尚未）参与列表的人。
[Chestek][chestek:evolve:eject]
不同意任何人都会被驱逐的说法
– 相反，这些变化的目标是邀请比目前情况
更多样化的回应。
Chestek 指出了 Peren 的消息如何显得具有攻击性的具体例子
“这是一种不恰当的语气和参与风格。”
[Perens][perens:evolve:reject] 认为这拒绝了他的观点，而没有给予适当的关注。
[Russel McOrmond][mcormond:evolve:freeperens]
赞扬 Perens 坚持不懈地倡导软件自由，
并敦促他不要将反驳视为个人恩怨。
[Lawrence Rosen][rosen:evolve:freespeech]
赞赏新流程的清晰度，
但认为对严格的行为准则过于关注。
只需删除您不想要的电子邮件即可。
Rosen 最近得知
Perens 代表 OSI 参与了他们的开放标准活动
（[Perens][perens:evolve:picknick] 回应）。
重要的是，在讨论中明确谁代表 OSI，谁不代表。
[Rick Moen][moen:evolve:goodfaith]
表示同意，并敦促每个人都假设善意。
Moen 还区分了不同类型的邮件列表主持。
在某种意义上，OSI 列表是未经主持的。
[Perens][perens:evolve:picknick] 回应了 Rosen 关于标准参与的题外话。
Perens 还认为任何关于欺凌的指责都太过分了，
并且对列表的这些更改只是语气管控。
Perens 告诫说
“许可证提交者将以对他们最有利的方式讲述故事”，
尤其是当他们是律师时。
当这种情况发生时，能够指出这一点很重要。
[John Cowan][cowan:evolve:lawyers]
认为 Peren 关于律师的观点与事实相反。
修辞和彻底的虚假陈述之间存在差异。
[Chestek][chestek:evolve:allvoices]
同意 Rosen 的观点，即应该听取所有意见，
但这些意见不能以您想要的任何方式表达。
“接受现实”的态度疏远了有价值的声音。
与此相反，
“我从未听说过有哪个论坛
人们会因为太礼貌而不参与。”
[Rosen][rosen:evolve:bluster]
认为一些律师的虚张声势是正常的，
并且通常不需要礼貌
“那很无聊。我们都是成年人。”
[James][james:evolve:chilling]
认为主持应该仅作为最后手段进行，并且尽可能透明，
因为它可能会产生寒蝉效应。
[John Cowan][cowan:evolve:fido]
回忆起 Fidonet 上的主持活动
主持并没有想象的那么大的问题，
并且禁令是当之无愧的。
[Fontana][fontana:evolve:clarity]
赞赏 Chestek 的更改带来的清晰度提高。
License-Review 列表的（纯粹咨询）角色
是对流程描述方式的重大改变，
但它更准确地反映了实际流程。
[McOrmond][mcormond:evolve:passion]
认为热情和粗鲁之间的界限太主观，无法发挥作用。
严格关注行为准则会排除充满热情的人。
在社区中，一定程度的共同观点是必要的。
[Rick Moen][moen:evolve:commonground]
反驳说：完全有可能找到一些共同点
并与观点冲突的人合作。
OSI 列表“是支持 OSI 现实世界目标的人
的自然场所。”
McOrmond [[1][mcormond:evolve:threats],[2][mcormond:evolve:labels]]
（Affero 等是一种威胁），
（Affero 等是一种威胁），
[Perens][perens:evolve:affero] （Affero 很好），
[Simon Phipps][phipps:evolve:serve] （规则服务于运动），
和 [Moen][moen:evolve:shared] （软件自由是一种共同的价值观）之间
[Martijn Verburg][verburg:evolve:robust]
加入了评估，认为 OSI 的列表比其他列表更“稳健”。
“尝试使两个列表更欢迎各种声音 […] 不会有任何坏处。”
[Moen][moen:evolve:conspiracy]
提出了一个阴谋论，
即在 OSI 未批准某些许可证后，才出现这些关于不文明行为的说法。
是否是邪恶势力试图压制有效的批评者？
那些更多样化的观点是否不会更同情那些被拒绝的许可证？
（注意：无法判断这在多大程度上是开玩笑。）
[Chestek][chestek:evolve:conspiracy] 回应说
“我理解此列表上的人可能对
我对软件自由和/或开源软件的承诺持怀疑态度”。
但委员会和董事会不仅仅是一个人。
“我确实希望仅仅是对于软件自由在边缘的意义
持不同意见
并不意味着一个人已经成为反自由力量的俘虏。”
OSI 正在努力解决重要问题，
例如列表的功能、审查流程的质量，
以及开源的确切范围。
[Henrik Ingo][ingo:evolve:essay]
对各种观点做出了详细回应。
* 审查流程取决于少数
能够实际剖析许可证并阅读所有电子邮件的人
* 除了重新讨论过去很久的审查之外，列表似乎相对有纪律
除了重新讨论过去很久的审查之外，列表似乎相对有纪律
* SSPL 审查见证了新参与者的涌入。
在出现问题的地方，列表会自我调节
* 新董事会指出现有的行为准则不应是新闻
* 更令人担忧的是“董事会认为
存在需要解决的实际问题”
* 列表上的一些“担忧”
只是律师式的争吵或游说以改变 OSI 政策
* 在许多提到的案例中，
未批准的原因非常明确
并且不必不断重新审理
* OSI 审查不是法院，没有案件败诉 – 修订后的许可证可以获得批准
* 审查不仅仅是检查 OSD 是否适用，
还关于新许可证如何服务于社区
* 许可证不造成损害是不够的
* 许可证审查很像“代码审查”，
从某种意义上说，存在一种共同所有权
* 虽然 FSF 的四大自由具有重要的支持材料和讨论，
但 OSD 似乎如此一致和明显，以至于没有可比的评论体系存在
* 也许这是一个问题，更多的评论会有帮助？
* 该流程似乎比以往任何时候都运行得更好，那么为什么要修复它？
[Richard Fontana][fontana:evolve:predictability]
认为审查流程被认为不可预测，因为
很少有许可证进入董事会投票。
那些进入董事会投票的许可证往往是显而易见的案例，不需要理由。
大多数有问题的许可证都被提交者
因社区反馈而撤回。
Fontana 还认为 OSI 在处理错误方面存在问题，
例如根据当前理解，已批准的许可证不是开源的。
可能有必要制定取消列表程序。
[Henrik Ingo][ingo:evolve:delist]
认为彻底取消列表会有问题。
作为第一步，可以要求许可证管理员自愿撤回许可证。
否则，可以将它们移至“不推荐”类别，
这承认它们是出于善意使用的。
[Nigel Tzeng][tzeng:evolve:delist]
认为取消许可证列表会有问题，
因为它们可能会针对特殊用途的许可证。
Tzeng 特别关注
政府开源 (GOSS) 许可证的（缺乏）接受度。
（注意：由于数量庞大且缺乏新意，
本摘要将不涵盖随后关于 GOSS 的讨论。）
关于可能的取消列表，
[Perens][perens:evolve:delist]
声明 OSI 的政策不是推广某些许可证而不是其他许可证，
除了将一些许可证标记为“遗留”。
即使在实践中，三个许可证就足够了
（请参阅单独的部分）。
[Tzeng][tzeng:evolve:delist]
不认为他认为列表被 Perens 和 Fontana 支配的看法
应被视为人身攻击。
[Perens][perens:evolve:delist]
回应说，拥有自信的个性和相关的专业知识应该没问题
Rosen [[1][rosen:evolve:trained],[2][rosen:evolve:sorrynotsorry]] 最强烈地不同意，
[Perens][perens:evolve:adhominem] 想知道*那*个回应怎么可能不是人身攻击。
[Henrik Ingo][ingo:evolve:merit] 表达了精英管理的观点，
即 Peren 和 Fontana 的影响力
主要是因为他们花费大量时间审查许可证。
[Luis Villa][villa:evolve:freedom]
认为 Chestek 的澄清非常棒，
但担心“软件自由”的含义
在 OSI 的背景下仍然不清楚。
Villa 指出，虽然这些改进的目标是*决策*流程，
但*记录保存*流程也可能需要改进。
列表存档是不合适的媒介，
相反，需要权威的摘要。
Villa 提供了一些关于类似 RFC 流程的链接。
这似乎与 [2019 年 3 月关于 PEP 风格的流程是否有帮助的讨论][LD04-pep] 类似。
[LD04-pep]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020528.html
[chestek:evolve:ann]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020483.html
[perens:evolve:adhom]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020484.html
[chestek:evolve:eject]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020485.html
[perens:evolve:reject]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020495.html
[mcormond:evolve:freeperens]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020487.html
[rosen:evolve:freespeech]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020488.html
[moen:evolve:goodfaith]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020489.html
[chestek:evolve:allvoices]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020491.html
[james:evolve:chilling]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020492.html
[cowan:evolve:fido]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020497.html
[rosen:evolve:bluster]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020494.html
[mcormond:evolve:passion]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020496.html
[moen:evolve:commonground]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020500.html
[mcormond:evolve:threats]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020503.html
[perens:evolve:affero]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020504.html
[phipps:evolve:serve]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020505.html
[moen:evolve:shared]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020507.html
[mcormond:evolve:labels]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020509.html
[verburg:evolve:robust]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020498.html
[phipps:evolve:authority]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020501.html
[moen:evolve:conspiracy]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020506.html
[chestek:evolve:conspiracy]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020508.html
[fontana:evolve:predictability]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020510.html
[ingo:evolve:delist]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020512.html
[ingo:evolve:essay]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020511.html
[perens:evolve:picknick]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020493.html
[cowan:evolve:lawyers]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020499.html
[tzeng:evolve:delist]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020513.html
[perens:evolve:delist]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020514.html
[rosen:evolve:trained]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020515.html
[ingo:evolve:merit]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020517.html
[fontana:evolve:clarity]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020486.html
[rosen:evolve:sorrynotsorry]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020523.html
[perens:evolve:adhominem]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020525.html
[villa:evolve:freedom]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020581.html
## 已批准许可证列表的全面性 {#comprehensiveness}
[Luis Villa][villa:comp:useful]
认为 OSI 批准的许可证列表
不是可用开源许可证的完整列表。
因此，在合同或许可证条款中应避免使用该列表。
但如果不是这样，该列表的目的是什么？
创建一个较小的有用许可证列表是否有意义？
Villa 指出他的 Blue Oak 项目是一个有用的许可许可证列表。
[Richard Fontana][fontana:comp:process]
认为审批流程比最终列表更重要。
在某种程度上，许可证只是澄清“开源”概念的媒介。
Fontana 还警告不要依赖自封的权威机构，
并指出 OSI 的 License-Review 比其他替代方案更透明。
Ben Hilburn [[1][hilburn:comp:define],[2][hilburn:comp:define2]]
认为这个讨论很重要，
但发现 Fontana 的立场令人困惑。
许可证是否“开源”由其 OSI 批准定义。
否则，OSI 如何成为该术语的仲裁者？
[Nicholas Weinstock][weinstock:comp:osd]
坚持认为 OSD 而不是审查流程是开源的定义。
由此可见，OSD 不仅仅是在审查期间要考虑的一系列因素。
由此可见，许可证可以是开源的，而无需获得 OSI 批准。
过于关注当前批准的许可证列表
也会导致已从列表中删除的遗留许可证
处于奇怪的状态。
[Van Lindberg][vanl:comp:certification]
将 OSI 批准比作产品认证。
重要的是是否已获得批准，
而不是某物是否有可能获得批准。
最终，决定许可证是否满足 OSD 必须由 OSI 决定。
相比之下，“自由软件”一词可以更自由地使用。
[Nicholas Weinstock][weinstock:comp:certification]
不同意 Lindberg 的比较，
OSI 批准不是完全中立的审查，
而是考虑了更广泛的担忧。
[Lindberg][vanl:comp:define]
认为 Linux 发行版中只有经 OSI 批准的部分才应称为“开源”。
需要对该术语进行*某种*定义，
显然，由 OSI 决定其含义。
McCoy Smith [[1][smith:comp:deprecation],[2][smith:comp:deprecation2]]
链接到 OSI 的弃用/停用类别（
“不应将其用于许可任何新代码。”
Lindberg [[1][vanl:comp:deprecation],[2][vanl:comp:deprecation2]]
声称尚不清楚此类许可证是否仍然是开源的。
Lindberg 建议了一个截止日期。
[John Cowan][cowan:comp:judge]
认为“法律就是法官所说的”，
在此：开源就是 OSI 所说的。
然后，完全可以参考 OSI 批准的许可证列表。
只是这种观点没有为 OSI 的审查流程提供指导。
这种方法效果很好，
只要 OSI 的决定没有太偏离社区期望。
[Stephen Paul Weber][weber:comp:aggregator]
偶尔会在竞赛或聚合器中看到这样的“任何 OSI 批准的许可证”条款。
在竞赛或聚合器中看到这样的“任何 OSI 批准的许可证”条款。
有时，允许任何 OSI 或 FSF 批准的许可证，以避免“站队”。
[Fontana][fontana:comp:choosing] 认为这种方法很聪明，
OSI 和 FSF 都是受人尊敬的中立权威机构，
不像 Blue Oak 或 Fedora 等。
作为一个历史观点，
Fontana 记得 Fedora 没有依赖 OSI 许可证列表，
因为当时 OSI 被视为受商业影响太大。
如今，对 OSI 的批评似乎恰恰相反。
[Henrik Ingo][ingo:comp:kingmaker]
认为 OSI 现在比那时重要得多，
因为 Linux 发行版不再具有造王者
软件是否为 Debian 或 Fedora 打包
对于开源项目而言不再至关重要。
[Ingo][ingo:comp:kingmaker]
不认为 OSI 许可证列表甚至应该尝试做到全面。
大多数开源软件都由少数许可证覆盖，
但存在大量据称符合要求的许可证。
这些许可证可以在提交时获得批准，
但没有必要积极寻找它们。
[Fontana][fontana:comp:masslegacy] 确实看到大规模遗留批准的一些价值，
Linux 软件包中未经 OSI 批准的许可证很常见。
批准将消除这些许可证不是开源的说法。
[Ingo][ingo:comp:distromotivation]
认为发行版与 OSI 的动机不同。
例如，OSI 没有批准 libpng 许可证
– 但 Linux 发行版将继续发布它。
### CC0 和专利 {#cc0}
[Weinstock][weinstock:comp:certification]
曾提到未能批准 CC0，即使它符合 OSD。
[Fontana][fontana:comp:cc0] 在这里插话，
因为 CC0 明确不许可专利，所以存在严重担忧。
Nigel Tzeng [[1][tzeng:comp:cc0],[2][tzeng:comp:cc0-relevance]]
回顾了 2012 年 CC0 审查的历史，声称它不像 Fontana 声称的那么简单。
CC0 现在是一种广泛使用的开源许可证，尽管未获得 OSI 批准。
相比之下，[Henrik Ingo][ingo:comp:cc0] 和 [Rick Moen][moen:comp:cc0] 回忆说，
Fontana 的担忧很快成为共识。
[Fontana][fontana:comp:cc0-recollections]
更深入地探讨了他当时的动机。
CC0 审查有助于建立对
开源中专利问题的理解。
[Christopher Sean Morrison][morrison:comp:patents]
认为问题在于 OSI 没有关于专利作用的明确政策。
如果涉及专利，则排除专利的许可证可以说违反了 OSD 7。
但是，如果没有专利，这样的许可证仍然符合 OSD。
（注意：但也要比较上面引用的 [Fontana 的][fontana:comp:cc0-recollections] 消息。）
关于专利的作用，
Rick Moen [[1][moen:comp:cc0],[2][moen:comp:bsd],[3][moen:comp:bsd2]]
认为拥有开源许可证
是软件实际成为开源的必要但不充分的先决条件。
对于软件实际成为开源的必要但不充分的先决条件。
作为一个假设，Moen 考虑了一个以某种方式限制 BSD 许可软件的司法管辖区。
John Cowan [[1][cowan:comp:allpatents],[2][cowan:comp:otherpatents]]
不同意 Moen 假设的前提。
开源软件面临的最大专利威胁
不是来自作者，而是来自第三方。
不可能最终确定某些软件是否安全地开源。
[Rick Moen][moen:comp:conclusively] 认为这种立场不可行。
开源软件应被称为开源，
直到软件受到具体威胁的那一天。
[Nicholas Weinstock][weinstock:comp:separate]
同意 Cowan 的分析。
但最好将许可证的开源性
与许可的程序分开讨论。
OSD 没有始终如一地做出这样的区分。
[Van Lindberg][vanl:comp:relationship]
认为开源仅描述许可人与接受人之间的关系。
第三方不在范围内，许可证不提供关于此的保证。
[Moen][moen:comp:anyway] 同意，
但这并没有改变软件如果受到第三方索赔
就无法自由分发的问题。
[Lawrence Rosen][rosen:comp:defensive]
指出某些许可证具有防御性终止条款，
这可能是对第三方专利威胁的充分防御。
（注意：Apache 2 和 GPLv3 具有此类条款。）
[Bruce Perens][perens:comp:entity] 担心
如果公司将专利转移到单独的实体，
此类条款可能无效。
GPLv2 包括“自由或死亡”条款，
该条款可以禁止在某些司法管辖区发行。
[Fontana][fontana:comp:gplcease] 认为
如果调用此条款，软件将不再是开源的。
关于 BSD 的题外话，[Lawrence Rosen][rosen:comp:bsd] 建议
OSI 有责任警告公众
由于 BSD 缺乏专利许可证，因此它不是一个有用的许可证
– “请改用专业许可证！”
[Morrison][morrison:comp:fearmongering]
认为这是毫无根据的恐吓。这种风险是否真的经过测试？
[McCoy Smith][smith:comp:tested] 不记得有判例法，
但链接到学术文献。
[villa:comp:useful]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020423.html
[fontana:comp:process]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020425.html
[hilburn:comp:define]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020434.html
[hilburn:comp:define2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020436.html
[weinstock:comp:osd]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020442.html
[vanl:comp:certification]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020443.html
[smith:comp:deprecation]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020444.html
[smith:comp:deprecation2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020446.html
[vanl:comp:deprecation]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020445.html
[vanl:comp:deprecation2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020447.html
[cowan:comp:judge]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020450.html
[weinstock:comp:certification]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020452.html
[fontana:comp:cc0]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020453.html
[tzeng:comp:cc0]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020456.html
[morrison:comp:patents]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020457.html
[fontana:comp:cc0-recollections]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020458.html
[tzeng:comp:dominance]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020461.html
[perens:comp:participation]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020463.html
[ingo:comp:cc0]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020459.html
[tzeng:comp:cc0-relevance]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020460.html
[moen:comp:cc0]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020462.html
[rosen:comp:bsd]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020465.html
[moen:comp:bsd]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020466.html
[morrison:comp:fearmongering]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020467.html
[smith:comp:tested]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020471.html
[cowan:comp:allpatents]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020464.html
[moen:comp:bsd2]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020468.html
[cowan:comp:otherpatents]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020469.html
[moen:comp:conclusively]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020474.html
[vanl:comp:relationship]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020477.html
[fontana:comp:gplcease]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020480.html
[moen:comp:anyway]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020481.html
[weinstock:comp:separate]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020472.html
[rosen:comp:defensive]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020473.html
[perens:comp:entity]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020475.html
[weber:comp:aggregator]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020426.html
[fontana:comp:choosing]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020428.html
[ingo:comp:kingmaker]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020455.html
[fontana:comp:masslegacy]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020470.html
[ingo:comp:distromotivation]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020482.html
[vanl:comp:define]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020437.html
## 许可证许可 {#license-licenses}
[帕特里克·马森][masson:ll:ann]
希望更新 OSI 许可列表
以包含关于许可的元数据，
例如许可文本的许可。
[托尔斯滕·格拉泽][glaser:ll:mirbsd]
为他的 MirBSD 许可提供了元数据，
但指出其文本的许可尚未被调整。
[约翰·考恩][cowan:ll:gpl]
链接到/提取相关的许可信息
来自 GPL、EPL、Apache 2、MPL 2、CDDL
并指出 MIT/BSD 在实践中可以自由修改。
[劳伦斯·罗森][rosen:ll:osl] 从 OSL 中提取了相关段落。
[理查德·丰塔纳][fontana:ll:cautions]
警告说，许可提交者和版权所有者可能是不同的，
并且指出版权所有者并非总是有用。
例如，MIT 许可没有版权所有者，没有许可管理员，
甚至不隶属于 MIT。
([麦考伊·史密斯][smith:ll:mit] 链接到一些 [MIT 考古学])。
许可证是否通常受版权保护也值得怀疑。
([佩伦斯][perens:ll:copyrightability] 同意)。
相反，[帕梅拉·切斯泰克][chestek:ll:copyrightability]
为法律文件的可版权性提供了先例。
“对于我们这些编写它们的人来说，它们和代码一样具有创造性。”
[masson:ll:ann]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020562.html
[glaser:ll:mirbsd]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020563.html
[cowan:ll:gpl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020564.html
[rosen:ll:osl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020565.html
[fontana:ll:cautions]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020569.html
[MIT archeology]: https://opensourcecom.cn/article/19/4/history-mit-license
[smith:ll:mit]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020573.html
[perens:ll:copyrightability]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020576.html
[chestek:ll:copyrightability]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020579.html
## 三种许可 {#three}
实际上需要多少种许可？
[布鲁斯·佩伦斯][perens:evolve:delist]
布鲁斯·佩伦斯 [[1][perens:evolve:delist],[2][perens:three:list]]
建议任何人三种许可应该足够了
AGPLv3、LGPLv3 和 Apache 2。
它们是相互兼容的，经过 OSI 和 FSF 批准，
具有明确的专利条款，
并涵盖从宽松到网络 copyleft 的广泛许可目标。
为什么不引导人们使用这套“战略上连贯”的组合呢？
[约翰·考恩][cowan:three:whynot] 回答说
因为那看起来像是 ASF/FSF 的偏袒。
[布莱恩·贝伦多夫][behlendorf:three:legitimacy]
同意处理几十种细微不同的许可证令人厌倦。
但 OSI 的合法性源于其原则。
偏袒某些许可证（而忽略其他许可证）会使这种合法性受到质疑。
但教育潜在的许可方了解许可证的特性是可以的，
并鼓励他们坚持使用更常见的组合。
罗森在其他地方提到 OSL
促使 [约翰·考恩][cowan:three:osl] 宣布他不喜欢该许可证，
它建立了一个独立的、不兼容的 copyleft 生态系统或公共领域，
与已经存在的 GPLv2 和 GPLv3 生态系统不同。
[罗森][rosen:three:commons] 不同意。
Copyleft 许可证在聚合或集体作品方面通常是兼容的，
而在联合或衍生作品方面则不兼容。
但这不是问题，因为在实践中联合衍生作品很少见。
GPL/AGPL 组是特例，
因为 FSF 将它们解释为适用于静态链接和其他交互。
这是 FSF 解释的问题，而不是版权法的问题。
[托尔斯滕·格拉泽][glaser:three:agenda] 指责罗森在这里推行议程，
并且 GPLv2/GPLv3 生态系统在实践中比
EPL/MPL/OSL 生态系统重要得多。
[cowan:three:osl]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020567.html
[rosen:three:commons]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020574.html
[glaser:three:agenda]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020575.html
[perens:three:list]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004211.html
[cowan:three:whynot]: http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-May/004212.html
[behlendorf:three:legitimacy]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020526.html
## 主题性和电子邮件线程 {#topicality}
[凯文·弗莱明][fleming:topicality:frustration]
对讨论线程经常被离题讨论所干扰感到沮丧。
此类讨论应拆分到单独的主题中，
以便其他人不必在离题讨论中跋涉
才能找到相关的部分。
Discourse 允许事后将消息移动到新主题。
[约翰·考恩][cowan:topicality:threading]
认为线程邮件阅读器有帮助，
但在任何媒介中，一定程度的主题混合是不可避免的。
[里克·莫恩][moen:topicality:threading]
赞同线程很容易的观点。
“以上是互联网 101 [...] 当用户懒得操作时，不要责怪工具”。
关于 Discourse，它不显示主题内的任何线程。
[路易斯·维拉][villa:topicality:email]
认为这些 OSI 邮件列表是一个过度依赖电子邮件的群体。
即使在这里，线程在实践中也不起作用——很难说是互联网 101 的情况。
这是功能失调的。
必须掌握高级电子邮件技术似乎是不必要的入门障碍。
值得庆幸的是，其他软件不会责怪用户
– Discourse 试图“在用户实际阅读和写作的地方接触用户”。
[莫恩][moen:topicality:notme] 回应道。
[fleming:topicality:frustration]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020568.html
[cowan:topicality:threading]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020572.html
[moen:topicality:threading]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020570.html
[villa:topicality:email]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020577.html
[moen:topicality:notme]: http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2019-May/020578.html
## 其他讨论 {#other}
[奈杰尔·曾][tzeng:comp:dominance]
认为 License-Review 列表在早期（2012 年）更加多样化，
但现在由理查德·丰塔纳和布鲁斯·佩伦斯主导。
即使每个人都是真诚的，但这也会损害列表的参与度。
[布鲁斯·佩伦斯][perens:comp:participation]
指出他已经多年没有参与该列表，
自 2018 年中期以来才再次参与。
2012 年的情况真的那么不同吗？
在档案中，佩伦斯发现的大多数发帖者与今天相同。
## 招聘！ {#help}
我们目前每月 License-Discuss 和 License-Review 报告的编辑，
卢卡斯·阿特金森，
将无法在六月和七月继续担任编辑，
并且在今年剩余时间内的可用性可能有限。
如果您想加入 OSI 成为列表编辑，或者认识可能加入的人，
请联系 [OSI 总经理帕特里克·马森](mailto:[email protected])。
列表编辑以自由职业的方式工作
以提供 License-Review 和 License-Discuss 邮件列表的月度摘要。