Minecraft creator credits and licences: a practical publishing habit

Credits answer who contributed. A license or written permission answers what you may do with someone else's work. Those are different records, and a clean publishing workflow keeps both attached to every borrowed dependency before a project is released.

Build the source record before publication

Create one entry for each third-party texture, model, sound, script, library, map component, reference asset, or collaborator contribution. Record:

• the project or asset name;
• the creator or rights holder exactly as the source identifies them;
• the creator-controlled source URL;
• the exact license name and link, or the written-permission record;
• the version or dated source state you used;
• any changes you made;
• where the material appears in your release;
• any notice, attribution, share-alike, or distribution condition that still needs review.

A homepage link or a creator name by itself is not a complete license record. Preserve the exact source that governs the version you used, and recheck it before a new release.

Separate three permission states

Use a fail-closed status for each dependency:

1. License identified: the governing text is linked and its conditions have been reviewed for the planned use.
2. Direct permission recorded: the rights holder supplied permission that covers the planned use, and the record states its scope.
3. Permission unresolved: the source is missing, the license is unclear, or the planned use is outside the documented terms.

The third state is a stop signal. Do not replace it with “credit to the owner,” a search-result link, or an assumption that free access means free reuse. Remove or replace the dependency until the rights state is clear.

Write credits that can be audited

Group credits by function so a player or reviewer can trace them: building, code, textures, models, audio, testing, translation, and other contributions. Use the contributor's requested public name when known. Link to the creator-controlled source, not a repost or download mirror.

If a dependency was modified, say what changed without implying that you own the original. If different files use different terms, keep separate entries. A single project-wide license label should not hide asset-specific conditions.

Keep release notes and the rights record together

When a dependency changes, update its source, version, modification note, and permission state in the same revision. If a creator removes a page or changes a license, do not silently carry the old claim forward. Preserve the prior audit record and make a new release decision from the evidence that still applies.

The current Minecraft EULA distinguishes original creator work from Minecraft-owned content and directs creators to current Usage Guidelines. It provides a general official boundary only; it is not individualized legal advice and does not grant permission for third-party material.

Final disclosure gate

Do not publish until every dependency has an identified source, a resolved permission state, accurate credit, and a record of modifications. This page owns the disclosure workflow. Portfolio selection, project storytelling, and presentation order belong to the separate portfolio guide.