2020 年 2 月 License-Discuss 摘要

2020 年 2 月，License-Discuss 邮件列表讨论了以下内容：

• OSD 和强制用户报告
• 许可证除名
• MIT-Clone 以及对版权声明的担忧
• GDPR/CCPA 和加密自主许可证（Beta 4）
• CERN 开放硬件许可证 2.0
• 道德开源许可 – Persona non Grata 序言
• 公平性与 OSI 的使命目标
• 道德开源许可 – 为正义而进行双重许可
• 劝阻政府创建定制许可证
• 作者与作品之间的心理关系

OSD 和强制用户报告

问题：如果许可证要求向作者或另一方提供有关软件使用情况的信息，该许可证是否符合 OSD。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021221.html

答案是不符合，并参考了“荒岛测试”，即荒岛上的人们是否可以在彼此之间分发该软件。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021228.html

许可证除名

担忧：除名可能不公平，并给 OSI 带来不良观感。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021222.html

建议：设定缺乏使用的阈值和弃用期。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021223.html

声明：缺乏使用的许可证意味着即使放任不管也不会有太大影响。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021224.html

担忧：许可证主体如何影响 OSD 的解释。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021226.html

提醒：之前有人建议设立“荣誉退休”许可证列表，以避免失效，并明确指出这些许可证不建议积极使用。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021227.html

MIT-Clone 以及对版权声明的担忧

问题：版权声明指的是初始文件的作者，而不是贡献者。建议将“版权声明”替换为“署名声明”，将“copyright me”替换为“created by me”。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021230.html

建议：修改为添加其他版权所有者，因为通常会在原始声明下方添加另一行。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021231.html

避免使用“copyright”一词实际上没有任何效果。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021233.html

GDPR/CCPA 和加密自主许可证（Beta 4）

问题：如果仅依靠合同法来限制数据的使用或分发，那么控制受版权保护或专利保护的软件所使用的数据的宪法或法定权力是什么。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021234.html

参考：美国宪法对州际贸易的监管属于国会而非各州，因为其中存在复杂性。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021235.html

CERN 开放硬件许可证 2.0

请求反馈：是否应将一整套许可证提交 OSI 批准，因为硬件和软件趋于融合，并且许多硬件都具有固件等软件元素。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021236.html

道德开源许可 – Persona non Grata 序言

提议：关于许可和道德 FOSS 社区政策如何互动，以基于道德规范劝阻和羞辱某些潜在用户，社区可以就其价值观和不欢迎的对象发表声明。此序言将作为许可证的一部分在重新分发中保留。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021237.html

声明：这不属于许可证的范畴，而应属于行为准则。将其添加到许可证中会使其失去作为自由软件许可证的地位，因为它使其成为专有许可证。参考 OSD 5。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021238.html

澄清：该提议没有设置任何限制，仅保留许可方的意见，但人们担心序言即使失去相关性也会永存。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021240.html

担忧：由于潜在的诽谤和中伤问题，这可能仍然违反 OSD 5，从而阻止开发人员使用带有可诉声明的代码，他们可能会被认为与该声明有关联。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021268.html

问题：由谁来定义谁是被劝阻和羞辱的对象。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021239.html

问题：是否需要为最终用户做出免责声明。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021241.html

回答：许可方定义谁是被劝阻和羞辱的对象。声明：最终用户可能不会在用户界面中看到此类序言，并建议要求显示它。担忧：添加名字可能比删除旧名字更容易，因为任何人都可以添加名字，但删除名字需要共识，并且可能需要启用重新许可权转让，以防止知识产权集中化。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021247.html

建议：添加代理条款，以便委托更新序言的能力，例如委托给非营利性机构。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021266.html

声明：大多数下游被许可人不能被期望更新序言副本，并且上游和“侧流”副本更新其序言也存在困难。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021267.html

担忧：序言造成的歧视，这违反了 OSD 5 和 OSD 6，无论授予何种权限。还提到了其他问题：如果序言是可更改的，则其可移除性问题、由于多种变体而引起的扩散问题以及可能产生负面观感的序言。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021242.html

声明：对不同的人进行区别对待的情况已经存在，许可证可以设置为自由复制，但除了作者之外，任何人都不能更改，并且模板将是一种实用的方法。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021243.html

澄清：传播要求序言不能被删除。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021250.html

