Licensing Your Add-On and Crediting Other People

The primary location for machine-readable credit and license information in a Bedrock pack is the `metadata` object inside `manifest.json`. While `header` and `modules` are strictly required for the game to recognize and load the pack, `metadata` is an optional top-level block designed specifically for distribution platforms, pack managers, and curious players who open the archive.

Inside `metadata`, you can define an `authors` array containing the names or handles of the primary creators, a `license` string stating the legal terms or SPDX identifier, and a `url` string pointing to your project home or source repository. If your add-on consists of both a behavior pack and a resource pack, you should duplicate this `metadata` block across both `BP/manifest.json` and `RP/manifest.json`. Players frequently separate resource packs from behavior packs to use the textures standalone, and keeping the metadata in both ensures your credits travel with whichever half of the add-on is being used.

Although the vanilla Bedrock client does not currently render the `metadata` block directly on the main pack selection screen, external tooling, dedicated server dashboards, and community launchers parse these exact fields to display author names and license badges automatically.

{
  "format_version": 2,
  "header": {
    "name": "pack.name",
    "description": "pack.description",
    "uuid": "a1b2c3d4-e5f6-4a5b-8c9d-0e1f2a3b4c5d",
    "version": [1, 0, 0],
    "min_engine_version": [1, 20, 80]
  },
  "modules": [
    {
      "type": "data",
      "uuid": "f6e5d4c3-b2a1-4f5e-8d9c-0b1a2f3e4d5c",
      "version": [1, 0, 0]
    }
  ],
  "metadata": {
    "authors": [
      "Alex_Dev",
      "SamModels"
    ],
    "license": "MIT",
    "url": "example.com/my-addon-project"
  }
}

Because the `metadata` block is only visible to people who unpack your files, you also need a way to show credits to everyday players inside the Minecraft interface. The standard way to do this is through your localization files (`RP/texts/en_US.lang` and `BP/texts/en_US.lang`). By referencing localization keys in your `manifest.json` header (`pack.name` and `pack.description`), you gain full control over how the text looks in the Settings and World Edit menus.

The `pack.description` string supports newline characters (`\n`) and standard Minecraft formatting codes (`§`). While the pack selection list truncates long descriptions after the first couple of lines, the expanded pack info panel displays the rest of the string. Putting a concise credit line and license note on the second line of your description guarantees that anyone activating your pack sees who made it.

If you are building a behavior pack that uses `@minecraft/server` scripts, another polite, non-intrusive method is to register a custom chat trigger or `/scriptevent` listener—such as `/scriptevent mypack:credits`—that prints a formatted list of contributors and asset licenses to the player's chat screen on demand. This avoids cluttering the screen during normal gameplay while keeping detailed attributions accessible in-game.

pack.name=§6Industrial Machinery Add-On§r
pack.description=Adds automated quarries and conveyor belts.\n§7By Alex_Dev & SamModels | License: MIT§r

An add-on is rarely just one type of work; it is a hybrid archive containing JSON definitions, TypeScript or JavaScript code, 3D geometry, pixel art textures, and audio files. When you pick a license, you need to think about how it applies to both the functional code in your behavior pack and the artistic assets in your resource pack.

Software licenses like the MIT License, BSD, or GNU GPL v3 are built for code and JSON data. They handle liability disclaimers and source redistribution well, making them ideal for script libraries, entity behavior templates, and utility packs. On the other hand, Creative Commons licenses (such as CC-BY-4.0 or CC-BY-NC-SA-4.0) are tailored for artistic works like textures, Blockbench models, animations, and custom sounds.

You do not have to apply a single license to the entire `.mcaddon` archive. Dual-licensing is common and practical in the Bedrock community: you might release your TypeScript scripts and behavior JSON under the permissive MIT License so other coders can learn from your mechanics, while keeping your bespoke monster models and textures under CC-BY-NC-ND-4.0 or All Rights Reserved so people cannot rip your art for low-effort re-uploads. Whatever combination you choose, state the split clearly in both your manifest and your root license files.

