Align licensing documentation and adopt MIT catalogs

docs/policy/documentation.md

@@ -1,8 +1,8 @@
 # Documentation Policy
 
-**Base Policy Version:** 1.1
+**Base Policy Version:** 1.5
 
-**Last Updated:** 2026-09-23
+**Last Updated:** 2026-09-26
 
 ## Purpose
 
@@ -79,6 +79,11 @@ mechanisms, not secret values.
 | Documentation organization | `docs/policy/documentation.md` | Documentation ownership, audience boundaries, maintenance rules, and document lifecycle. | Library architecture or runtime behavior. |
 | Testing policy | `docs/policy/testing.md` | Test philosophy, risk-based sufficiency, test boundaries, doubles, coverage guidance, regression policy, and test maintenance. | Subsystem behavior, exact public contracts, subsystem-specific test inventories, and implementation plans. |
 | Release policy | `docs/policy/release.md` | Versioning, compatibility, release-note requirements, validation obligations, immutability, recovery, and adoption scope. | Executable commands, publication mechanics, and historical release summaries. |
+| Licensing and attribution policy | `docs/policy/oss.md` | Project licensing conventions, attribution format, text and notice-link rules, discoverability, maintenance, and concrete exceptions. | Component entries, license texts, release commands, and dependency security review. |
+| Project grant | `COPYRIGHT` | Project identity, holders and years, SPDX expression, grant, warranty disclaimer, and third-party statement. | Complete license texts and component attribution. |
+| Project license texts | `LICENSE` | Complete project license and incorporated companion texts. | General licensing policy and dependency attribution. |
+| Upstream attribution | `docs/oss/attribution.md` | Component names, copyright statements, license identification, and license, notice, and source links. | General policy and complete standard texts. |
+| Standard dependency license texts | `docs/oss/licenses/` | Complete, verbatim texts shared by attribution entries. | Project-specific notices, attribution prose, and policy interpretation. |
 | Release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, concrete publication guards and commands, verification, and recovery steps. | Release-policy requirements, public API semantics, and historical summaries. |
 | Exact exported Go API | Go declarations and GoDoc, as APIs are implemented | Exported names, signatures, types, values, errors, and exact behavioral contracts. | Task-oriented consumer walkthroughs, implementation details, and future API proposals. |
 | Framework file formats | `docs/formats.md` | Prompt-definition and profile YAML fields, schema references, defaults, validation modes, built-in profiles, credentials, and file-to-request precedence. | Exported Go declarations, outbound wire behavior, internal parsing mechanics, and application configuration. |
@@ -133,6 +138,14 @@ Adoption is prospective. Previously published tags and historical notes retain
 their original records and are not reformatted or rewritten to satisfy the new
 requirements.
 
+### Project Licensing And Attribution
+
+The [OSS policy](oss.md) owns licensing conventions, the attribution House
+Format, and README/release navigation. COPYRIGHT owns the project grant;
+LICENSE supplies complete texts. Component-specific information belongs in
+attribution entries, not parallel README or release-note notice lists. The
+release procedure owns concrete footer URLs and publication mechanics.
+
 ### Security Topics
 
 This policy owns what documentation and examples may contain. Architecture owns

docs/policy/oss.md

