# FablePool Kite Map — Open Source Project Charter

**Document:** 09 — Project Charter
**Status:** Adopted (v1.0)
**Applies to:** All repositories under the FablePool Kite Map project

---

## 1. Mission

Build and maintain a free, open-source web application that helps kite flyers —
casual flyers, sport/stunt kiters, and kite surfers — find good places and good
moments to fly, by combining open map data, open weather/wind forecasts, and a
community-maintained database of flying spots.

**One-line mission:** *"Google Maps, but for kites — open data in, open data out."*

## 2. Scope

### In scope
- The web client (map view, spot details, forecast panel, flyability scoring UI).
- The backend API (spot CRUD, forecast proxy/cache, scoring engine, auth).
- The flyability scoring rubric and its reference implementation
  (see `docs/05-flyability-scoring.md`).
- The community spot database: schema, moderation tooling, import/export.
- Public, documented REST API (`api/openapi.yaml`) so third parties can build on it.
- Deployment artifacts (Docker, infra-as-code) for self-hosting.

### Out of scope (for the core project)
- Native mobile apps (welcome as sibling community projects consuming the API).
- Commercial/paid features, ads, or telemetry beyond anonymous, opt-in metrics.
- Any dependency that requires a paid API key for core functionality. Optional
  integrations behind feature flags are acceptable if the app fully works
  without them. This is a **founding constraint**, not a preference — see §6.

## 3. Core principles

1. **Open by default.** Code, data schemas, scoring rubric, and design docs are
   public from day one. Decisions are made in public issues/discussions.
2. **No paid-API lock-in.** Core functionality must run on free, open data
   sources (OpenStreetMap, Open-Meteo, NOAA). Swappable provider interfaces are
   mandatory wherever an external service is consumed
   (see `docs/04-data-sources.md` and `docs/08-architecture.md`).
3. **Self-hostable.** Anyone must be able to run the full stack from a clean
   checkout with `docker compose up` and zero paid credentials.
4. **Community data stays with the community.** Spot data contributed by users
   is licensed so that it can never be enclosed by a single party, including us
   (see §5.2).
5. **Safety-honest.** Flyability scores are advisories, not guarantees. The UI
   and docs must always present them with appropriate caveats, especially for
   kite surfing (offshore wind warnings, gust ratios — see
   `docs/05-flyability-scoring.md` §7).
6. **Privacy-respecting.** No tracking pixels, no third-party analytics by
   default, minimal account data, GDPR-friendly data export and deletion.

## 4. Governance

### 4.1 Roles

| Role | Who | Powers |
|---|---|---|
| **Maintainers** | Initially the founding team; expanded by maintainer vote | Merge rights, release tagging, security response, moderation of spot data disputes |
| **Committers** | Contributors with sustained quality contributions, nominated by a maintainer, approved by lazy consensus of maintainers (72 h) | Merge rights on designated areas (e.g., frontend, scoring engine, docs) |
| **Contributors** | Anyone who opens a PR, issue, spot edit, or translation | Recognition in `CONTRIBUTORS.md`; voice in discussions |
| **Spot Moderators** | Trusted community members per region | Approve/reject spot submissions and edits in the moderation queue |

### 4.2 Decision making

- **Default:** lazy consensus. A proposal (issue or RFC PR) is accepted if no
  maintainer objects within 72 hours of a maintainer +1.
- **Substantial changes** (license, governance, scoring rubric semantics,
  public API breaking changes) require an **RFC**: a PR against `docs/rfcs/`
  open for at least 14 days, then a maintainer vote. Pass = 2/3 of maintainers
  voting, minimum quorum of two.
- **Tie-breaking:** while the project has fewer than five maintainers, the
  founding maintainer holds a casting vote. This clause dissolves automatically
  once the maintainer team reaches five members; thereafter ties fail.
- **Vetoes:** any maintainer may veto a change *with a written technical or
  mission-based rationale*. A veto can be overridden by a 2/3 maintainer vote.

### 4.3 Maintainer lifecycle

- **Adding:** nomination by an existing maintainer; approved by 2/3 vote.
  Candidates should have ≥ 3 months of sustained, high-quality contribution.
- **Stepping down:** maintainers may resign at any time; they move to an
  honorary "emeritus" list.
- **Removal:** for Code of Conduct violations or 6+ months of unexplained
  inactivity, by 2/3 vote of the other maintainers.

### 4.4 Releases

- Semantic versioning for the API (`/v1` path prefix is the contract; see
  `docs/07-api-contract.md` §2) and for tagged releases of the application.
- A release requires: green CI, changelog entry, and sign-off by one maintainer
  who did not author the majority of the release's changes (when team size allows).
- Security fixes may be released by any single maintainer immediately,
  with retroactive review.

### 4.5 Security policy

- Private disclosure via the `SECURITY.md` contact (security@ project address).
- Target: acknowledgement within 72 hours, fix or mitigation within 30 days
  for high-severity issues.
- Coordinated disclosure credit given to reporters unless they decline.

## 5. Licensing

The project deliberately uses **different licenses for code, data, and
documentation**, because they have different enclosure risks.

### 5.1 Code — MIT License

All source code (backend, frontend, scoring engine, infra) is licensed under
the **MIT License** (see `LICENSE`).

**Rationale:**
- **Maximum adoption.** We *want* kite clubs, weather hobbyists, and even
  commercial kite shops to embed the map, fork the scoring engine, or build
  native apps. A permissive license removes every barrier to that.
