← All takes

TAKES

Which license should we pick?

Three people picked MIT. No two for the same reason.

Tap anyone to read and share their take on its own.

EVERYONE'S RIGHT

Every answer

AlexThe Architect“Write a license policy first. Every future repo inherits it.”
JoThe Cowboy“MIT. I already clicked it in the GitHub dropdown.”
RileyThe Minimalist“None. It's internal. Not publishing needs zero lawyers.”
TaylorThe AI Native“MIT, so anyone's agent can use it without a lawyer.”
MorganThe Threat Modeler“Apache 2.0. I want the patent grant in writing.”
ChrisThe Sovereign“AGPL. Whoever hosts it publishes their changes. Even our acquirer.”
PatThe Enterprise Adult“Whatever Legal already approved. The list is on the wiki.”
MayaThe Visionary“Whatever gets the most installs this week. So, MIT.”
NoraThe User Advocate“Whichever one our users' companies let them install.”
HugoThe Perfectionist“Proprietary until it has docs. Then Apache 2.0, with SPDX headers.”
RuthThe Maintainer“GPL, like in 2009. It still works. So does that code.”
GregThe Hedger“Dual license: AGPL for everyone, commercial for whoever wants out.”

🎯 SUPER REASONABLE

Super Reasonable, the advisor who never takes a side

A license is a business decision written in legal text. Start from what the code should do for the company, adoption, a hosted business, longevity or plain reuse, then check what your users' employers allow and what your legal team already supports. Pick the most common license that fits, write the reason down next to it, and keep the copyright clean so the choice can be revisited without drama.

  • What is the code for? Adoption points to MIT or Apache, a hosted business to AGPL or dual licensing.
  • Who will adopt it? Ask what their legal teams allow before you choose.
  • Do you need patent cover? Prefer Apache 2.0 when contributors or users hold patents.
  • Can you change your mind later? Keep copyright clean so relicensing stays possible.
Borrowed from

🔬 IN THE FIELD GUIDE

Species in this debate

The field guide →