Problem
Once the repo flips public (#147), we need an external-contributor onboarding doc plus a Contributor License Agreement (CLA) before merging any non-trivial PR from outside the maintainer set.
Today there is no `CONTRIBUTING.md`, no CLA, and no PR template. This was originally bundled into #147 but split out — the licensing change can ship without it (we control all current commits; no third-party PRs are pending), and the CLA decision deserves more deliberate thought.
Why a CLA, not a DCO
The project is licensed under FSL-1.1-Apache-2.0 (#147). The intent is to keep the public source under FSL while preserving the option to dual-license — granting separate commercial licenses to enterprise customers whose legal teams can't accept FSL terms.
A DCO alone would lock us into FSL forever and forfeit that option. A CLA explicitly grants the project owner a broad enough copyright/patent license to relicense contributed code, without needing every past contributor's consent.
We don't intend to relicense the public source — FSL stays — but the option matters for enterprise sales conversations.
TODOs
CLA mechanism
Documents
Wiring
Acceptance
Out of scope
Context
Split out from #147 at the maintainer's request — the FSL adoption can land without CLA/CONTRIBUTING infrastructure. They're an admission ticket for opening the repo to external PRs, not for going public read-only.
Problem
Once the repo flips public (#147), we need an external-contributor onboarding doc plus a Contributor License Agreement (CLA) before merging any non-trivial PR from outside the maintainer set.
Today there is no `CONTRIBUTING.md`, no CLA, and no PR template. This was originally bundled into #147 but split out — the licensing change can ship without it (we control all current commits; no third-party PRs are pending), and the CLA decision deserves more deliberate thought.
Why a CLA, not a DCO
The project is licensed under FSL-1.1-Apache-2.0 (#147). The intent is to keep the public source under FSL while preserving the option to dual-license — granting separate commercial licenses to enterprise customers whose legal teams can't accept FSL terms.
A DCO alone would lock us into FSL forever and forfeit that option. A CLA explicitly grants the project owner a broad enough copyright/patent license to relicense contributed code, without needing every past contributor's consent.
We don't intend to relicense the public source — FSL stays — but the option matters for enterprise sales conversations.
TODOs
CLA mechanism
Documents
Wiring
Acceptance
Out of scope
Context
Split out from #147 at the maintainer's request — the FSL adoption can land without CLA/CONTRIBUTING infrastructure. They're an admission ticket for opening the repo to external PRs, not for going public read-only.