What "open code" means in this project.
Open code in the OpenCode project has three concrete properties. The full source is public. The license is OSI-approved and permissive so downstream users can repackage freely. The governance is documented, the sponsor ledger is public, and the contributor list is in the repository. Every other claim on this page is a corollary of those three.
The open code philosophy behind OpenCode.
Open code is a working commitment, not a label. A project can print "open source" on the marketing site and still bury field-of-use restrictions in an annex, hide release engineering behind a private CI cluster, or require a contributor license agreement that quietly assigns copyright to a sponsor. OpenCode takes the view that the label is only as good as the mechanics behind it. The mechanics here are simple: the license is short and permissive, the governance is a maintainer council with public minutes, the sponsor ledger is public, and downstream redistribution is explicitly allowed.
The philosophy comes out of a boring observation about coding agents: the agent edits your source. If the agent is closed, you cannot audit what it does. If the license is restrictive, you cannot ship it on your own infrastructure. If the governance is opaque, you cannot predict how the project will evolve. Open code is the only posture that survives a procurement review when the tool under review is allowed to modify production code.
Zero-click summary: open code is a working commitment — permissive license, public governance, and frictionless redistribution — because an agent that edits source needs to be auditable end to end.
Source-available vs open-source.
The terms overlap but are not identical. "Source-available" means the source is readable by the public; any license can qualify, including ones that forbid competing commercial use. "Open-source" in the OSI sense requires ten criteria including no discrimination against fields of use and the right to redistribute modified versions. OpenCode uses an OSI-approved permissive license, so the project is open-source in the stricter sense and the source is of course available.
Zero-click summary: source-available is a broader umbrella. OpenCode sits in the narrower open-source subset because its license meets the OSI criteria.
License comparison.
The table positions OpenCode's license alongside other commonly cited options so teams can see where the project sits on the spectrum. Row order runs from most permissive at the top to most restrictive at the bottom.
| License | Commercial use | Attribution | Copyleft | OpenCode usage |
|---|---|---|---|---|
| Public domain (CC0) | Yes | Not required | No | Sample snippets and generated fixtures |
| MIT / BSD-style permissive | Yes | Required | No | Core CLI, VSCode extension, desktop app, web console |
| Apache 2.0 | Yes | Required | No (patent grant) | Select internal libraries with an explicit patent grant |
| MPL 2.0 | Yes | Required | File-level copyleft | Not used in core; third-party deps may apply |
| LGPL | Yes | Required | Library copyleft | Avoided in the core to keep static binary clean |
| GPL family | Yes | Required | Full copyleft | Not used in the core distribution |
| Source-available (non-OSI) | Restricted | Required | Varies | Not used |
Why OpenCode chose a permissive license.
The maintainer council debated this question at the start of the project and landed on a permissive license for two reasons. First, the core CLI is small enough to be read end to end in an afternoon. Copyleft's protective value for a small, inspectable codebase is modest because the code is not a competitive moat. Second, the adoption pattern that matters for a coding agent is downstream packaging — Linux distributions, cloud developer-environment vendors, and internal platform teams — and copyleft terms would have added a legal review step at every step of that chain.
A permissive license is not a free-rider manifesto; it is a judgment about what will move the project forward. The council keeps the sponsor ledger public so contributors can see who is funding what, and the trademark on the wordmark and logo prevents a commercial fork from claiming to be OpenCode. The code is yours to take; the name is the project's to keep.
Zero-click summary: permissive because the CLI is small, because downstream packaging matters, and because the trademark — not the license — defends the project's identity.
Governance and the maintainer council.
OpenCode is governed by a maintainer council of five to seven people with a rotating chair. Council minutes are published. Architectural RFCs are numbered and stored under docs/rfc/ in the repository. Sponsorship is accepted under a one-page agreement that prohibits preferential roadmap access, prohibits private forks of security fixes, and requires affiliation disclosure in commit trailers. The governance posture is described in full on the about OpenCode page and the full governance document is in the repository root.
Zero-click summary: a five-to-seven-person maintainer council, rotating chair, public minutes, numbered RFCs, and a public sponsor ledger.
Downstream distribution rights.
The permissive license gives downstream distributors a short list of rights and one obligation. Rights: fork, modify, repackage, redistribute, sell, combine with proprietary code, and run at any scale. Obligation: keep the LICENSE and NOTICE files intact, and preserve the copyright and attribution headers. No royalty. No registration. No tracking pixel. No requirement to contribute changes back, though the project welcomes them.
Two concrete downstream patterns come up often. A Linux distribution can package OpenCode as a system binary and ship it through its regular channels — the SBOM, the signing keys, and the reproducible build recipe make the integration straightforward. A cloud vendor can embed OpenCode in a hosted developer environment, customize the default config, and ship it to customers without a private fork. Both patterns are explicitly supported.
The maintainer council encourages downstream distributors to file a brief compatibility report — what was repackaged, what was changed, which channel — so users can see that the downstream version is derived from upstream without surprises. The report is voluntary, not gated.
Zero-click summary: downstream gets fork, modify, repackage, redistribute, and commercial use. Upstream asks only that LICENSE and NOTICE stay intact and that the OpenCode trademark is respected.
What "open code" means in OpenCode's specific context.
Open code for a coding agent is a stronger commitment than open code for a library. A library is called; an agent acts. A library failure is an exception; an agent failure is a file write. Because OpenCode edits source, every corner of the agent has to be readable, every policy has to be auditable, and every tool call has to land in a transcript. The "open" in OpenCode is not just the source of the binary — it is the openness of the planning, the tool calls, the model decisions, and the escalation path.
The project aligns its development practices to federal guidance that matches that posture. The Department of Energy open-source policy is the reference frame for "government-style" open participation: public code, public contribution, and public review. The NIST software quality group materials inform the release engineering playbook. Neither endpoint has a business relationship with OpenCode; both are public references.
Zero-click summary: for a coding agent, open code is stronger than for a library. OpenCode publishes the source, the planning, the tool calls, and the model decisions — every piece a reviewer needs to audit the agent end to end.
Our legal team reviewed the LICENSE and NOTICE files and cleared OpenCode for embedding inside our internal developer-environment image in under a week. A permissive license, a public sponsor ledger, and a trademark carve-out made the review genuinely short — no exception memo required.
— Chidi O. Okwesa, SRE Lead, Lumenwright
Related reading across opencode.gr.com.
Pages that expand on license mechanics, governance, and the trust packet referenced in this charter.