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

Align policies with the standard and record their provenance

Browse Source
This commit is contained in:
Eric Rakestraw
2026-09-27 21:18:11 +00:00
parent 843d07b636
commit a16c2a38d6
13 changed files with 782 additions and 695 deletions
Download Patch File Download Diff File Expand all files Collapse all files

280
docs/policy/oss.md
View File

@@ -1,135 +1,227 @@
# 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-27
Adapted from the standard policy; see [provenance and licensing](../oss/attribution.md#standard-repository-policies).
**Upstream Source:** [oss.md](https://gitea.maximumdirect.net/eric/policy/src/commit/d84a38ebab26f048cafbe59a2246700c35d29843/docs/policy/oss.md)
## Purpose And Scope
This policy defines Promptkit's project licensing conventions and House Format
for upstream attribution. It covers relevant incorporated or distributed
components, including transitive dependencies and copied code, documentation,
or assets. Treatment follows the component's terms and actual use, not merely
its direct-dependency status or common ownership. Development tools do not
automatically require attribution.
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.
Promptkit is a Go library with an author-selected LGPL-3.0-or-later grant in
[COPYRIGHT](../../COPYRIGHT). Its public source repository is
`https://gitea.maximumdirect.net/eric/promptkit`; it publishes source-only Go
module releases through annotated tags, not binaries or separate hosted release
pages. The [release procedure](../release.md) owns publication mechanics.
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 House Format does not establish license compatibility or resolve every
obligation arising from use or distribution. Adoption does not relicense
existing material or override third-party terms.
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, holders and years, SPDX expression, grant,
warranty disclaimer, and statement about third-party material.
- `LICENSE`: complete, unmodified project license texts, including incorporated
companion text. Promptkit includes LGPLv3 followed by GPLv3.
- `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 dependency texts, including
companions where applicable. Shared texts can serve multiple entries.
- `docs/oss/licenses/`: complete, verbatim standard and applicable companion texts.
Keep explanations and project-specific notices outside standard texts. Preserve
distinct versions and exceptions, using recognizable filenames.
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
The house defaults for new projects are GPL-3.0-or-later for applications and
LGPL-3.0-or-later for libraries. An author's explicit choice takes precedence
without an exception rationale, extra approval, or compensating controls.
Promptkit retains its selected library grant; do not infer different licenses
for individual packages or relicense existing code by adopting this policy.
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.
Keep COPYRIGHT, LICENSE, SPDX expressions, and README descriptions consistent.
Use accurate holders and years; do not assume the maintainer owns every
contribution or advance years automatically. Update grant, disclaimer, and text
references together when the author deliberately changes licensing. Preserve
third-party terms and required existing notices. No blanket per-file header
requirement is introduced.
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
Each component entry contains 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 heading.
2. Upstream copyright statements, preserving their wording.
3. Applicable SPDX license identifier or expression.
4. License and notice links.
5. Source repository link at the exact imported commit.
Each entry presents these five fields in order, with blank lines between them:
These are fields, not a line limit. Include multiple statements or links where
needed. Do not invent absent copyright statements or SPDX identifiers. Describe
nonstandard terms through their linked text, preserve alternatives and
exceptions, and record a selected option when relevant. Do not silently resolve
an unsettled licensing choice.
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:
```markdown
[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 texts to local copies. Link project-specific notices to the
upstream copies at the exact commit corresponding to the imported version or
copied material. Moving branches and version tags are not substitutes for
commit-specific component 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 by content, not filename: an upstream LICENSE or COPYING can
mix standard text with project-specific notices or exceptions. Link both when
needed. Make incorporated companion texts directly reachable from each entry.
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, direct upstream links
are accepted as satisfying reproduction, inclusion, or copy requirements under
the adopted house interpretation. Do not add local-copy requirements or request
repeated approval solely because a license uses those terms. This concerns
notice reproduction, not other concrete obligations such as marking modified
files or supplying corresponding source. Central entries do not authorize
stripping required notices from incorporated source.
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 README with friendly statements linking to the actual grant in COPYRIGHT
and to the attribution document. Each new checked-in release note ends with
links whose visible text is `COPYRIGHT | LICENSE | ATTRIBUTION`, using absolute
URLs at the release's immutable tag or corresponding immutable source revision.
These release links differ from imported-component links, which use commits.
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:
The release procedure owns concrete URL construction. If a hosted download page
is deliberately introduced, reuse the checked-in note and preserve its footer
there. This convention does not require a new hosted page, downloadable license
assets, source bundles, or another packaging format. Do not maintain duplicate
notice lists.
```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.
## Maintenance And Exceptions
Update attribution in the change that adds, removes, upgrades, copies, or changes
distribution of a relevant component. Inspect the selected source's actual
licenses/notices rather than assuming they are unchanged. Update entries,
commit links, and texts together; retain history through Git.
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.
Review affected statements, standard-text fidelity, and link destinations during
ordinary change review. Future-release URLs can be checked against candidate
paths before the tag exists remotely. Do not add publication-time network checks,
CI polling, recurring legal sign-offs, mandatory scanners, or an SBOM just to
implement this policy. Attribution maintenance is preparation, not a release gate.
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.
Raise exceptions only for concrete obligations or unresolved rights questions
the House Format does not address, including distribution-specific issues.
Record their selected treatment here or in the affected entry and resolve them
before the affected use/distribution, without reopening settled choices.
Common ownership is not a blanket exception. Adapted standard policy documents
retain their upstream documentation license and identify modifications in their
provenance entry; this does not change Promptkit's library grant.
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.
The maintainer-provided standard policy templates are internal and non-public.
Their attribution entry identifies that source in prose and retains the
applicable license locally; do not link to or require publication of the
internal repository.
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.
Apply conventions prospectively. Do not rewrite published tags, notes, binaries,
or checksums to retrofit formatting. Handle actual omissions deliberately under
applicable terms and the [release correction policy](release.md#immutability-and-failure-recovery).
## Promptkit Adoption
Promptkit retains its LGPL-3.0-or-later library grant in
[COPYRIGHT](../../COPYRIGHT). Adapted policy documentation has the separate
scope identified there and in [attribution](../oss/attribution.md).
Promptkit publishes source-only Go module tags on Gitea, with no binaries or
separate hosted download page. The [release procedure](../release.md) owns
publication and concrete footer URLs. The hosted-page guidance applies if such
a channel is deliberately introduced; it does not require creating one.