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

Define project licensing defaults and COPYRIGHT examples

Browse Source
This commit is contained in:
Eric Rakestraw
2026-09-26 20:16:48 +00:00
parent eea8bcd21a
commit dafa823981
4 changed files with 106 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

16
docs/policy/documentation.md
View File

@@ -1,6 +1,6 @@
# Documentation Policy
**Base Policy Version:** 1.4
**Base Policy Version:** 1.5
**Last Updated**: 2026-09-26
@@ -80,8 +80,9 @@ secret values.
| Documentation policy | `docs/policy/documentation.md` | Documentation ownership, audience boundaries, maintenance rules, and ADR/document lifecycle. | Application architecture or product behavior. |
| Testing policy | `docs/policy/testing.md` | Test philosophy, risk-based sufficiency, test boundaries, doubles, coverage guidance, regression-test policy, and criteria for adding, rewriting, or deleting tests. | Subsystem behavior, application contracts, subsystem-specific test inventories, and implementation plans. |
| Release policy | `docs/policy/release.md` | Versioning and compatibility rules, release integrity and immutability requirements, release-documentation policy, proportionate gate selection, publication controls, release completion, and the boundary between required checks and optional verification. | Repository-specific commands, product installation guidance, CLI version semantics, historical release summaries, and CI implementation detail. |
| Open source licensing and attribution policy | `docs/policy/oss.md` | House attribution format, license-text and notice-link conventions, discoverability, maintenance, and handling of concrete exceptions. | Component entries, license texts, release commands, and dependency security review. |
| Project license | `LICENSE` | The project's own license terms. | Upstream component attribution and dependency license texts. |
| Open source licensing and attribution policy | `docs/policy/oss.md` | Project licensing defaults and author choices, COPYRIGHT conventions, upstream attribution format, license-text and notice-link conventions, discoverability, maintenance, and handling of concrete exceptions. | Component entries, license texts, release commands, and dependency security review. |
| Project copyright and license grant | `COPYRIGHT` | Project identity, copyright holders and years, SPDX expression, license grant, warranty disclaimer, and statement about third-party material. | Complete license texts and upstream component attribution. |
| Project license texts | `LICENSE` | Complete project license text and incorporated companion text, with project-specific fields where required by the selected license. | General licensing policy and upstream component attribution. |
| Upstream component attribution | `docs/oss/attribution.md` | Component names, copyright statements, license identification, and license, notice, and source links. | General attribution policy and complete standard license texts. |
| Standard dependency license texts | `docs/oss/licenses/` | Complete, verbatim standard license texts shared by attribution entries where applicable. | Project-specific upstream notices, attribution prose, and policy interpretation. |
| Repository-specific release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, concrete validation and publication commands, automated publication guards, asynchronous deliverable publication, separate delivery status, optional consumer-facing verification, and failure recovery. | General release requirements, product installation guidance, historical release summaries, and current compatibility contracts. |
@@ -130,11 +131,12 @@ must change with the behavior it describes. Do not use a release procedure or
release note to weaken policy, redefine current behavior, or defer required
documentation updates.
### Open Source Attribution
### Project Licensing And Upstream Attribution
The [OSS policy](oss.md) defines the House Format and README and release-link
conventions. Attribution entries own component-specific information. README
and release documents provide navigation to those canonical materials; the
The [OSS policy](oss.md) defines project licensing conventions, the upstream
House Format, and README and release-link conventions. `COPYRIGHT` states the
project grant; `LICENSE` supplies its complete license texts. Attribution entries
own component-specific information. README and release documents provide navigation to those canonical materials; the
release procedure owns URL construction and publication mechanics.
### Contracts And Implementation

77
docs/policy/oss.md
View File

@@ -1,6 +1,6 @@
# Open Source Licensing And Attribution Policy
**Base Policy Version:** 1.1
**Base Policy Version:** 1.2
**Last Updated**: 2026-09-26
@@ -8,10 +8,11 @@
Repositories adopting this policy should:
1. Identify the project's license location, source and release host, distribution
channels, and publication mechanism in the appropriate canonical documents;
2. Connect the contributor reading guide to this policy for dependency,
attribution, and release-document changes;
1. Identify the author's selected project license, source and release host,
distribution channels, and publication mechanism in the appropriate canonical
documents;
2. Connect the contributor reading guide to this policy for project licensing,
dependency, attribution, and release-document changes;
3. Record any concrete requirements outside the House Format that apply to the
project, with their reason and selected treatment;
4. Update `Last Updated` to the adoption date, retaining the actual Base Policy
@@ -26,23 +27,26 @@ own attribution entries and upstream notice links under this policy.
## Purpose And Scope
This policy establishes a repeatable House Format for open source attribution
and license notices. It covers upstream components incorporated into or
distributed with the project, including relevant transitive dependencies and
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 obligations beyond attribution and notice handling.
compatibility, or resolve every obligation arising from use or distribution.
## Canonical Locations
The [documentation policy](documentation.md) assigns ownership:
- `LICENSE` contains the project's own license. Dependency attribution does
not relicense the project.
- `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.
@@ -51,7 +55,41 @@ 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.
## House Format
## 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.
Use the copyable [application COPYRIGHT](../../examples/licensing/application/COPYRIGHT)
or [library COPYRIGHT](../../examples/licensing/library/COPYRIGHT) as appropriate.
Replace the project name, years, and holders with accurate information; 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. The examples do not constrain the author's choice.
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:
@@ -111,18 +149,18 @@ 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
license and the attribution document. For example, for a project with the stated
license:
grant in `COPYRIGHT` and the attribution document. For example, for a project
with the stated license:
```markdown
PROJECT_NAME is licensed under the [LGPL v3.0 or later](LICENSE).
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 `LICENSE | ATTRIBUTION`. Use absolute URLs to
those files at the release's immutable tag or corresponding immutable source
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.
@@ -134,8 +172,9 @@ assets, source bundles, or a different binary package format.
## Maintenance And Exceptions
Update notices in the change that adds, removes, upgrades, copies, or changes
the distribution of a relevant component. Check the selected source's license
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.