# Licensing model

**Decision: Fair Source core (FSL-1.1-ALv2) + proprietary `ee/` layer.**

## How it works

- Everything outside `ee/` is licensed under the **Functional Source License
  1.1 with Apache 2.0 future grant** (`LICENSE` in repo root, text from
  fsl.software). Anyone may read, audit, self-host and use Pablan internally
  for free; offering a competing product/service based on the code is
  prohibited. **Each released version automatically becomes Apache 2.0 two
  years after its release** — the built-in trust promise: even if Pablan (the
  company) disappears, the code inevitably becomes true open source.
- `ee/` is proprietary (`ee/LICENSE`), activated via license key. Planned EE
  scope: OIDC/Entra ID SSO, fine-grained permissions beyond the basics, the
  management insights module, audit log, priority support.
- The free core is the funnel: small teams start free, grow, need SSO and
  permissions — that is where revenue begins (GitLab/Cal.com playbook,
  Sentry licensing).

## Rules that follow from this

1. **Never call it "Open Source"** in public communication — FSL is not
   OSI-approved. The correct, established term is **"Fair Source"**
   (fair.io). Using "open source" invites justified openwashing criticism.
   The two-year Apache conversion may and should be highlighted.
2. **Core must never import from `ee/`** — enforced by import-linter in CI.
   The core only offers extension points (mode registry, frontend slot
   registry, `ee_hooks.py`).
3. **CLA required from day one** if external contributions are ever
   accepted — without it we can never change the license later.
4. **Register the "Pablan" trademark.** The license protects code; the brand
   carries the trust. This also neutralizes forks: a fork may not be offered
   commercially (FSL) and must be renamed (trademark).
5. `LICENSE` (root) and `ee/LICENSE` exist from the first commit so the
   boundary is unambiguous in the entire history. The final wording of
   `ee/LICENSE` and the FSL fine print are owned by the legal co-founder
   with an IT lawyer.

## Rationale (short)

Considered alternatives: Open Core with MIT/Apache core (maximum trust, but
competitors may resell the core), AGPL + dual licensing (self-hosting
without distribution triggers no obligations → no revenue mechanism for our
deployment model, only FUD), fully proprietary (loses bottom-up adoption —
the only realistic sales channel for a three-person company). FSL + `ee/`
keeps the auditability that our target market actually means by "trust"
(every commit inspectable — critical when companies put their entire
internal knowledge into the system) while protecting against the one real
threat: a competitor commercializing our code.