Add open source licensing and attribution policy

docs/policy/documentation.md

@@ -1,8 +1,8 @@
 # Documentation Policy
 
-**Base Policy Version:** 1.3
+**Base Policy Version:** 1.4
 
-**Last Updated**: 2026-09-25
+**Last Updated**: 2026-09-26
 
 ## Base Policy Template
 
@@ -73,13 +73,17 @@ secret values.
 
 | Topic | Canonical owner | Owned content | Content owned elsewhere |
 | --- | --- | --- | --- |
-| Product orientation and minimal end-to-end quickstart | `README.md` | What this application 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 application 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, detailed change recipes. |
 | 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` | Implementation discipline for coding agents, including proportionality, idiomatic simplicity, and rules against inventing requirements, restrictions, guarantees, or repository policy. | Application contracts, architecture, testing policy, and contributor procedures. |
 | Documentation policy | `docs/policy/documentation.md` | Documentation ownership, audience boundaries, maintenance rules, and ADR/document lifecycle. | Application architecture or product behavior. |
 | Testing policy | `docs/policy/testing.md` | Test philosophy, risk-based sufficiency, test boundaries, doubles, coverage guidance, regression-test policy, and criteria for adding, rewriting, or deleting tests. | Subsystem behavior, application contracts, subsystem-specific test inventories, and implementation plans. |
 | Release policy | `docs/policy/release.md` | Versioning and compatibility rules, release integrity and immutability requirements, release-documentation policy, proportionate gate selection, publication controls, release completion, and the boundary between required checks and optional verification. | Repository-specific commands, product installation guidance, CLI version semantics, historical release summaries, and CI implementation detail. |
+| 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. |
 | Repository-specific release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, concrete validation and publication commands, automated publication guards, asynchronous deliverable publication, separate delivery status, optional consumer-facing verification, and failure recovery. | General release requirements, product installation guidance, historical release summaries, and current compatibility contracts. |
 | CLI contract (if applicable) | `docs/cli.md` | Commands, arguments, flags, invocation semantics, and exit codes. | End-to-end operating procedures, configuration field definitions, runtime filesystem layout, module implementation details. |
 | Configuration contract (if applicable) | `docs/config.md` | Discovery and precedence, file schema, fields, defaults, environment overrides, validation rules, and user-selectable module or validator keys. | Complete example files, CLI syntax, runtime state lifecycle, module implementation details. |
@@ -126,6 +130,13 @@ must change with the behavior it describes. Do not use a release procedure or
 release note to weaken policy, redefine current behavior, or defer required
 documentation updates.
 
+### 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,154 @@
+# Open Source Licensing And Attribution Policy
+
+**Base Policy Version:** 1.0
+
+**Last Updated**: 2026-09-26
+
+## Base Policy Template
+
+Repositories adopting this policy should:
+
+1. Identify the project's license location, source and release host, distribution
+   channels, and publication mechanism in the appropriate canonical documents;
+2. Connect the contributor reading guide to this policy for dependency,
+   attribution, and release-document changes;
+3. Record any concrete requirements outside the House Format that apply to the
+   project, with their reason and selected treatment;
+4. Update `Last Updated` to the adoption date, retaining the actual Base Policy
+   Version; and
+5. Remove this heading and its associated text.
+
+## 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 example, for a project with the stated
+license:
+
+```markdown
+PROJECT_NAME is licensed under the [LGPL v3.0 or later](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,8 +1,8 @@
 # Release Policy
 
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.2
 
-**Last Updated**: 2026-09-25
+**Last Updated**: 2026-09-26
 
 ## Base Policy Template
 
@@ -107,6 +107,12 @@ where useful. A release note must not substitute for current documentation.
 If annotated tags are used, derive their summary from the checked-in note
 rather than requiring a separately authored account of the same release.
 
+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.
+
 Version selection, release-note content, and retirement of completed roadmaps
 are preparation responsibilities, not separate human approval gates. Preserve
 planned and deferred work and repair affected links when retiring roadmaps.