TL;DR: Crush is FSL-1.1-MIT (converts to MIT after 2 years), but all Charm libraries it depends on are already MIT/Apache-2.0. You can study the architecture, use the libraries, and build your own tool with independent code. Just don't copy Crush's actual code or fork the repo for a competing product. Clean room implementation is your friend.

FSL-1.1-MIT License Analysis: Building Alongside Crush

Status: Complete

Analysis of the Functional Source License as it applies to building an independent agentic coding tool that shares architectural patterns with Crush.

The License: FSL-1.1-MIT

Licensor: Charmbracelet, Inc. Applies to: Crush (github.com/charmbracelet/crush) only Does NOT apply to: Charm's open-source libraries (Fantasy, Bubble Tea, Lipgloss, etc.)

The FSL-1.1-MIT grants the right to use, copy, modify, create derivative works, publicly perform, publicly display, and redistribute the Software for any Permitted Purpose.

A Permitted Purpose is any purpose other than a Competing Use.

What "Competing Use" Means

The license defines Competing Use as making the Software available to others as a commercial product or service that:

Substitutes for the Software (Crush itself)
Substitutes for any other product/service the Licensor offers using the Software
Offers the same or substantially similar functionality as the Software

Always Permitted (Regardless of Competing Use)

Internal use and access — running the software inside your organization
Non-commercial education — studying, teaching, learning
Non-commercial research — academic and personal research
Professional services — provided to a licensee using the Software

The Gray Area: "Substantially Similar Functionality"

Prong 3 is the broadest and most legally ambiguous. Licensing experts (including Thierry Carrez, GM of the Open Infrastructure Foundation and OSI board member) acknowledge that "much is open to interpretation" regarding noncompete rules in source-available licenses.

There is no established case law interpreting "substantially similar functionality" under FSL specifically.

The 2-Year Conversion

The license states: "We hereby irrevocably grant you an additional license to use the Software under the MIT license that is effective on the second anniversary of the date we make the Software available."

Key details:

Per-release: Each version starts its own 2-year clock
Irrevocable: Cannot be taken back
Additive: MIT rights are added on top of FSL rights
Timeline: Crush's initial release (~mid-2025) converts to MIT ~mid-2027. New releases continue to be FSL-protected for their first 2 years.

What You Can and Cannot Do

Clearly Permitted

Activity	Why It's Permitted
Reading and studying Crush's code	Explicitly listed as "non-commercial education"
Running Crush internally	Explicitly listed as "internal use and access"
Modifying Crush for internal use	Explicitly permitted
Learning architectural concepts from Crush	Ideas are not copyrightable (idea-expression dichotomy)
Implementing the same concepts independently	Copyright protects expression, not ideas
Using Charm's open-source libraries (Fantasy, Bubble Tea, etc.)	These are MIT/Apache-2.0, not FSL
Contributing improvements back to Crush	Explicitly permitted
Using old versions that have passed 2-year conversion	Full MIT license applies

Clearly Prohibited

Activity	Why It's Prohibited
Forking Crush and selling a competing commercial product	Textbook Competing Use
Copying Crush's code into a competing product	Copyright infringement + license violation
Rebranding Crush and offering it commercially	Direct substitution
Removing copyright notices from redistributed copies	License requirement

Gray Areas (Higher Risk)

Activity	Risk Level	Analysis
Building a full agentic coding CLI with overlapping features	Medium	Depends on how "substantially similar" the functionality is
Copying specific file/package structure	Medium	Could be seen as copying creative expression vs. functional necessity
Using code snippets from Crush	High	Combines copyright infringement with potential license violation

Ideas vs. Expression: What Copyright Protects

Ideas, algorithms, architectures, and patterns — NOT copyrightable, free for anyone to use
Specific expression (actual code, unique creative choices in implementation) — IS copyrightable

Doctrines That Protect Independent Implementation

Merger Doctrine: When there are limited ways to express an idea, the idea and expression merge, and the expression is not protectable. An LLM agent loop that sends messages, handles tool calls, and persists results has very few ways to be structured.

Scenes a Faire Doctrine: Standard patterns common to a genre are not copyrightable. For LLM coding agents, these include:

A main loop sending messages to an LLM and processing tool calls
A tool execution framework with typed parameters
File operations (view, edit, write, glob, grep)
Shell execution with permission checks
MCP integration
TUI with chat display and input

These are dictated by the problem domain (how LLM APIs work, how terminals work, what MCP defines), not creative choices unique to Crush.

What IS Unique Creative Expression in Crush

The specific text of system prompt templates
Unique UI design choices (specific layout compositions, animation details)
Novel algorithmic approaches (if any exist beyond standard patterns)
The specific prose in tool descriptions
Creative naming conventions beyond the functional (e.g., "Catwalk" for model registry)

The FSL "Competing Use" vs. Copyright: A Key Distinction

The FSL's Competing Use restriction is a contractual term, not a copyright claim. This matters:

