audita/docs/roadmap/policy.md

# Licensing Policy Adoption

**Last updated:** 2026-09-26

**Status:** Accepted direction; adoption work remains to be implemented. This
roadmap defines the target and scope, not a staged implementation plan.

## Purpose

Establish self-contained licensing and attribution documentation for Audita,
using the House Format defined below. Keep licensing, documentation ownership,
and release guidance consistent while retaining Audita's existing policies.

Audita's selected grant is already GPL-3.0-or-later. This work documents that
choice and the applicable upstream attribution; it does not reconsider the
license, change application behavior, or replace the entire policy suite.

## Current Baseline

As of commit `982b595`:

- [COPYRIGHT](../../COPYRIGHT) contains the project identity, copyright,
  GPL-3.0-or-later SPDX expression and grant, warranty disclaimer, and third-party
  statement. [LICENSE](../../LICENSE) contains the full GPLv3 text. These already
  follow the selected project licensing convention and need no substantive revision.
- There is no `docs/policy/oss.md`, canonical `docs/oss/attribution.md`, or local
  dependency license-text collection.
- The [documentation policy](../policy/documentation.md) lacks ownership and
  boundary rules for licensing documents. The [contributor guide](../development.md)
  lacks a licensing and attribution reading path.
- The [README](../../README.md) does not end with the prescribed project-license
  and attribution statements.
- The [release policy](../policy/release.md) and [release procedure](../release.md)
  do not specify the licensing footer. The tag-triggered
  [release workflow](../../.woodpecker/release.yml) publishes Linux binaries and
  checksums, but does not explicitly use the checked-in release note as its
  hosted release body.
- Dependencies include ConfigKit, PromptKit and its backend packages, YAML and
  JSON Schema libraries, and other transitive modules. A complete inventory of
  relevant components, exact source revisions, and applicable notices has not yet
  been established; `go.mod` alone is not that inventory.

Audita publishes source and releases through its Gitea repository. Linux amd64
and arm64 are the supported production targets; macOS arm64 remains best-effort
for local development. Successful release completion remains the successful
push of the release source and tag, without waiting for CI asset publication.

## Reviewed Dependency Updates

ConfigKit v0.4.1 and PromptKit v0.11.1 are now selected. Both make their
LGPL-3.0-or-later grant explicit in `COPYRIGHT` and provide the LGPLv3 and
incorporated GPLv3 texts together in `LICENSE`. Neither changes library code.
PromptKit also selects MIT-licensed OpenRouter and Rakestrawhome catalogs at
v2.20260926.0; those catalog updates leave Go code and profile data unchanged.

Use the selected public source revisions as the starting points for their
attribution entries:

- ConfigKit v0.4.1: `0adb94f59e44827908eff401d4381a398fe17107`.
- PromptKit v0.11.1: `15e40679546f2e21b6f51cc84b6f0a087a8486db`.
- OpenRouter catalog v2.20260926.0: `4f731d217e0bc39151c010f50fb5912706e7b6b3`.
- Rakestrawhome catalog v2.20260926.0: `48918a3ad39fd99843cda94a86133b1b3881d596`.

Inspect the selected components directly. Dependency attribution documents can
help locate relevant notices, but should not be copied wholesale: Audita's
inventory reflects material actually incorporated into or distributed with Audita.

## Targeted End State

### Canonical Policy and Ownership

Create `docs/policy/oss.md` for Audita's selected grant and distribution, using
the requirements in this roadmap. Make it self-contained, with references to
Audita's canonical documents and public component sources. Record its adoption
date and appropriate policy version metadata.

The policy establishes the House Format, maintenance responsibilities,
and treatment of concrete exceptions. It identifies the settled project grant
and routes readers to the canonical documents for source hosting and release
publication mechanics. It does not infer separate licenses for Audita packages.

Add the following licensing ownership and boundary guidance to the local
documentation policy:

| Document | Owned content |
| --- | --- |
| `docs/policy/oss.md` | Licensing conventions, attribution format, maintenance, and concrete exceptions. |
| `COPYRIGHT` | Project identity, copyright statements, SPDX expression, grant, disclaimer, and third-party statement. |
| `LICENSE` | Complete, unmodified project license text. |
| `docs/oss/attribution.md` | Relevant component attribution entries. |
| `docs/oss/licenses/` | Complete, verbatim applicable standard license and companion texts. |
| `docs/release.md` | Concrete immutable release-link URLs and publication mechanics. |

The contributor guide directs licensing, dependency, copied-code or asset,
attribution, and release-document changes to the appropriate policy and owner.
Preserve existing documentation ownership, agent commit and discovery rules,
and Audita's retirement of standalone troubleshooting documentation. Keep
policy version metadata accurate; unrelated policy changes are outside this
adoption scope.

### Relevant Attribution and License Texts

Create a canonical inventory covering upstream components incorporated into or
distributed with Audita: relevant direct and transitive dependencies, copied code
or assets, and applicable Go runtime notices. Determine inclusion from actual use
and distribution, not merely presence in `go.mod` or classification as direct or
indirect. Do not automatically include every development tool or test-only module.

Each component entry uses the five-field House Format:

1. Project name.
2. Upstream copyright statements, preserving their wording.
3. Applicable SPDX identifier or expression, when one exists.
4. Links to applicable local standard texts and upstream project-specific notices.
5. A source repository link identifying the exact imported commit.

