eric/ConfigKit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Align policy provenance and licensing documentation

Browse Source
This commit is contained in:
Eric Rakestraw
2026-09-28 00:27:03 +00:00
parent 12a03dbb9a
commit 5f4a8f1919
9 changed files with 519 additions and 180 deletions
Download Patch File Download Diff File Expand all files Collapse all files

144
docs/policy/oss.md
View File

@@ -1,26 +1,33 @@
# Open Source Licensing And Attribution Policy
**Base Policy Version:** 1.2
**Base Policy Version:** 1.8
**Last Updated**: 2026-09-26
**Last Updated**: 2026-09-28
## ConfigKit applicability
**Upstream Source:** [Standard Repository Policies](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/oss.md)
## 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.
texts in [LICENSE](../../LICENSE). The [release procedure](../release.md)
owns source-only Go module publication through Gitea. No separate hosted release
object or license asset is required for this 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.
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.
@@ -31,18 +38,23 @@ compatibility, or resolve every obligation arising from use or distribution.
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.
- `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` contains the canonical component entries.
- `docs/oss/licenses/` contains complete, verbatim standard license texts,
including companion texts where applicable.
- `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
Unless the author specifies otherwise, use **GPL version 3 or later**
@@ -57,10 +69,12 @@ 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.
Use the upstream [application COPYRIGHT example](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/examples/licensing/application/COPYRIGHT)
or [library COPYRIGHT example](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/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
@@ -75,40 +89,70 @@ fields; the standard reference collection remains unchanged. Keep `COPYRIGHT`,
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
Each component entry has five fields:
Begin `docs/oss/attribution.md` with `# Open Source Attribution Notices`,
followed directly by component entries. These comprise the complete document.
1. **Project name**, normally as the entry heading.
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.
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.
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).`.
The [go-yaml entry](../oss/attribution.md#go-yaml-v4) demonstrates this format
with the pinned module's actual statements and links.
Use the upstream [attribution example](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/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. 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.
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
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.
Do not use moving branches or version tags as substitutes for that commit.
Classify material by its contents, not its filename. An upstream `LICENSE`,
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 rather than leaving readers to infer their location.
reachable from the entry.
For project-specific license and attribution material, this policy accepts
direct links to the applicable upstream texts as satisfying reproduction,
@@ -124,15 +168,15 @@ 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.
grant in `COPYRIGHT` and the attribution document. ConfigKit's
[README](../../README.md) contains the two required statements: one linking to
the project grant and one linking to attribution.
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
Each new checked-in release document 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 for source-only Gitea publication. Where a hosted download page is used,
it carries the same links. 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.
@@ -159,8 +203,10 @@ 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.
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,