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:
-
Dependency freedom: I want to freely adopt any dependency to further the project's features. The strongest copyleft license covers most cases.
-
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.
-
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.
-
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.