Update package inclusion policy (#601)

Fixes #566, fixes #222

app/flatpages/policy_and_guidance.md

@@ -1,22 +1,5 @@
 title: Package Inclusion Policy and Guidance
 
-## 0. Overview
-
-ContentDB is for the community, and as such listings should be useful to the
-community. To help with this, there are a few rules to improve the quality of
-the listings and to combat abuse.
-
-* **No inappropriate content.** <sup>2.1</sup>
-* **Content must be playable/useful, but not necessarily finished.** <sup>2.2</sup>
-* **Don't use the name of another mod unless your mod is a fork or reimplementation.** <sup>3</sup>
-* **Licenses must allow derivatives, redistribution, and must not discriminate.** <sup>4</sup>
-* **Don't put promotions or advertisements in any package metadata.** <sup>5</sup>
-* **Don't manipulate package placement using reviews or downloads.** <sup>6</sup>
-* **Screenshots must not be misleading.** <sup>7</sup>
-* **The ContentDB admin reserves the right to remove packages for any reason**,
-  including ones not covered by this document, and to ban users who abuse
-  this service. <sup>1</sup>
-
 
 ## 1. General
 
@@ -26,35 +9,53 @@ including ones not covered by this document, and to ban users who abuse this ser
 
 ## 2. Accepted Content
 
-### 2.1. Acceptable Content
+### 2.1. Mature Content
 
-Sexually-orientated content is not permitted.
-If in doubt at what this means, [contact us by raising a report](/report/).
+See the [Terms of Service](/terms/) for a full list of prohibited content.
 
-Content which depicts or encourages the use of illegal drugs (under the laws of the United Kingdom) is not permitted.
+Other mature content is permitted providing that it is labelled with the applicable
+[content warning](/help/content_flags/).
 
-Mature content is permitted providing that it is labelled correctly.
-See [Content Flags](/help/content_flags/).
+### 2.2. Useful Content / State of Completion
 
-### 2.2. State of Completion
+ContentDB is for playable and useful content - content which is sufficiently
+complete to be useful to end-users.
 
-ContentDB should only currently contain playable content - content which is
-sufficiently complete to be useful to end-users. It's fine to add stuff which is
-still a Work in Progress (WIP) as long as it adds sufficient value; Note that
-this doesn't mean that you should add a thing you started working on yesterday,
-it's worth adding all the basic stuff to make your package useful.
-
-You should make sure to mark Work in Progress stuff as such in the "maintenance
-status" column, as this will help advise players.
+It's fine to add stuff which is still a Work in Progress (WIP) as long as it
+adds sufficient value. You must make sure to mark Work in Progress stuff as
+such in the "maintenance status" dropdown, as this will help advise players.
 
 Adding non-player facing mods, such as libraries and server tools, is perfectly
-fine and encouraged. ContentDB isn't just for player-facing things, and adding
-libraries allows them to be installed when a mod depends on it.
+fine and encouraged. ContentDB isn't just for player-facing things and adding
+libraries allows Luanti to automatically install dependencies.
+
+### 2.3. Language
+
+We require packages to be in English with (optional) client-side translations for
+other languages. This is because Luanti currently requires English as the base language
+([Issue to change this](https://github.com/luanti-org/luanti/issues/6503)).
+
+Your package's title and short description must be in English. You can use client-side
+translations to [translate content meta](https://api.luanti.org/translations/#translating-content-meta).
+
+### 2.4. Attempt to contribute before forking
+
+You should attempt to contribute upstream before forking a package. If you choose
+to fork, you should have a justification (different objectives, maintainer is unavailable, etc).
+You should use a different title and make it clear in the long description what the
+benefit of your fork is over the original package.
+
+### 2.5. Copyright and trademarks
+
+Your package must not violate copyright or trademarks. You should avoid the use of
+trademarks in the package's title or short description. If you do use a trademark,
+ensure that you phrase it in a way that does not imply official association or
+endorsement.
 
 
 ## 3. Technical Names
 
-### 3.1 Right to a name
+### 3.1. Right to a Name
 
 A package uses a name when it has that name or contains a mod that uses that name.
 
@@ -72,23 +73,46 @@ to change the name of the package, or your package won't be accepted.
 
 We reserve the right to issue exceptions for this where we feel necessary.
 
-### 3.2. Mod Forks and Reimplementations
+### 3.2. Forks and Reimplementations
 
 An exception to the above is that mods are allowed to have the same name as a
 mod if it's a fork of that mod (or a close reimplementation). In real terms, it
-should be possible to use the new mod as a drop-in replacement.
+must be possible to use the new mod as a drop-in replacement.
 
 We reserve the right to decide whether a mod counts as a fork or
 reimplementation of the mod that owns the name.
 
+### 3.3. Game Mod Namespacing
+
+New mods introduced by a game must have a unique common prefix to avoid conflicts with
+other games and standalone mods. For example, the NodeCore game's first-party mods all
+start with `nc_`: `nc_api`, `nc_doors`.
+
+You may include existing or standard mods in your game without renaming them to use the
+namespace. For example, NodeCore could include the `awards` mod without needing to rename it.
+
+Standalone mods may not use a game's namespace unless they have been given permission by
+the game's author.
+
+The exception given by 3.2 also applies to game namespaces - you may use another game's
+prefix if your game is a fork.
+
 
 ## 4. Licenses
 
-### 4.1. Allowed Licenses
+### 4.1. License file
 
+You must have a LICENSE, LICENSE.txt, or LICENSE.md file describing the licensing of your package.
 Please ensure that you correctly credit any resources (code, assets, or otherwise)
-that you have used in your package. For help on doing copyright correctly, see
-the [Copyright help page](/help/copyright/).
+that you have used in your package.
+
+You may use lowercase or include a suffix in the filename (ie: `license-code.txt`). If
+you are making a game or modpack, your top level license file may just be a summary or
+refer to the license files of individual components.
+
+For help on doing copyright correctly, see the [Copyright help page](/help/copyright/).
+
+### 4.2. Allowed Licenses
 
 **The use of licenses that do not allow derivatives or redistribution is not
 permitted. This includes CC-ND (No-Derivatives) and lots of closed source licenses.
@@ -98,13 +122,13 @@ of the content on servers or singleplayer is also not permitted.**
 However, closed sourced licenses are allowed if they allow the above.
 
 If the license you use is not on the list then please select "Other", and we'll
-get around to adding it. We tend to reject custom/untested licenses, and
-reserve the right to decide whether a license should be included.
+get around to adding it. We reject custom/untested licenses and reserve the right
+to decide whether a license should be included.
 
 Please note that the definitions of "free" and "non-free" is the same as that
 of the [Free Software Foundation](https://www.gnu.org/philosophy/free-sw.en.html).
 
-### 4.2. Recommended Licenses
+### 4.3. Recommended Licenses
 
 It is highly recommended that you use a Free and Open Source software (FOSS)
 license. FOSS licenses result in a sharing community and will increase the
@@ -152,10 +176,14 @@ Doing so may result in temporary or permanent suspension from ContentDB.
 
 ## 7. Screenshots
 
-1.  **Screenshots must not violate copyright.** You should have the rights to the
-    screenshot.
+1.  We require all packages to have at least one screenshot. For packages without visual
+    content, we recommend making a symbolic image with icons, graphics, or text to depict
+    the package.
 
-2.  **Screenshots must depict the actual content of the package in some way, and
+2.  **Screenshots must not violate copyright.** This means don't just copy images
+    from Google search, see [the copyright guide](/help/copyright/).
+
+3.  **Screenshots must depict the actual content of the package in some way, and
     not be misleading.**
 
     Do not use idealized mockups or blender concept renders if they do not
@@ -171,20 +199,9 @@ Doing so may result in temporary or permanent suspension from ContentDB.
     will look like in a typical/realistic game scene, but should be "in the
     background" only as far as possible.
 
-3.  **Screenshots must only contain content appropriate for the Content Warnings of
+4.  **Screenshots must only contain content appropriate for the Content Warnings of
     the package.**
 
-4.  **Screenshots should be MOSTLY in-game screenshots, if applicable.** Some
-    alterations on in-game screenshots are okay, such as collages, added text,
-    some reasonable compositing.
-
-    Don't just use one of the textures from the package; show it in-situ as it
-    actually looks in the game.
-
-5.  **Packages should have a screenshot when reasonably applicable.**
-
-6.  **Screenshots should be of reasonable dimensions.** We recommend using 1920x1080.
-
 
 ## 8. Security
 

app/tasks/minetestcheck/tree.py

@@ -25,7 +25,7 @@ from .config import parse_conf
 from .translation import Translation, parse_tr
 
 basenamePattern = re.compile("^([a-z0-9_]+)$")
-licensePattern = re.compile("^(licen[sc]e|copying)(.[^/\n]+)?$", re.IGNORECASE)
+licensePattern = re.compile("^licen[sc]e[^/.]*(\.(txt|md))?$", re.IGNORECASE)
 
 DISALLOWED_NAMES = {
 	"core", "minetest", "group", "table", "string", "lua", "luajit", "assert", "debug",