Files
pablan/docs/licensing.md
T
ProfessorNovaandClaude Opus 5 97dbff309c Pablan, as it stands
Self-hosted knowledge management for SMEs: a split-screen Markdown editor
whose sections an LLM refines while you write, and RAG question answering
over the documents that result. FastAPI + Postgres/pgvector on the back,
SvelteKit on the front, everything OpenAI-compatible and self-hostable.

Squashed into a single commit; the development history stays local.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CA43ZJda8Rbp2hKXNy8f6b
2026-09-04 08:36:17 +02:00

2.7 KiB

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.