Zed, edytor w Rust i jego mieszane licencje

Zed, edytor w Rust i jego mieszane licencje

Zed to edytor kodu napisany w Rust przez Zed Industries, firmę założoną przez autorów Atoma i Tree-sittera. Wersja stabilna 1.16.1 pochodzi z 19 sierpnia 2026 roku, repozytorium zed-industries/zed ma około 89 tysięcy gwiazdek, a licencja nie jest jedna: rdzeń stoi na GPL-3.0-or-later, a wybrane katalogi na Apache 2.0.

Czym Zed jest, a czym nie

Zed to natywna aplikacja okienkowa, która rysuje swój interfejs sama, przez kartę graficzną, bez przeglądarki w środku. Nie ma tu Electrona, nie ma DOM ani warstwy webowej. Interfejs rysuje własny framework o nazwie GPUI, napisany w tym samym repozytorium i utrzymywany jako osobna biblioteka.

Poza edycją tekstu Zed obsługuje serwery języka po protokole LSP, adaptery debugowania po protokole DAP, integrację z Git, terminal, zadania uruchamiane z pliku konfiguracyjnego, tryb wieloosobowy w czasie rzeczywistym oraz panel agentowy. Do parsowania kodu używa Tree-sittera, co ma prostą przyczynę historyczną: Tree-sitter powstał w tej samej firmie i jego autor pracuje nad edytorem.

Trzy rzeczy, których Zed nie robi, warto ustawić na początku. Nie jest środowiskiem programistycznym w rozumieniu pakietu JetBrains, więc refaktoryzacje i analiza projektu są tak dobre, jak serwer języka, który podłączysz. Nie działa w przeglądarce, a katalog gpui_web w repozytorium to prace nad kompilacją do WebAssembly, nie gotowa funkcja. Nie ma też odpowiednika kilkudziesięciu tysięcy rozszerzeń z rynku VS Code i to jest najpoważniejsze ograniczenie praktyczne, do którego wrócę osobno.

Repozytorium jest żywe. Ostatnia zmiana w gałęzi głównej pochodzi z 21 sierpnia 2026 roku, projekt nie jest zarchiwizowany, ma 10173 rozgałęzienia i 3201 otwartych zgłoszeń. Wydania stabilne i kanał preview wychodzą mniej więcej co tydzień, przy czym preview wyprzedza stabilny o około siedem dni.

Licencja: GPL-3.0 z wyspami Apache 2.0

To jest punkt, w którym Zed odbiega od typowego projektu na MIT, i w którym najłatwiej pomylić się przy audycie zależności. Interfejs programistyczny GitHuba zwraca dla tego repozytorium NOASSERTION i nazwę Other, czyli mówi wprost, że nie potrafi opisać stanu faktycznego jedną wartością.

Stan faktyczny sprawdzony w drzewie źródeł wydania 1.16.1 wygląda tak. W katalogu głównym leżą dwa pliki: LICENSE-GPL z pełnym tekstem GNU General Public License w wersji trzeciej oraz LICENSE-APACHE z nagłówkiem „Copyright 2022 - 2025 Zed Industries, Inc.". Głębiej w drzewie jest 215 plików o nazwie LICENSE-GPL i 47 plików o nazwie LICENSE-APACHE, po jednym w katalogu każdego modułu. Manifesty Cargo potwierdzają ten podział niezależnie: 206 z nich deklaruje license = "GPL-3.0-or-later", a 34 deklaruje license = "Apache-2.0". Plik README opisuje to jednym zdaniem: kod źródłowy Zeda jest licencjonowany głównie na GPL-3.0-or-later, z komponentami na Apache-2.0 tam, gdzie je oznaczono.

Podział nie jest przypadkowy i da się go streścić regułą. Na Apache 2.0 są te części, które mają sens jako biblioteka poza edytorem: gpui wraz z całą rodziną modułów platformowych, extension_api, czyli interfejs dla autorów rozszerzeń, oraz zestaw narzędziowy taki jak collections, sum_tree, util, path, http_client i scheduler. Na GPL jest sam edytor: editor, project, language, agent_ui, terminal_view, a także collab, czyli serwer obsługujący tryb wieloosobowy.

Konsekwencje są konkretne. Jeśli budujesz własną aplikację na GPUI albo piszesz rozszerzenie do Zeda, obowiązuje Cię Apache 2.0 i możesz zamknąć swój kod. Jeśli rozgałęziasz edytor i rozprowadzasz zmodyfikowaną wersję, obowiązuje Cię GPL-3.0-or-later ze wszystkim, co z tego wynika, łącznie z obowiązkiem udostępnienia źródeł odbiorcom. To jest realna różnica wobec Cursora czy Windsurfa, które są zamkniętymi rozgałęzieniami VS Code.

