scriptorium/docs/policy/oss.md

Open Source Licensing And Attribution Policy

Base Policy Version: 1.1

Last Updated: 2026-09-26

Purpose And Scope

This policy establishes a repeatable House Format for open source attribution and license notices. It covers upstream components incorporated into or distributed with the project, including relevant transitive dependencies and copied code or assets. Treatment follows the component's terms and actual use, rather than its classification as a direct dependency.

The baseline is a publicly available source repository with releases published alongside it. The format is independent of language, forge, and build system. It does not require attribution for every development tool, establish license compatibility, or resolve obligations beyond attribution and notice handling.

Canonical Locations

The documentation policy assigns ownership:

• LICENSE contains the project's own license. Dependency attribution does not relicense the project.
• docs/oss/attribution.md contains the canonical component entries.
• docs/oss/licenses/ contains complete, verbatim standard license texts, including companion texts where applicable.

Use recognizable license filenames, such as Apache-2.0.txt or LGPL-3.0.txt. A shared standard text may serve multiple entries. Keep explanations outside license texts and preserve distinct versions and exceptions.

House Format

Each component entry has five fields:

1. Project name, normally as the entry heading.
2. Upstream copyright statement or statements, preserving their wording.
3. SPDX license identifier or expression, when applicable.
4. License and notice links, covering the applicable standard texts and upstream project-specific material.
5. Source repository link, identifying the source corresponding to the imported version.

Illustrative Markdown, with placeholders for the actual upstream information:

## Example Library

Copyright <upstream copyright statement>

SPDX-License-Identifier: Apache-2.0

License and notices: [Apache 2.0](licenses/Apache-2.0.txt) | [NOTICE](<upstream NOTICE URL at the imported commit>)

Source: [Example Library](<upstream repository URL at the imported commit>)

These are five fields, not a line limit. Include multiple statements and links where needed. Omit the SPDX field when no applicable identifier exists; identify nonstandard terms accurately through the linked text. Preserve licensing alternatives and exceptions, and record a selected option when relevant. Do not invent an identifier or silently resolve an unsettled licensing choice.

License Texts And Upstream Links

Link standard license texts to their local copies. Link project-specific notices to the upstream copies instead of storing them locally. Every upstream repository or notice link must identify the exact commit corresponding to the imported version, including the selected source revision for copied material. Do not use moving branches or version tags as substitutes for that commit.

Classify material by its contents, not its filename. An upstream LICENSE, COPYING, or similar file may contain project-specific notices or exceptions in addition to standard wording. Link both the local standard text and the commit-specific upstream file when needed. Make companion license texts directly reachable from the entry rather than leaving readers to infer their location.

For project-specific license and attribution material, this policy accepts direct links to the applicable upstream texts as satisfying reproduction, inclusion, or copy requirements. This is the adopted house interpretation. Agents must apply it without adding local-copy requirements or seeking repeated approval solely because a license uses those terms.

This interpretation concerns notice reproduction. Concrete obligations such as marking modified files or supplying corresponding source receive their own applicable treatment. Preserve required notices already present in incorporated source files; the central attribution entry does not authorize stripping them.

Discoverability

End the project's README with two friendly statements linking to its actual license and the attribution document. For Scriptorium:

Scriptorium is licensed under the [BSD 3-Clause License](LICENSE).

[Open Source attribution notices](docs/oss/attribution.md) are available.

Each new checked-in release document and its hosted download page must end with links whose visible text is LICENSE | ATTRIBUTION. Use absolute URLs to those files at the release's immutable tag or corresponding immutable source revision so the links work in both locations. This release navigation is distinct from upstream component links, which must use the imported commit.

Reuse the checked-in release document as the hosted release body where supported. The release procedure owns concrete URLs and publication mechanics for delivering the links through the selected channel. Do not maintain duplicate notice lists. These conventions do not by themselves require separate downloadable license assets, source bundles, or a different binary package format.

Maintenance And Exceptions

Update notices in the change that adds, removes, upgrades, copies, or changes the distribution of a relevant component. Check the selected source's license and notices rather than assuming they are unchanged. Update affected entries, commit links, and texts; retain historical versions through Git.

Check affected statements, faithful standard-text copies, and link destinations as part of ordinary change review. For a future release tag, check intended file paths against the candidate source; the tag need not resolve remotely before publication. Do not add publication-time network checks, CI polling, recurring legal sign-offs, mandatory scanners, or a full software bill of materials merely to implement this policy.

Use the House Format routinely. Raise an exception only for a concrete obligation or unresolved rights question it does not address, including any arising from a particular distribution channel. Record the issue and selected treatment in the adopted policy or affected attribution entry as appropriate. Resolve the issue before the affected use or distribution without reopening settled choices. Common ownership of projects is neither required nor a blanket exception.

Apply the formatting convention prospectively. Do not rewrite published tags, notes, binaries, or checksums to retrofit it. Address actual omissions deliberately under the applicable terms and the release correction policy. Ordinary attribution maintenance and release links are preparation work, not new release approval gates.