promptkit/docs/roadmap/policy.md

# Licensing Documentation And Policy Alignment

**Status:** Accepted scope; not yet implemented.

## Purpose

Align Promptkit with the upstream standard's licensing-documentation guidance
without changing its selected license, runtime behavior, or source-only release
model. Make the project grant and dependency attribution easy to find and
maintain, with one canonical owner for each topic.

This roadmap defines the target and changes relative to the current baseline.
A separate implementation plan may define staged work later.

## Baseline

The reviewed upstream standard is the sibling `../policy` repository at commit
`dafa823`, including OSS policy version 1.2, documentation policy version 1.5,
and release policy version 1.2. These are adoption references, not a new runtime
dependency or a requirement to synchronize automatically with future revisions.

Promptkit's baseline is commit `1cd0c61`:

- [COPYRIGHT](../../COPYRIGHT) already identifies the project, copyright holder,
  LGPL-3.0-or-later grant, warranty disclaimer, and third-party material.
- [LICENSE](../../LICENSE) contains the LGPLv3 and incorporated GPLv3 texts.
  The reviewed standard-text comparison found only a missing final newline in
  the GPL portion; no substantive license-text replacement is needed.
- There is no `docs/policy/oss.md`, attribution document, or dependency license
  text collection.
- The [README](../../README.md#license) still refers to the removed `COPYING`
  file and describes the earlier license transition as applying from “this
  revision forward.” The working-tree [v0.11.0 notes](../releases/v0.11.0.md)
  also have a now-broken relative `COPYING` link.
- The [release policy](../policy/release.md) and
  [release procedure](../release.md) already use local validation and successful
  tag publication as the release completion point. No CI wait is required.

## Target End State

### A Customized OSS Policy

Add `docs/policy/oss.md`, adapted from the reviewed upstream policy. Retain the
actual base version, record the adoption date, and remove template instructions.
Identify Promptkit as an LGPL-3.0-or-later Go library whose source and tagged
releases are published on Gitea at `gitea.maximumdirect.net/eric/promptkit`.
Promptkit does not publish binaries or separate hosted release pages.

Preserve the author's selected grant and existing third-party terms. Policy
adoption is not relicensing. Do not require blanket per-file copyright headers,
advance copyright years automatically, or infer ownership of contributions.
Any final-newline normalization must leave both license texts unchanged in
substance. Do not recreate `COPYING` as a duplicate project-license owner.

Adopt the upstream House Format and its selected treatment of project-specific
notice links. Standard texts are local; project-specific notices link to the
exact imported upstream commit. Do not invent additional local-copy requirements
or repeatedly reopen that settled house interpretation. Preserve notices already
present in incorporated source. Surface concrete obligations or unresolved
rights questions not addressed by the format and record their selected treatment;
the format itself does not establish license compatibility.

### Canonical Attribution Materials

Create `docs/oss/attribution.md` with entries for relevant incorporated or
distributed components, including applicable transitive dependencies and copied
code/assets. Determine coverage from actual use and selected source versions,
not merely direct dependency status or common project ownership. Development
tools do not automatically need entries.

Each entry supplies the upstream project name, faithfully preserved copyright
statements, applicable SPDX expression, license/notice links, and a source link
at the exact commit corresponding to the imported version. Preserve alternatives
and exceptions; do not guess an SPDX identifier or silently choose unresolved
licensing terms. Moving branches and version tags are not substitutes for
commit-pinned component links.

Populate `docs/oss/licenses/` with only the required complete, verbatim standard
texts, including companion texts where applicable. Reuse shared texts across
entries, and make companion texts directly reachable. Inspect the selected
dependencies' actual notices before deciding which texts and entries are needed;
this roadmap does not preselect their licenses.

Maintain attribution in the same change that adds, removes, upgrades, copies, or
changes distribution of a relevant component. No dependency upgrades are needed
solely to adopt this documentation structure.

### Documentation Ownership And Navigation

Update the [documentation policy](../policy/documentation.md) to assign ownership
to the OSS policy, `COPYRIGHT`, `LICENSE`, attribution entries, and standard
dependency texts. Keep Promptkit's library-specific GoDoc, format, and consumer
documentation ownership intact. README and release notes provide navigation,
not competing licensing or attribution references.

Update the [contributor guide](../development.md) to route project licensing,
dependency/catalog, attribution, and release-document changes to the OSS policy
and affected canonical materials. Adopt relevant upstream guidance selectively;
do not replace the customized policy set wholesale or create placeholder docs.

End README with two friendly statements linking to the actual grant in
`COPYRIGHT` and the attribution document. Remove the stale transition wording
and obsolete `COPYING` reference. Do not expand the README into a legal checklist.

### Prospective Release Navigation

Update the release policy and procedure so each new checked-in release note ends
with links whose visible text is `COPYRIGHT | LICENSE | ATTRIBUTION`. Use absolute
Gitea URLs targeting those files at that release's immutable tag or corresponding
immutable source revision. The procedure owns concrete URL construction;
component attribution links continue to use imported commits, not release tags.

Promptkit's existing source-only publication channel remains sufficient. Its
annotated tag already derives from the checked-in release note; do not create a
hosted download page, separately maintained release body, or downloadable license
assets to adopt this convention. If a hosted page is deliberately introduced in
the future, preserve the note's footer there as required by the OSS policy.

Apply footer formatting prospectively. Do not retrofit published notes or move
published tags. Repair the current-branch v0.11.0 note's broken `COPYING` link by
pointing to that file in the immutable v0.11.0 source tree, where it exists. This
navigation correction does not alter the published release or add a new-format
footer to its historical note.

## Scope Boundaries

No runtime or public API changes, license/grant changes, dependency refresh,
new publication channel, or automatic policy synchronization. Preserve existing
release completion and compatibility choices, including catalog-data policy.
Adopting the licensing guidance does not authorize unrelated changes to release
note structure or existing validation gates.

Attribution preparation and affected-link/text review remain ordinary change
work. Do not add mandatory license scanners, an SBOM, recurring legal approvals,
publication-time network checks, CI polling, or extra release gates. Future-tag
links can be checked against candidate paths before the tag exists remotely.

The upstream architecture and testing clarifications about adopted constraints,
threat scope, and tests that must not invent contracts are a separate follow-up;
they are not part of this licensing-focused scope.

## Completion Criteria

The customized OSS policy and affected ownership/reading guidance agree; the
grant and license texts remain intact; relevant attribution entries and standard
texts are present and grounded in selected upstream source; README navigation
and the historical broken link are corrected; and future-release footer guidance
is usable through Promptkit's existing publication process. Affected local links,
standard-text fidelity, and commit-specific upstream destinations receive
proportionate validation without introducing permanent new release gates.