Projects/Personal Site/Architecture Decisions

ADR 037: AGPL-3.0 License

Context

This project had no license, which means no one has legal rights to contribute, fork, or build upon it. I need to choose a license that aligns with my goals:

  1. Dependency freedom: I want to freely adopt any dependency to further the project's features. The strongest copyleft license covers most cases.

  2. Build in public without strategic doubt: AGPL's strong copyleft means anyone who builds on this work must also open-source their modifications. This removes the concern that sharing openly could enable a closed-source competitor. Combined with my retained rights as author (see next point), I can focus purely on building without second-guessing what should be public.

  3. Preserve future flexibility: As the sole author, I retain rights to my code regardless of the public license—I can create a differently-licensed fork at any time. A Contributor License Agreement (CLA) extends this flexibility to contributions, enabling potential open-core models or license changes without legal complications.

  4. Aligned with agile principles: Don't predict the future. Enable optionality rather than hamstringing myself with premature decisions.

Alternatives Considered

  • MIT/Apache: Too permissive. Allows proprietary forks without contributing back. Doesn't match my "build in public" philosophy.

  • GPL: Strong copyleft, but AGPL adds the network clause. Important for a web project where someone could run a modified version without distributing.

  • No license (status quo): Blocks all contributions. Not viable if I want community involvement.

Decision

Use AGPL-3.0 with a Contributor License Agreement.

The AGPL-3.0 ensures that any modifications—including those deployed over a network—must share source code. This matches my goal of building in public.

The CLA grants me relicensing rights over contributions, preserving future flexibility (open-core, license changes) while keeping all current code open under AGPL-3.0.

CLA enforcement is handled by cla-assistant, which prompts contributors to sign when they open a pull request.

Consequences

Pros

  • Strongest copyleft: Derivative works must remain open source, including network deployments.
  • Dependency compatibility: Can incorporate most copyleft-licensed code.
  • Clear open-source stance: No ambiguity about the project's nature.
  • Future optionality: CLA preserves ability to relicense or create proprietary versions without contributor coordination.

Cons

  • May deter some contributors: AGPL has stigma in corporate environments. Some companies prohibit employees from contributing to AGPL projects.
  • CLA friction: Contributors must sign before their first PR merges. Minimal friction with cla-assistant, but still an extra step.