Krąży przekonanie, że część Zeda stoi na AGPL. W drzewie wydania 1.16.1 nie ma ani jednego pliku licencyjnego AGPL, ani jednego manifestu z takim polem. Jedyne wystąpienie tego skrótu to plik script/licenses/zed-licenses.toml, w którym komentarz mówi wprost, że AGPL nie ma być dodawane do listy dopuszczonych licencji zależności. Lista dopuszczonych obejmuje Apache-2.0, MIT, MPL-2.0, BSD, ISC, Zlib i kilka innych licencji permisywnych, a zgodność wymusza cargo-about w potoku ciągłej integracji.

Do audytu przydaje się jeszcze jedna rozbieżność. Pakiet zed_extension_api opublikowany na crates.io ma numer 0.7.0 z 12 września 2025 roku, podczas gdy plik crates/extension_api/Cargo.toml w wydaniu 1.16.1 deklaruje wersję 0.8.0. Numer z gałęzi źródłowej nie jest więc numerem, który zainstalujesz poleceniem cargo add. Osobno działa jeszcze bariera wejścia dla współtwórców: przed scaleniem zmiany trzeba podpisać umowę o przekazaniu praw autorskich, publikowaną pod adresem zed.dev/cla.

# licencje deklarowane w manifestach Cargo, zliczone
grep -rh '^license' --include=Cargo.toml . | sort | uniq -c | sort -rn

# pliki licencyjne w drzewie, z podziałem na nazwy
find . -name 'LICENSE-*' -type f | xargs -n1 basename | sort | uniq -c

# co o repozytorium sądzi interfejs programistyczny GitHuba
curl -s https://api.github.com/repos/zed-industries/zed | grep -A4 '"license"'

Skąd bierze się szybkość i gdzie ma granice

Rust sam z siebie nie robi edytora szybkim. Robią to decyzje architektoniczne, które Rust dopiero umożliwia bez płacenia za nie pauzami odśmiecacza pamięci.

Pierwsza to własny silnik interfejsu. GPUI rysuje okno przez kartę graficzną, z osobnymi zapleczami dla macOS, Windows i Linuksa oraz zapleczem opartym na wgpu. Nie ma tu układu pudełkowego przeglądarki ani przeliczania stylów kaskadowych. Druga to struktura danych na tekst. Bufor siedzi w drzewie sum, zaimplementowanym w module sum_tree, dzięki czemu wstawienie znaku w środku pliku o wielkości stu megabajtów nie przepisuje bufora. Trzecia to Tree-sitter, który parsuje przyrostowo i nie odtwarza całego drzewa po każdym naciśnięciu klawisza.

Granice tej szybkości warto znać, zanim się je odkryje w pracy. Podświetlanie i nawigacja po składni są szybkie, bo robi je Zed. Uzupełnianie kodu, sprawdzanie typów i akcje naprawcze robi serwer języka, który jest osobnym procesem i najczęściej nie jest napisany w Rust. Projekt w TypeScripcie będzie w Zedzie odpowiadał dokładnie tak szybko, jak odpowiada tsserver, i żaden silnik interfejsu tego nie zmieni. Zed przyspiesza to, co dzieje się między klawiaturą a ekranem, nie to, co dzieje się w narzędziach języka.

Druga granica jest sprzętowa. Na Linuksie oficjalne wydania oczekują karty graficznej zgodnej z Vulkanem oraz systemowej biblioteki glibc w wersji co najmniej 2.31 na x86_64 i co najmniej 2.35 na aarch64. Na maszynie wirtualnej bez akceleracji graficznej albo na starszej dystrybucji trzeba budować ze źródeł, co wymaga łańcucha narzędzi Rust przypiętego w repozytorium do wersji 1.97.1 oraz zestawu wasi-sdk do kompilacji parserów Tree-sittera.

Systemy operacyjne, instalacja i konfiguracja

Kolejność, w jakiej systemy dołączały, wciąż widać w dokumentacji. Dziś strona pobierania podaje jedno wydanie stabilne 1.16.1 dla wszystkich trzech platform: macOS w wersji 10.15 lub nowszej, Windows na procesorach Intela i AMD oraz Linux przez skrypt instalacyjny. Windows ma pakiet w menedżerze winget o identyfikatorze ZedIndustries.Zed. Wersji przeglądarkowej nie ma i jest ona prowadzona jako otwarta dyskusja, nie jako zapowiedź.

