ConfigKit/docs/policy/oss.md

# Open Source Licensing And Attribution Policy

**Base Policy Version:** 1.2

**Last Updated**: 2026-09-26

## ConfigKit applicability

ConfigKit's selected grant is LGPL-3.0-or-later, recorded in
[COPYRIGHT](../../COPYRIGHT), with the complete LGPLv3 and incorporated GPLv3
texts in [LICENSE](../../LICENSE). Adoption does not change that grant.
The [release procedure](../release.md) owns the Gitea source host, source-only
Go module distribution, and annotated-tag publication mechanism. No separate
hosted download page or license asset is required for this source-only channel.

The [attribution record](../oss/attribution.md#author-owned-adaptations) records
the author's explicit relicensing authorization for the incorporated Narratio
and WeatherReporter adaptations. That specific authorization is not a general
exception for commonly owned projects.

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

## Canonical Locations

The [documentation policy](documentation.md) 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.

## 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.

Keep project name, years, and holders accurate in COPYRIGHT; 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.

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.

## Upstream Attribution 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.

The [go-yaml entry](../oss/attribution.md#go-yaml-v4) demonstrates this format
with the pinned module's actual statements and links.

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
grant in `COPYRIGHT` and the attribution document. ConfigKit's [README](../../README.md)
uses "ConfigKit is licensed under the LGPL v3.0 or later" and "Open Source
attribution notices are available", linking the license name to COPYRIGHT and
the attribution phrase to `docs/oss/attribution.md` relative to the repository root.

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 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-correction).
Ordinary attribution maintenance and release links are preparation work, not new
release approval gates.