# Zed: a 298-word README where licences and sponsorship take half the page

> Zed is a Rust editor from the creators of Atom and Tree-sitter, and its README spends most of its length on three subjects: dependency licence compliance, the fact that the company behind it is a for-profit, and where to get a binary. Nothing about configuration, extensions or multiplayer is in there.

**zed-industries/zed** — High-performance multiplayer code editor written in Rust by the creators of Atom and Tree-sitter, available for macOS, Linux, and Windows.

- Repository: https://github.com/zed-industries/zed
- Website: https://zed.dev
- Stars: 91,065 · Forks: 10,831
- Language: Rust
- License: not declared
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/zed-industries-zed

## A 298-word README where licences and sponsorship take half the page

Zed is introduced as a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter, and then the file changes subject. Installation is three sentences pointing at a download page plus three per-platform documentation anchors for package managers, and a note that other platforms are not yet available. Developing Zed is three links to build guides for macOS, Linux and Windows. Contributing is one link to CONTRIBUTING.md and a line saying the company is hiring.

Consequence: the file answers none of the questions an editor usually gets asked. There is no keybinding story, no extension model, no language server detail, no configuration reference, and nothing about multiplayer beyond the adjective in the first line. What you get instead is unusually complete on the two subjects a commercial project has to be careful about, licensing and money.

## cargo-about fails the build in three named ways, each with a different file to edit

The licensing section states that licence information for third party dependencies must be correctly provided for CI to pass, and that cargo-about is used to comply with open source licences automatically. Three failures are then named one by one. A no license specified error on a crate you created is fixed by adding publish = false under [package] in that crate's Cargo.toml. A failed to satisfy license requirements error on a dependency is fixed by adding the licence's SPDX identifier to the accepted array in script/licenses/zed-licenses.toml, and the guidance there is to work out whether the system is sufficient and, if unsure, ask a lawyer. A dependency whose licence cargo-about cannot find at all is fixed by adding a clarification field at the end of the same toml file, following the cargo-about book.

Consequence: adding one dependency is a paperwork task with a legal step buried in it, and the person doing it may be a first-time contributor who has never opened a licence file.

## The primary licence is GPL-3.0-or-later, and the Apache-2.0 carve-out is per component

Zed's source is licensed primarily under GPL-3.0-or-later, with Apache-2.0 components where marked, and the root carries two licence files, LICENSE-GPL and LICENSE-APACHE. A copyleft grant and a permissive exception are therefore both in play, and the README states the split without saying which parts fall on which side of it.

Consequence: mostly GPL with some Apache is not something you can act on without opening the files. A reader who needs to know whether one particular component is permissively licensed has to find the marking, and the README names no component at all. Anyone planning to ship Zed inside a product should expect that lookup per component rather than once.

## Web is the one platform the file names as not yet available

macOS, Linux and Windows each get two routes: a direct download from zed.dev/download, or the local package manager, with a separate documentation anchor for each platform. Then comes the exception. Other platforms are not yet available, and the single entry is Web, which points at a tracking discussion rather than a build or a package.

Consequence: the multiplayer and agent side of the product reads like a browser product, and none of it is reachable on the web. A tracking discussion is a place where progress is recorded, not a schedule, so the README offers no way to judge when that changes. The package manager routes also point at documentation rather than naming a package, so a scriptable install has to go and read the page first.

## compose.yml starts an object store and a media server with credentials in the file

The tree carries a compose file with two services, and both are infrastructure rather than editor code:

```yaml
  blob_store:
    image: quay.io/minio/minio
    ports:
      - 9000:9000
  livekit_server:
    image: docker.io/livekit/livekit-server
    ports:
      - 7880:7880
      - 7881:7881
      - 7882:7882/udp
```

Credentials sit in the same file as MINIO_ROOT_USER and MINIO_ROOT_PASSWORD placeholders, MinIO's data directory is bind-mounted from ./.blob_store, and the LiveKit configuration is bind-mounted from ./.config/livekit.yaml.

Consequence: this is a development stack, and it reads like a deployment template. Copied onto a shared host it puts an object store on port 9000 and a media server on 7880 with the placeholder values untouched, and a Dockerfile-collab sits beside it for the same purpose. Nothing in the file marks it local-only.

## One workspace, one crate per integration, and no list of them in the README

Cargo.toml declares a workspace with resolver 2 and an explicit member list, and the visible part of that list runs well past two hundred crates. The names cluster by concern rather than by layer: acp_thread, acp_tools, agent, agent_servers, agent_settings, agent_skills and agent_ui sit together, anthropic, bedrock, codestral, deepseek and copilot each get their own crate, and edit_prediction appears in cli, context, metrics, types and ui variants.

Consequence: an integration or an agent feature is a crate boundary rather than a plugin, so nothing about switching one off is answered by a single configuration key, and a reader looking for where a setting lives has dozens of plausible files to open. The README mentions none of them, which leaves the tree itself as the only map.

## Two tags on one afternoon, and the higher version is a pre-release

Three releases sit at the top of the tag list: v1.22.0-pre published at 16:21 on 2026-09-23, v1.21.0 published at 15:42 the same afternoon, and v1.20.2 on 2026-09-17. The last commit to main is dated 2026-09-29 and the project is not archived.

Consequence: a pre-release and a stable cut land forty minutes apart, so a script that takes the highest semver tag ends up on a -pre build rather than on the release it wanted, and the repository carries no dist-tag to steer it. A team pinning versions by hand is fine. An automated installer is guessing.

## Conclusion

Read Zed's repository when you want to know how the project handles licence compliance or what the company says about funding it, because those are the two subjects the README genuinely covers. Do not expect it to answer how to configure the editor, because that lives under docs/ and the file's own links are three build guides and a contribution document. Two things to check before you build. CI fails on unresolved dependency licences and the fix is a hand-edited entry in script/licenses/zed-licenses.toml, which makes every new dependency a paperwork task with a legal question in it. And if you plan to run the collaboration stack from the compose file in the tree, read it first: it starts a MinIO object store and a LiveKit server on fixed ports with credentials written into the file.

## FAQ

### What is Zed used for?

Zed is a high-performance, multiplayer code editor written in Rust, built by the creators of Atom and Tree-sitter. It ships for macOS, Linux and Windows as a direct download or through a local package manager, and it is developed by Zed Industries, Inc. as a for-profit company.

### Is Zed safe to use?

The README makes no security claim of any kind. What it does state is that the source is licensed primarily under GPL-3.0-or-later with Apache-2.0 components where marked, and that licence information for third party dependencies has to be correct for CI to pass. A security question has to be answered from the code and the issue tracker rather than from this file.

### How does Zed make money?

Zed is developed by Zed Industries, Inc., a for-profit company, and the README describes financial support as GitHub Sponsorships that go directly to the company and count as general company revenue. It states plainly that there are no perks or entitlements associated with sponsorship.

### Is the Zed editor legitimate?

It comes from the creators of Atom and Tree-sitter, and the repository is not archived: the last commit to main is dated 2026-09-29 and v1.21.0 was published on 2026-09-23. The source is primarily GPL-3.0-or-later with Apache-2.0 components where marked, and two licence files sit at the root.

## Sources

- [Official documentation](https://zed.dev)
- [Official README](https://github.com/zed-industries/zed#readme)
- [Project repository](https://github.com/zed-industries/zed)
- [Release notes](https://github.com/zed-industries/zed/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/zed-industries-zed