140 lines
6.6 KiB
Markdown
140 lines
6.6 KiB
Markdown
# 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.
|