Adopt the standard OSS attribution policy

docs/policy/documentation.md

@@ -1,6 +1,6 @@
 # Documentation Policy
 
-**Base Policy Version:** 1.3
+**Base Policy Version:** 1.4
 
 **Last Updated:** 2026-09-26
 
@@ -71,7 +71,7 @@ secret values.
 
 | Topic | Canonical owner | Owned content | Content owned elsewhere |
 | --- | --- | --- | --- |
-| Product orientation and minimal end-to-end quickstart | `README.md` | What this project is, why it is useful, one shortest successful invocation, and links onward. | Complete command reference, configuration reference, operational procedures, implementation detail. |
+| Product orientation and minimal end-to-end quickstart | `README.md` | What this project is, why it is useful, one shortest successful invocation, and links onward, including license and attribution navigation. | Complete command reference, configuration reference, operational procedures, implementation detail. |
 | Contributor entry point | `docs/development.md` | Task-oriented reading guide, minimal contributor orientation, baseline validation commands, and links to canonical docs. | Package inventory, architecture rules, subsystem behavior, and detailed change recipes, which belong in the relevant internal component document. |
 | Application architecture policy | `docs/policy/architecture.md` | System shape, normative ownership, dependency direction, architectural boundaries, invariants, safety properties, and non-goals. | Concrete package inventory, implementation mechanics, contributor procedures, decision history, future work. |
 | Agent policy | `docs/policy/agents.md` | Agent implementation discipline, proportionality, idiomatic simplicity, local commit rules, and rules against inventing requirements, restrictions, guarantees, or repository policy. | Application contracts, architecture, testing policy, and contributor procedures. |
@@ -83,7 +83,10 @@ secret values.
 | Release policy | `docs/policy/release.md` | Versioning and compatibility, release integrity and immutability, documentation requirements, proportionate gates, publication controls, source completion, and optional verification boundaries. | Repository-specific commands, installation guidance, historical summaries, and CI implementation details. |
 | Release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, publication command and guards, asynchronous delivery, optional diagnostics, and failure recovery. | General release requirements, runtime operations, historical announcements, and current application contracts. |
 | Version-specific release notes | `docs/releases/` | Immutable release summaries, compatibility notices, and migration announcements for one published version. | Complete CLI, HTTP, configuration, operations, or dependency contracts. |
-| Open-source attribution and license texts | `docs/oss/attribution.md` and `docs/oss/licenses/` | Component notices, selected source links, and verbatim dependency license texts. | Scriptorium's own `LICENSE`, release preparation, or a duplicate dependency inventory in release notes. |
+| Open source licensing and attribution policy | `docs/policy/oss.md` | House attribution format, license-text and notice-link conventions, discoverability, maintenance, and handling of concrete exceptions. | Component entries, license texts, release commands, and dependency security review. |
+| Project license | `LICENSE` | The project's own license terms. | Upstream component attribution and dependency license texts. |
+| Upstream component attribution | `docs/oss/attribution.md` | Component names, copyright statements, license identification, and license, notice, and source links. | General attribution policy and complete standard license texts. |
+| Standard dependency license texts | `docs/oss/licenses/` | Complete, verbatim standard license texts shared by attribution entries where applicable. | Project-specific upstream notices, attribution prose, and policy interpretation. |
 | Public HTTP contract | `docs/api.md` | Routes, authentication, media types, request and response schemas, status codes, pagination, caching, idempotency, rate limits, and HTTP retry semantics. | Client walkthroughs, upstream or downstream integration internals, implementation detail. |
 | Consumer guidance | `docs/consumers/` | Choosing between Scriptorium's executable interfaces and understanding consumer responsibilities. | HTTP wire semantics, CLI syntax, Promptkit's Go package, and internal implementation detail. |
 | External and durable integration contracts | `docs/integrations/` | Scriptorium-owned process and executable integration contracts. | Promptkit framework formats and outbound provider protocols, physical runtime placement, internal transformations, CLI syntax, and configuration defaults. |
@@ -123,6 +126,13 @@ that release; current documentation changes with the behavior it describes.
 Neither a procedure nor a note may weaken policy or defer required updates to
 canonical contracts.
 
+### Open Source Attribution
+
+The [OSS policy](oss.md) defines the House Format and README and release-link
+conventions. Attribution entries own component-specific information. README
+and release documents provide navigation to those canonical materials; the
+release procedure owns URL construction and publication mechanics.
+
 ### Contracts And Implementation
 
 Integration and API documents define externally observable shapes and

docs/policy/oss.md