观点：序言中声明的信念不会使许可证不合规，因为每个要求声明的许可证，无论某人自己的观点如何，都已经构成了强制言论。请求提供有关被认为违反 OSD 的充分法律风险的信息。关于模板的进一步声明：OSI 将批准模板，而不是其他任何内容，并且应制定版本控制流程。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021284.html

声明：OSI 不应参与社会正义，其责任在于保护狭隘而特定的自由。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021312.html

观点：将序言与开源许可证中的软件专利声明进行比较是不相关的，因为序言针对的是超出软件许可权利范围的行为。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021324.html

回应：序言不会使软件成为专有软件，因为没有对独占所有权主张权利。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021323.html

问题：虽然在序言中可以容忍某些关于 OSD 5 和 OSD 6 的政策声明，但有些可能无法容忍，并且违背了它们的精神。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021300.html

声明：只有为了实现对开源合作的捍卫或倡导，政治语言或倡导才应被认为是可接受的。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021313.html

问题：序言中语言选择的效果导致某个群体避免使用该软件，这与直接禁止这些群体使用该软件本质上是否相同。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021301.html

参考：与 Badgeware 许可证的相似之处，邮件列表指出，署名要求阻碍了衍生作品权利的行使。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021252.html

声明：如果新条款需要具有法律约束力，则缺乏法律可执行性。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021399.html

问题：针对非法活动的歧视是否在法庭上进行过测试，例如，如果一个开源库是增强非法活动的关键贡献者。请求澄清 OSD 5 中所述的“流程”。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021403.html

回答：法律责任在于被许可人，而不是许可人，并且许可证不能包含基于许可人管辖权禁止使用的条款。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021404.html

 回答：犯罪与 OSD 6 无关，因为它与执法有关，并且 OSD 5 不阻止政策的实施，例如传入的拉取请求。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021411.html

公平性与 OSI 的使命目标

建议：如果发现 OSI 方面存在错误，则应撤销许可证，这样做对已采用该许可证的人来说并不不公平，因为这样做是为了最大限度地减少未来的损害。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021272.html

同意：如果许可证不符合 OSD 要求，则应取消认证，但指出，诸如最大限度地减少许可证扩散和冗余之类的目标不太明确。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021274.html

请求澄清：该提议是完全撤销还是仅弃用，并建议采用弃用，因为它不会对其用户造成直接的严重后果，同时仍然劝阻未来的使用。进一步的问题：未来的许可证提交将如何考虑撤销或弃用另一个类似许可证的先例。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021277.html

澄清：许可证管理员的弃用请求已被接受，原因要么是它不再适用，要么是被取代，这对遗留应用程序没有损害。建议：创建一个由非许可证管理员发起弃用的流程。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021278.html

问题：是否有必要审查当前许可证，并建议审查过程应包括评估可修复性、提供明确的解释、多渠道公告、项目不得使用该许可证的等待期以及最终转移到历史档案。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021296.html

声明：项目不能被拒绝，因为它们一开始就没有被接受。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021297.html

澄清：弃用和取消认证之间的区别，同时强调后者需要更高的要求。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021310.html

建议：还应积极努力认证许可证，即使没有主动提交。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021299.html

建议：为新许可证添加一个标签，说明“不建议通用”。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021306.html

声明：将弃用作为第一步的做法有先例，即英特尔在 2005 年请求删除其一项开源许可证。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021327.html

建议：将弃用作为第一步，并理解可能会根据进一步的数据取消认证。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021287.html

论点：OSI 无权断言某些东西不是开源的，因为“开源”一词早在 OSI 和 OSD 存在之前就已存在。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021279.html

澄清：OSD 的修订过去已完成，例如添加了 OSD #10，并且 OSI 不受始终像以前的案例那样裁决当前案例的约束，可以进行更改。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021281.html

澄清：“开源”一词在 OSI 成立之前并未用于描述许可证。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021289.html

道德开源许可 – 为正义而进行双重许可

想法：关于软件的著作权许可证，社区将为该许可证创建一个特殊例外，向除特定实体列表之外的所有人提供更大的许可。问题：与 FSD 和 OSD 的兼容性如何，特殊许可是否可以在任何条件下撤销，是否可以在其他维度上扩展并仍然是 FOSS，以及它对 Copyleft 概念的影响。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021285.html

问题：为什么不直接使用豁免特定组织的单个许可证，而需要将其置于开源的保护伞之下。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021293.html

