eric/scriptorium
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 9 Wiki Activity

Adopt the standard OSS attribution policy

Browse Source
This commit is contained in:
Eric Rakestraw
2026-09-26 16:36:45 +00:00
parent b399ebe391
commit 979697f19d
14 changed files with 350 additions and 303 deletions
Download Patch File Download Diff File Expand all files Collapse all files

233
docs/roadmap/policy.md
View File

@@ -1,194 +1,63 @@
# OSS Attribution Policy Roadmap
# OSS Policy Adoption
## Status And Purpose
## Status
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.
Completed on 2026-09-26. The upstream template work proposed here is now
available and adopted locally. This document records the adoption; the
[OSS policy](../policy/oss.md) is the canonical owner of the ongoing rules.
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.
The adopted baseline is the standard policy repository at commit
`eea8bcd21a964b395e31971077d7fddb445f2c28`:
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.
- OSS policy base version 1.1;
- documentation policy base version 1.4; and
- release policy base version 1.2.
## Intended Scope
Each affected policy records its base version and local update date. Template
adoption instructions were removed. Unchanged agent, architecture, and testing
policies retain their existing versions.
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.
## Adoption Outcome
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.
- [Documentation ownership](../policy/documentation.md) distinguishes the
project license, component entries, standard texts, and OSS policy.
- The [contributor guide](../development.md) routes dependency, copied-asset,
attribution, and release-document work to the OSS policy.
- [Component entries](../oss/attribution.md) cover the six selected direct and
transitive Go modules. Source and project-specific notice links identify the
imported commits. LGPL entries link directly to both LGPL v3 and GPL v3.
- Project-specific notices are linked upstream under the adopted house
interpretation. YAML's former local LICENSE and NOTICE copies were removed;
their history remains in Git. Missing upstream copyright statements are
identified in the affected entries rather than fabricated.
- The five applicable standard texts in `docs/oss/licenses/` match the upstream
reference collection byte-for-byte: GPL v3, LGPL v3, Apache 2.0, BSD 3-Clause,
and MIT. The reference collection documents their publisher/SPDX provenance.
Adoption removed a stray LGPL prefix, restored the complete Apache text,
separated the standard BSD text from the Go-specific notice, and added MIT.
- The [README](../../README.md) ends with friendly project-license and
attribution links. The [release policy](../policy/release.md) delegates footer
conventions to the OSS policy; the [release procedure](../release.md) retains
Scriptorium's immutable-tag URLs and existing hosted-body reuse.
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.
## Preserved Scope
## Canonical Files And Ownership
This adoption changes documentation and attribution, not Scriptorium's license,
dependencies, application architecture, or release machinery. Published notes,
tags, and assets remain unchanged. Existing source-release completion and
asynchronous binary-delivery behavior remain intact.
The proposed convention is:
There is no new publication-time network check, approval gate, scanner, source
bundle, downloadable license asset, or modified-dependency rebuild exercise.
Concrete exceptions continue to receive the treatment specified by the adopted
OSS policy; the house format is not a universal legal-sufficiency guarantee.
| 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. |
## Validation
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.
The standard texts were compared against the upstream reference collection.
The BSD reference intentionally retains its publisher's trailing space in the
copyright placeholder; it is not reformatted to satisfy a whitespace check.
Dependency commit references were resolved from Go module origin metadata or
the selected upstream tag, and affected local links and upstream attribution
destinations were checked. No runtime code, commands, or executable examples
changed.