Resolve component versions to their actual source commits. Upstream source and
notice links use those commits, not version tags or moving branches. Preserve
multiple copyright statements, licensing alternatives, and exceptions; record a
selected licensing option when relevant without inventing an SPDX identifier.

Copy only applicable standard license texts and required companion texts into
`docs/oss/licenses/`. Preserve complete wording and use recognizable filenames;
multiple entries can share a text. Make companions directly reachable from each
relevant entry, including GPLv3 where an LGPLv3 entry requires it. Inspect upstream
file contents rather than assuming a file named `LICENSE` contains only standard
wording.

Apply the selected house interpretation accepting direct, commit-specific links
for project-specific license and attribution notice reproduction. Do not add a
blanket local-copy requirement or repeated approval solely because upstream terms
use reproduction, inclusion, or copy language. Preserve required notices already
present in incorporated source. Concrete obligations beyond notice reproduction,
such as source supply or modified-file marking, receive their own applicable
treatment and are recorded in the policy or affected entry when needed.

This inventory and format do not themselves certify license compatibility or
resolve every possible distribution obligation. Resolve concrete uncovered
issues before the affected use or distribution; do not reopen settled choices
without such an issue.

### Discoverability and Release Publication

End the README with these two statements:

```markdown
Audita is licensed under the [GPL v3.0 or later](COPYRIGHT).

[Open Source attribution notices](docs/oss/attribution.md) are available.
```

Add the following licensing navigation requirements to Audita's release policy.
Each new checked-in release note and its hosted download page ends with links visibly labeled `COPYRIGHT | LICENSE | ATTRIBUTION`.
Use absolute Gitea URLs to the three canonical files at the release's immutable
tag or corresponding immutable source commit. This differs from dependency
attribution links, which identify the exact imported upstream commit.

The release procedure owns the concrete URL pattern and how publication delivers
that footer. Reuse the checked-in release note as the hosted release body through
the release workflow where supported, avoiding separately maintained notice
lists or release prose. Verify the publication plugin's supported configuration
when implementing that integration; if it cannot consume the note directly, use
the smallest supported publication mechanism that preserves the same content.

Validate future-tag paths against the candidate checkout during ordinary release
preparation. A future tag need not already resolve remotely. Keep release success
at source/tag push and treat asynchronous publication failures under the existing
release correction procedure.

### Ongoing Maintenance and Published History

Update affected attribution, source commits, and license texts alongside changes
that add, remove, upgrade, copy, or change distribution of relevant components.
Check the selected upstream source instead of assuming notices are unchanged.
Git retains previous attribution versions.

Apply the new presentation convention prospectively. Do not retrofit v2.0.0 or
older published tags, notes, binaries, or checksums. Current licensing statements
do not change the grant recorded in an older tagged source tree. Any concrete
historical omission discovered during inventory should receive deliberate
handling under its applicable terms and Audita's release correction policy.

## Work Required

- Adopt and tailor the OSS policy; merge related documentation ownership and
  release guidance while retaining Audita-specific decisions.
- Inspect actual incorporated and distributed components, establish their source
  revisions and notices, and create attribution entries and applicable texts.
- Add contributor navigation and the README statements once their destinations
  exist.
- Extend the release procedure with the immutable footer convention and connect
  hosted release content to the checked-in note through the publication workflow.
- Review affected links, standard-text fidelity, attribution evidence, policy
  references, and consistency with the existing release process. Validate the
  publication configuration at its affected boundary without creating a release
  solely to test this documentation change.

These are work areas, not an implementation sequence. Policy and attribution
content form one coherent area; release publication integration is another.
Detailed implementation steps can be planned separately.

## Acceptance Criteria

- Audita has an adopted OSS policy with working repository references, accurate
  version metadata, and self-contained repository-specific guidance.
- Documentation ownership and contributor navigation identify the canonical
  licensing documents without duplicating their substantive content.
- Relevant incorporated and distributed components have evidence-based House
  Format entries, exact imported-commit links, and applicable standard and
  companion texts. Concrete uncovered obligations have a recorded treatment.
- The existing project grant and full license text remain consistent; no
  relicensing or unsupported claims of ownership are introduced.
- The README ends with the license and attribution statements.
- Future release preparation produces the immutable licensing footer in both the
  checked-in note and hosted body, with one maintained source for that content.
- Affected local links, intended future-tag paths, text copies, and publication
  configuration are checked with validation proportionate to the change.
- Published history and Audita's existing platform scope and release-success
  definition remain intact.

## Scope Boundaries

This work introduces no mandatory scanner, full software bill of materials,
recurring legal sign-off, additional human approval, publication-time network
check, or CI wait. Ordinary attribution maintenance and release-document review
are preparation work, not new release gates.

The formatting convention alone does not require separate downloadable license
assets, source bundles, or a different binary package format. A concrete component
obligation may need specific treatment, but is not a basis for inventing blanket
requirements. No application code, dependency upgrade, prompt change, or general
policy-suite rewrite is part of this feature.

## Open Questions

No product or policy decisions remain open for this scope. Component-specific
source revisions and notices, and the publication plugin's supported release-body
mechanism, require verification during implementation. These are factual follow-up
work, not additional approval gates; raise a decision only if that verification
reveals a concrete unresolved obligation or a material publication tradeoff.