Paul Miles — Accelerator Distribution & Licensing Setup Guide

Tag: S-2026-06-16-accelerator-distribution-setup Type: own-writing Author(s): Paul Miles (Red Strata), drafted by AI assistant on his instruction Date of source: 2026-06-16 Date ingested: 2026-06-16 Authority weight: own-writing. (Design/approach doc; the platform-feature claims within it draw on current vendor documentation cited in §11, which can change.) Raw file: S-2026-06-16-accelerator-distribution-setup.md (markdown master); companion work-breakdown record on disk at C:\Users\pgmil\OneDrive\Documents\_ClaudeWorkspace\07 Home Configuration\ (Accelerator_Distribution_Setup_Guide.md, Accelerator_Distribution_Approach_and_Work_Breakdown.md).

What it claims

A setup guide for storing, versioning, licensing and distributing Redstrata’s AI/Data accelerators — starting with the Business Glossary Build Kit and the Glossary Test Harness — as licensable products for clients. The central principle is to separate “build & version (internal)” from “license & deliver (external)”: clients receive a sealed, sanitised, versioned package, never access to the canonical repository.

It recommends starting on Bitbucket (Redstrata already holds the licence; enterprise clients are Atlassian-heavy; the delivery model is manual and low-volume) and documents GitHub as a deliberate later upgrade for self-serve or scaled distribution. A side-by-side comparison establishes that Bitbucket covers canonical repo, git-tag versioning and external client access (workspace/project invites; read-only access keys), but lacks native Releases (emulated via a tag plus a .zip in the repo Downloads area) and one-click templates (clients fork instead). GitHub’s first-class Releases, template repositories and storefront/licence-key integrations (Lemon Squeezy, Gumroad, Payhip) are the reasons to migrate when productising for scale.

Other positions: a hard /_internal/ boundary keeps answer keys, ground truth, QA reports and the Test Harness scoring logic out of every client package (the Test Harness may become a separate higher-tier “validation pack”); the kit is licensed under a proprietary commercial EULA, not open source; and platform tools do not enforce licence terms — control is contractual plus access revocation. The guide includes a repository structure, semantic-versioning/packaging steps, a distribution-flow diagram, a step-by-step Bitbucket setup, the GitHub upgrade path, and a risks/mitigations table.

Notable quotes

  • “The repository is the factory; the client never gets the keys to the factory — they get a sealed, numbered product.” (§1)
  • “Neither Bitbucket nor GitHub enforces licence terms — they are not DRM. Your control is contractual (the EULA) plus access revocation.” (§6)

What’s speculative vs. asserted

  • Asserted (own design positions): the internal/external separation; Bitbucket-now / GitHub-later sequencing; proprietary commercial licensing; the /_internal/ exclusion boundary.
  • Asserted on current vendor documentation (June 2026, may change): Bitbucket has no native Releases equivalent and uses Downloads for artifacts; Bitbucket access via workspace/project invites and read-only access keys; GitHub template repositories and Releases; outside-collaborator/fine-grained-token limits; licence-key handling on Lemon Squeezy/Gumroad/Payhip. (Cited in §11.)
  • Conditional / not yet decided: the GitHub upgrade, EULA terms and tiers, pricing model, and whether the Test Harness ships separately — all flagged as open items for Paul.

Topics this feeds

Open questions raised

  • Commercial EULA drafting (legal review) and tier definitions (Evaluation / Commercial / Validation pack).
  • Whether the Glossary Test Harness ships as a separate licensed product or stays internal-only.
  • Pricing/contract model before first client delivery.