# ADR-0004: AGPLv3 for Platform Code

- **Status:** Accepted
- **Date:** 2024-06-01
- **Deciders:** FablePool core team
- **Related:** ADR-0005 (content license), ADR-0009 (widget sandboxing)

## Context

FablePool is a community-owned alternative to a commercial product. The
license must protect the commons against the most likely failure mode for
this category: a well-funded actor taking the platform, running it as a
closed SaaS with proprietary improvements, and out-competing the community
deployment without contributing back. Because the platform is *used over a
network*, ordinary GPL does not trigger source-sharing obligations for SaaS
operators — the "ASP loophole."

Forces:

- **Protect against SaaS enclosure** — the primary threat model.
- **Encourage contributions back** from anyone operating the platform.
- **Not deter contributors or self-hosters.** Schools, clubs, and
  individuals must be able to run instances without legal anxiety.
- **Keep content and code licensing separable** — educational content has
  different reuse dynamics than code (ADR-0005).
- **Allow widgets/plugins by third parties** without forcing every widget
  author into AGPL if they merely target our sandbox API.

## Decision

License all platform code (backend, frontend, infrastructure, tooling)
under the **GNU Affero General Public License v3.0 (AGPLv3)**.

Accompanying policy decisions:

1. **No CLA; DCO instead.** Contributors sign off commits
   (`Signed-off-by`, Developer Certificate of Origin). There is no
   copyright assignment and therefore **no entity that can unilaterally
   relicense** — the AGPL commitment is structural, not just stated.
2. **Widget boundary clarification.** Sandboxed widgets communicate with
   the platform only via the postMessage protocol defined in
   `07-widget-sandboxing.md`. We publish that protocol specification and
   the TypeScript SDK types under **MIT**, and document our position that
   widgets which only use this interface are independent works and may
   carry any license. This keeps the widget ecosystem open to all authors
   while the platform core remains AGPL.
3. **JSON Schemas and API specifications** in `docs/schemas/` are released
   under **CC0** so any tool, importer, or competing implementation can
   adopt the formats freely — format adoption benefits the commons.
4. Every source file carries an SPDX header
   (`SPDX-License-Identifier: AGPL-3.0-only`); CI checks for it.

## Alternatives Considered

- **MIT/Apache-2.0.** Maximizes adoption, but offers zero protection against
  proprietary SaaS forks — directly contrary to the project's
  community-ownership goal. Rejected.
- **GPLv3.** Closes less than AGPL: a SaaS operator never "distributes" and
  thus never owes source. Rejected.
- **SSPL / BSL / fair-source.** Not OSI-approved; would exclude FablePool
  from Debian/Fedora ecosystems, many corporate contribution policies, and
  the trust of the open-source community we are trying to build. Rejected.
- **AGPL with a CLA enabling dual licensing.** A CLA concentrates power to
  relicense in one entity — recreating the enclosure risk internally.
  Rejected in favor of DCO.

## Consequences

- ✅ Anyone offering FablePool over a network must offer the source of their
  modified version to its users (AGPL §13) — improvements flow back.
- ✅ No relicensing chokepoint; the community can trust the terms are
  permanent.
- ⚠️ Some companies categorically avoid AGPL dependencies; we accept losing
  those contributors. Note this only restricts *using FablePool's code*,
  not using a FablePool *instance* or its API.
- ⚠️ "AGPL-3.0-only" (not "-or-later") is chosen deliberately; with no CLA,
  moving to a hypothetical future license version would require consent of
  all contributors. We accept this rigidity as the price of trust.
- ℹ️ Self-hosters who modify the code satisfy §13 by linking their source
  from the instance footer; the platform ships a built-in "Source code"
  link that admins must point at their fork — making compliance a config
  field, not a legal project.