Release Sandwich Hime v1 source and contribution policy

Signed-off-by: Cole Speelman <crspeelman@gmail.com>
This commit is contained in:
2026-09-09 09:33:44 -04:00
parent 7e89ebfaba
commit d978994b27
22 changed files with 636 additions and 104 deletions
+4 -1
View File
@@ -2,7 +2,10 @@
# Brand vocabulary
Use **Sandwich Hime** for the project and **Hime-san** as its friendly short form. Use `himesan` for the command, `.sando` for source, `.sando.go` for generated Go, and `sando` for the runtime.
Use **Sandwich Hime** as the primary project identity and **Hime-san** for its
compiler/tool personality within that project, not as a separate framework
brand. Use `himesan` for the command, `.sando` for source, `.sando.go` for
generated Go, and `sando` for the runtime.
Never call the project bare “Hime,” which can be confused with an existing Go framework. Never use `.san`; it belongs exclusively to the separate San language project. “Sando” evokes a sandwich and keeps both projects unmistakable in editors, tooling, and search results.
+11 -13
View File
@@ -2,22 +2,20 @@
# Compatibility policy
## Current release-candidate contract
## v1 release contract
Compiler `v1.0.0-rc.1` and runtime `sando/v1.0.0-rc.1` are the current
semantic-version prereleases. The intended v1 source syntax, generated API,
runtime API, CLI behavior, diagnostics, and configuration schemas are frozen
except for release-blocking corrections. Every correction receives a new
immutable RC, documentation, and deterministic generation evidence.
This document defines the compatibility contract for compiler `v1.0.0` and
runtime `sando/v1.0.0`. Canonical Gitea tags and release announcements establish
version and artifact availability. Every correction receives a new immutable
version, documentation, and deterministic generation evidence.
The RC is not yet the final-v1 support commitment. Maintainers accept and
triage security reports within the boundary described in
Maintainers accept and triage security reports within the boundary described in
[SECURITY.md](../SECURITY.md). A security correction may intentionally fail
closed when retaining behavior would contradict a published safety guarantee.
## Final-v1 contract
## v1 compatibility contract
At final v1, semantic versions apply independently to the compiler and
For v1, semantic versions apply independently to the compiler and
`sando` runtime. Generated files record the exact compiler version and
required runtime ABI. Patch releases do not intentionally change accepted
source semantics or generated public signatures. Minor releases may add
@@ -35,7 +33,7 @@ codes, `himesan.json`, and generated provenance. English diagnostic wording,
internal packages, temporary paths, and compiler implementation details are not
stable API.
An API deprecated after final v1 remains available for the rest of the v1
An API deprecated during v1 remains available for the rest of the v1
major line and may be removed in v2. A security correction may fail closed in
a patch release when retaining old behavior would contradict a published safety
guarantee; that exception receives an advisory and migration note rather than a
@@ -58,7 +56,7 @@ support change is announced in release notes before it takes effect.
The following table is retained because the tests genuinely ran. It records a
point-in-time Beta 1 campaign and does not define the current support matrix.
The current public evidence is the exact Beta 1 source at commit
The historical Beta 1 evidence is bound to source commit
`b7a84054d755e42285e50298e41e47f06a8325a5` (tree
`be9e118e38dfebed19f60403ededdadabe07d2aa`):
@@ -80,7 +78,7 @@ module-cache path-selection ambiguity observed in the reverse order.
## Portability feedback
Developers may try the beta on an unsupported target and report useful gaps. A
Developers may try Hime-san on an unsupported target and report useful gaps. A
good report includes the operating system and architecture, `go version`, the
exact command, and a minimal reproduction or diagnostic output. Ordinary
portability reports belong on the canonical Gitea project. Suspected
+115
View File
@@ -0,0 +1,115 @@
<!-- SPDX-License-Identifier: AGPL-3.0-only -->
# Shared tools, commercial freedom
The design principle is **earn from useful work; preserve the shared freedoms
that made the work possible**. Commercial users are welcome. Sponsorship is
appreciated, not a license fee or a claim to project control. The intended users
are software developers and maintainers; v1 is a maintained compatibility
commitment, not a declaration that development has ended.
This document explains the [contribution agreement](../CLA.md) and official governance.
It is not a new software license, a downstream contract or a claim that every
future use or derivative of every component must be open source.
## Four different jobs
- The software license supplies recipients' permissions and obligations.
- The CLA records the rights for submitted contributions and reciprocal
promises by the named official steward; it is not a contract with every user.
- Governance determines official decisions, repository access and succession.
- The trademark policy addresses origin and endorsement, not ownership of
ideas or a veto on honest independent development.
Open-source commercial freedoms include competition. A subjective ban on
"greed," commercial hosting or businesses the maintainer dislikes would not
preserve those freedoms. We instead use concrete source-sharing, attribution,
no-hidden-relicensing and stewardship commitments. See the
[Open Source Definition](https://opensource.org/osd).
## The deliberate compiler/application boundary
The current [license map](../LICENSES.md) remains unchanged:
- Compiler/project material is AGPL-3.0-only. Distribution and covered modified
network use have source obligations under that license.
- The `sando` runtime is Apache-2.0. That is permissive, not network copyleft;
compliant closed-source derivatives are possible.
- User templates and generated applications may use their authors' chosen
terms, subject to input/dependency rights and the explicit output permission.
A proprietary paid website built with Hime is deliberately possible.
This protects the compiler's shared code without requiring its developers'
applications to become AGPL. Private production adoption is intentional: the
maintainer has confirmed this split for the release. The runtime's rendering,
escaping and URL-safety helpers are valuable implementation work; permissive
embedding makes them useful without imposing compiler licensing on applications.
It does not deliver "every part always open." Neither a later CLA nor a changed
README retracts existing recipients' licenses. No license conversion is proposed.
## Concrete cases
- A consultant sells a website built with Hime: allowed under the existing
application boundary; no mandatory payment, public badge or CLA for the client.
- A business distributes a modified compiler: it must follow the AGPL's
applicable source, licensing and notice requirements.
- A business operates a modified AGPL compiler with remote user interaction:
section 13 requires an offer of that version's Corresponding Source to those
interacting users. This is not necessarily every unrelated part of its service.
- A business merely hosts an unmodified program: hosting alone does not meet
section 13's modification condition. Wrappers and combined works require
fact-specific analysis, not an assumed universal SaaS prohibition.
- A company publishes a complying, independently branded fork: permitted,
even if it competes successfully and submits no changes upstream.
- A sponsor wants official control or private permission to close contributor
AGPL work: sponsorship grants neither; the steward covenant rejects
that official relicensing route. A fork cannot claim official endorsement.
These examples summarize boundaries, not legal opinions on a specific service.
The [AGPL text](https://opensource.org/license/agpl-3.0), including sections 2,
7, 10 and 13, controls actual covered uses. The
[Apache license](https://www.apache.org/licenses/LICENSE-2.0) controls the runtime.
The AGPL permits removing additional permissions from a redistributed copy;
do not promise that every independent fork must keep our output exception.
## What the contribution agreement adds
An identified contributor keeps ownership and grants only the recorded public
license plus an expressly authorized output permission. No alternate broad
sublicensing grant, copyright assignment, forced upstream labor, contributor
indemnity or proprietary buyout permission is collected. Patent rights and
termination follow the relevant established license.
The named Steward promises accurate attribution, preservation of contribution
records, public licensing of accepted material in official releases, no official
side deal to remove contributor copyleft, and written assumption of those duties
before a voluntary transfer of official stewardship. Those contractual promises
are not appended to downstream AGPL licenses. They cannot guarantee that a
project will never be abandoned, that a competitor will never outperform it,
or that every later actor is bound without agreement. Copyright enforcement
for contributor-owned work may require separate cooperation or authority.
Contributors remain free to license their own work elsewhere. This is reciprocal
stewardship rather than acquiring all rights from contributors. Existing public
licenses, usable source and the ability to fork preserve continuity if official
stewardship fails; governance and operational recovery still require real people.
## Deliberate adoption, without a barrier to learning
The AGPL compiler, Apache runtime and chosen application-license boundary is
settled. Version 1.0 of the contribution agreement is prospective: explicit
contributor and Steward acceptance is necessary, and no earlier contribution
is silently covered. The small recordkeeping process is in its section 9.
Nobody signs it merely to learn, download or build a private paid application.
The maintainer chose to proceed with this reviewed project-specific wording
without making outside legal review a release prerequisite. It is not an
ASF-approved agreement, a claim that counsel reviewed it, or a guaranteed
takeover shield. The [ASF ICLA](https://www.apache.org/licenses/icla.pdf) is a
useful comparison for contribution scope, authority and explicit acceptance;
its broader licensing grant is not imported into this agreement. Specific
future disputes or changes in jurisdiction may warrant professional advice.
The principle may inform other Gamertan projects, but each license, dependency
and contributor history needs its own decision. This document does not change
other repositories or turn "Canadian license" into a new license family.
+9 -3
View File
@@ -216,7 +216,13 @@ resolution and the public Go proxy after normal proxy propagation. Future
release decisions require fresh evidence for the maintained Linux/amd64 and
Darwin/arm64 targets rather than reusing this historical campaign.
## Open assurance gaps
## Historical pre-RC assurance gaps
The list below preserves the pre-RC assessment, not current completion status.
RC.1 native verification and artifact publication are recorded in
`../CHANGELOG.md`; the final-release queue is `../ROADMAP.md`. The v1
dispositions below distinguish required exact-candidate evidence from explicitly
accepted recovery deferrals.
- delivery to `security@sandwichhime.com` is owner-confirmed through a
controlled domain catch-all; encrypted reporting, documented backup, and
@@ -250,8 +256,8 @@ subject to exact-public-candidate review:
| Gap | v1 disposition |
| --- | --- |
| Security mailbox delivery, backup, and recovery | Release blocker. Complete the delivery/reply and recovery drill before RC publication. Encrypted reporting may remain optional if the supported confidential channel and its limit are stated accurately. |
| Artifact signing, provenance, and key recovery | Release blocker. Complete deterministic native artifacts, Developer ID notarization, signed-tag rehearsal, and recovery evidence. |
| Security mailbox delivery, backup, and recovery | Delivery/reply remains required and is maintainer-confirmed. Offline restoration and independent second-person recovery/verification are explicitly deferred assurance work for v1.0.0, not completed drills. Encrypted reporting may remain optional if the supported confidential channel and its limit are stated accurately. |
| Artifact signing, provenance, and key recovery | Deterministic native artifacts, Developer ID notarization and signed-tag evidence remain required for the exact release candidate. Offline signing-key restoration and independent second-person recovery/verification are explicitly deferred for v1.0.0; successful signing does not prove recovery. |
| Maintained native matrix | Release blocker for Linux/amd64 and Darwin/arm64 only. Other architectures and operating systems are explicitly unsupported, not silently untested promises. |
| Real-browser parser and supervisor evidence | Release blocker. The repository-owned gate covers a generated typed document, parsed structure, hostile-value inertness, and supervisor behavior. Execute it against the exact public candidate on both maintained hosts before publication. |
| Compiler resource budgets | Accepted v1 boundary. The compiler is a trusted local build tool; operating-system and runner limits own CPU, memory, and input quotas. No hostile-input resource guarantee is made. |
+26 -10
View File
@@ -16,13 +16,23 @@ releases originate only from the reviewed canonical public tree.
| Surface | Purpose | History and tags |
| --- | --- | --- |
| Private development storage | Working branches, private review records, and historical context | identities and history are not exported; no public release tags |
| Public Gitea `sandwich-hime` | Canonical sanitized source, contribution venue, module origin, and releases | fresh reviewed history; authoritative immutable `sando/vX.Y.Z` and `vX.Y.Z` tags |
| Public Gitea `sandwich-hime` | Canonical sanitized source, contribution venue, module origin, and releases | stable reviewed public history; authoritative immutable `sando/vX.Y.Z` and `vX.Y.Z` tags |
| GitHub `gamertan/sandwich-hime` | Discoverability and a convenient sanitized source snapshot | no private refs, force-mirrors, workflows, contribution authority, release artifacts, or semver tags |
Each public update is exported through the exact committed allowlist, inspected,
committed as a fresh public snapshot, and compared byte-for-byte with the
reviewed export. GitHub receives that public tree only. It never receives
private history or an indiscriminate Git mirror.
appended as a meaningful publication commit to the existing public `main`, and
compared byte-for-byte with the reviewed export. Development commits may be
squashed for publication; do not reset public ancestry for each version, merge
private history into public branches, or force-push existing releases. Versions
are immutable tags on that public history, not separate orphan branches.
Preserve contributor attribution, sign-offs and any output-permission grants
as required by [CONTRIBUTING.md](../CONTRIBUTING.md).
GitHub receives the reviewed public tree only. It never receives private
branches, private notes or an indiscriminate Git mirror. Branch names and
protected branches are not privacy boundaries: private development remains in
a separate access-controlled repository. The tutorial, tooling and website
remain independent projects, not archival branches of the compiler.
## Current readiness
@@ -65,9 +75,11 @@ Other demonstrated controls include:
- byte-identical generated output and independently reproduced release
archives across the maintained native evidence lanes.
The final immutable tags, clean direct/proxy installation, credential-recovery
drills, and public observation period remain publication or post-publication
gates rather than properties that source code can prove by itself.
The final immutable tags, clean direct/proxy installation and public observation
review remain publication or post-publication gates rather than properties
that source code can prove by itself. Offline restoration and second-person
recovery/verification are explicitly deferred assurance work for v1.0.0, as
recorded in [ROADMAP.md](../ROADMAP.md).
## Beta 1 publication lane
@@ -143,8 +155,9 @@ Required before security/native release-candidate work is declared complete:
committed outputs are current under that exact binary.
- [x] Produce deterministic archives/binaries, checksums, SBOMs, signatures,
and source/build provenance from a clean sanitized canonical checkout.
- [ ] Test release-key backup and two-person recovery for Gitea, domains,
signing material, and publication instructions.
- [x] Record the explicit v1.0.0 deferral of offline release-key restoration and
independent second-person recovery; retain the drills as assurance follow-ups
in [ROADMAP.md](../ROADMAP.md), without claiming they passed.
- [x] Make evidence gates validate content and commit identity rather than only
the presence of non-empty files.
- [ ] Rehearse runtime-first publication and rollback without creating public
@@ -162,7 +175,10 @@ Required before security/native release-candidate work is declared complete:
5. Operate the official Sandwich Hime website on the RC runtime for a 14-day
observation period with no unresolved Hime render, security, accessibility,
or rollback regression. This is product dogfooding, not a dependency on
another application's private repository.
another application's private repository. For v1.0.0 the maintainer accepted
the existing live-use experience despite missing timed checkpoint notes;
see [ROADMAP.md](../ROADMAP.md). This does not assert the missing reviews
occurred or waive a reproduced Hime defect.
6. Fix findings in a new RC; restart the observation period when the affected
boundary warrants it.
7. Finalize the changelog, supported-version table, migration notes, release