回答：这将是一个可执行的许可证，但它不是 FOSS，并且需要一组维护 OSD 和 FSD 的选项，允许包含其他问题。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021304.html

反驳：这不是必要的，反而会适得其反。澄清：OSD 和 FSD 的建立是为了解决与软件相关的问题。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021315.html

声明：道德许可证提案与 OSD 中的非歧视价值观从根本上是不可调和的。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021316.html

质疑：除非它允许或要求行使根据相同许可证提供软件副本的权利和可能的义务，否则它是不可执行的。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021318.html

劝阻政府创建定制许可证

请求：关于劝阻政府和类似机构创建定制许可证的资源。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021349.html

推荐：Iain Mitchell 在《自由和开源软件》一书中的章节。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021351.html

声明：所有主要的开源许可证都依赖版权进行保护，它们都没有可分割性条款来解决如果许可证中的一个或多个条款无法执行时会发生什么情况，并且美国政府（USG）创作的作品在美国不附加版权。担忧：如果使用标准许可证，则不清楚许可证会被完全撤销还是仅部分撤销，以及当某些条款不适用时，如果使用标准许可证是否会使政府面临风险。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021368.html

示例：关于公共领域的音乐数字版本，其中有关许可证的信息位于页脚，许可证条款位于元数据中。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021376.html

问题：关于确定提起诉讼的可行性以及由此产生的诉讼费用。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021382.html

建议：美国政府律师应参与讨论，以便提供有关联邦索赔法院的运作、对私人实体针对美国政府的索赔的限制以及许可证如何提出担忧的见解。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021385.html

澄清：问题还在于保护下游用户，他们可能会因简单地使用美国政府分发的材料而被起诉。回应：美国政府律师可能担心所提供的信息被解释为法律建议。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021388.html

解决方案：提供通知，说明未提供法律建议，以及他们仅代表其客户，不代表阅读该消息的任何人，并且人们应咨询自己的律师等。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021392.html

更正：Mozilla 2.0 和 Eclipse 2.0 都在第 9 节和第 7 节中分别包含可分割性条款。问题：由于开源许可证基于版权许可，如果版权条款被撤销，那么剩下的东西就不多了。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021378.html

澄清：担忧在于美国政府需要解决自身和下游用户的专利、责任和保证问题，并且在没有可分割性条款的情况下，尚不清楚非版权条款是否能在法庭上幸存下来。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021381.html

建议：编写许可证的人员应在 license-review 上解释许可证，而不是代理人。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021387.html

声明：美国政府非常庞大，专利条款的编写方式必须确保其一个部门不会无意中放弃由另一个部门创建并已许可给另一方的专利。建议：存在类似于 CC0 的许可证，其中包含来自 ECL V2 的明确专利授权，并对作者所属的机构进行一些扩展。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021362.html

作者与作品之间的心理关系

请求：关于某人对其开发的代码的依恋感，以至于他们决定其他人在其解决方案中使用该代码的条款。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021369.html

个人解读：创建的代码不被认为是他们自己的，代码属于所有人，一旦开源就不应“拥有”。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021374.html

反向解读：在精心制作的作品中存在自豪感，同时认识到他们是“站在巨人的肩膀上”，因此根据 Copyfree 条款发布。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021377.html

澄清：在无所有者的视角中，自豪感和认可感不会被剥夺。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021379.html

声明：一个人的代码副本仍然是他们自己的，但是该副本可能相同也可能不同，并且如果修改广泛但并不压倒性，则有可能将其视为“我们的代码”。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021375.html

评论：随着人们对代码会发生什么变得不那么害怕，控制的欲望就会消失，占有欲思维也会停止。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021395.html

声明：版权法侧重于创造性表达，这将是想法的实现，但它不保护纯粹功能性的事物。问题：根据贡献的重要性确定贡献中的创造性表达。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021380.html

类比：与绘画类似，一个人可以画自己的作品，并拥有自由和控制权以及风险，并将其与委托作品进行比较，在委托作品中，画家不承担风险，但艺术家保持个人联系，而委托人保留所有权。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021391.html

澄清：这就是为什么存在项目，其中所有权归项目所有，而不是个人作者，尽管他们保留共同所有者身份。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021400.html

观点：虽然享受获得荣誉，但对于工作成果没有专有感，因为作品建立得越多，其价值就越高。
https://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/2020-February/021405.html