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:

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.