From 422a6887416d2845e02b01a05108fda53dd98666 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Sat, 26 Sep 2026 20:47:35 +0000 Subject: [PATCH] Document licensing policy adoption roadmap --- docs/roadmap/policy.md | 222 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 222 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 0000000..58e1ab5 --- /dev/null +++ b/docs/roadmap/policy.md @@ -0,0 +1,222 @@ +# 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 + +Align Audita's licensing documentation with the updated upstream policy set in +`../policy`, using its Open Source Licensing and Attribution Policy (base version +1.2) and the related documentation and release guidance. Adopt the licensing +changes deliberately while retaining Audita's existing policy adaptations. + +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 substantive upstream 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. + +## Targeted End State + +### Canonical Policy and Ownership + +Adopt `docs/policy/oss.md` from upstream base version 1.2, tailored to Audita's +selected grant and distribution. Remove template adoption instructions and +replace or remove template-only example and reference links. Retain the actual +base version and record the adoption date. + +The policy establishes the upstream 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. + +Merge the licensing-related ownership and boundary guidance from upstream +Documentation Policy 1.5 into 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. Record +upstream base versions truthfully alongside repository adaptations; unrelated +upstream 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 upstream 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. +``` + +Merge the licensing-related guidance from upstream Release Policy 1.2 into +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 + base-version metadata, and no leftover template setup instructions. +- 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.