|
|
|
|
@@ -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
|
|
|
|
|
|
|
|
|
|
|