License Selection Is Your First Business Decision
When starting an open source project, most people treat the license as an afterthought — “I’ll pick one later” or “MIT should be fine.” But the license defines the boundaries of what business models are possible.
Synthesizing the license choices of the eight companies analyzed in G4a through G4d, clear patterns emerge:
| Company | License | Revenue Model | License Change History |
|---|---|---|---|
| LangChain | MIT | Framework to LangSmith (SaaS) | None |
| LlamaIndex | MIT | Framework to LlamaCloud (SaaS) | None |
| CrewAI | MIT | Framework to Enterprise (SaaS) | None |
| Langfuse | MIT + EE | MIT core + paid Enterprise features | None |
| Dify | Conditional | Resale restrictions | None |
| Hugging Face | Apache 2.0 | Hub to compute sales | None |
| n8n | Fair-code | Free self-host to paid Cloud | None (Fair-code from start) |
| Elastic | SSPL to AGPL added | Self-host to paid Cloud | Apache to SSPL (AWS response) |
License Permissions and Restrictions Comparison
graph LR
subgraph PERMISSIVE["Permissive"]
MIT["MIT"]
APACHE["Apache 2.0"]
end
subgraph COPYLEFT["Copyleft"]
GPL["GPL v3"]
AGPL["AGPL v3"]
end
subgraph RESTRICTED["Restricted (Source Available)"]
BSL["BSL 1.1"]
SSPL["SSPL"]
FAIR["Fair-code"]
end
MIT -->|"+ Patent protection"| APACHE
APACHE -->|"+ Modification disclosure"| GPL
GPL -->|"+ Service included"| AGPL
AGPL -->|"+ Competing service ban"| BSL
BSL -->|"+ Full stack disclosure"| SSPL
style PERMISSIVE fill:#e8f5e9,stroke:#4caf50
style COPYLEFT fill:#e3f2fd,stroke:#2196f3
style RESTRICTED fill:#fff3e0,stroke:#ff9800| Aspect | MIT | Apache 2.0 | GPL v3 | AGPL v3 | BSL 1.1 | SSPL | Fair-code |
|---|---|---|---|---|---|---|---|
| View source code | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Modification | Yes | Yes | Yes (disclose) | Yes (disclose) | Yes | Yes | Yes |
| Commercial internal use | Yes | Yes | Yes | Yes | Yes | Yes | Yes |
| Redistribution | Yes | Yes | Yes (disclose) | Yes (disclose) | Restricted | Restricted | No |
| Offer as SaaS | Yes | Yes | Yes | Yes (disclose) | No | No | No |
| Fork & compete | Yes | Yes | Yes | Yes | No | No | No |
| Patent protection | No | Yes | Yes | Yes | Yes | Yes | Varies |
| OSI certified | Yes | Yes | Yes | Yes | No | No | No |
One-Line Summary of Each License
- MIT: “Take it and do anything. Just include the attribution”
- Apache 2.0: “MIT + automatic license termination in patent disputes”
- GPL v3: “If you modify it, the modified code must also be released under GPL”
- AGPL v3: “GPL + source disclosure required even when offering as a service”
- BSL 1.1: “Competing services prohibited. Automatically converts to open source after 4 years”
- SSPL: “To offer this as a service, you must disclose the entire service stack”
- Fair-code: “Internal use is free, resale is prohibited”
Decision Framework by Project Scale
Decision Flow
graph TD
START["Starting an open source project"] --> Q1{"Could the code\nitself become a\ncompetitive threat?"}
Q1 -->|"YES\n(Infrastructure, platform)"| Q2{"Could AWS/cloud\nproviders build a\nmanaged service?"}
Q1 -->|"NO\n(CLI, library, tool)"| Q3{"Is the revenue\nsource the code\nor content/services?"}
Q2 -->|"Likely"| R1["Fair-code / BSL\n(Defend from day one)"]
Q2 -->|"Unlikely"| Q4{"Are community\ncontributions\nessential?"}
Q3 -->|"Code"| Q4
Q3 -->|"Content / services"| R2["MIT\n(Maximum adoption)"]
Q4 -->|"YES"| R3["MIT / Apache 2.0\n(Minimize contribution friction)"]
Q4 -->|"NO"| R4["AGPL / MIT+EE\n(Defense + contribution balance)"]
style R1 fill:#fff3e0,stroke:#ff9800
style R2 fill:#e8f5e9,stroke:#4caf50
style R3 fill:#e8f5e9,stroke:#4caf50
style R4 fill:#e3f2fd,stroke:#2196f3Recommendations by Scale
| Project Scale | Characteristics | Recommended License | Reasoning |
|---|---|---|---|
| Solo side project | 0-100 users, no revenue | MIT | Maximize adoption; defense unnecessary |
| Solo + monetization attempt | 100-1K users, early revenue | MIT (non-code revenue) or AGPL (code revenue) | Branch based on revenue source |
| Startup (Seed-A) | 1K-10K users, VC-funded | Apache 2.0 + EE or BSL | Patent protection + competitive defense |
| Growth stage (Series B+) | 10K+ users, $1M+ ARR | Fair-code or BSL | AWS defense essential |
MIT vs Apache 2.0: When Is Apache Better?
The practical difference between the two licenses comes down to patent clauses:
- MIT: No mention of patents
- Apache 2.0: Contributors automatically grant a patent license. If a contributor files a patent lawsuit, the license automatically terminates
In patent-sensitive domains (AI algorithms, database engines, etc.), Apache 2.0 is safer. For CLI tools and utilities, MIT is sufficient.
MMU’s License Decision Process
Applying the Decision Criteria
| Question | MMU’s Answer |
|---|---|
| Could the code itself be a competitive threat? | No — the probability of AWS creating a managed service from a CLI checklist is zero |
| Is the revenue source the code? | No — revenue comes from Playbook Pack (content) and AI Coach (service) |
| Are community contributions essential? | Yes — maintaining 534 items alone is difficult |
| Patent issues? | No — no patentable technology involved |
Conclusion: MIT
Risk Assessment
| Risk | Probability | Impact | Mitigation |
|---|---|---|---|
| Someone forks and launches a competing CLI | Low | Low | Content differentiation (Playbook Pack) |
| Company adopts internally without contributing | Medium | Low | MIT’s adoption benefit outweighs contribution loss |
| Someone turns MMU into a SaaS | Very low | Medium | Content + AI Coach serve as defensive moats |
For MMU, Fair-code would be overkill. When there’s no “competitive threat” to protect against, blocking resale only reduces adoption without providing meaningful defense.
The Cost of Changing Licenses
“Start with MIT and change it if problems arise” is a strategy that’s theoretically possible but practically very expensive — this is the key lesson from the case studies covered in G4d.
Costs Incurred When Changing a License
| Cost Type | Details |
|---|---|
| Community trust | HashiCorp to OpenTofu fork. Developer community resentment |
| Legal complexity | Existing contributors’ consent required. Retroactive CLA (Contributor License Agreement) nearly impossible |
| Fork risk | Competing projects emerge based on the pre-change version |
| Enterprise customer confusion | Legal teams must review the new license, delaying adoption |
| Brand damage | ”It’s no longer open source” media and community criticism |
Once a license is set, changing it is hard. “Post-hoc change” is far more expensive than “upfront design.”
Practical Checklist
When starting an open source project, answering these five questions determines your license:
| # | Question | If YES | If NO |
|---|---|---|---|
| 1 | Will you earn money by selling the code itself? | Consider AGPL or above | MIT / Apache |
| 2 | Could a cloud provider build a service from your code? | Fair-code / BSL | MIT / Apache |
| 3 | Do you want to prevent contributor code from ending up in closed-source products? | GPL / AGPL | MIT / Apache |
| 4 | Is the technology patent-relevant? | Apache 2.0 | MIT works |
| 5 | Do you want to promise full open source conversion after 4 years? | BSL | Fair-code |
If the answer to all five is NO, choose MIT. This applies to the majority of solo projects.
CLA (Contributor License Agreement)
If there’s any possibility you may want to change your license in the future, it’s critical to have a CLA (Contributor License Agreement) in place from the start. Without a CLA, changing the license requires individual consent from every contributor — which is practically impossible at scale. One key reason Elastic, MongoDB, and HashiCorp were all able to execute their license changes was that they had secured CLAs from contributors upfront.
Even for solo projects, introduce a CLA once you start accepting external contributions. Tools like GitHub’s CLA Assistant can automate the process — the initial setup cost is low, but it preserves the flexibility to change your licensing strategy later.
Summary
| Key Point | Details |
|---|---|
| License = business model frame | Determines which monetization paths are possible and which are blocked |
| The most important question | ”Could your code itself become a competitive threat?” YES = defensive; NO = permissive |
| Solo project default | MIT (maximize adoption, no need for excessive defense) |
| Post-hoc change costs | Community trust, legal complexity, fork risk — expensive |
| MMU’s choice | MIT — revenue comes from content, not code, so defense is unnecessary |
The next post covers the series conclusion — Can a solo builder monetize open source without enterprise sales? It synthesizes the G4a-G5 analysis into a 5-stage framework that a single person can actually execute.
Related Posts
n8n's Fair-code Experiment — Neither Open Source Nor Proprietary
Analyzing n8n's Fair-code license strategy as a defense against AWS risk in open source monetization, and how licensing defines the boundaries of viable business models.
AI Search Engine Comparison: ChatGPT Search, Perplexity, AI Overviews
Comparative analysis of ChatGPT Search, Perplexity, and Google AI Overviews on accuracy, speed, and cost, with optimal engine recommendations for each query type.
GEO Definition and Structural Differences from SEO
Definition of GEO and its six structural differences from SEO. Proposes a new framework for brand visibility in an environment where AI search provides answers instead of link clicks.