Plan licensing policy and attribution updates

docs/roadmap/policy.md

@@ -0,0 +1,211 @@
+# Licensing Policy And Attribution Alignment
+
+## Purpose
+
+Align Notarius with the upstream licensing-documentation standards while
+preserving its deliberate policy adaptations, existing project grant, and
+source-only release process. This is a documentation and policy work set, not
+a relicensing, runtime, or release-automation project.
+
+This feature roadmap defines the target end state and required changes. It does
+not implement the policy or authorize release publication.
+
+## Reviewed Baseline
+
+Reviewed on 2026-09-26 against upstream `policy` commit
+`dafa823981004d4d58a5eb1b59a84ffebbd979da`, available in `../policy`.
+Notarius's existing policies record upstream baseline
+`45591a79004c6811950f14dca554f6ff69b7f58e`.
+
+| Policy | Current Notarius baseline | Target upstream baseline | Required change |
+| --- | --- | --- | --- |
+| `docs/policy/oss.md` | Absent | 1.2 | Adopt the licensing and attribution policy with Notarius-specific adaptation. |
+| `docs/policy/documentation.md` | 1.3 | 1.5 | Merge licensing ownership and discoverability rules. |
+| `docs/policy/release.md` | 1.1 | 1.2 | Add prospective release-footer guidance without new publication gates. |
+| Agents, architecture, testing | 1.1 | 1.1 | Retain; these upstream templates have not changed since the recorded baseline. |
+
+`COPYRIGHT` already identifies Notarius, its copyright statement, and the
+`GPL-3.0-or-later` grant, including the warranty disclaimer and third-party
+material statement. `LICENSE` contains the matching GPLv3 text. Comparison with
+upstream's reference text found only a missing final newline; no substantive
+license-text change is required.
+
+Current gaps are the absent `docs/oss/` attribution materials, missing README
+licensing navigation, missing contributor routing to an OSS policy, and missing
+release-footer instructions. `docs/integrations/pkg-promptkit.md` currently
+contains a dependency-license paragraph but is not a canonical attribution
+inventory.
+
+## Target End State
+
+### Policy Alignment Without Policy Replacement
+
+Adopt the upstream OSS House Format and maintenance rules in
+`docs/policy/oss.md`. Remove template-adoption instructions and adapt or replace
+template-only example/reference links so the adopted document has no broken
+links or dependencies on an adjacent checkout. There is no need to import the
+template's example project directories.
+
+Identify Notarius as an application with its already selected
+`GPL-3.0-or-later` grant. Preserve the upstream distinction between licensing
+defaults and explicit author choices: adopting the policy does not change
+existing grants, infer different licenses for internal packages, automatically
+advance copyright years, or assume ownership of third-party contributions.
+
+Merge the new documentation ownership rows and licensing boundary guidance into
+Notarius's adapted documentation policy. Merge the release-footer provision
+into its adapted release policy. Do not replace either document wholesale.
+Preserve subprocess-consumer ownership, prospective/current documentation
+boundaries, immutable accepted ADRs, and the distinction between descriptive
+implementation details and adopted policy.
+
+Changed or newly adopted policies must record their actual upstream template
+version, the upstream commit above, and the actual adoption date. Unchanged
+policies need no version or date churn merely because the upstream repository
+has advanced.
+
+### Canonical Licensing Documentation
+
+| Path | Target responsibility |
+| --- | --- |
+| `COPYRIGHT` | Existing project identity, copyright statement, SPDX expression, grant, disclaimer, and third-party scope statement. |
+| `LICENSE` | Existing complete project license text. |
+| `docs/policy/oss.md` | Licensing conventions, attribution format, maintenance, discoverability, and treatment of concrete exceptions. |
+| `docs/oss/attribution.md` | Canonical component-specific attribution entries. |
+| `docs/oss/licenses/` | Applicable complete, verbatim standard dependency license texts, including required companion texts. |
+| `README.md` | Friendly navigation to the project grant and attribution. |
+| `docs/development.md` | Task-specific routing for licensing, dependency, attribution, and release-document changes. |
+| `docs/release.md` | Concrete release-footer URLs and preparation instructions for Notarius's existing publication channel. |
+
+Retain the substance of `COPYRIGHT` and `LICENSE`. Adding a missing final newline
+is optional formatting cleanup, not relicensing or a prerequisite to adoption.
+
+### Attribution Based On Actual Incorporated Components
+
+Inventory relevant direct and transitive dependencies and copied code/assets.
+Use `go.mod`, the resolved dependency/build graph, pinned module contents, and
+repository evidence to identify scope; do not treat either direct dependencies
+alone or every `go.sum` entry as the complete attribution inventory. Development
+tools do not automatically require entries merely because maintainers use them.
+
+The current module declarations identify these starting points:
+
+- ConfigKit v0.4.0 and PromptKit v0.11.0;
+- `github.com/santhosh-tekuri/jsonschema/v6` v6.0.2;
+- `golang.org/x/text` v0.40.0;
+- `gopkg.in/yaml.v3` v3.0.1 and `go.yaml.in/yaml/v4` v4.0.0-rc.6;
+- PromptKit's OpenRouter and Rakestrawhome backend catalogs at their pinned
+  v2.20260922.1 and v2.20260922.0 revisions, respectively.
+
+This list is an inspection starting point, not a pre-approved license inventory.
+Verify each relevant component's terms, notices, and exact source revision at
+the imported version; do not infer them from a newer sibling checkout or common
+project ownership. Inspect copied material separately from Go module imports.
+
+Each attribution entry follows the five-field House Format:
+
+1. Project name.
+2. Upstream copyright statement or statements, preserving their wording.
+3. Applicable SPDX identifier or expression, preserving alternatives/exceptions.
+4. License and notice links.
+5. Corresponding source repository link.
+
+Copy only applicable standard license texts from the upstream reference
+collection, or an authoritative source if the collection lacks a needed text.
+Preserve them verbatim and keep explanations outside the texts. Shared standard
+texts may serve multiple entries. Include directly reachable companion texts;
+for example, an LGPLv3 entry must link to both LGPLv3 and GPLv3 texts.
+
+Component source and project-specific notice links must identify the exact
+imported commit, not a branch or version tag. Determine those commits from
+authoritative module/VCS metadata; do not guess them. Classify upstream files
+by their contents: `LICENSE` or `COPYING` can contain project-specific statements
+as well as standard wording.
+
+Follow upstream's adopted interpretation that direct links to project-specific
+notices satisfy its notice-reproduction convention. Do not add local copies or
+repeated approval requirements solely because license language refers to
+reproduction or inclusion. Preserve notices already present in incorporated
+source. Concrete obligations or unresolved rights questions outside this
+convention receive their own documented treatment; the formatting policy is not
+a blanket license-compatibility determination.
+
+### Discoverability And Maintenance
+
+End README with these links, consistent with the existing project grant:
+
+```markdown
+Notarius is licensed under the [GPL v3.0 or later](COPYRIGHT).
+
+[Open Source attribution notices](docs/oss/attribution.md) are available.
+```
+
+Add a contributor reading-guide entry that routes licensing, dependency,
+attribution, and release-document changes to `docs/policy/oss.md` and the relevant
+canonical materials. Update component entries in the same change that adds,
+removes, upgrades, copies, or changes distribution of a relevant component.
+
+The PromptKit integration guide should link to its canonical attribution entry
+instead of maintaining a competing notice inventory. Keep integration behavior
+and pinned API documentation in that guide; the exact-commit rule for attribution
+links does not require rewriting unrelated API-reference links.
+
+### Prospective Release Navigation
+
+New release notes end with links whose visible text is
+`COPYRIGHT | LICENSE | ATTRIBUTION`, using absolute URLs to the corresponding
+Notarius files at the immutable release tag or source revision. Unlike upstream
+component attribution links, these release-navigation links may use the release
+tag.
+
+`docs/release.md` supplies a copyable footer using Notarius's Gitea repository
+and the selected release version. Check intended paths against the candidate
+source during preparation; an unpublished tag need not resolve remotely yet.
+
+Notarius continues publishing source through lightweight Git tags and checked-in
+release notes. It has no hosted release objects or separate download pages, so
+the upstream hosted-page provision is currently inapplicable. Do not create
+another publication channel to satisfy it. Preserve branch-before-tag order,
+the existing validation command, and successful tag push as release completion.
+
+Apply the formatting convention prospectively. Do not rewrite historical notes,
+published tags, or accepted ADRs merely to retrofit navigation. Handle any actual
+omission discovered during inventory deliberately under the applicable policy,
+not by changing published history.
+
+## Scope Boundaries
+
+- No application-code or dependency-version changes are needed for this work.
+- No substantive rewrite of the existing project grant is proposed.
+- No new ADR is needed merely to adopt these explicit policy choices.
+- No mandatory license scanner, SBOM, blanket per-file header sweep, recurring
+  legal sign-off, or full dependency security audit is introduced.
+- No publication-time network check, CI polling, extra approval gate, binary
+  packaging, or release-script redesign is introduced.
+- Do not copy unused standard license texts or create placeholder documentation.
+- Do not weaken or strengthen unrelated Notarius invariants and operator choices.
+
+## Acceptance And Verification
+
+- The adopted OSS policy, documentation policy 1.5, and release policy 1.2 agree
+  on canonical ownership and preserve Notarius's deliberate adaptations.
+- Policy metadata identifies the reviewed upstream baseline and actual adoption
+  date; unchanged policies retain their existing metadata.
+- Project licensing statements remain consistent with `GPL-3.0-or-later`.
+- Attribution covers the relevant incorporated components identified by the
+  inventory, including applicable transitive dependencies and copied material.
+  Entries preserve upstream statements and use verified exact-commit links.
+- Applicable local standard texts are complete and faithful, with companion
+  texts directly reachable from their entries. No unrelated license bundle is
+  imported.
+- README, contributor guidance, integration references, and the release runbook
+  link to canonical materials without duplicating the attribution inventory.
+- New-release footer instructions work with the existing source-only workflow;
+  historical releases and publication mechanics are unchanged.
+- Review edited relative links, source/notice destinations, SPDX expressions,
+  and standard-text comparisons, and run `git diff --check`. This documentation
+  change does not itself warrant production model runs or new runtime tests.
+
+There are no blocking design decisions at the reviewed baseline. Any concrete
+unresolved upstream notice or rights issue found during inventory should be
+recorded with its evidence rather than resolved by an invented blanket rule.