Nierówności zostały w pracy zdalnej. Zed potrafi otworzyć projekt na zdalnym serwerze przez SSH, uruchamiając tam bezgłowy proces serwera, podczas gdy interfejs działa lokalnie. Serwerem zdalnym może być macOS od wersji Catalina albo Linux na x86_64 lub arm64. Windows w tej roli nie jest jeszcze obsługiwany, choć może być maszyną lokalną łączącą się z takim serwerem. Starszy tryb, w którym ruch szedł przez serwery Zeda, został usunięty w wersji 0.157, a do dzisiejszego trybu SSH potrzeba co najmniej wersji 0.159.

# Linux, kanał stabilny
curl -f https://zed.dev/install.sh | sh

# Linux, kanał preview, wydania około tydzień przed stabilnymi
curl -f https://zed.dev/install.sh | ZED_CHANNEL=preview sh

# Windows przez menedżera pakietów
winget install -e --id ZedIndustries.Zed

# otwarcie katalogu na zdalnym serwerze
zed ssh://deploy@192.168.1.10/srv/app

# uruchomienie z pełnymi logami przy diagnozowaniu rozszerzeń
zed --foreground

Konfiguracja siedzi w jednym pliku settings.json, z osobną wersją użytkownika i wersją projektową w katalogu .zed. Schemat ma ponad dwieście pól najwyższego poziomu, więc poniżej tylko te, które ustawia się najczęściej.

{
  "theme": { "mode": "system", "light": "One Light", "dark": "One Dark" },
  "buffer_font_family": ".ZedMono",
  "buffer_font_size": 14,
  "vim_mode": false,
  "tab_size": 2,
  "format_on_save": "on",
  "formatter": [{ "code_action": "source.fixAll.eslint" }, "prettier"],
  "telemetry": { "diagnostics": false, "metrics": false },
  "disable_ai": false,
  "edit_predictions": {
    "provider": "zed",
    "disabled_globs": ["**/.env*", "**/*.pem"]
  },
  "agent": { "enabled": true, "dock": "right" },
  "ssh_connections": [
    { "host": "192.168.1.10", "projects": [{ "paths": ["~/code/app"] }] }
  ]
}

Pole format_on_save przyjmuje wartości on, off, modifications i modifications_if_available, przy czym dwie ostatnie formatują wyłącznie linie ze zmianami niezaindeksowanymi w Git. Pole formatter przyjmuje listę kroków wykonywanych po kolei, a pojedynczy krok może być akcją kodu serwera języka, wywołaniem Prettiera albo poleceniem zewnętrznym. Ustawienie disable_ai wyłącza wszystkie funkcje modeli językowych naraz i jest osobne od agent.enabled.

Rozszerzenia i rozmiar ekosystemu

Rejestr rozszerzeń Zeda to publiczne repozytorium zed-industries/extensions z plikiem extensions.toml. W chwili pisania zawiera on 1441 wpisów, z czego 429 ma w identyfikatorze słowo „theme", a 24 słowo „icon". Po odjęciu motywów i zestawów ikon zostaje mniej więcej tysiąc rozszerzeń funkcjonalnych. Rynek rozszerzeń VS Code jest większy o rzędy wielkości i to jest twarda różnica, której nie da się obejść konfiguracją.

Model techniczny również różni się od VS Code. Rozszerzenie to repozytorium Git z manifestem extension.toml. Część proceduralna, jeśli w ogóle jest potrzebna, powstaje w Rust i kompiluje się do celu wasm32-wasip2, czyli działa w piaskownicy WebAssembly. Dokumentacja zaznacza, że większość rozszerzeń nie zawiera żadnego kodu w Rust, bo motywy, składnia, wycinki kodu i podstawowa obsługa języka opisują się deklaratywnie.

id = "my-extension"
name = "My extension"
version = "0.0.1"
schema_version = 1
authors = ["Twoje Imie <ty@example.com>"]
description = "Przykladowe rozszerzenie"
repository = "https://github.com/twoje-konto/my-zed-extension"

[language_servers.vscode-html-language-server]
name = "vscode-html-language-server"
language = "HTML"

[grammars.html]
repository = "https://github.com/tree-sitter/tree-sitter-html"
commit = "bfa075d83c6b97cd48440b3829ab8d24a2319809"

