From 7a7f12142f04983e71eff6e6b35fd7f74e70626b Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Sat, 26 Sep 2026 20:47:11 +0000 Subject: [PATCH] Plan licensing policy and attribution updates --- docs/roadmap/policy.md | 211 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 211 insertions(+) create mode 100644 docs/roadmap/policy.md diff --git a/docs/roadmap/policy.md b/docs/roadmap/policy.md new file mode 100644 index 00000000..28d45712 --- /dev/null +++ b/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.