policy/docs/policy/oss.md

Open Source Licensing And Attribution Policy

Base Policy Version: 1.6

Last Updated: 2026-09-27

Base Policy Template

Repositories adopting this policy should:

1. Identify the author's selected project license, source and release host, distribution channels, and publication mechanism in the appropriate canonical documents;
2. Connect the contributor reading guide to this policy for project licensing, dependency, attribution, and release-document changes;
3. Record any concrete requirements outside the House Format that apply to the project, with their reason and selected treatment;
4. Update Last Updated to the adoption date, retaining the actual Base Policy Version; and
5. Remove this heading and its associated text.

Selected standard license texts are available in this template repository's reference collection. Copy the applicable texts, including companion licenses, into the adopting repository. The collection is a convenience, not an exhaustive catalog or a required bundle; maintain the project's own attribution entries and upstream notice links under this policy.

Purpose And Scope

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

Consulting development guidance or using tooling alone does not require an attribution entry. Copying or adapting documentation for inclusion in the repository is different: preserve its applicable attribution and license terms. A material's role as development guidance does not exempt copied documents. Apply any express permissions for attribution-free reuse of example formatting.

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 every obligation arising from use or distribution.

Canonical Locations

The documentation policy assigns ownership:

• COPYRIGHT contains the project name, copyright statements, SPDX expression, license grant, warranty disclaimer, and statement about third-party material.
• LICENSE contains the complete, unmodified project license text, including incorporated companion text. 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.

Upstream Reference Examples

The linked examples are reference material hosted in the public policy repository at a fixed commit. Retain these upstream links when adopting this policy; do not copy the example collection into the application's or library's examples/ directory. Create the project's actual COPYRIGHT and attribution files using the examples. Applicable license texts still belong locally in LICENSE and docs/oss/licenses/ as specified here.

Project Licensing

Unless the author specifies otherwise, use GPL version 3 or later (GPL-3.0-or-later) for applications and LGPL version 3 or later (LGPL-3.0-or-later) for libraries. An author's explicit choice takes precedence: for example, a one-off script may use MIT. Such a choice requires no exception rationale, additional approval, or compensating controls under this policy.

These defaults guide new license selection. Adopting this policy does not relicense existing code or override third-party terms. Preserve an existing license unless the author deliberately changes it. For mixed-purpose projects, follow the author's selected scope rather than inferring different licenses for individual packages.

Use the upstream application COPYRIGHT example or library COPYRIGHT example to create the project’s root COPYRIGHT file. Replace the project name, years, and holders with accurate information; do not assume the maintainer owns every contribution or advance years automatically. For another selected license, adapt the grant, SPDX expression, disclaimer, and text references together. The examples do not constrain the author's choice.

For GPLv3 projects, copy the complete GPLv3 text into LICENSE. For LGPLv3 projects, place the complete LGPLv3 text followed by the complete GPLv3 text in LICENSE; the LGPL incorporates the GPL terms. Keep the texts unmodified and place project-specific statements in COPYRIGHT. For the default grants, the grant and SPDX expression in COPYRIGHT must expressly identify or-later; follow the author’s choice if a different grant is selected.

For other licenses, provide their complete text and any required project-specific fields; the standard reference collection remains unchanged. Keep COPYRIGHT, LICENSE, SPDX expressions, and README descriptions consistent with the actual grant. This convention introduces no blanket requirement for per-file headers; preserve notices or add them where the applicable terms require them.

Identify separately licensed documentation or assets in the project grant, with links to their attribution and license information. An application's default code license does not override the terms of incorporated documentation.

Upstream Attribution House Format

Begin docs/oss/attribution.md with # Open Source Attribution Notices, followed directly by component entries. Do not add an introductory summary, policy links, audit narrative, disclaimer, or concluding explanation.

Each entry presents these five fields in order, with blank lines between them:

1. Project name as a level-two heading. An optional identification paragraph may follow, such as Selected module: MODULE at VERSION. with the module and version in backticks. For copied documentation, a concise Material: sentence may identify the affected files and whether they were adapted or copied without modification. A factual qualifier such as (transitive dependency) is permitted; do not describe dependency-discovery methods.
2. Upstream copyright statement or statements, preserving their wording. Put multiple statements in separate paragraphs. If the selected upstream source supplies no applicable statement, omit this field without inventing one or adding an explanation of its absence.
3. SPDX license identifier or expression, when applicable, using SPDX-License-Identifier: EXPRESSION.
4. License and notice links, beginning License and notices:, separated by |, and ending with a period. Label local standard texts by license name, such as MIT or Apache 2.0. Label upstream files by their actual filenames, such as COPYRIGHT, LICENSE, NOTICE, or PATENTS.
5. Source repository link, using [Source](COMMIT_URL). with no Source: prefix or additional description.

Use the upstream attribution example to create the project’s docs/oss/attribution.md. Its three illustrative entries demonstrate a normal entry, omission of an unavailable copyright statement, and multiple copyrights and license texts. Replace the uppercase placeholders and illustrative URLs with actual component information. Local license links are relative to the destination docs/oss/attribution.md; copy the applicable texts into its licenses/ directory. Do not copy example entries for components the project does not use.

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

Keep entries factual. Do not add agent-authored explanations of license expressions, file-level license scope, research performed, retained source notices, or compliance conclusions. Avoid filler such as "none is invented here" and embellished link labels such as "upstream LICENSE", "additional patent grant", or "at the imported commit". Preserve actual required upstream content; this rule excludes editorial additions, not required notices. Policy interpretation and exception reasoning belong in the adopted OSS policy or an appropriate decision record, not the attribution document.

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 grant in COPYRIGHT and the attribution document. For example, for a project with the stated license:

PROJECT_NAME is licensed under the [LGPL v3.0 or later](COPYRIGHT).

[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 COPYRIGHT | 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 project licensing statements together when the author changes the grant or its scope. Update upstream 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 OSS policy or an appropriate decision record. Attribution entries contain the resulting factual identification and required material, without repeating that reasoning. 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.