C.A.T.S.Crunchy Automated Tactical System

← All documents

Originality Policy

This is a hard rule for this repository. It is not advisory and it is not negotiable.

It binds every contributor, human or AI. A change that violates it does not get merged, no matter how good the mechanic is.


The rule

Derive systems. Never copy material.

Existing games may be studied for how their mechanics function. Nothing they say may appear here — no text, no names, no tables reproduced, no equipment lists, no setting, no art, no trade dress.

Why the line falls where it does

Under US copyright law, a game's system — its procedures, methods of operation, and underlying ideas — is not copyrightable. Its expression is: the actual wording of the rules, the names, the art, the setting fiction, the specific presentation of tables. Trademarks protect names and branding separately and indefinitely.

So the boundary is not "how similar is the math." It is "did any expression travel."

This is the working policy for the project, not legal advice. If C.A.T.S. ever moves toward commercial release, get an actual IP attorney to review it.

Permitted — study and derive

Forbidden — no exceptions

The practical procedure

When a mechanic from another game is worth learning from:

  1. Close the source. Write from understanding, not with the book open. If you cannot restate the mechanic from memory in your own words, you do not understand it well enough to derive from it yet.
  2. State the problem, not the solution. Record what design problem the mechanic solves. Solve that problem for C.A.T.S. from first principles.
  3. Choose different numbers. Derived values must be set by our own math and playtesting, never inherited. Matching values are the clearest evidence of copying.
  4. Choose our own vocabulary. Every term in C.A.T.S. is ours.
  5. Log the influence. Note in CHANGELOG.md what inspired the change and how the result differs. An honest, visible influence trail is a defense; a hidden one is a liability.

Two tests before merging

The convergence test. If several independent games solve a problem the same way, that approach is a genre convention, not anyone's property. Convergence is strong evidence a mechanic is safe to derive from — and it is the reason for the triangulation method below.

The substitution test. Read the passage and ask: could a reader who knows the source game identify which game this came from, on the basis of the words rather than the math? If yes, rewrite it. Similar mechanics are fine. Recognizable expression is not.


Derivation method for the first combat draft

The first draft of C.A.T.S. combat is to be triangulated against three reference systems, all of which independently solved parts of the problem this project is taking on:

ReferenceWhat it demonstrates
Battlelords of the 23rd CenturyLayered, localized personal armor across a wide technology range
MechWarriorPilot and crew skill mattering alongside machine statistics
BattleTechPersistent machine degradation — heat, ammunition, construction limits, and consequences that outlive the battle

The method, in order of preference:

  1. Find the common ground. Where all three converge on the same solution, that solution is a genre convention and the safest possible foundation. Build there first, in our own terms and our own numbers.
  2. Where they diverge, build new. Divergence means there is no settled answer, so take the problem all three were addressing and solve it fresh for C.A.T.S. Do not pick a favorite and reskin it.

Reskinning any one of the three is a policy violation even where it would be legally defensible. The point of triangulation is to land somewhere none of them is, by construction.

Note that OQ-13 already flags a structural resemblance risk from exactly this direction. The current location templates converge hard on one of the three references. Triangulation is the remedy: deliberate divergence on at least one structural axis.

Handling source material

Owning a rulebook grants the right to read it. It never grants the right to republish it. Those are different acts, and this repository is built so the first is easy and the second cannot happen by accident.

ConcernWhere it livesCommitted?
Source rulebooks, PDFs, scansreference/Never
Our functional analysis of themdocs/notes/Yes — it is our writing
Our own play aids and record sheetsprint/Yes
Generated rulebook exportsbuild/No — ship as Release assets

Reading source material is encouraged. The originality rule constrains what gets written and published, not what gets studied. .gitignore excludes reference/ from version control while leaving every file in it readable on disk, which is precisely the intended behavior.

Two practical consequences:

If anything in reference/ ever needs git add -f to commit, that is the policy working correctly. Do not override it.

Open-license content

None is currently incorporated.

If any is added later, record its exact source, license, and version in the same commit that adds it, and add it to a NOTICE file at the repository root. Do not mix ORC, OGL, Creative Commons, or custom-licensed material without a compatibility review first — these licenses are not automatically compatible with one another, and mixing them incorrectly can encumber the entire work.

Default assumption: C.A.T.S. is 100% original content and stays that way unless someone makes a deliberate, documented decision otherwise.

Source: docs/02-originality-policy.md — this page is generated from it.