# The reference we won't clone: X12 licensing, stated plainly

> transactions.dev · by visibility.cloud — 2026-07-31
> Written for the in-house supply-chain platform team — the engineering manager who needs the dependency-provenance answer in writing before an architecture review.

One thesis: **X12's copyright regime makes a free X12 segment dictionary
legally unbuildable without a negotiated partner agreement — so every X12
page on this site is original prose plus deep links to the licensed
canonical reference, and that constraint is stated here rather than
obscured.**

If you are defending a buy-over-build decision to an architecture review,
the provenance of your dependencies is on the questionnaire. Here is ours,
for the one input in this layer that is somebody's licensed property.

## What X12 sells, at published prices

X12 Incorporated is a standards body that monetizes access to its work
products. The licensing program is public
([x12.org/products/licensing-program](https://x12.org/products/licensing-program)),
and the published tiers, as of our 2026-07-31 reading, are:

- **Glass Premium** — $180 per user per year (volume tiers step down to
  $102.21 at 100+ seats): view-only browser access to the EDI Standard, the
  code directories, control standards, and technical reports. Explicitly
  scoped to internal development and production support — not a right to
  embed content in solutions facing third parties.
- **Developer License** — $1,200 per year: downloadable access,
  development-only, positioned as the on-ramp to a partner tier.
- **Licensed User** — $180 per year: for end-users of a solution somebody
  else built under license.
- **Internal Use Partner** — $3,600 per year: X12 IP inside internal
  production systems.
- **Commercial Use Partner** — a variable, negotiated annual fee: X12 IP
  inside products provided to customers. This is the tier a shipped EDI
  product points at.

Note what no fixed-price tier grants: redistribution. X12's IP-use policy
([x12.org/products/ip-use](https://x12.org/products/ip-use)) is blunt about
it — *"Direct distribution of X12's copyrighted products by any organization
or individual to another organization or individual is strictly
prohibited"* — and posting X12 content on another organization's public
website is named as a prohibited act. Republication-grade rights exist only
inside negotiated Partner agreements.

## How Stedi's free reference is legal

The best public X12 reference on the internet is
[Stedi's](https://www.stedi.com/edi/x12) — full segment listings across
releases 2 through 8, free of charge, stable URLs. It is not fair use and it
is not an oversight. X12's own
[Licensing Partners page](https://x12.org/products/licensing-program/partners)
lists Stedi as a licensing partner, alongside Availity, Oracle, SAP, and
MuleSoft. Stedi's reference exists under a negotiated partner agreement —
theirs, not reproducible by assumption, and not something a competitor can
clone by scraping.

That is the single most load-bearing licensing fact in this field, and it
is why our posture toward Stedi's reference is credit and deep links, never
copies. The [856 segments](https://www.stedi.com/edi/x12-008010/856), the
[214 structure](https://www.stedi.com/edi/x12-008010/214), the element
dictionaries — those pages are the canonical public authority, and every
X12 page on this site links them at the exact segment depth where our
original prose stops. [Our own 856 anatomy](/blog/anatomy-of-an-856/) is
the pattern in practice: three claims read in our words, every element
detail a link.

## Our rule, and why it holds under audit

The bright line the engine and this site operate under:

1. **Original prose.** Envelope mechanics, HL-tree semantics,
   acknowledgment behavior, compile mappings — facts about a wire format,
   explained in our own words. Copyright protects X12's expression, not the
   facts and methods of interoperability; this is the position the entire
   open-source X12 parser ecosystem has occupied in public for twenty years.
2. **Self-authored artifacts.** Our grammar files are data built from public
   implementation conventions, corpus observation, and differential parser
   behavior — each carrying a provenance block, pinned by sha256, changed
   only by journaled ruling. Nothing is transcribed from Glass into the
   repo, ever. Our canonical-JSON schema and our X12-to-EPCIS mapping tables
   are entirely our own expression — they describe our output and reproduce
   nobody's prose.
3. **Element dictionaries stay links.** The one asset that is
   spec-as-database — element numbers with X12's names, definitions, and
   code values, en masse — is exactly what Glass sells and what Stedi's
   partner agreement covers. We do not ship it, quote it, or paraphrase it
   at dictionary depth.

The same discipline has a mirror image on the open side:
[EDIFACT's directories are published free by UNECE](/blog/edifact-is-open-we-pinned-it/),
which is why our EDIFACT and EANCOM reference content goes
dictionary-deep with per-file digests while the X12 pages stay at
original-prose depth. The licensing asymmetry is the content strategy, and
it is stated as such.

## Why this is also your answer

If your team writes companion guides or partner onboarding docs, you are
inside the same regime: X12's policy requires explicit permission even to
distribute companion guides to trading partners. The pattern that survives
audit is the one above — your own prose, your own constraint files, deep
links to a licensed reference for element detail. It is not a workaround;
it is the only posture that is simultaneously legal, honest, and
maintainable, which is presumably why the vendor with the negotiated
license and the vendor without one (that's us) converge on linking to the
same pages.

One more consequence worth naming for a review board: because our grammars
are self-authored data with journaled provenance rather than licensed
imports, there is no upstream license whose termination can strand the
engine, and the [pins gate](/blog/edifact-is-open-we-pinned-it/) refuses to
run against a tampered file. Dependency provenance is not a paragraph in
our security questionnaire response — it is a verifiable artifact, and this
page is its plain-language twin.

---
Access: https://transactions.dev/get-access/ · All posts: https://transactions.dev/blog/ · Machine face: https://transactions.dev/llms.txt