@@ -0,0 +1,139 @@
+# Open Source Licensing And Attribution Policy
+
+**Base Policy Version:** 1.1
+
+**Last Updated:** 2026-09-26
+
+## Purpose And Scope
+
+This policy establishes a repeatable House Format for open source attribution
+and license notices. It covers upstream components incorporated into or
+distributed with the project, including relevant transitive dependencies and
+copied code or assets. Treatment follows the component's terms and actual use,
+rather than its classification as a direct dependency.
+
+The baseline is a publicly available source repository with releases published
+alongside it. The format is independent of language, forge, and build system.
+It does not require attribution for every development tool, establish license
+compatibility, or resolve obligations beyond attribution and notice handling.
+
+## Canonical Locations
+
+The [documentation policy](documentation.md) assigns ownership:
+
+- `LICENSE` contains the project's own license. Dependency attribution does
+  not relicense the project.
+- `docs/oss/attribution.md` contains the canonical component entries.
+- `docs/oss/licenses/` contains complete, verbatim standard license texts,
+  including companion texts where applicable.
+
+Use recognizable license filenames, such as `Apache-2.0.txt` or `LGPL-3.0.txt`.
+A shared standard text may serve multiple entries. Keep explanations outside
+license texts and preserve distinct versions and exceptions.
+
+## House Format
+
+Each component entry has five fields:
+
+1. **Project name**, normally as the entry heading.
+2. **Upstream copyright statement or statements**, preserving their wording.
+3. **SPDX license identifier or expression**, when applicable.
+4. **License and notice links**, covering the applicable standard texts and
+   upstream project-specific material.
+5. **Source repository link**, identifying the source corresponding to the
+   imported version.
+
+Illustrative Markdown, with placeholders for the actual upstream information:
+
+```markdown
+## Example Library
+
+Copyright <upstream copyright statement>
+
+SPDX-License-Identifier: Apache-2.0
+
+License and notices: [Apache 2.0](licenses/Apache-2.0.txt) | [NOTICE](<upstream NOTICE URL at the imported commit>)
+
+Source: [Example Library](<upstream repository URL at the imported commit>)
+```
+
+These are five fields, not a line limit. Include multiple statements and links
+where needed. Omit the SPDX field when no applicable identifier exists; identify
+nonstandard terms accurately through the linked text. Preserve licensing
+alternatives and exceptions, and record a selected option when relevant. Do not
+invent an identifier or silently resolve an unsettled licensing choice.
+
+## License Texts And Upstream Links
+
+Link standard license texts to their local copies. Link project-specific
+notices to the upstream copies instead of storing them locally. Every upstream
+repository or notice link must identify the exact commit corresponding to the
+imported version, including the selected source revision for copied material.
+Do not use moving branches or version tags as substitutes for that commit.
+
+Classify material by its contents, not its filename. An upstream `LICENSE`,
+`COPYING`, or similar file may contain project-specific notices or exceptions
+in addition to standard wording. Link both the local standard text and the
+commit-specific upstream file when needed. Make companion license texts directly
+reachable from the entry rather than leaving readers to infer their location.
+
+For project-specific license and attribution material, this policy accepts
+direct links to the applicable upstream texts as satisfying reproduction,
+inclusion, or copy requirements. This is the adopted house interpretation.
+Agents must apply it without adding local-copy requirements or seeking repeated
+approval solely because a license uses those terms.
+
+This interpretation concerns notice reproduction. Concrete obligations such as
+marking modified files or supplying corresponding source receive their own
+applicable treatment. Preserve required notices already present in incorporated
+source files; the central attribution entry does not authorize stripping them.
+
+## Discoverability
+
+End the project's README with two friendly statements linking to its actual
+license and the attribution document. For Scriptorium:
+
+```markdown
+Scriptorium is licensed under the [BSD 3-Clause License](LICENSE).
+
+[Open Source attribution notices](docs/oss/attribution.md) are available.
+```
+
+Each new checked-in release document and its hosted download page must end
+with links whose visible text is `LICENSE | ATTRIBUTION`. Use absolute URLs to
+those files at the release's immutable tag or corresponding immutable source
+revision so the links work in both locations. This release navigation is distinct
+from upstream component links, which must use the imported commit.
+
+Reuse the checked-in release document as the hosted release body where supported.
+The release procedure owns concrete URLs and publication mechanics for delivering
+the links through the selected channel. Do not maintain duplicate notice lists.
+These conventions do not by themselves require separate downloadable license
+assets, source bundles, or a different binary package format.
+
+## Maintenance And Exceptions
+
+Update notices in the change that adds, removes, upgrades, copies, or changes
+the distribution of a relevant component. Check the selected source's license
+and notices rather than assuming they are unchanged. Update affected entries,
+commit links, and texts; retain historical versions through Git.
+
+Check affected statements, faithful standard-text copies, and link destinations
+as part of ordinary change review. For a future release tag, check intended file
+paths against the candidate source; the tag need not resolve remotely before
+publication. Do not add publication-time network checks, CI polling, recurring
+legal sign-offs, mandatory scanners, or a full software bill of materials merely
+to implement this policy.
+
+Use the House Format routinely. Raise an exception only for a concrete obligation
+or unresolved rights question it does not address, including any arising from a
+particular distribution channel. Record the issue and selected treatment in the
+adopted policy or affected attribution entry as appropriate. Resolve the issue
+before the affected use or distribution without reopening settled choices.
+Common ownership of projects is neither required nor a blanket exception.
+
+Apply the formatting convention prospectively. Do not rewrite published tags,
+notes, binaries, or checksums to retrofit it. Address actual omissions deliberately
+under the applicable terms and the [release correction policy](release.md#immutability-and-failure-recovery).
+Ordinary attribution maintenance and release links are preparation work, not new
+release approval gates.

docs/policy/release.md

@@ -1,6 +1,6 @@
 # Release Policy
 
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.2
 
 **Last Updated:** 2026-09-26
 
@@ -80,12 +80,11 @@ instructions. Keep the note proportionate to the change. Fixed sections and
 explicit no-action boilerplate are not required. Existing historical notes
 need not be rewritten to adopt this format.
 
-End each new release note with a `LICENSE | ATTRIBUTION` footer. Both links
-must be absolute URLs to files at that release's immutable Scriptorium tag:
-the root `LICENSE` and `docs/oss/attribution.md`, respectively. The checked-in
-note remains the source of the hosted release body, so this footer reaches the
-hosted page without a separately maintained notice. Do not retrofit published
-notes.
+Include the release footer defined by the [OSS policy](oss.md#discoverability)
+in each new release document and preserve it on the hosted download page. The
+release procedure defines the concrete URLs and publication mechanics. Prepare
+these links with the release note; they do not add a network check or approval
+gate.
 
 Keep exact current contracts in their canonical documents and update affected
 documentation with the behavior change. Link to those documents from the note