- **Ecosystem compatibility.** Our core stack is permissively licensed
  (Leaflet/MapLibre: BSD-3-Clause, FastAPI: MIT, React: MIT). MIT keeps the
  whole dependency graph friction-free for downstream users.
- **Why not AGPL?** AGPL would prevent proprietary SaaS forks of the *code*,
  but our analysis (see `docs/04-data-sources.md` §6) concluded the project's
  real moat and community value is the **spot database and scoring rubric
  refinements**, not the code. We protect those at the data layer instead
  (§5.2), which is both stronger in practice and friendlier to integrators.
  AGPL also creates adoption hesitancy in exactly the organizations (clubs,
  schools, tourism boards) we most want as deployers.
- **Why not GPL/LGPL?** Same reasoning; copyleft on a CRUD-plus-map web app
  protects little of unique value while taxing every embedder.

### 5.2 Community spot data — ODbL 1.0

The community spot database (spot locations, descriptions, hazards,
launch-zone geometries, condition reports) is licensed under the
**Open Database License (ODbL) 1.0** — the same license as OpenStreetMap.

**Rationale:**
- **Share-alike where it matters.** Anyone may use, redistribute, and build on
  the spot database, but improvements to the *database itself* must be shared
  back under ODbL. This is the actual anti-enclosure guarantee: nobody —
  including the project's own maintainers or any future corporate sponsor —
  can take the community's spot data proprietary.
- **OSM compatibility.** Many spots will be seeded from or cross-referenced
  with OSM data. Using ODbL eliminates license-mixing questions in both
  directions and lets us contribute corrections upstream to OSM.
- **Produced Works clause.** ODbL permits "produced works" (rendered maps,
  screenshots, printed spot guides) under any license, so a kite school can
  put our map in a paid PDF guide — only *database extractions* trigger
  share-alike. This is the right balance.
- Contributors agree to ODbL for their spot submissions via the contributor
  terms presented at sign-up and recorded with `terms_accepted_at` in the
  `users` table (`docs/06-database-schema.md`).

### 5.3 Documentation, wireframes, and the scoring rubric text — CC BY 4.0

Design docs (`docs/*`), the written scoring rubric, and wireframe descriptions
are licensed **Creative Commons Attribution 4.0 International**, so kite clubs
and safety organizations can translate, adapt, and republish them with credit.
(The rubric's *implementation* in code is MIT per §5.1.)

### 5.4 Contributor terms

- **No CLA.** We use the **Developer Certificate of Origin (DCO)**: every
  commit must carry a `Signed-off-by:` line (`git commit -s`). This certifies
  the contributor has the right to submit the work under the project's
  licenses, without assigning copyright to anyone. See `CONTRIBUTING.md` §7.
- Copyright remains with each contributor. The project is a collective work;
  the `LICENSE` copyright line reads "The FablePool Kite Map Contributors".
- **Relicensing** of code, data, or docs is a Substantial Change (§4.2) and
  additionally requires that the new license be no less open (OSI-approved for
  code; Open Definition-conformant for data).

### 5.5 Third-party data attribution obligations

Deployments **must** display, and the reference client **does** display:
- `© OpenStreetMap contributors` with a link to the OSM copyright page, on the
  map at all times (ODbL requirement).
- Attribution for the active weather provider ("Weather data by Open-Meteo.com",
  CC BY 4.0; NOAA data is US-public-domain but is credited as a courtesy).

These attributions are wired into the map component and the provider adapter
metadata (`docs/04-data-sources.md` §5.3) so forks inherit them by default.

## 6. The "no paid lock-in" guarantee (binding)

The following are charter-level requirements; violating them in a PR is
grounds for veto without further justification:

1. Every external service is consumed through a provider interface with at
   least one zero-cost, keyless default implementation.
2. CI runs the full test suite, including integration tests against recorded
   fixtures, with **no secrets configured**.
3. `docker compose up` on a clean machine must yield a working app (map tiles,
   forecasts, scoring) using only free endpoints, subject to the providers'
   public rate limits.
4. Optional paid/keyed providers (e.g., commercial tile servers for
   high-traffic deployments) live behind config flags, are off by default, and
   are documented as optional.

## 7. Trademark and name

"FablePool Kite Map" and the project logo (when created) are held in trust by
the maintainer team. Forks must rename if they diverge in scoring semantics or
data-moderation policy, to protect users' safety expectations. Faithful
self-hosted deployments may use the name with a "community instance" label.

## 8. Funding and transparency

- Crowd-funding income and any future sponsorships are recorded on a public
  ledger in the repository (`FUNDING.md`, to be added when funds beyond the
  current milestone exist).
- Funds may be spent on: infrastructure for the flagship instance, security
  audits, accessibility audits, and bounties for issues labeled `funded`.
- Funds may **not** be spent on: paid data sources for core features (§6),
  advertising user data, or anything conflicting with §3.

## 9. Code of Conduct

The project adopts the **Contributor Covenant v2.1** (see
`CODE_OF_CONDUCT.md`). It applies to all project spaces: repositories, issue
trackers, chat, spot-moderation discussions, and project events. Enforcement
is handled by the maintainer team per the ladder defined in that document; a
maintainer who is the subject of a report recuses themselves.

## 10. Amendments

This charter may be amended by the RFC process (§4.2, Substantial Change),
except that §3 (Core principles), §5.4 (relicensing floor), and §6 (no paid
lock-in) may only be amended by a unanimous vote of all active maintainers
plus a 14-day public comment period with no sustained community objection.

---

*Adopted with milestone 1. Version history is tracked in git.*