Define independent-implementation provenance and MIT inbound-license policy

[zoeyrose]

Outcome

Make the legal and engineering boundary of the replacement server auditable before feature implementation begins.

The replacement is an independent implementation under MIT, not a translation, mechanical port, or refactor of the GPL code in classic/server or its GPL runtime Python scripts.

Required policy

Document:

• Allowed design inputs: public issues and specifications, independently licensed content/data, observable behavior, interoperability facts, clean-room test vectors, and permissively licensed third-party dependencies.
• Disallowed inputs: copied or transliterated GPL source, structure-preserving rewrites, copied GPL tests/fixtures, or dependencies that impose GPL/AGPL terms on the server.
• How contributors record source-of-design and authorship for new modules.
• How an exact contribution solely and originally owned by an approved MIT provenance grantor can receive an explicit MIT grant, including exact paths/commits and treatment of embedded third-party material.
• How mixed-license maps, archetypes, audio, and graphics remain external data with their own notices rather than becoming MIT by association.
• Dependency allow/deny rules, SPDX inventory, notice generation, and exception review.
• The clean separation between black-box behavior comparison and source translation.

Deliverables

• CONTRIBUTING.md independent-implementation declaration.
• PROVENANCE.md with module-level source-of-design records.
• A machine-checkable dependency-license policy and generated third-party notice.
• Pull-request checklist entries for provenance, generated code, copied fixtures, and asset/data licensing.
• A short decision record covering Protobuf-generated code, CEL, and any future Starlark dependency.

Acceptance criteria

• A new contributor can determine what may and may not be consulted without private guidance.
• CI fails on an unapproved reciprocal-code dependency or missing required provenance record.
• At least one example demonstrates the difference between preserving a gameplay rule and copying its implementation.
• The policy explicitly says content distributions may be mixed-license while independently implemented server code remains MIT.
• No blanket relicensing claim is made for the content or runtime Python corpus.

Dependency

This policy gates implementation PRs but can be authored in parallel with repository bootstrap. It is coordinated by the organization-wide provenance issue and roadmap.

[github-actions]

🎉 This issue has been resolved in version 1.0.0 🎉

The release is available on:

• v1.0.0
• GitHub release

Your semantic-release bot 📦🚀