Decide the code signing route: reapply to the SignPath Foundation later, or pay #358

Split out of #77, which had this as a cross-cutting line item. It is not an engineering task and it blocks several that are, so it deserves its own place.

Where things stand

The SignPath Foundation application — the free programme for open source — was declined for now. It is for projects with an established user base, and Skrog does not have one yet. They invited a reapplication as visibility grows.

Binaries are unsigned, SmartScreen warns on first run, and nobody has promised a date.

The two routes

The circularity, which is the real problem

free route  ->  needs adoption
adoption    ->  driven fastest by winget
winget      ->  wants a signed installer (an unsigned one asking for
                elevation is a worse first impression than a zip)
signing     ->  needs a certificate

And SmartScreen reputation only begins accruing after signing, so the warning persists for a while even once signed. Paying is the only move that breaks the loop without waiting on anyone else. That does not make it right — it makes it the one that does not depend on a third party's judgement of our popularity.

The part that is not about money

This is the bit worth deciding deliberately.

The Foundation issues the certificate to the project, and requires an OSI-approved licence with no commercial dual-licensing, for any component. A future paid tier would end eligibility. They can also pause or revoke, immediately or retroactively, over a Code of Conduct violation.

A purchased certificate costs money, but nobody can withdraw it over a licence change or a disagreement.

So the free route keeps a door open that the paid route closes, and vice versa. If a paid tier is ever plausible — ROADMAP lists a priority-support tier as a sustainability idea — accepting a Foundation certificate later is the thing that forecloses it.

What a decision unblocks

• Installer: WiX MSI (blocked on code signing) #77 — WiX MSI, winget, scoop, choco
• long term: reach the wslc root namespace through the WSL Plugin API (WSLCCreateProcess/WSLCProcessGetFd) once skrog binaries are signed #325 — the WSL Plugin API, which needs a signed DLL for wslservice.exe to load it

What is already true regardless

Every release carries SLSA build provenance and a cosign-signed SHA256SUMS, which answer "was this built by that workflow, from that commit" — a question an Authenticode signature does not answer. Not a substitute for signing, and documented as such. See docs/code-signing.md, which also keeps the roles and CI-only signing rules ready for whichever route wins.

Options, for the record

1. Wait and reapply. Free, no decision now, indefinite.
2. Pay. Unblocks everything immediately; costs money; keeps a commercial option open later.
3. Wait, but push visibility deliberately — the upstream posts on microsoft/WSL, docs SEO, a Show HN — and reapply at a threshold decided in advance rather than "when it feels like enough".

Option 3 is the only one that treats the circularity as a plan rather than a trap; it is also the slowest.