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, with the complete LGPLv3 and incorporated GPLv3 texts in LICENSE. Adoption does not change that grant. The release procedure 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.

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