Mod category `Open Source` is misleading as some mods under this category are not really open source

[ttyv1]

mcmod.cn currently have a category for mods called Open Source, with description The author has made the source code publicly available, and specified an Open Source license.

However some mods, despite having source code available somewhere (often github.com), they don't come with a true Open Source license. An example is TrainCraft, its license prohibits distribution of the mod, nor use the source code for commercial purposes, therefore didn't comply with the Open Source Definition that published by Open Source Initiative.

Note that calling non-Open-Source programs Open Source is wrong, and badly misleads people for the true meaning of word 'Open Source', which is already vulnerable to this kind of misleading.

I suggest adding another category for those mods, with label Source Available and description The author has made the source code available, but didn't provide a license or the license did not qualified as an Open Source license.

Wikipedia have an article for Source-available software.

[ttyv1]

Mod 分类中的“开源”有误导性因为其中的一些 mod 并非开源

mcmod.cn 目前对 mod 有一称作“开源”的分类，其描述为“作者已公开模组源码，并指定了开源许可协议。”

然而对于一些 mod 虽然其源码可在某些位置获得（通常是 github.com），它们并不提供一个真正的开源许可协议。其中一个例子是 TrainCraft，它附带的许可协议禁止公开分发 mod 的副本，也不允许商业使用其源码，因此并不符合开源促进会发布的开源定义。

需要注意的是将并非开源的程序称作“开源”是错误的，并且这会误导大众对“开源”一词的正确理解，这点十分糟糕因为这词本身就容易产生此类的理解错误。

我建议为这些 mod 增加一个新的分类，“看源”，描述为“作者已公开模组源码，但并未提供许可协议或许可协议不被认定为开源许可。”

维基百科有一个详细描述看源软件的条目。

[HanlieChina]

Mod分类中还有一种情况：一个模组，如果其源代码可见，但未指定协议，则是未知。 所以目前对开源的定义其实比维基百科更加严格。 当然部分早期编辑由于当时的要求可能与目前实际执行的方案存在一些偏差。

[3TUSK]

如果其源代码可见，但未指定协议，则是未知

The convention for this scenario is to assume "All Rights Reserved".

---

with label Source Available

There is one more gotcha - having source available for public viewing does NOT mean that you can do whatever you want with it. I would like to argue for naming this label Visible Source (「源码可见」、「看源软件」、……), but it still fails to convey the idea of "check the license before doing anything".

---

That being said, if the new label is a thing, there will be a new issue: what constitutes open-source software license?

• Open-Source Initiative approved license?
• FSF approved / GPL-compatible license?
• Anything listed in Debian Free Software Guidelines?
• What about Server-Side Public License (cf. MongoDB) and Redis Source Available License (cf. Redis)?
  • OSI has deemed SSPL as non-open-source.
  • A while ago, I emailed FSF people to seek clarification on "whether SSPL is Free Software license". Their reply is that SSPL is still in their evaluation queue.
• If a valid Creative Common clauses combination satisfies OSI definition for open-source, is that an open-source license?
• If I just write a license on my own, and I paid for a lawyer to ensure it matches OSI definition, does it count?

Also, allow me to introduce some tricky cases:

• Multiple license for different assets: Twilight Forest
  • Code is LGPL
  • Non-sound assets (texture, etc) are CC-BY-NC-SA 4.0
  • Sounds are All Rights Reserved
• Multiple license for different assets: Applied Energistics 2
  • API code is MIT (X11/Expat)
  • Main code is LGPLv3
  • Textures & models are CC-BY-NC-SA 3.0
  • Language files are public domain
  • Sounds are CC-BY 4.0
• License was changed: Sodium
  • Relicensed from LGPLv3 to Polyform Shield 1.0.0
  • Non-retroactive; code and binary jars prior relicense are staying under LGPLv3 terms.
• License was changed: BuildCraft
  • Relicense from Minecraft Mod Public License to Mozilla Public License v2.0
  • Non-retroactive; code and binary jars prior relicense are staying under this non-FLOSS license.
• Source code available under open-source license, but author explicitly prohibits redistribution of compiled jar.
  • Real question: can we have different license for source code and binary jar?
  • I don't have an example for this one in my hand at this moment.