建议添加 "可见源代码" 开源状态

[colinxu2020]

站长能否再加一个"可见源代码"的开源状态呢？我最近的编辑中看到有许多模组的源代码是可见的，但其使用的协议不是开源协议（例如 All Rights Reserved），这些模组不符合当前的开源状态中 "开源" 的定义（未指定开源许可协议），也不符合闭源的定义（源代码确实可见），目前百科中对于此类模组的归类中 "开源"，"闭源"（#218） 和 "待确定"（#9530） 都有，希望能通过添加 "可见源代码" 的开源状态将这些模组统一为 "可见源代码"。

另附：维/基/百/科 中对于开源软件的定义（开源软件促进会给出的定义）：

第一条："自由再分发 许可证不应该限制其他方出售或者分发该软件，当该软件作为包含多个不同源码程序的集成软件的一部分。许可证不应该要求专利费或其他销售费用。" 第三条："衍生作业 许可证必须允许修改和衍生作业，需要像原来的许可证那样发布。"

原发布地址：Mcmod 第 3536 楼。

[3TUSK]

949 重复

[3TUSK]

顺带把我在 GH-949 里的回复复制一遍：

如果我们确定要加「可见源代码」，我们会遇到全新的问题：怎么才算「开源」？

• 开放源代码促进会（OSI）认可的许可证？
• 自由软件基金会（FSF）认可，或兼容 GPL 的许可证？
• Debian 自由软件指南中列出的许可证？
• MongoDB 用的 SSPL，或者 Redis 用的 RSAL？
  • OSI 已经明确表示 SSPL 不是开源软件许可证。
  • 但 FSF 至今仍未表态。我曾就此事去信 FSF，得到的回复是「仍在评估」。
• 如果某种有效 Creative Common 条款组合同时也满足 OSI 对「开源软件许可证」的定义，那这个算不算？
• 我花钱请律师帮忙写了份符合 OSI 对「开源软件许可证」定义的许可证，这个算不算？

以及更多特殊情况：

• 不同组件使用不同许可证：暮色森林（Twilight Forest）、应用能源（Applied Energistics）
  • 暮色森林的 jar 中存在禁止二次分发的部分
  • 应用能源的所有组成部分皆可自由分发，惟贴图及模型使用的 CC 条款中有 NC 一款禁止商用。
• 旧版是自由软件，新版不是：Sodium
• 旧版不是自由软件，新版是：BuildCraft，尽管新版 BuildCraft 遥遥无期
• 源码在自由或开源软件许可证条款下发布，但作者禁止分发编译好的 jar：暂无案例

[HanlieChina]

顺带把我在 GH-949 里的回复复制一遍：

如果我们确定要加「可见源代码」，我们会遇到全新的问题：怎么才算「开源」？

• 开放源代码促进会（OSI）认可的许可证？
• 自由软件基金会（FSF）认可，或兼容 GPL 的许可证？
• Debian 自由软件指南中列出的许可证？

• MongoDB 用的 SSPL，或者 Redis 用的 RSAL？

  • OSI 已经明确表示 SSPL 不是开源软件许可证。
  • 但 FSF 至今仍未表态。我曾就此事去信 FSF，得到的回复是「仍在评估」。
• 如果某种有效 Creative Common 条款组合同时也满足 OSI 对「开源软件许可证」的定义，那这个算不算？
• ~我花钱请律师帮忙写了份符合 OSI 对「开源软件许可证」定义的许可证，这个算不算？~

以及更多特殊情况：

• 不同组件使用不同许可证：暮色森林（Twilight Forest）、应用能源（Applied Energistics）

  • 暮色森林的 jar 中存在禁止二次分发的部分
  • 应用能源的所有组成部分皆可自由分发，惟贴图及模型使用的 CC 条款中有 NC 一款禁止商用。
• 旧版是自由软件，新版不是：Sodium
• 旧版不是自由软件，新版是：BuildCraft，尽管新版 BuildCraft 遥遥无期
• 源码在自由或开源软件许可证条款下发布，但作者禁止分发编译好的 jar：暂无案例

懂了，这就写一个符合全部特殊情况的垃圾模组（不是。

[sxjeru]

狭义上的开源（Open Source）由 OSI 全权定义，FSF 定义“自由（Free）许可证”。 如果说仅讨论“开源”，那请按照 OSI 授权的许可证来实行。 上述约定俗成的结论有许多法庭案例作为支持。

当然还存在未被明确定义的 FOSS 。

[3TUSK]

狭义上的开源（Open Source）由 OSI 全权定义

我要在鸡骨头里挑个刺。OSI 的定义可能是最广泛接受的对「开源软件（许可证）」的定义，但绝对不是「全权」定义。