Package Inclusion Policy and Guidance

1. General 🔗

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.

2. Accepted Content 🔗

2.1. Mature Content 🔗

See the Terms of Service for a full list of prohibited content.

Other mature content is permitted providing that it is labelled with the applicable content warning.

2.2. Useful Content / State of Completion 🔗

ContentDB is for playable and useful 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. 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 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).

Your package's title and short description must be in English. You can use client-side translations to translate 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.

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 🔗

A package uses a name when it has that name or contains a mod that uses that name.

The first package to use a name based on the creation of its forum topic or ContentDB submission has the right to the technical name. The use of a package on a server or in private doesn't reserve its name. No other packages of the same type may use the same name, except for the exception given by 3.2.

If it turns out that we made a mistake by approving a package and that the name should have been given to another package, then we may unapprove the package and give the name to the correct one.

If you submit a package where you don't have the right to the name you will be asked 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. 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 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. 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.

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.

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. The use of licenses that discriminate between groups of people or forbid the use 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 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.

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 number of potential users your package has. Using a closed source license will result in your package not being shown in Luanti by default. See the help page on non-free licenses for more information.

It is recommended that you use a proper license for code with a warranty disclaimer, such as the (L)GPL or MIT. You should also use a proper media license for media, such as a Creative Commons license.

The use of WTFPL is discouraged as it doesn't contain a valid warranty disclaimer, and also includes swearing which prevents settings like schools from using your content. Read more.

Public domain is not a valid license in many countries, please use CC0 or MIT instead.

5. Promotions and Advertisements (inc. asking for donations) 🔗

You may not place any promotions or advertisements in any metadata including screenshots. This includes asking for donations, promoting online shops, or linking to personal websites and social media. Please instead use the fields provided on your user profile page to place links to websites and donation pages.

ContentDB is for the community. We may remove any promotions if we feel that they're inappropriate.

6. Reviews and Package Score 🔗

You may invite players to review your package(s). One way to do this is by sharing the link found in the "Share and Badges" page of the package's settings.

You must not require anyone to review a package. You must not promise or provide incentives for reviewing a package, including but not limited to monetary rewards, in-game items, features, and/or privileges. You may give a cosmetic-only role or badge to those who review your package - this must not be tied to the content or rating of the review.

You must not attempt to unfairly manipulate your package's ranking, whether by reviews or any other method. Doing so may result in temporary or permanent suspension from ContentDB.

7. Screenshots 🔗

  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 not violate copyright. This means don't just copy images from Google search, see the copyright guide.

  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 accurately reflect in-game appearance.

    Content in screenshots that is prominently displayed or "focal" should be either present in, or interact with, the package in some way. These can include things in other packages if they have a dependency relationship (either way), or if the submitted package in some way enhances, extends, or alters that content.

    Unrelated package content can be allowed to show what the package content will look like in a typical/realistic game scene, but should be "in the background" only as far as possible.

  4. Screenshots must only contain content appropriate for the Content Warnings of the package.

8. Security 🔗

The submission of malware is strictly prohibited. This includes software that does not do as it advertises, for example, if it posts telemetry without stating clearly that it does in the package meta.

Packages must not ask that users disable mod security (secure.enable_security). Instead, they should use the insecure environment API.

Packages must not contain obfuscated code.

9. Reporting Violations 🔗

Please click "Report" on the package page.