How to generate THIRD_PARTY_NOTICES.txt and CREDITS.md in Unity (Game Compliance Pack quickstart)

#automation #gamedev #tooling #tutorial

Shipping a Unity game often means shipping third-party software too: Unity Package Manager (UPM) dependencies, Asset Store plugins, embedded DLLs, native plugins, copied utilities, and random folders someone dragged into Assets/.

At release time, this turns into the same panic checklist:

What third-party did we ship?
What are the license obligations?
Where is our third-party notices file?
Did we forget something?

This post shows a practical workflow using Third-Party Notices & Credits: License Compliance for Unity (Game Compliance Pack) to generate release-ready compliance artifacts directly from your Unity project.

Tool link (copy/paste):
https://kevindevelopment.itch.io/compliance

What the tool generates (release-ready outputs)

From your Unity project, it can export:

THIRD_PARTY_NOTICES.txt (full attributions plus license text when available)
CREDITS.md (short, human-friendly credits block)
compliance-manifest.json (machine-readable source of truth for diffs and repeatable builds)

The key design goal is deterministic outputs you can commit to version control so diffs stay meaningful.

The workflow (scan, review UNKNOWN, export)

1) Import the package into your Unity project

Purchase and download the Unity package
Import it into the project (like any other .unitypackage)
Reopen the project if Unity does not immediately compile editor scripts

2) Run a scan for third-party components

In the tool window, run the scan. The scanner is designed to pick up the most common sources of third-party software in Unity projects:

UPM dependencies (direct and transitive)
Asset Store imports
Embedded folders (common “ThirdParty” style locations)
Native plugins and binaries (DLLs and platform libs)

After the scan, you should see a component list with evidence for where each item came from.

3) Treat UNKNOWN as a feature, not a bug

If a license cannot be identified with high confidence, the tool marks it UNKNOWN instead of guessing.

This is exactly what you want for real compliance work: unknowns become visible, reviewable tasks, not silent risk.

Practical rule: do not export and ship until your UNKNOWN items are handled.

4) Resolve UNKNOWN items using overrides (the real work)

UNKNOWNs are expected. The fast path is to resolve them once and store the decisions in source control so everyone on the team shares the same results.

Typical resolution steps per UNKNOWN component:

Confirm what the component is (where it lives in the project, what it is used for)
Locate license evidence (LICENSE, NOTICE, COPYING, vendor docs, repo metadata)
Fill in attribution fields (name, author/publisher, URL if applicable)
Set the license identifier and include license text when required

The tool supports JSON overrides and manual components so the final attribution data reflects what you actually ship.

Example override shape (illustrative, check the tool docs for exact fields):


json
{
  "overrides": [
    {
      "key": "com.vendor.component",
      "licenseId": "MIT",
      "attribution": "Component Name by Vendor Name",
      "url": "https://example.com",
      "licenseText": "..."
    }
  ]
}