Manifest opisuje, co rozszerzenie dostarcza. Dokumentacja wymienia języki, adaptery debugowania, motywy, zestawy ikon, wycinki kodu i serwery MCP, a osobne rozdziały opisują polecenia ukośnikowe i serwery agentowe. Czego na tej liście nie ma, to dowolny widok interfejsu. Rozszerzenie nie namaluje własnego panelu ani własnej wizualizacji, co odcina całą kategorię wtyczek znanych z VS Code.

Uprawnienia rozszerzeń są nadawane jawnie i da się je zawęzić. Domyślnie przyznane są trzy: uruchamianie procesów, pobieranie plików i instalacja pakietów npm, każde z wzorcem dopuszczającym wszystko.

{
  "auto_install_extensions": { "html": true },
  "granted_extension_capabilities": [
    { "kind": "process:exec", "command": "*", "args": ["**"] },
    { "kind": "download_file", "host": "github.com", "path": ["**"] },
    { "kind": "npm:install", "package": "*" }
  ]
}

Ustawienie pustej listy odbiera rozszerzeniom wszystko i, jak ostrzega dokumentacja, zwykle unieruchamia większość z nich. Zawężenie hosta pobierania do github.com, jak wyżej, jest kompromisem sensownym w firmie z polityką bezpieczeństwa łańcucha dostaw.

Funkcje agentowe, konta i cennik

Zed ma dwie warstwy funkcji opartych na modelach językowych i mylenie ich prowadzi do złych decyzji o kosztach.

Pierwsza to przewidywanie edycji, czyli podpowiedzi wieloliniowe wstawiane klawiszem tabulatora. Domyślnym dostawcą jest Zeta, otwarty model rozwijany przez Zed Industries, a alternatywami są GitHub Copilot, Codestral i Mercury Coder. Druga to panel agentowy, w którym działa albo własny agent Zeda z modelami hostowanymi przez firmę, albo agent zewnętrzny podłączony przez Agent Client Protocol. W tej drugiej roli dokumentacja wymienia między innymi Claude, Codex, OpenCode, Copilota i Cursora, a za agentów zewnętrznych Zed nie pobiera opłat, bo rozliczasz się bezpośrednio z ich dostawcą. To układ inny niż w Cline czy Continue, gdzie rozszerzenie samo jest agentem wewnątrz cudzego edytora.

Cennik ze strony dostawcy ma trzy poziomy. Plan Personal kosztuje zero i daje pełny edytor, przy czym przewidywania edycji są ograniczone do 2000 zaakceptowanych podpowiedzi miesięcznie. Własne klucze do dostawców modeli oraz agenci zewnętrzni działają na tym planie bez ograniczeń. Plan Pro kosztuje 10 dolarów miesięcznie, znosi limit podpowiedzi i zawiera 5 dolarów kredytu na tokeny, a zużycie ponad tę kwotę rozliczane jest po cenie cennikowej dostawcy powiększonej o 10 procent. Plan Business kosztuje 30 dolarów za stanowisko miesięcznie i dokłada warstwę administracyjną: polityki modeli dla całej organizacji, blokadę ustawień udostępniania danych i wspólne rozliczenie.

Trzy rzeczy z cennika warto przeczytać uważnie. Stanowiska Business nie zawierają puli kredytów na tokeny, więc koszt użycia modeli dochodzi osobno. Logowanie jednokrotne w standardach SAML i SCIM jest opisane jako planowane, a nie dostępne, co dla części organizacji przesądza sprawę. Dostawca podaje też dwie różne kwoty kredytu: strona planów mówi o 5 dolarach w abonamencie Pro, a opis dwutygodniowego okresu próbnego o 20 dolarach, więc są to dwie odrębne pule, nie jedna liczba.

Tryb wieloosobowy jest osobną funkcją i wymaga zalogowania. Kanały i połączenia prywatne pozwalają wspólnie edytować projekt oraz rozmawiać głosem. Dokumentacja stawia przy tym ostrzeżenie, które łatwo przeoczyć: udostępnienie projektu daje współpracownikom dostęp do Twojego systemu plików w obrębie tego projektu.

Zed a alternatywy

Wybór rozstrzyga się na jednym pytaniu: ile Twojej codziennej pracy zależy od konkretnych rozszerzeń. Jeśli w VS Code masz pięć wtyczek, z których żadna nie rysuje własnego panelu, przejście do Zeda jest kwestią jednego popołudnia i zyskujesz odczuwalnie krótszy czas reakcji edytora. Jeśli masz trzydzieści wtyczek, w tym firmowe, przejście oznacza pisanie ich od nowa albo rezygnację z części pracy. Jeżeli głównym powodem jest agent, warto najpierw sprawdzić, czy Twój agent działa przez Agent Client Protocol, bo wtedy dostaniesz go w Zedzie bez zmiany dostawcy i bez podwójnej subskrypcji.

