gamertan/sandwich-hime
1
0
Fork 0
Code Issues Pull Requests Actions Releases 4 Activity

Release Sandwich Hime v1 source and contribution policy

Browse Source 
Signed-off-by: Cole Speelman <crspeelman@gmail.com>
This commit is contained in:
gamertan
2026-09-09 09:33:44 -04:00
parent 7e89ebfaba
commit d978994b27
22 changed files with 636 additions and 104 deletions
Download Patch File Download Diff File Expand all files Collapse all files
GOVERNANCE.md
+28 -2
View File
@@ -4,10 +4,36 @@
Sandwich Hime is founder-led. Cole Speelman is lead maintainer and has final authority over product direction, merges, releases, project identity, and security coordination. Authority is exercised through reviewable public releases, written rationale for material public decisions, and the published compatibility and release policies. Publishing a prerelease creates only the support commitment stated for that version; it does not transfer stewardship.
Pre-1.0 contributions use the DCO process described in `CONTRIBUTING.md`; the CLA draft is inactive. Acceptance is never guaranteed. Maintainers may close work that expands the product beyond an HTML-first, ahead-of-time Go template engine, weakens fail-closed safety, couples the runtime to a framework, or imposes unsustainable maintenance.
New contributions use the DCO and prospective versioned agreement process in
`CONTRIBUTING.md`. Acceptance is never guaranteed. Maintainers may close work
that expands the product beyond an HTML-first, ahead-of-time Go template engine,
weakens fail-closed safety, couples the runtime to a framework, or imposes
unsustainable maintenance.
Maintainers disclose relevant employment or financial conflicts and recuse when a conflict would compromise review. If the project reaches three maintainers, no single employer may control a majority of seats.
Repository ownership, domain control, package namespace, release signing, and security recovery must not depend on a sponsor account. Before a supported v1.0.0 release, at least two independent humans must hold documented recovery capability. Succession may transfer official stewardship to a person or mission-aligned organization committed to the license map, public source releases, and trademark policy.
Repository ownership, domain control, package namespace, release signing, and security recovery must not depend on a sponsor account. Independent recovery capability remains a governance aim; the maintainer explicitly deferred offline restoration and second-person recovery/verification for v1.0.0. They remain unproven assurance follow-ups in `ROADMAP.md`, not a claim of resilient stewardship. Succession may transfer official stewardship to a person or mission-aligned organization committed to the license map, public source releases, and trademark policy.
The project does not accept copyright assignment as a condition of contribution. It will not represent that it can proprietary-relicense contributor-owned code unless it has permission from every rights holder whose permission is required. This governance statement does not alter rights already granted by an applicable file license.
## Shared value and independent stewardship
Official stewardship preserves the compiler's open, reciprocal licensing.
Commercial users, paid services and compliant independent forks are welcome;
funding does not purchase ownership, a governance seat, a veto, or authority to
erase attribution. Maintainers must not use a contribution agreement or private
side deal to remove copyleft from accepted contributor-owned AGPL work. The
existing runtime and output permissions remain deliberate separate boundaries.
Material licensing, governance and stewardship transfers require a public
rationale and respect for recorded rights; a vote or repository transfer cannot
supply someone else's copyright permission. A successor to a contribution
agreement must expressly assume its steward obligations. Preserve accessible
released source and provenance so lawful community continuation remains possible
without ownership of official domains, release accounts or marks. This is not a
promise of perpetual free hosting or a restriction on independent fork rights.
The reciprocal agreement requires explicit contributor and Steward acceptance.
Publication alone does not bind a contributor, an earlier submission or an
unrelated third party. No agreement is required to learn or use the software.
See [Licensing intent](docs/LICENSING_INTENT.md) for the distinctions and limits.