Clarify "minimum functionality" policy (2.2) for acceptance

[Warr1024]

We've seen a few recent projects on CDB where an author has effectively committed to a major project (e.g. creating a completely original game), but then submitted what amounts to a day or two worth of basic startup work (in contrast, game efforts that have proven later to be "serious" usually enter public beta after weeks to months of work) and then leave, or otherwise only weakly commit to any further work.

We have an existing Inclusion Policy section 2.2 that suggests a package should at least have some minimal level of completion to be included, but does not clarify what this actually means. Discussion on #321 has brought up ideas about what makes a package "good enough" for inclusion/promotion at different levels on CDB, and it seems like some of the ideas described there may be useful to clarify the inclusion policy.

Some examples:

• Game packages should meet a generally higher standard of functionality than mod packages. Mods are only judged by what they add, while games also need to fulfill certain basic expectations.
• Each package should have at least one distinguishing/unique feature, which could be anything, including a better-executed version of a common feature, or a better development process or transparency, but must be something that can be identified and articulated.

The original theory was that CDB editors would only need to check package technical requirements, and we would largely leave the community to handle curation via the reviews system, but there is some risk that CDB may become inundated if an author tries to just throw a lot of ideas against the wall and see what sticks, or resubmit trivial remixes of old ideas to reset reputation and bypass bad reviews, so the inclusion policy can be a helpful rate limit to control the review burden placed on the community.

[Warr1024]

An additional thing I think we should clarify in policy:

A license file MUST be included inside the package distribution. It should use a common name, such as LICENSE or COPYING or license.txt. I think it should also not be allowed to merely be a section of the readme; it must be trivially easy to find specifically.

For packages with complex or piecemeal licensing, the LICENSE file must still exist, and describe how to identify the license of all components. If there is no "fallback" license (e.g. "all content without its own license is covered by X") then there must be a license present for all non-trivial content (e.g. other than pure metadata).

Obviously the text of the license should match the package metadata.

I think we should also require the relevant text of the license, as specified by external sources. A URL can be acceptable for some licenses where the foundation that created the license provides stable versioned URLs for the license content (e.g. CC) but for most, the full text should be included (e.g. MIT, GPL).

Obviously the author's name and copyright year(s) should be in the text file, and not left as placeholders or omitted.

[ghost]

This all seems reasonable. We'll probably want to dedicate some space to common examples to demonstrate what "one distinguishing/unique feature" typically looks like though, since it's a phrase that I'd expect some confusion/mixed readings of.

[rubenwardy]

I disagree with "one distinguishing/unique feature". If someone wants to remake something that already exists, that's fine by me - that's how you get choices

I agree that games should meet a higher standard

[ghost]

iirc, from discussions on Discord Warr clarified that remaking something with your own spin or further polish/quality should count as a distinguishing feature. ...which is why I think that language should be clarified.

[rubenwardy]

I suggest rephrasing "one distinguishing/unique feature" to "one unique selling point"

[Warr1024]

One unique feature, or selling point, or creative direction, or some other specific intent.

Things I would accept are actually pretty broad:

• Like MTG but more polished
• Like MTG but more trimmed and minimalistic (i.e. these features are absent not because they're not done yet but because the point is to permanently eliminate them)
• Like MTG but with more permissive licensing

Identifying this unique trait should not be the responsibility of the editor, but should be evident from the package. This also sort of imposes a de facto requirement that games should have a more useful description than "hey join my discord!"

A game must have a unique raison d’être which is evident in the package listing, and evident within the game experience itself.

[Warr1024]

To clarify, since I suggested this requirement for all packages, not merely games:

• Each package should have some identifiable unique value, feature, purpose, or characteristic that distinguishes it from other published content.
• The unique value of a package should be obvious from the package listing, ideally from just the name and short description (for Content Tab users), or name + short description + thumbnail for texture packs.
• The unique value described in the package listing cannot be misleading and must be evident in the package releases themselves.
• This restriction may be relaxed at discretion of the CDB editors for various reasons, e.g. packages of historical significance, mod dependency relationships.

I'm including texture packs, even though as I understand it this has not been an issue for them yet, to be consistent, and because I think texture packs should have no challenge meeting this requirement (Less Dirt only changes like 1 texture and it qualifies thoroughly).

As far as the exact language to go into the policy (i.e. for a future PR) I would be open to proposals on how to make it more succinct. The "no misleading" requirement might actually be merged with a similar policy outside the scope of the "completeness" requirement that covers things like screenshots as well...

[doxygen-spammer]

I agree that there should be a better policy about licensing packages.

For example, all my mods are REUSE compliant. (https://reuse.software/spec) But I have to remove the licenses from the packages before uploading them, because otherwise ContentDB rejects them, because the Minetest client fails on them.

[Suggestion:] A license file MUST be included inside the package distribution. It should use a common name, such as LICENSE or COPYING or license.txt. I think it should also not be allowed to merely be a section of the readme; it must be trivially easy to find specifically. [...]

Including the license in every package will easily double the size of the releases. GPL licenses are bigger than many small mods’ code base and textures.

In the Debian world it is uncommon to include licenses in packages. There is typically a file “copyright”, which references the licenses for each file in the package. (Like a “software bill of materials”.) The licenses themselves are provided separately.

[...] A URL can be acceptable for some licenses where the foundation that created the license provides stable versioned URLs for the license content (e.g. CC) but for most, the full text should be included (e.g. MIT, GPL).

I think ContentDB already allows only licenses for which it provides the full text itself (via a stable URL to spdx.org).

Obviously the author's name and copyright year(s) should be in the text file, and not left as placeholders or omitted.

I think copyright information should be attached to the copyrighted files, and not filled in in license texts.

REUSE requires copyright information attached to every single file, and discourages filling it in in the license text. I agree with REUSE, because that makes it very easy to... well... reuse stuff.

---

My recommendation is that all releases (e. g. uploaded after 2024-07) require the “copyright” file in the root directory, in debian/copyright format. (https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/) Every file in the release must then be covered by this file, and be available under any license allowed on ContentDB. The package license can then be calculated automatically as the superset of all files.

Additional requirements on copyright specification (e. g. a section in the long description) can then be dropped.

(And yes, debian/copyright is easily readable and writable for both humans and machines, and even included in REUSE.)