Typowe błędy

Pierwszy to potraktowanie repozytorium jako projektu na jednej licencji permisywnej. Jeśli w firmie prowadzisz listę licencji, wpisanie samego NOASSERTION z GitHuba nic nie mówi, a wpisanie samego Apache 2.0 jest po prostu nieprawdą. Poprawny zapis to GPL-3.0-or-later dla edytora i Apache 2.0 dla oznaczonych bibliotek.

Drugi to założenie, że skoro GPUI jest na Apache 2.0, to rozgałęzienie edytora też można zamknąć. Moduł editor i sąsiednie mają w manifestach GPL-3.0-or-later i rozprowadzanie zmodyfikowanego edytora podlega tej licencji niezależnie od tego, że część zależności jest permisywna.

Trzeci to instalacja na maszynie bez akceleracji graficznej. Na Linuksie oficjalne wydanie oczekuje karty zgodnej z Vulkanem, a na serwerze bez takiej karty albo na starej dystrybucji z glibc poniżej 2.31 pozostaje budowanie ze źródeł.

Czwarty to próba użycia Windowsa jako serwera zdalnego. Windows jest obsługiwany jako maszyna lokalna, ale bezgłowy serwer Zeda działa dziś tylko na macOS i Linuksie.

Piąty to pozostawienie domyślnych uprawnień rozszerzeń w środowisku z polityką bezpieczeństwa. Domyślnie każde rozszerzenie może uruchomić dowolne polecenie, pobrać plik z dowolnego hosta i zainstalować dowolny pakiet npm. Zawężenie listy granted_extension_capabilities zajmuje minutę.

Szósty to instalowanie zed_extension_api z numerem widzianym w źródłach wydania. W repozytorium stoi 0.8.0, a na crates.io opublikowane jest 0.7.0 i to ta wersja trafi do Twojego projektu.

Siódmy to liczenie na plan Business jako gotową warstwę korporacyjną. Kontrola administracyjna dotyczy usług hostowanych przez Zeda, a logowania jednokrotnego w standardach SAML i SCIM jeszcze nie ma.

FAQ

Na jakiej licencji jest Zed?

Na dwóch naraz, w zależności od katalogu. Edytor i serwer współpracy stoją na GPL-3.0-or-later, a biblioteki przeznaczone do użycia poza edytorem, w tym GPUI i interfejs rozszerzeń, na Apache 2.0. W wydaniu 1.16.1 manifesty Cargo deklarują 206 razy GPL-3.0-or-later i 34 razy Apache-2.0.

Czy Zed używa gdzieś licencji AGPL?

W wydaniu 1.16.1 nie. Nie ma w drzewie ani pliku licencyjnego AGPL, ani manifestu z takim polem, a plik z polityką licencyjną zależności zawiera komentarz mówiący wprost, że AGPL nie ma być dodawane do listy dopuszczonych.

Czy Zed działa na Windowsie tak samo jak na macOS?

Do pracy lokalnej tak, jest jedno wydanie stabilne dla wszystkich trzech systemów i pakiet w menedżerze winget. Różnica dotyczy pracy zdalnej: bezgłowy serwer Zeda działa na macOS od wersji Catalina i na Linuksie, a Windows może być tylko maszyną lokalną.

Czy da się napisać rozszerzenie w JavaScripcie?

Nie. Część proceduralna rozszerzenia powstaje w Rust i kompiluje się do WebAssembly dla celu wasm32-wasip2. Motywy, wycinki kodu i podstawowa obsługa języka opisują się deklaratywnie i nie wymagają żadnego kodu.

Czy Zed jest darmowy?

Sam edytor tak, plan Personal kosztuje zero i nie ogranicza funkcji edycyjnych. Płatne są funkcje modeli językowych hostowane przez firmę: plan Pro za 10 dolarów miesięcznie i plan Business za 30 dolarów za stanowisko miesięcznie. Własne klucze do dostawców modeli działają również na planie darmowym.

Ile rozszerzeń ma Zed?

Rejestr zawiera 1441 wpisów, z czego 429 to motywy, a 24 zestawy ikon. Funkcjonalnych rozszerzeń jest więc około tysiąca, czyli o rzędy wielkości mniej niż na rynku rozszerzeń VS Code.

Dokumentację znajdziesz na stronie Zeda, kod źródłowy w repozytorium na GitHubie, a specyfikację protokołu agentowego na stronie Agent Client Protocol.