Copyright protects expression. Independent implementation of the same ideas does not infringe copyright.
FSL Competing Use is broader — it restricts certain uses of the Software itself, regardless of whether you copy expression.
BUT: the contractual restriction only binds you if you "use" the Software (run, copy, modify Crush's actual code).

If you never use Crush's code — never run it, never copy from it, never modify it — the FSL's Competing Use clause has weak grounds to apply to you. You'd only be subject to normal copyright law, which protects expression, not ideas.

If you study Crush's code for education (explicitly permitted), then independently write your own code, the question becomes: was studying the code "use of the Software" for a "Competing Use"? The license explicitly permits education/research as a Permitted Purpose, which creates tension with the Competing Use restriction if the education later informs a competing product. This is legally untested territory for FSL.

The OpenCode Lineage

Crush has a notable history relevant to licensing:

OpenCode was created by Kujtim Hoxha under MIT license
Charm hired the original author; the project was relicensed to FSL-1.1-MIT
SST forked the MIT-licensed version and continued as sst/opencode (later anomalyco/opencode)
Crush's LICENSE.md acknowledges the history with a separate MIT license section for code by Kujtim Hoxha dated 2025-03-21 to 2025-05-30

This means:

The pre-FSL codebase has an MIT-licensed lineage available through SST's fork
New features added to Crush after the FSL relicensing are only available under FSL terms
The core architecture (agent loop, tool system, TUI patterns) was present in the MIT era

The HashiCorp/OpenTofu Precedent

The most relevant real-world precedent for navigating source-available licenses:

HashiCorp changed Terraform from MPL to BSL (August 2023)
Community forked the last MPL version as OpenTofu (via Linux Foundation)
HashiCorp sent a cease-and-desist alleging OpenTofu copied BSL-licensed code (April 2024)
OpenTofu responded with line-by-line analysis showing code was derived from pre-BSL MPL version
OpenTofu had instituted a "taint team" — a clean-room-like process where a separate team reviewed PRs to ensure no BSL code was included

Key lessons:

Forking the pre-license-change version is legal for open-source predecessors
Clean room processes matter for defensibility
Line-by-line provenance matters — tracing every line to a permissibly-licensed source
The dispute was never fully litigated (HashiCorp was acquired by IBM)

FSL-1.1 vs. BSL Comparison

Aspect	FSL-1.1	BSL 1.1
Conversion period	2 years (fixed)	Up to 4 years (variable)
Conversion license	MIT or Apache 2.0 (fixed)	GPL-compatible (variable)
Restriction scope	"Competing Use" (specific)	"Production Use" (broad, variable)
Consistency	Every FSL is the same license	Every BSL is effectively different
Notable users	Sentry, Codecov, Crush, PowerSync	HashiCorp, MariaDB, CockroachDB

FSL is more predictable and narrower than BSL. It only restricts competing commercial use, not all production use.

Charm Library Licensing (Verified)

Critical finding: ALL Charm libraries used as dependencies are permissive open-source. FSL applies ONLY to Crush itself.

Library	Import Path	License	Verified
Fantasy	`charm.land/fantasy`	Apache-2.0	GitHub + pkg.go.dev
Catwalk	`charm.land/catwalk`	MIT	GitHub + pkg.go.dev
Bubble Tea v2	`charm.land/bubbletea/v2`	MIT	GitHub + pkg.go.dev
Bubbles v2	`charm.land/bubbles/v2`	MIT	GitHub + pkg.go.dev
Lip Gloss v2	`charm.land/lipgloss/v2`	MIT	GitHub + pkg.go.dev
Glamour v2	`charm.land/glamour/v2`	MIT	GitHub + pkg.go.dev
Log v2	`charm.land/log/v2`	MIT	GitHub + pkg.go.dev

Using these libraries in any product — including a commercial competitor to Crush — is fully permitted by their licenses.

Clean Room Implementation

Traditional Clean Room Design

Team A ("dirty room"): Studies the original software, creates a functional specification describing what it does (not how)
Team B ("clean room"): Implements the specification without ever seeing the original code
Separation: Team B has zero exposure to the original source

This provides evidence that similarities are due to functional requirements, not copying.

For a Solo Developer

A pure clean room isn't practical for a solo developer who has already studied Crush's code. Instead, the equivalent protections are:

Document your independent design decisions — architecture docs, design rationale, whiteboard sketches
Write all code from scratch — no copy-paste, no "type along while reading"
Differentiate your feature set — focus on capabilities Crush doesn't have
Use the permissive libraries directly — Fantasy, Bubble Tea, etc. are yours to use freely
Reference the MIT-licensed OpenCode lineage when studying foundational patterns

Risk Assessment Summary

Low Risk (Green Light)

Using Charm's MIT/Apache-2.0 libraries (Fantasy, Bubble Tea, Lipgloss, etc.)
Studying Crush's architecture for education
Building a tool with different primary features (multi-agent teams, Docker integration)
Implementing standard LLM agent patterns (agent loop, tool execution, chat TUI)
Writing all code independently from scratch

Medium Risk (Proceed with Caution)

Building a tool with significant feature overlap if distributed commercially
Using Crush-specific creative expressions (prompt text, unique UI designs)

High Risk (Avoid)

Copying any actual code from Crush
Forking Crush's repository
Directly replicating Crush's feature set without differentiation

Recommendations

Build from scratch, using only permissive libraries. All Charm libraries are MIT/Apache-2.0. Use them freely.
Differentiate features. Multi-agent teams, Docker integration, and team orchestration are features Crush explicitly does NOT have. This is strong differentiation.
Document your design process. The architecture docs, implementation plans, and design decisions you've already created serve as evidence of independent design.
Don't copy code. Write every line yourself. Similar patterns are fine (they're dictated by the problem domain). Similar code is not.
Consider the OpenCode MIT fork as reference for foundational patterns rather than current FSL-licensed Crush.
The 2-year clock is ticking. Crush's initial release converts to MIT ~mid-2027. Older code progressively becomes fully open.

DISCLAIMER: This is legal research and analysis, not legal advice. For decisions affecting commercial viability, consult a qualified intellectual property attorney specializing in software licensing.

Crush License Analysis: FSL-1.1-MIT