Define the OSS attribution approach

docs/roadmap/implementation.md

@@ -62,8 +62,10 @@ that built-in retry policy. Do not duplicate upstream's complete status,
 backoff, parser, or repair test matrices.
 
 Reports are included in this implementation sprint, not deferred by default.
-Stage 9 has one explicit prerequisite in Open Questions. Stages 1–8 do not
-depend on its answer, but the distribution work and release-readiness claim do.
+The distribution decision is resolved: Stage 9 implements repository-hosted
+attribution and license texts, made discoverable through release-note footers.
+The [OSS attribution policy roadmap](policy.md) generalizes that approach for
+future upstream template adoption; that separate adoption is not a prerequisite.
 No stage authorizes a tag, push, publication, or changes to historical releases.
 
 ## Stage 1: Adopt The Released Dependency And Catalog Baseline
@@ -386,44 +388,62 @@ Acceptance: opt-in works for success and errors, reports participate in response
 limits, defaults remain compatible, and concurrent runs do not share collectors.
 Diagnostics include no disallowed content even when an upstream error contains it.
 
-## Stage 9: Resolve And Implement Binary Distribution Materials
+## Stage 9: Add OSS Attribution And Release Links
 
-**Status: Pending; requires the decision in Open Questions.**
+**Status: Pending; distribution approach settled.**
 
-Do not turn the recommendation below into an assertion of legal sufficiency.
-Once the maintainer resolves the distribution approach, record that decision
-here before implementing its packaging mechanics.
+Retain the existing static Linux binaries and source repositories. The selected
+approach is repository-hosted license texts and attribution, with a
+`LICENSE | ATTRIBUTION` footer in each new release document and hosted release
+page. This is the maintainer's selected arrangement, not a general assertion
+that repository co-location satisfies every license or distribution model.
 
-1. Inventory licenses and notices for the selected module graph, including the
-   two catalog modules, against the actual tagged sources. Keep Scriptorium's
-   own license unchanged. Record dependency notices and license texts in a
-   maintained third-party location and link it from the appropriate user and
-   release documentation.
-2. For the recommended static-binary/source-material approach, provide an
-   accompanying versioned source/material archive tied to the exact candidate:
-   Scriptorium sources, selected dependency sources and license texts,
-   go.mod/go.sum, and instructions/toolchain information for rebuilding with
-   a modified Promptkit. Include additional materials required by the resolved
-   approach. Build this as a release artifact, not a committed vendor tree
-   or runtime replacement.
-3. Update the hosted workflow's asset selection/checksum generation to include
-   the chosen materials with the binaries. Preserve published-asset immutability
-   and consistent manifests on partial-upload recovery. Update the release
-   procedure's deliverable list and packaging instructions. Do not add CI
-   polling, consumer-installation checks, or routine human approval gates to
-   source publication.
-4. Exercise archive construction and the documented rebuild procedure locally
-   using prepared dependencies and no paid calls. Verify included versions,
-   source availability, notices, and association with the binary source
-   revision. Record what was actually validated, not a blanket legal guarantee.
-5. If the chosen approach differs, revise this stage's concrete packaging
-   steps before coding. A source-only approach must explicitly reconcile the
-   existing asynchronous-binary workflow; simply leaving automatic binary
-   publication enabled would not implement that decision.
+1. Add verbatim GPLv3 and LGPLv3 texts under `docs/oss/licenses/`, using
+   `GPL-3.0.txt` and `LGPL-3.0.txt`. Obtain the texts from the selected
+   Promptkit release's COPYING and license text; retain the complete license
+   text without folding Promptkit's project-specific preamble into the generic
+   LGPL file. Keep Scriptorium's own LICENSE unchanged.
+2. Add `docs/oss/attribution.md` with a Promptkit heading and three
+   attribution lines: `Copyright (C) 2026 Eric Rakestraw`;
+   `SPDX-License-Identifier: LGPL-3.0-or-later`, linked to the local LGPL
+   text; and a link to the Promptkit source repository. Link the corresponding
+   v0.11.0 tag as the source destination for this adoption. Make the companion
+   GPL text reachable from the document's general license-text navigation
+   without expanding the three-line Promptkit entry into a legal essay.
+3. Preserve any additional notices required for other distributed components,
+   including catalog dependencies, based on their actual selected licenses.
+   The agreed Promptkit entry does not determine other components' terms.
+   Keep attribution concise; do not add a dependency audit framework.
+4. Update the release policy and runbook to require the footer on future
+   release notes, with absolute URLs targeting that Scriptorium release tag's
+   root LICENSE and `docs/oss/attribution.md`. The visible text is
+   `LICENSE | ATTRIBUTION`. Update the last-updated date of any edited
+   policy, retaining its base template version. Do not edit published notes.
+5. Keep the checked-in release document as the source of the hosted release
+   body. The existing workflow already uses it; no new asset packaging or
+   separately maintained hosted notice is needed. During the next release
+   preparation, add the footer with the selected version. Do not invent a
+   release version or create a release solely to exercise this stage.
+6. Link the attribution document from README and assign ownership of
+   attribution/license files in the documentation policy. Check local license
+   links and the release-footer URL construction against the tagged-file
+   layout and existing note-to-hosted-body flow. A not-yet-published tag need
+   not resolve online before publication. Review the copied texts for fidelity.
+   No live publication or network-dependent release gate is required.
 
