# Open Source Licensing And Attribution Policy **Base Policy Version:** 1.8 **Last Updated**: 2026-09-28 **Upstream Source**: https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/oss.md ## 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. Determine treatment from the component's terms and actual use. 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](documentation.md) assigns ownership: - `COPYRIGHT`: project name, copyright statements, SPDX expression, grant, warranty disclaimer, and third-party statement. - `LICENSE` contains the complete, unmodified project license text, including incorporated companion text. Dependency attribution does not relicense the project. - `docs/oss/attribution.md`: canonical component entries. - `docs/oss/licenses/`: complete, verbatim standard and applicable companion texts. 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 Use the commit-pinned upstream examples to create actual project notices. Retain their links and keep the example collection upstream; keep applicable license texts locally as specified above. ## Project Licensing Notarius's selected application grant is `GPL-3.0-or-later`, recorded in [COPYRIGHT](../../COPYRIGHT). 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](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/application/COPYRIGHT) or [library COPYRIGHT example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/library/COPYRIGHT) to create the project’s root `COPYRIGHT` file. Use verified project names, contribution years, and copyright holders. For another selected license, adapt the grant, SPDX expression, disclaimer, and text references together to reflect the author's selected grant. 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. These comprise the complete document. 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. Limit optional identification prose to factual component and material scope. 2. **Upstream copyright statement or statements**, preserving their wording. Put multiple statements in separate paragraphs. Include this field when the selected upstream source supplies an applicable statement; otherwise, omit it. 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**, rendered exactly as `[Source](COMMIT_URL).`. Use the upstream [attribution example](https://gitea.maximumdirect.net/eric/policy/src/commit/a469273adda336625f96b9d769ea27b33999f146/examples/licensing/attribution.md) to create the project’s `docs/oss/attribution.md`. The example illustrates omitted fields and multiple copyrights and licenses. 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 their upstream copies. Every upstream repository or notice link must identify the exact commit corresponding to the imported version, including the selected source revision for copied material. Classify material according to its contents. 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. 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: ```markdown 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. For Notarius, the [release runbook](../release.md) owns the concrete source-only publication process and release navigation. ## 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](release.md#immutability-and-failure-recovery). Ordinary attribution maintenance and release links are preparation work, not new release approval gates.