scriptorium/docs/roadmap/policy.md

# OSS Attribution Policy Roadmap

## Status And Purpose

Proposed cross-project policy direction, based on the attribution and release
discoverability approach agreed for Scriptorium. This document replaces the
completed policy-template adoption roadmap, whose history remains in Git.
The existing documents under `docs/policy/` continue to govern the repository.

The target is a reusable OSS attribution policy template for the upstream policy
suite, with a locally adopted policy in each participating project. It should
standardize the location, content, discoverability, and maintenance of notices
without introducing a compliance platform or unnecessary release gates.

This is a roadmap for that template, not an adopted policy or a claim that
every project or license has identical obligations. Scriptorium's concrete
Promptkit work is defined in [implementation Stage 9](implementation.md#stage-9-add-oss-attribution-and-release-links).
Creating the upstream template and adopting it across projects are future work,
not changes made by this document.

## Intended Scope

The policy should cover attribution and license notices for OSS components
incorporated into or distributed with a project, including relevant transitive
dependencies and copied code or assets. A component's treatment follows its
actual license and how it is used or distributed, not merely whether it is
listed as a direct dependency.

The baseline arrangement is an openly available project source repository,
dependency source references, and releases published alongside that repository.
The template must remain independent of programming language, forge, build
system, and particular dependency. Promptkit, Go, and Gitea are local examples,
not upstream policy requirements.

This policy should not automatically require attribution for every tool ever
used in development, create a full software bill of materials, approve license
compatibility, or replace applicable license terms. Distinct requirements
arising from a component or distribution channel remain relevant; the baseline
must neither erase them nor invent additional ones.

## Canonical Files And Ownership

The proposed convention is:

| Location | Responsibility |
| --- | --- |
| `LICENSE` | The project's own license; dependency attribution does not relicense the project. |
| `docs/oss/attribution.md` | Canonical component attributions, applicable license identifiers, and upstream source links. |
| `docs/oss/licenses/` | Complete, verbatim license texts referenced by attribution entries, including companion texts when applicable. |
| `docs/policy/oss.md` | The eventually adopted local OSS attribution policy, derived from the upstream template. |
| Release documents and hosted release pages | Discoverability through links to the release's license and attribution files, not duplicate notice inventories. |

Use recognizable license filenames, such as `GPL-3.0.txt` and
`LGPL-3.0.txt`. A shared unmodified license text can serve multiple entries.
Distinct texts, exceptions, or component-specific required notices must not be
lost through deduplication. Keep license wording intact; explanations belong
in attribution or policy prose, not edits to license text.

A project's documentation policy owns the assignment of these canonical
locations. The OSS policy owns attribution conventions; the release policy
owns the footer requirement; the release procedure owns the concrete URL and
publication mechanics. Cross-references should avoid competing definitions.

## Attribution Entry Convention

Use a component heading or other clear identifier, followed by a concise entry:

1. The upstream copyright statement or statements, preserving the applicable
   wording rather than substituting the application's copyright holder.
2. `SPDX-License-Identifier: <identifier or expression>`, with a link to the
   corresponding local license text or texts.
3. A link to the component's source repository.

This is the standard compact form, not a three-line cap on notices that a
component actually requires. Preserve additional notices or exceptions where
applicable. Use the actual upstream license identification; do not invent an
SPDX identifier or silently choose between licensing alternatives when that
choice is unresolved. A nonstandard license should be identified accurately
and accompanied by its text.

Prefer a source link to the revision or release used by the project where
practical, so the source corresponding to a distribution is easy to locate.
Dependency manifests remain useful version records; do not duplicate a
complete lockfile in the attribution document. A source link does not replace
a copyright notice or a license-text copy.

Make companion license texts reachable through concise document navigation.
For example, an LGPL entry may link its SPDX line to the local LGPL text while
the document also exposes the incorporated GPL text. Readers should not need
to infer where that companion document is stored.

## Release Discoverability

Each new checked-in release document and its hosted download page should end
with two links whose visible text is:

`LICENSE | ATTRIBUTION`

The first links to the project's own license; the second links to the
attribution document. Use absolute URLs to the files at that release's
immutable tag or corresponding immutable source revision, not a moving default
branch. The links should work both when viewing the release document in the
repository and when viewing its rendered body on the download page.

Where publication already derives the hosted release body from the checked-in
document, preserve that single source. Do not maintain a second notice list
or footer by hand. Where a platform uses a different mechanism, the local
release procedure specifies how the same links reach recipients.

The attribution document links onward to dependency sources and checked-in
license texts. Under this selected repository-hosted arrangement, the policy
does not additionally require separate downloadable license assets, a combined
source archive, or a new binary package format by default. Different channels,
such as offline distribution or a package registry without the repository's
release page, need treatment appropriate to that channel and its actual terms;
the footer convention is not a universal legal-sufficiency guarantee.

Apply the convention prospectively. Do not rewrite published notes, tags,
binaries, or checksums to retrofit the footer. Follow the project's existing
release correction policy for an actual defect in published material.

## Source Availability And Proportionality

The intended baseline makes the project's source and relevant dependency
sources available with permissions and existing build materials that enable
modification and combination. Attribution identifies where those sources can
be obtained.

Do not automatically add a special modified-dependency rebuild tutorial,
verification exercise, relinking harness, source-bundle build, or dynamic-linking
migration when the existing sources, permissions, and build materials already
enable that work. If something actually needed is missing, address that gap
rather than assuming either that all source links suffice or that extra
machinery is always mandatory.

Common ownership of two projects may affect their particular licensing
position, but is not a prerequisite or blanket exception in the reusable
policy. Other dependencies and future contributors can have different owners
and terms. The upstream template should encode the attribution practice, not
depend on Scriptorium and Promptkit sharing a copyright holder.

## Maintenance And Validation

Maintain notices as part of the change that adds, removes, upgrades, copies,
or changes the distribution of a relevant component. Check its selected
source's notices and license, update affected entries/texts, and preserve useful
history through version control rather than retaining misleading current
entries. Do not assume that a dependency's license is unchanged across versions.

Proportionate review covers:

- accurate component identification, notices, and license references;
- faithful copies of the required texts;
- working local links and source references appropriate to the selected version;
- release footer destinations matching the intended release's file layout; and
- preservation of the footer by the existing publication mechanism.

A future release tag need not be remotely resolvable before it is published.
Validate its intended paths against the candidate source. Do not turn link
checking into a publication-time network gate, CI polling loop, or recurring
manual legal signoff. Dedicated scanners, exhaustive dependency inventories,
and new compliance tooling are not required by this baseline; add machinery
only for a concrete unmet need.

Resolve an actual uncertainty about rights, missing materials, or applicable
terms explicitly. Ordinary notice maintenance should not require repeated
approval of an already selected distribution approach. This policy supplements,
rather than replaces, normal dependency review and the project's release policy.

## Upstream Template And Local Adoption Target

The eventual upstream template should contain the general conventions above,
with no Scriptorium-specific paths beyond the shared documentation convention,
no Promptkit version pin, and no assumptions about Gitea URL syntax. Its
adoption guidance should ask each project to identify its license location,
source/release host, distribution channels, and publication mechanism.

Follow the existing suite's provenance convention when the template is
versioned and adopted: the local policy has a Base Policy Version and a
Last Updated date immediately below its title. Record the real template version
and local adoption date; do not invent a base version for this proposal.
Template-only adoption instructions are removed from locally adopted policies.

Coordinate the upstream documentation and release templates so they recognize
the OSS policy and its canonical files without duplicating its detailed rules.
Locally, connect the contributor reading guide to the OSS policy for dependency,
attribution, and release-document changes. These are documentation/policy
integration changes, not an application architecture migration.

Completion of this roadmap means a reusable template exists, the relevant suite
cross-references agree, and local adoption can produce clear notices and
release links without speculative guarantees or unnecessary machinery.
Scriptorium may implement its already-agreed Stage 9 before that upstream
template is created; the template's availability is not a release prerequisite.