Adopt the standard OSS attribution policy

This commit is contained in:
2026-09-26 16:36:45 +00:00
parent b399ebe391
commit 979697f19d
14 changed files with 350 additions and 303 deletions

View File

@@ -38,7 +38,6 @@ a model. For complete invocation and output behavior, see the
- [Migration from the former Go package](docs/consumers/migrating-to-promptkit.md)
- [Subprocess integration](docs/integrations/subprocess.md)
- [Architecture policy](docs/policy/architecture.md)
- [Open-source attribution and dependency licenses](docs/oss/attribution.md)
- [Promptkit framework formats](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md)
- [Promptkit Go consumer guide](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/consumers/pkg-promptkit.md)
@@ -50,3 +49,7 @@ a model. For complete invocation and output behavior, see the
[schemas](examples/schemas/), and [synthetic input fixtures](examples/fixtures/)
- [Render script](examples/render-markdown-summary.sh)
- [HTTP request](examples/http-run.json)
Scriptorium is licensed under the [BSD 3-Clause License](LICENSE).
[Open Source attribution notices](docs/oss/attribution.md) are available.

View File

@@ -32,7 +32,8 @@ tests.
| OpenAI-compatible outbound behavior or timeout layering | [Promptkit integration contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/integrations/openai-compatible-chat.md) |
| Subprocess behavior | [Subprocess integration](integrations/subprocess.md) and [CLI contract](cli.md) |
| Runtime operation or recovery | [Operations](operations.md) |
| Release packaging or publication | The [release policy](policy/release.md), [release procedure](release.md), [hosted release workflow](../.woodpecker/release.yml), and [architecture policy](policy/architecture.md) |
| Dependencies, copied assets, or attribution | The [OSS policy](policy/oss.md), [component attributions](oss/attribution.md), and [architecture policy](policy/architecture.md) |
| Release documentation, packaging, or publication | The [release policy](policy/release.md), [OSS policy](policy/oss.md), [release procedure](release.md), [hosted release workflow](../.woodpecker/release.yml), and [architecture policy](policy/architecture.md) |
| Examples or copyable assets | The owning Scriptorium contract, the relevant [Promptkit format contract](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0/docs/formats.md), and the related files under `examples/` |
| Architecture decisions or future work | The [documentation policy](policy/documentation.md), relevant accepted ADRs, and relevant roadmap documents |

View File

