notarius/docs/roadmap/policy.md

# Licensing Policy And Attribution Alignment

## Purpose

Adopt the licensing-documentation conventions defined below 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 Notarius's current policy documents and pinned
dependencies. The table records the selected policy-version targets; repository
documentation must remain self-contained.

| Policy | Current Notarius baseline | Target version | 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 existing substantive rules. |

`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. 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 OSS House Format and maintenance rules defined below in
`docs/policy/oss.md`, adapted to Notarius. All links must resolve within this
repository or to public authoritative sources; no adjacent checkout is required.

Identify Notarius as an application with its already selected
`GPL-3.0-or-later` grant. Preserve the 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 base policy version and
actual adoption date. Do not add private provenance headers, links, or attribution
entries. Unchanged policies need no version or date churn.

### 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.1 and PromptKit v0.11.1;
- `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.20260926.0 revisions (now MIT licensed).

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 public authoritative sources,
such as the license publisher or the verified dependency release.
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.

Use the selected convention that direct links to project-specific
notices satisfy the notice-reproduction format. 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
hosted-page guidance 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 base policy version and actual adoption
  date, without private provenance; 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.