Align licensing policy and attribution with the house standard
This commit is contained in:
@@ -2,7 +2,10 @@
|
||||
|
||||
**Base Policy Version:** 1.1
|
||||
|
||||
**Last Updated:** 2026-09-23
|
||||
**Last Updated:** 2026-09-26
|
||||
|
||||
Licensing ownership incorporates the upstream documentation policy v1.5;
|
||||
unrelated policy revisions remain outside this adoption.
|
||||
|
||||
## Purpose
|
||||
|
||||
@@ -63,6 +66,11 @@ handling, not secret values.
|
||||
| Documentation rules | `docs/policy/documentation.md` | Ownership and document lifecycle |
|
||||
| Testing rules | `docs/policy/testing.md` | Risk-based sufficiency, test boundaries, and maintenance principles |
|
||||
| Release rules | `docs/policy/release.md` | Compatibility, integrity, gates, immutability, and exceptions |
|
||||
| Licensing and attribution rules | `docs/policy/oss.md` | Project licensing conventions, attribution format, notice links, discoverability, and maintenance |
|
||||
| Project grant | `COPYRIGHT` | Project identity, holders and years, SPDX expression, grant, disclaimer, and third-party statement |
|
||||
| Project license texts | `LICENSE` | Complete selected license and incorporated companion text |
|
||||
| Upstream attribution | `docs/oss/attribution.md` | Component names, copyright statements, license identification, and source/license/notice links |
|
||||
| Standard dependency license texts | `docs/oss/licenses/` | Complete verbatim texts, not project-specific upstream notices |
|
||||
| Release procedure | `docs/release.md` | Exact maintainer commands, prerequisites, supported targets, and verification |
|
||||
| Exported Go API | Go documentation beside declarations | Symbol contracts, errors, ownership, and lifecycle API behavior |
|
||||
| YAML and resolution semantics | `docs/config.md` | Syntax, composition, precedence, conversion, secret references/bootstrap, and explanation semantics; Go reference docs link here for shared rules |
|
||||
@@ -86,6 +94,12 @@ interface. Do not create those reference documents for consuming applications.
|
||||
|
||||
## Boundary rules
|
||||
|
||||
The [OSS policy](oss.md) owns licensing and attribution conventions. COPYRIGHT
|
||||
owns the project grant, LICENSE owns its complete texts, and attribution entries
|
||||
own component-specific information. README and new release documents provide
|
||||
navigation; the release procedure owns concrete release URLs and publication
|
||||
mechanics. Do not duplicate notice lists in those documents.
|
||||
|
||||
Architecture owns governing constraints; ADRs explain why; contracts describe
|
||||
implemented semantics; internal documentation explains how. A roadmap may link
|
||||
to all of them but must not become a second current reference.
|
||||
|
||||
175
docs/policy/oss.md
Normal file
175
docs/policy/oss.md
Normal file
@@ -0,0 +1,175 @@
|
||||
# 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.
|
||||
@@ -2,7 +2,10 @@
|
||||
|
||||
**Base Policy Version:** 1.0
|
||||
|
||||
**Last Updated:** 2026-09-23
|
||||
**Last Updated:** 2026-09-26
|
||||
|
||||
The licensing-footer requirement incorporates upstream release policy v1.2;
|
||||
other release-workflow changes from that version are not adopted here.
|
||||
|
||||
## Purpose
|
||||
|
||||
@@ -135,6 +138,12 @@ canonical documentation for exact behavior. Every affected canonical document
|
||||
must be updated in the same candidate; a release note must not substitute for
|
||||
current documentation or defer required documentation changes.
|
||||
|
||||
Each new release note must end with the release navigation defined by the
|
||||
[OSS policy](oss.md#discoverability). Preserve those links on a hosted download
|
||||
page if one is used. The release procedure owns URL construction and channel
|
||||
treatment. This is ordinary preparation, not a new network check or approval
|
||||
gate; historical release notes are unchanged.
|
||||
|
||||
## Candidate Preparation And Validation
|
||||
|
||||
ConfigKit provides one local release checker. Run it once against the final
|
||||
|
||||
Reference in New Issue
Block a user