-Acceptance: the adoption-specific distribution question is resolved and the
-chosen materials/workflow exist and are tested. Do not publish upgraded
-binaries while it is unresolved. This is not a new recurring release signoff.
+The full Scriptorium and Promptkit sources, applicable permissions, and existing
+build materials are the basis for modification and recombination in this
+arrangement. Do not add a separate source/material archive, standalone license
+download assets, special modified-library rebuild instructions or verification
+exercise, dynamic linking, or a recurring legal-approval gate merely for this
+adoption. This does not excuse addressing an actual missing source/build
+material or a distinct dependency obligation if one is found.
+
+Acceptance: attribution and both license texts exist and are linked; future
+release preparation specifies the version-specific footer; the existing
+workflow carries that footer to the hosted page. Binary packaging, checksum
+behavior, source-publication completion, and historical releases stay intact.
+The broader upstream policy template remains separate future work.
 
 ## Stage 10: Verify The Integrated End State And Prepare The Handoff
 
@@ -462,30 +482,7 @@ publication still follows the existing release policy and requires authorization
 
 ## Open Questions
 
-### Which Distribution Approach Will Satisfy The Upgraded Dependency Licenses?
-
-The runtime interfaces above are settled for implementation. The outstanding
-decision is the applicable material/permission requirements for distributing
-Scriptorium's statically linked binaries with LGPL-3.0-or-later Promptkit and
-the other selected dependencies. The roadmap identified this as a prerequisite;
-this plan cannot establish legal sufficiency from a dependency version alone.
-
-**Recommended approach:** retain the current static Linux binary delivery and
-add a version-matched source/license/rebuild-material archive as outlined in
-Stage 9. Have the maintainer confirm the applicable requirements and whether
-those materials and permissions are sufficient before finalizing packaging.
-This preserves the established installation model and gives recipients an
-auditable route to rebuild with a modified library. It is an adoption-specific
-decision, not a proposal for a manual gate on every release.
-
-**Viable alternative:** defer upgraded binary distribution and deliver source
-only while the requirements are resolved. This avoids claiming that an
-unreviewed binary package is ready, but reduces installation convenience and
-requires an explicit change to the current binary-delivery workflow and its
-documentation. Another possible route is obtaining suitable additional
-distribution permission from the relevant rights holders; its availability
-must be confirmed, not assumed.
-
-**Impact:** settle this before Stage 9 and before any tag that would trigger
-upgraded binary distribution. No runtime implementation stage needs to wait,
-but the full distribution end state must remain incomplete until resolved.
+None currently. The previously open distribution question is resolved by
+Stage 9's repository-hosted attribution/license texts and release footer.
+Its implementation remains pending; resolution of the decision does not imply
+that the notices or footer already exist.