@@ -0,0 +1,135 @@
+# Open Source Licensing And Attribution Policy
+
+**Base Policy Version:** 1.2
+
+**Last Updated:** 2026-09-26
+
+Adapted from the standard policy; see [provenance and licensing](../oss/attribution.md#standard-repository-policies).
+
+## Purpose And Scope
+
+This policy defines Promptkit's project licensing conventions and House Format
+for upstream attribution. It covers relevant incorporated or distributed
+components, including transitive dependencies and copied code, documentation,
+or assets. Treatment follows the component's terms and actual use, not merely
+its direct-dependency status or common ownership. Development tools do not
+automatically require attribution.
+
+Promptkit is a Go library with an author-selected LGPL-3.0-or-later grant in
+[COPYRIGHT](../../COPYRIGHT). Its public source repository is
+`https://gitea.maximumdirect.net/eric/promptkit`; it publishes source-only Go
+module releases through annotated tags, not binaries or separate hosted release
+pages. The [release procedure](../release.md) owns publication mechanics.
+
+The House Format does not establish license compatibility or resolve every
+obligation arising from use or distribution. Adoption does not relicense
+existing material or override third-party terms.
+
+## Canonical Locations
+
+The [documentation policy](documentation.md) assigns ownership:
+
+- `COPYRIGHT`: project name, holders and years, SPDX expression, grant,
+  warranty disclaimer, and statement about third-party material.
+- `LICENSE`: complete, unmodified project license texts, including incorporated
+  companion text. Promptkit includes LGPLv3 followed by GPLv3.
+- `docs/oss/attribution.md`: canonical component entries.
+- `docs/oss/licenses/`: complete, verbatim standard dependency texts, including
+  companions where applicable. Shared texts can serve multiple entries.
+
+Keep explanations and project-specific notices outside standard texts. Preserve
+distinct versions and exceptions, using recognizable filenames.
+
+## Project Licensing
+
+The house defaults for new projects are GPL-3.0-or-later for applications and
+LGPL-3.0-or-later for libraries. An author's explicit choice takes precedence
+without an exception rationale, extra approval, or compensating controls.
+Promptkit retains its selected library grant; do not infer different licenses
+for individual packages or relicense existing code by adopting this policy.
+
+Keep COPYRIGHT, LICENSE, SPDX expressions, and README descriptions consistent.
+Use accurate holders and years; do not assume the maintainer owns every
+contribution or advance years automatically. Update grant, disclaimer, and text
+references together when the author deliberately changes licensing. Preserve
+third-party terms and required existing notices. No blanket per-file header
+requirement is introduced.
+
+## Upstream Attribution House Format
+
+Each component entry contains five fields:
+
+1. Project name, normally as the heading.
+2. Upstream copyright statements, preserving their wording.
+3. Applicable SPDX license identifier or expression.
+4. License and notice links.
+5. Source repository link at the exact imported commit.
+
+These are fields, not a line limit. Include multiple statements or links where
+needed. Do not invent absent copyright statements or SPDX identifiers. Describe
+nonstandard terms through their linked text, preserve alternatives and
+exceptions, and record a selected option when relevant. Do not silently resolve
+an unsettled licensing choice.
+
+## License Texts And Upstream Links
+
+Link standard texts to local copies. Link project-specific notices to the
+upstream copies at the exact commit corresponding to the imported version or
+copied material. Moving branches and version tags are not substitutes for
+commit-specific component links.
+
+Classify material by content, not filename: an upstream LICENSE or COPYING can
+mix standard text with project-specific notices or exceptions. Link both when
+needed. Make incorporated companion texts directly reachable from each entry.
+
+For project-specific license and attribution material, direct upstream links
+are accepted as satisfying reproduction, inclusion, or copy requirements under
+the adopted house interpretation. Do not add local-copy requirements or request
+repeated approval solely because a license uses those terms. This concerns
+notice reproduction, not other concrete obligations such as marking modified
+files or supplying corresponding source. Central entries do not authorize
+stripping required notices from incorporated source.
+
+## Discoverability
+
+End README with friendly statements linking to the actual grant in COPYRIGHT
+and to the attribution document. Each new checked-in release note ends with
+links whose visible text is `COPYRIGHT | LICENSE | ATTRIBUTION`, using absolute
+URLs at the release's immutable tag or corresponding immutable source revision.
+These release links differ from imported-component links, which use commits.
+
+The release procedure owns concrete URL construction. If a hosted download page
+is deliberately introduced, reuse the checked-in note and preserve its footer
+there. This convention does not require a new hosted page, downloadable license
+assets, source bundles, or another packaging format. Do not maintain duplicate
+notice lists.
+
+## Maintenance And Exceptions
+
+Update attribution in the change that adds, removes, upgrades, copies, or changes
+distribution of a relevant component. Inspect the selected source's actual
+licenses/notices rather than assuming they are unchanged. Update entries,
+commit links, and texts together; retain history through Git.
+
+Review affected statements, standard-text fidelity, and link destinations during
+ordinary change review. Future-release URLs can be checked against candidate
+paths before the tag exists remotely. Do not add publication-time network checks,
+CI polling, recurring legal sign-offs, mandatory scanners, or an SBOM just to
+implement this policy. Attribution maintenance is preparation, not a release gate.
+
+Raise exceptions only for concrete obligations or unresolved rights questions
+the House Format does not address, including distribution-specific issues.
+Record their selected treatment here or in the affected entry and resolve them
+before the affected use/distribution, without reopening settled choices.
+Common ownership is not a blanket exception. Adapted standard policy documents
+retain their upstream documentation license and identify modifications in their
+provenance entry; this does not change Promptkit's library grant.
+
+The maintainer-provided standard policy templates are internal and non-public.
+Their attribution entry identifies that source in prose and retains the
+applicable license locally; do not link to or require publication of the
+internal repository.
+
+Apply conventions prospectively. Do not rewrite published tags, notes, binaries,
+or checksums to retrofit formatting. Handle actual omissions deliberately under
+applicable terms and the [release correction policy](release.md#immutability-and-failure-recovery).

docs/policy/release.md

@@ -1,8 +1,8 @@
 # Release Policy
 
-**Base Policy Version:** 1.0
+**Base Policy Version:** 1.2
 
-**Last Updated:** 2026-09-23
+**Last Updated:** 2026-09-26
 
 ## Purpose And Adoption Scope
 
@@ -84,6 +84,11 @@ than maintaining a second summary.
 
 ## Validation And Publication
 
+New release notes prepared after the 2026-09-26 OSS-policy adoption end with
+the [licensing footer](oss.md#discoverability). The release procedure owns
+absolute, release-pinned URLs. This is prospective preparation work, not a new
+approval or network-validation gate; historical notes and tags are not reformatted.
+
 The [publication script](../../scripts/release.sh) runs the
 [local checks](../../scripts/release-check.sh) once for the final candidate.
 Retain clean-candidate, synchronized-main, unused-version, module-hygiene,