Relying solely on a short string like `"license": "MIT"` in `manifest.json` is not enough to satisfy the legal terms of most open-source or Creative Commons licenses, which require you to include the full license text or a link to it alongside the distributed files. Furthermore, when players install a `.mcaddon` or `.mcpack` file, Minecraft unzips the archive and copies the behavior and resource pack folders into independent directories (`development_behavior_packs` or `behavior_packs`, and `resource_packs`). Any loose text files sitting in the outer `.mcaddon` zip wrapper are discarded during installation.

To ensure your legal terms and contributor attributions actually remain on the user's device after installation, place a `LICENSE.txt` and a `CREDITS.txt` file directly inside the root folder of your Behavior Pack (`BP/LICENSE.txt`) and the root folder of your Resource Pack (`RP/LICENSE.txt`). Minecraft's pack loader ignores `.txt` and `.md` files in the root directory, so they add virtually zero overhead and will never trigger content log warnings.

Inside `CREDITS.txt`, break down third-party contributions by specific file paths. If you used three sound effects from a public sound library under a CC-BY license, or a script utility written by another developer, list the exact internal path (`RP/sounds/machines/drill_loop.ogg`), the original author's name, the source license, and whether you modified the file. This granularity protects you if someone questions the provenance of your assets and helps future developers know which parts of your pack are safe to reuse.

Beyond human authors, the `metadata` block in `manifest.json` supports an official `generated_with` sub-object. This field was designed to let automated editors, modelers, and build pipelines leave a small signature indicating which tools helped construct the pack. Each key inside `generated_with` is the string name of the tool or library (maximum 32 characters), and its value must be an array of version strings using semantic versioning format.

When you export a model or pack template from community tools like Blockbench or Bridge, they often inject or update their entry in `generated_with` automatically. If you are integrating a third-party code generator, a custom build script, or a community framework into your workflow, you can manually add entries here to credit the toolmakers.

Be careful with the formatting of version numbers inside `generated_with`. Unlike the `header.version` field—which normally takes an array of three integers like `[1, 0, 0]`—the `generated_with` entries strictly expect an array of strings, such as `["4.9.3"]`. Mixing up integer arrays and string arrays inside the manifest is one of the most frequent causes of validation errors when adding metadata by hand.

{
  "format_version": 2,
  "header": {
    "name": "pack.name",
    "description": "pack.description",
    "uuid": "11223344-5566-4778-8990-aabbccddeeff",
    "version": [1, 0, 0],
    "min_engine_version": [1, 20, 80]
  },
  "modules": [
    {
      "type": "resources",
      "uuid": "ffeeddcc-bbaa-4998-8776-665544332211",
      "version": [1, 0, 0]
    }
  ],
  "metadata": {
    "authors": [
      "Alex_Dev",
      "SamModels"
    ],
    "license": "CC-BY-NC-SA-4.0",
    "generated_with": {
      "blockbench": [
        "4.8.0",
        "4.9.2"
      ]
    }
  }
}

When writing your license and credits, remember that your rights only extend to the original work you created. Under the Minecraft Usage Guidelines, you cannot claim ownership over vanilla Minecraft assets, nor can you re-license Mojang's intellectual property. If your resource pack includes modified versions of vanilla textures or models—for example, a slightly recolored iron golem texture or the default humanoid geometry—your license must clarify that your terms cover only your original additions and modifications, while base game assets remain the property of Mojang AB.

You should also pay attention to how you name and brand your add-on in `pack.name` and your license headers. Official guidelines require that community creations do not pretend to be official Minecraft products or updates. Avoid naming your pack in a way that implies Mojang endorsement, and when distributing your pack externally, include the standard disclaimer stating that your project is not an official Minecraft product and is not approved by or associated with Mojang or Microsoft.

Applies to all modern Bedrock Edition versions supporting manifest format_version 2 (1.13.0 and above, including 1.20.x and 1.21.x). No experimental toggles are required.

Read out of the game itself, so the ids match the version you are building for.