Discussion: split go-glx into its own Go module so library consumers don't inherit CLI dependencies #1408

Problem

go-glx is the core library, and ADR-0006 keeps it free of I/O so other programs can embed it. But it shares one module with the CLI (go.mod at the repo root). Every program that imports github.com/genealogix/glx/go-glx therefore inherits:

• the root go directive (now go 1.27.2 after chore: Move to maintained YAML module and tighten go.mod floor #1407), and
• the CLI-only requirements in its module graph and go.sum: go-git and its ssh/crypto/transport tree (ProtonMail/go-crypto, circl, x/crypto, x/net, knownhosts, ssh_config, ssh-agent, …), cobra, and so on.

None of that is compiled into a program that uses only go-glx, but it does show up in that program's dependency review, its vulnerability scanner output (e.g. GO-2026-5932) and its license audit.

Why a plain go-glx/go.mod is not enough

1. specification/jsonld. go-glx/jsonld_export.go imports github.com/genealogix/glx/specification/jsonld, which embeds glx-context.jsonld and lives in the root module. A separate go-glx module would have to require the root module, which pulls the CLI requirements straight back in. go:embed cannot reach outside a module's directory, so the context file would have to be duplicated into go-glx/, either by hand plus a drift check, or generated (go generate + CI diff), or specification/ would have to become a module of its own.
2. gofakeit. go-glx/datagen.go uses github.com/brianvoe/gofakeit/v7 outside test code, so it would stay a library dependency. Options: move the data generator into glx/ (or an internal package), or accept the dependency.
3. Release tagging. A nested module is versioned by go-glx/vX.Y.Z tags. The release workflow, goreleaser, docs and CHANGELOG would need to cover a second tag stream, and contributors would need a go.work (or a replace that must never be released) to develop across both modules.

Options

• A. Split. Create go-glx/go.mod, move or generate the JSON-LD context inside it, relocate datagen.go, and add go-glx/v* tagging to the release process. The library gets its own go floor and a minimal dependency graph.
• B. Stay single-module, trim the library's imports. Keep one module but make sure go-glx imports nothing heavy (e.g. move datagen.go). Graph pruning keeps compiled dependencies small, but the module-level noise for consumers remains.
• C. Do nothing until there is a real external consumer of go-glx.

Context

Raised in a review of go.mod alongside #1407. Related: whether go-git stays a dependency at all (#1409).