# 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: `, 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.