@@ -1,33 +1,93 @@
# Open-Source Attribution
Scriptorium's own terms are in the repository [LICENSE](../../LICENSE).
Dependency license texts include the [GNU GPL v3](licenses/GPL-3.0.txt),
[GNU LGPL v3](licenses/LGPL-3.0.txt), [Apache 2.0](licenses/Apache-2.0.txt),
[BSD 3-Clause](licenses/BSD-3-Clause.txt), and the upstream
[yaml.v3 license](licenses/yaml.v3-LICENSE.txt) and
[notice](licenses/yaml.v3-NOTICE.txt). Versions are recorded in `go.mod` and
`go.sum`; component source links below identify the selected releases.
The [OSS policy](../policy/oss.md) governs these entries. Dependency versions
are recorded in [go.mod](../../go.mod) and [go.sum](../../go.sum); source and
notice links below identify the exact commits for the selected versions.
## Promptkit
Copyright (C) 2026 Eric Rakestraw
[SPDX-License-Identifier: LGPL-3.0-or-later](licenses/LGPL-3.0.txt)
SPDX-License-Identifier: LGPL-3.0-or-later
[Source: Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/tag/v0.11.0)
License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
[GPL v3 companion](licenses/GPL-3.0.txt) |
[upstream LICENSE](https://gitea.maximumdirect.net/eric/promptkit/src/commit/db05b56166ca2d8650dfaf660e1cf0eed3932e1d/LICENSE)
## Backend Catalogs
Source: [Promptkit v0.11.0](https://gitea.maximumdirect.net/eric/promptkit/src/commit/db05b56166ca2d8650dfaf660e1cf0eed3932e1d)
The selected OpenRouter and Rakestrawhome catalog modules carry the GNU LGPL v3
and its incorporated GPL v3. Their source repositories identify the profile
assets as originating in Promptkit and intentionally relicensed for the catalog
modules.
## Promptkit OpenRouter Catalog
- [OpenRouter catalog v2.20260922.1](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/tag/v2.20260922.1) — [LGPL v3](licenses/LGPL-3.0.txt).
- [Rakestrawhome catalog v2.20260922.0](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/tag/v2.20260922.0) — [LGPL v3](licenses/LGPL-3.0.txt).
Upstream copyright statement: no project-specific statement is present in the
selected module. The linked upstream README records the profile assets'
Promptkit origin and the copyright holder's deliberate relicensing.
## Other Go Dependencies
SPDX-License-Identifier: LGPL-3.0-only
- [jsonschema/v6 v6.0.2](https://github.com/santhosh-tekuri/jsonschema/tree/v6.0.2) — [Apache 2.0](licenses/Apache-2.0.txt).
- [golang.org/x/text v0.14.0](https://github.com/golang/text/tree/v0.14.0) — [BSD 3-Clause](licenses/BSD-3-Clause.txt); Copyright (c) 2009 The Go Authors. All rights reserved.
- [gopkg.in/yaml.v3 v3.0.1](https://github.com/go-yaml/yaml/tree/v3.0.1) — the upstream [MIT and Apache license notice](licenses/yaml.v3-LICENSE.txt) and separate [NOTICE](licenses/yaml.v3-NOTICE.txt).
License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
[GPL v3 companion](licenses/GPL-3.0.txt) |
[upstream LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/f7518043ebdd70b8959506201639903dff0b85ab/LICENSE) |
[asset licensing notice](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/f7518043ebdd70b8959506201639903dff0b85ab/README.md)
Source: [OpenRouter catalog v2.20260922.1](https://gitea.maximumdirect.net/eric/promptkit-backend-openrouter/src/commit/f7518043ebdd70b8959506201639903dff0b85ab)
## Promptkit Rakestrawhome Catalog
Upstream copyright statement: no project-specific statement is present in the
selected module. The linked upstream README records the profile asset's
Promptkit origin and the copyright holder's deliberate relicensing.
SPDX-License-Identifier: LGPL-3.0-only
License and notices: [LGPL v3](licenses/LGPL-3.0.txt) |
[GPL v3 companion](licenses/GPL-3.0.txt) |
[upstream LICENSE](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/d664696142bf7c2d93db2a6b2e07f3deb55f2226/LICENSE) |
[asset licensing notice](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/d664696142bf7c2d93db2a6b2e07f3deb55f2226/README.md)
Source: [Rakestrawhome catalog v2.20260922.0](https://gitea.maximumdirect.net/eric/promptkit-backend-rakestrawhome/src/commit/d664696142bf7c2d93db2a6b2e07f3deb55f2226)
## jsonschema/v6
Upstream copyright statement: no project-specific statement is present in the
selected module; no substitute statement is inferred here.
SPDX-License-Identifier: Apache-2.0
License and notices: [Apache 2.0](licenses/Apache-2.0.txt) |
[upstream LICENSE](https://github.com/santhosh-tekuri/jsonschema/blob/29cbed948d24a04700eb94436416b18a07953b71/LICENSE)
Source: [jsonschema/v6 v6.0.2](https://github.com/santhosh-tekuri/jsonschema/tree/29cbed948d24a04700eb94436416b18a07953b71)
## golang.org/x/text
Copyright (c) 2009 The Go Authors. All rights reserved.
SPDX-License-Identifier: BSD-3-Clause
License and notices: [BSD 3-Clause](licenses/BSD-3-Clause.txt) |
[upstream LICENSE](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353/LICENSE)
Source: [golang.org/x/text v0.14.0](https://go.googlesource.com/text/+/6c97a165dd661335ff7bce6104a008558123c353)
## gopkg.in/yaml.v3
Copyright (c) 2006-2010 Kirill Simonov
Copyright (c) 2006-2011 Kirill Simonov
Copyright (c) 2011-2019 Canonical Ltd
Copyright 2011-2016 Canonical Ltd.
SPDX-License-Identifier: MIT AND Apache-2.0
The upstream LICENSE assigns MIT to files ported from libyaml and Apache 2.0
to the remaining files; these are file-specific terms, not alternatives.
License and notices: [MIT](licenses/MIT.txt) |
[Apache 2.0](licenses/Apache-2.0.txt) |
[upstream LICENSE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/LICENSE) |
[upstream NOTICE](https://github.com/go-yaml/yaml/blob/f6f7691b1fdeb513f56608cd2c32c51f8194bf51/NOTICE)
Source: [gopkg.in/yaml.v3 v3.0.1](https://github.com/go-yaml/yaml/tree/f6f7691b1fdeb513f56608cd2c32c51f8194bf51)

View File

@@ -173,3 +173,30 @@
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following
boilerplate notice, with the fields enclosed by brackets "[]"
replaced with your own identifying information. (Don't include
the brackets!) The text should be enclosed in the appropriate
comment syntax for the file format. We also recommend that a
file or class name and description of purpose be included on the
same "printed page" as the copyright notice for easier
identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

View File

@@ -1,27 +1,11 @@
Copyright (c) 2009 The Go Authors. All rights reserved.
Copyright (c) <year> <owner>.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following disclaimer
in the documentation and/or other materials provided with the
distribution.
* Neither the name of Google Inc. nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

View File

@@ -1,5 +1,3 @@
provided in COPYING. Dependency code and assets retain their own licenses.
GNU LESSER GENERAL PUBLIC LICENSE
Version 3, 29 June 2007

18
docs/oss/licenses/MIT.txt Normal file
View File

@@ -0,0 +1,18 @@
MIT License
Copyright (c) <year> <copyright holders>
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and
associated documentation files (the "Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the
following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial
portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
USE OR OTHER DEALINGS IN THE SOFTWARE.

View File

@@ -1,50 +0,0 @@
This project is covered by two different licenses: MIT and Apache.
#### MIT License ####
The following files were ported to Go from C files of libyaml, and thus
are still covered by their original MIT license, with the additional
copyright staring in 2011 when the project was ported over:
apic.go emitterc.go parserc.go readerc.go scannerc.go
writerc.go yamlh.go yamlprivateh.go
Copyright (c) 2006-2010 Kirill Simonov
Copyright (c) 2006-2011 Kirill Simonov
Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies
of the Software, and to permit persons to whom the Software is furnished to do
so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
### Apache License ###
All the remaining project files are covered by the Apache license:
Copyright (c) 2011-2019 Canonical Ltd
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

View File

@@ -1,13 +0,0 @@
Copyright 2011-2016 Canonical Ltd.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

View File

@@ -1,6 +1,6 @@
# Documentation Policy
**Base Policy Version:** 1.3
**Base Policy Version:** 1.4
**Last Updated:** 2026-09-26
@@ -71,7 +71,7 @@ secret values.
| Topic | Canonical owner | Owned content | Content owned elsewhere |
| --- | --- | --- | --- |
| Product orientation and minimal end-to-end quickstart | `README.md` | What this project is, why it is useful, one shortest successful invocation, and links onward. | Complete command reference, configuration reference, operational procedures, implementation detail. |
| Product orientation and minimal end-to-end quickstart | `README.md` | What this project is, why it is useful, one shortest successful invocation, and links onward, including license and attribution navigation. | Complete command reference, configuration reference, operational procedures, implementation detail. |
| Contributor entry point | `docs/development.md` | Task-oriented reading guide, minimal contributor orientation, baseline validation commands, and links to canonical docs. | Package inventory, architecture rules, subsystem behavior, and detailed change recipes, which belong in the relevant internal component document. |
| Application architecture policy | `docs/policy/architecture.md` | System shape, normative ownership, dependency direction, architectural boundaries, invariants, safety properties, and non-goals. | Concrete package inventory, implementation mechanics, contributor procedures, decision history, future work. |
| Agent policy | `docs/policy/agents.md` | Agent implementation discipline, proportionality, idiomatic simplicity, local commit rules, and rules against inventing requirements, restrictions, guarantees, or repository policy. | Application contracts, architecture, testing policy, and contributor procedures. |
@@ -83,7 +83,10 @@ secret values.
| Release policy | `docs/policy/release.md` | Versioning and compatibility, release integrity and immutability, documentation requirements, proportionate gates, publication controls, source completion, and optional verification boundaries. | Repository-specific commands, installation guidance, historical summaries, and CI implementation details. |
| Release procedure | `docs/release.md` | Maintainer prerequisites, candidate preparation, publication command and guards, asynchronous delivery, optional diagnostics, and failure recovery. | General release requirements, runtime operations, historical announcements, and current application contracts. |
| Version-specific release notes | `docs/releases/` | Immutable release summaries, compatibility notices, and migration announcements for one published version. | Complete CLI, HTTP, configuration, operations, or dependency contracts. |
| Open-source attribution and license texts | `docs/oss/attribution.md` and `docs/oss/licenses/` | Component notices, selected source links, and verbatim dependency license texts. | Scriptorium's own `LICENSE`, release preparation, or a duplicate dependency inventory in release notes. |
| 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. |
| 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. |
| Public HTTP contract | `docs/api.md` | Routes, authentication, media types, request and response schemas, status codes, pagination, caching, idempotency, rate limits, and HTTP retry semantics. | Client walkthroughs, upstream or downstream integration internals, implementation detail. |
| Consumer guidance | `docs/consumers/` | Choosing between Scriptorium's executable interfaces and understanding consumer responsibilities. | HTTP wire semantics, CLI syntax, Promptkit's Go package, and internal implementation detail. |
| External and durable integration contracts | `docs/integrations/` | Scriptorium-owned process and executable integration contracts. | Promptkit framework formats and outbound provider protocols, physical runtime placement, internal transformations, CLI syntax, and configuration defaults. |
@@ -123,6 +126,13 @@ that release; current documentation changes with the behavior it describes.
Neither a procedure nor a note may weaken policy or defer required updates to
canonical contracts.
### Open Source 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
release procedure owns URL construction and publication mechanics.
### Contracts And Implementation
Integration and API documents define externally observable shapes and

139
docs/policy/oss.md Normal file
View File

@@ -0,0 +1,139 @@
# Open Source Licensing And Attribution Policy
**Base Policy Version:** 1.1
**Last Updated:** 2026-09-26
## 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
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.
## Canonical Locations
The [documentation policy](documentation.md) assigns ownership:
- `LICENSE` contains the project's own license. 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.
## 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.
Illustrative Markdown, with placeholders for the actual upstream information:
```markdown
## Example Library
Copyright <upstream copyright statement>
SPDX-License-Identifier: Apache-2.0
License and notices: [Apache 2.0](licenses/Apache-2.0.txt) | [NOTICE](<upstream NOTICE URL at the imported commit>)
Source: [Example Library](<upstream repository URL at the imported commit>)
```
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
license and the attribution document. For Scriptorium:
```markdown
Scriptorium is licensed under the [BSD 3-Clause License](LICENSE).
[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
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 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-failure-recovery).
Ordinary attribution maintenance and release links are preparation work, not new
release approval gates.

View File

@@ -1,6 +1,6 @@
# Release Policy
**Base Policy Version:** 1.1
**Base Policy Version:** 1.2
**Last Updated:** 2026-09-26
@@ -80,12 +80,11 @@ instructions. Keep the note proportionate to the change. Fixed sections and
explicit no-action boilerplate are not required. Existing historical notes
need not be rewritten to adopt this format.
End each new release note with a `LICENSE | ATTRIBUTION` footer. Both links
must be absolute URLs to files at that release's immutable Scriptorium tag:
the root `LICENSE` and `docs/oss/attribution.md`, respectively. The checked-in
note remains the source of the hosted release body, so this footer reaches the
hosted page without a separately maintained notice. Do not retrofit published
notes.
Include the release footer defined by the [OSS policy](oss.md#discoverability)
in each new release document and preserve it on the hosted download page. The
release procedure defines the concrete URLs and publication mechanics. Prepare
these links with the release note; they do not add a network check or approval
gate.
Keep exact current contracts in their canonical documents and update affected
documentation with the behavior change. Link to those documents from the note

View File

@@ -2,7 +2,9 @@
The [release policy](policy/release.md) owns versioning, compatibility,
publication completion, and immutability. This runbook supplies Scriptorium's
commands; release notes under `docs/releases/` are historical summaries.
commands; release notes under `docs/releases/` are historical summaries. The
[OSS policy](policy/oss.md#discoverability) owns license and attribution
discoverability requirements.
## Prepare The Candidate

View File

@@ -1,194 +1,63 @@
# OSS Attribution Policy Roadmap
# OSS Policy Adoption
## Status And Purpose
## Status
Proposed cross-project policy direction, based on the attribution and release
discoverability approach agreed for Scriptorium. This document replaces the
completed policy-template adoption roadmap, whose history remains in Git.
The existing documents under `docs/policy/` continue to govern the repository.
Completed on 2026-09-26. The upstream template work proposed here is now
available and adopted locally. This document records the adoption; the
[OSS policy](../policy/oss.md) is the canonical owner of the ongoing rules.
The target is a reusable OSS attribution policy template for the upstream policy
suite, with a locally adopted policy in each participating project. It should
standardize the location, content, discoverability, and maintenance of notices
without introducing a compliance platform or unnecessary release gates.
The adopted baseline is the standard policy repository at commit
`eea8bcd21a964b395e31971077d7fddb445f2c28`:
This is a roadmap for that template, not an adopted policy or a claim that
every project or license has identical obligations. Scriptorium's concrete
Promptkit work is defined in [implementation Stage 9](implementation.md#stage-9-add-oss-attribution-and-release-links).
Creating the upstream template and adopting it across projects are future work,
not changes made by this document.
- OSS policy base version 1.1;
- documentation policy base version 1.4; and
- release policy base version 1.2.
## Intended Scope
Each affected policy records its base version and local update date. Template
adoption instructions were removed. Unchanged agent, architecture, and testing
policies retain their existing versions.
The policy should cover attribution and license notices for OSS components
incorporated into or distributed with a project, including relevant transitive
dependencies and copied code or assets. A component's treatment follows its
actual license and how it is used or distributed, not merely whether it is
listed as a direct dependency.
## Adoption Outcome
The baseline arrangement is an openly available project source repository,
dependency source references, and releases published alongside that repository.
The template must remain independent of programming language, forge, build
system, and particular dependency. Promptkit, Go, and Gitea are local examples,
not upstream policy requirements.
- [Documentation ownership](../policy/documentation.md) distinguishes the
project license, component entries, standard texts, and OSS policy.
- The [contributor guide](../development.md) routes dependency, copied-asset,
attribution, and release-document work to the OSS policy.
- [Component entries](../oss/attribution.md) cover the six selected direct and
transitive Go modules. Source and project-specific notice links identify the
imported commits. LGPL entries link directly to both LGPL v3 and GPL v3.
- Project-specific notices are linked upstream under the adopted house
interpretation. YAML's former local LICENSE and NOTICE copies were removed;
their history remains in Git. Missing upstream copyright statements are
identified in the affected entries rather than fabricated.
- The five applicable standard texts in `docs/oss/licenses/` match the upstream
reference collection byte-for-byte: GPL v3, LGPL v3, Apache 2.0, BSD 3-Clause,
and MIT. The reference collection documents their publisher/SPDX provenance.
Adoption removed a stray LGPL prefix, restored the complete Apache text,
separated the standard BSD text from the Go-specific notice, and added MIT.
- The [README](../../README.md) ends with friendly project-license and
attribution links. The [release policy](../policy/release.md) delegates footer
conventions to the OSS policy; the [release procedure](../release.md) retains
Scriptorium's immutable-tag URLs and existing hosted-body reuse.
This policy should not automatically require attribution for every tool ever
used in development, create a full software bill of materials, approve license
compatibility, or replace applicable license terms. Distinct requirements
arising from a component or distribution channel remain relevant; the baseline
must neither erase them nor invent additional ones.
## Preserved Scope
## Canonical Files And Ownership
This adoption changes documentation and attribution, not Scriptorium's license,
dependencies, application architecture, or release machinery. Published notes,
tags, and assets remain unchanged. Existing source-release completion and
asynchronous binary-delivery behavior remain intact.
The proposed convention is:
There is no new publication-time network check, approval gate, scanner, source
bundle, downloadable license asset, or modified-dependency rebuild exercise.
Concrete exceptions continue to receive the treatment specified by the adopted
OSS policy; the house format is not a universal legal-sufficiency guarantee.
| Location | Responsibility |
| --- | --- |
| `LICENSE` | The project's own license; dependency attribution does not relicense the project. |
| `docs/oss/attribution.md` | Canonical component attributions, applicable license identifiers, and upstream source links. |
| `docs/oss/licenses/` | Complete, verbatim license texts referenced by attribution entries, including companion texts when applicable. |
| `docs/policy/oss.md` | The eventually adopted local OSS attribution policy, derived from the upstream template. |
| Release documents and hosted release pages | Discoverability through links to the release's license and attribution files, not duplicate notice inventories. |
## Validation
Use recognizable license filenames, such as `GPL-3.0.txt` and
`LGPL-3.0.txt`. A shared unmodified license text can serve multiple entries.
Distinct texts, exceptions, or component-specific required notices must not be
lost through deduplication. Keep license wording intact; explanations belong
in attribution or policy prose, not edits to license text.
A project's documentation policy owns the assignment of these canonical
locations. The OSS policy owns attribution conventions; the release policy
owns the footer requirement; the release procedure owns the concrete URL and
publication mechanics. Cross-references should avoid competing definitions.
## Attribution Entry Convention
Use a component heading or other clear identifier, followed by a concise entry:
1. The upstream copyright statement or statements, preserving the applicable
wording rather than substituting the application's copyright holder.
2. `SPDX-License-Identifier: <identifier or expression>`, with a link to the
corresponding local license text or texts.
3. A link to the component's source repository.
This is the standard compact form, not a three-line cap on notices that a
component actually requires. Preserve additional notices or exceptions where
applicable. Use the actual upstream license identification; do not invent an
SPDX identifier or silently choose between licensing alternatives when that
choice is unresolved. A nonstandard license should be identified accurately
and accompanied by its text.
Prefer a source link to the revision or release used by the project where
practical, so the source corresponding to a distribution is easy to locate.
Dependency manifests remain useful version records; do not duplicate a
complete lockfile in the attribution document. A source link does not replace
a copyright notice or a license-text copy.
Make companion license texts reachable through concise document navigation.
For example, an LGPL entry may link its SPDX line to the local LGPL text while
the document also exposes the incorporated GPL text. Readers should not need
to infer where that companion document is stored.
## Release Discoverability
Each new checked-in release document and its hosted download page should end
with two links whose visible text is:
`LICENSE | ATTRIBUTION`
The first links to the project's own license; the second links to the
attribution document. Use absolute URLs to the files at that release's
immutable tag or corresponding immutable source revision, not a moving default
branch. The links should work both when viewing the release document in the
repository and when viewing its rendered body on the download page.
Where publication already derives the hosted release body from the checked-in
document, preserve that single source. Do not maintain a second notice list
or footer by hand. Where a platform uses a different mechanism, the local
release procedure specifies how the same links reach recipients.
The attribution document links onward to dependency sources and checked-in
license texts. Under this selected repository-hosted arrangement, the policy
does not additionally require separate downloadable license assets, a combined
source archive, or a new binary package format by default. Different channels,
such as offline distribution or a package registry without the repository's
release page, need treatment appropriate to that channel and its actual terms;
the footer convention is not a universal legal-sufficiency guarantee.
Apply the convention prospectively. Do not rewrite published notes, tags,
binaries, or checksums to retrofit the footer. Follow the project's existing
release correction policy for an actual defect in published material.
## Source Availability And Proportionality
The intended baseline makes the project's source and relevant dependency
sources available with permissions and existing build materials that enable
modification and combination. Attribution identifies where those sources can
be obtained.
Do not automatically add a special modified-dependency rebuild tutorial,
verification exercise, relinking harness, source-bundle build, or dynamic-linking
migration when the existing sources, permissions, and build materials already
enable that work. If something actually needed is missing, address that gap
rather than assuming either that all source links suffice or that extra
machinery is always mandatory.
Common ownership of two projects may affect their particular licensing
position, but is not a prerequisite or blanket exception in the reusable
policy. Other dependencies and future contributors can have different owners
and terms. The upstream template should encode the attribution practice, not
depend on Scriptorium and Promptkit sharing a copyright holder.
## Maintenance And Validation
Maintain notices as part of the change that adds, removes, upgrades, copies,
or changes the distribution of a relevant component. Check its selected
source's notices and license, update affected entries/texts, and preserve useful
history through version control rather than retaining misleading current
entries. Do not assume that a dependency's license is unchanged across versions.
Proportionate review covers:
- accurate component identification, notices, and license references;
- faithful copies of the required texts;
- working local links and source references appropriate to the selected version;
- release footer destinations matching the intended release's file layout; and
- preservation of the footer by the existing publication mechanism.
A future release tag need not be remotely resolvable before it is published.
Validate its intended paths against the candidate source. Do not turn link
checking into a publication-time network gate, CI polling loop, or recurring
manual legal signoff. Dedicated scanners, exhaustive dependency inventories,
and new compliance tooling are not required by this baseline; add machinery
only for a concrete unmet need.
Resolve an actual uncertainty about rights, missing materials, or applicable
terms explicitly. Ordinary notice maintenance should not require repeated
approval of an already selected distribution approach. This policy supplements,
rather than replaces, normal dependency review and the project's release policy.
## Upstream Template And Local Adoption Target
The eventual upstream template should contain the general conventions above,
with no Scriptorium-specific paths beyond the shared documentation convention,
no Promptkit version pin, and no assumptions about Gitea URL syntax. Its
adoption guidance should ask each project to identify its license location,
source/release host, distribution channels, and publication mechanism.
Follow the existing suite's provenance convention when the template is
versioned and adopted: the local policy has a Base Policy Version and a
Last Updated date immediately below its title. Record the real template version
and local adoption date; do not invent a base version for this proposal.
Template-only adoption instructions are removed from locally adopted policies.
Coordinate the upstream documentation and release templates so they recognize
the OSS policy and its canonical files without duplicating its detailed rules.
Locally, connect the contributor reading guide to the OSS policy for dependency,
attribution, and release-document changes. These are documentation/policy
integration changes, not an application architecture migration.
Completion of this roadmap means a reusable template exists, the relevant suite
cross-references agree, and local adoption can produce clear notices and
release links without speculative guarantees or unnecessary machinery.
Scriptorium may implement its already-agreed Stage 9 before that upstream
template is created; the template's availability is not a release prerequisite.
The standard texts were compared against the upstream reference collection.
The BSD reference intentionally retains its publisher's trailing space in the
copyright placeholder; it is not reformatted to satisfy a whitespace check.
Dependency commit references were resolved from Go module origin metadata or
the selected upstream tag, and affected local links and upstream attribution
destinations were checked. No runtime code, commands, or executable examples
changed.