Adopt the standard OSS attribution policy

docs/policy/oss.md

@@ -0,0 +1,139 @@
+# 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](documentation.md) 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:
+
+```markdown
+## 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:
+
+```markdown
+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](release.md#immutability-and-failure-recovery).
+Ordinary attribution maintenance and release links are preparation work, not new
+release approval gates.