Zedless: プライバシーとローカルファーストを重視したZedフォーク

• Zedlessはオープンソースエディタ Zed をベースにした、プライバシー保護とローカルファーストな環境を重視するフォーク版
• Zedless は クラウド依存を取り除き、ユーザーが望むインフラ環境を自ら設定できるようにする
• スパイウェアおよびリモートテレメトリ機能をすべて削除する予定
• コントリビューターの著作権再譲渡なしのポリシー（No CLA）を導入し、すべての開発者が著作権を保持する
• ライセンス管理の自動化およびオープンソースライセンス準拠のために追加ツールを使用

---

Zedless の紹介

• Zedlessはコードエディタ Zed のフォーク版で、ユーザーのプライバシー確保とローカル環境最優先の使い勝手を目標としている
• 現在開発中のプロジェクトであり、外部からのコントリビューションを自由に受け付けている

主な変更計画

• セルフホストできないクラウドサービスへの依存の排除
  • サードパーティクラウドに厳密に依存するコンポーネントと機能は削除予定
• スパイウェアの除去とデータ保護
  • テレメトリ、自動クラッシュレポートシステムはすべて削除対象
• ユーザーインフラの優先サポート
  • ネットワークサービス機能の利用時、ユーザーは標準フォーマットで直接サービスプロバイダーを指定可能
  • 「デフォルトプロバイダー」のリストは存在せず、該当機能はデフォルトで無効化されている
• 著作権譲渡なし
  • プロジェクト参加者は著作権を自身に保持する
  • 開発者に不利益が生じないよう No rugpulls ポリシーを適用

ライセンスと依存関係の管理

• サードパーティ依存関係のライセンス情報の提供が必須であり、そのために cargo-about ツールを活用する
• 注意事項
  • 自分で作成した crate で no license specified エラーが発生した場合は、Cargo.toml に publish = false の追加が必要
  • 依存パッケージのライセンス要件未充足エラーが発生した場合は、そのライセンスの適合性を確認して明記する必要がある
  • cargo-about が依存ライセンスを見つけられない場合は、明確な説明項目をスクリプトに追加しなければならない

プロジェクトの意義

• Zedless は、プライバシーとローカル中心の開発環境を重視するユーザーやチームにとって、特に安定性、自律性、法的保護の面で優れた代替案
• 既存の Zed と比べ、私有クラウドサービスやリモート追跡機能などの潜在的なセキュリティ脆弱性を思い切って排除することで、自前のインフラとオープンソースエコシステムに基づく信頼性を確保できる

[GN⁺]

Hacker Newsの意見

• Zedについてこうした動きがあるのは歓迎したい。現時点では完璧ではないが、今後に期待している。ただし、AIやテレメトリ機能はまったく望んでいない。最近はエディタでAI機能をほとんど使わなくなった。Copilotなど何度も試したが、まだ満足できていない。こうした機能は、ソフトウェア開発パイプラインの別の場所、たとえばコードレビューやドキュメント作成支援などにより適している気がする。設定同期サービスやメンテナンスサブスクリプションのような形ならお金を払ってもよい。しかし、エディタというツールがVCの求めるROIをもたらせる製品だとは思わない。おそらく1年後にはまたEmacsとIntelliJの組み合わせに戻っているかもしれない
  • こういう意見をようやく見られてうれしい。多くの人がAIエディタを称賛しているあいだ、私はなぜそんなに大騒ぎするのかよく理解できず、取り残された気分だった。いくつかAIエディタを使ってみたが、自分のワークフローが良くなった経験はなかった。うちのチームではコードを書くことがボトルネックではないからか、むしろコードレビューが速く進まないことのほうが問題だ。そのため、一部の負担を減らすためにAIコードレビューの導入を検討している
  • ZedではAI機能を無効化できる Zedブログ: AI機能を無効化
  • ZedがAI機能の導入をやめてテキスト編集に集中すれば、本当に素晴らしい製品になり得ると思う
  • 単にAIやテレメトリ機能をまったく使わないか無効にすればいいだけでは？ 別に目の前に押しつけられているわけでもない。テレメトリもデフォルトOFFならなお良いが、簡単に切れるなら問題ない
  • メンテナンスサブスクリプションにお金を払うというこうした意見は、多くのHNやギーク系フォーラムでよく見かけるが、実際にはそういうユーザーは少数派で、製品や会社を持続可能にするには十分ではない
• フォークに対してはいつも複雑な感情がある。特にハードフォークではなおさらだ。Zedには最近、すべてのAI機能を無効化できる機能が追加され、テレメトリもオプトアウト可能になった。なので、そこまでフォークが必要なのかはよくわからない。提示されている機能一覧を見ると、本体にデフォルト機能としてupstreamできそうなものが多い。そうなってほしい。過去のRedisフォークのようにエコシステムが分裂した記憶もある
  • Zedの開発者は、Zedアカウント/ログイン機能の無効化を認めないなど、すでに少し怪しい動きを見せているので、フォークの必要性は小さくないと思う。エコシステムの分裂を恐れる理由はない。むしろ多様なツールが共生するほうが、ロックインや集団思考から自由になれる前向きな道だと思う
  • オプトイン方式のテレメトリであってもやはり不快だ。ソフトウェアがいつでも自分の下着のサイズや朝食の内容まで報告できるのだという意識を拭えない。たった1つのチェックボックスに依存するのも不安だ。他の機能でも毎回「不要」を選ばなければならないオプトアウト方式は面倒だ。基本的にミニマリズムを好む
  • すでにZedはオープンソースなので、フォークの必要性は低いと思う。だから、Zedがデフォルトですべての機能をオプトインに切り替えれば、こうしたフォークの存在意義はなくなるだろう
  • 初回起動時にバックグラウンドアップロードが絶対にないという追加の保証があるとよい。ちなみに私はopensnitchも一緒に動かして二重に防御している
• こういうフォークの話としては少し早い気がする。特に、何のためにフォークするのかを説明するマニフェストなしで出すのはなおさらだ。「no rugpulls」という文言を見ると、まるでZedで何か事件があったかのように見えるが、すべてのHN読者がこうしたオープンソース論争に常に詳しいわけではない
  • Contributor Agreement(CA)は、後でライセンス変更を行うための、いわゆる「ライセンス・ラグプル」に備えて著作権をすべて会社に帰属させる仕組みだ。ZedがCAを要求しているということは、将来的なライセンス変更の可能性を念頭に置いているという意味でもある
  • ZedはもともとクラウドとAI中心のプロジェクトとしてよく知られていた。こうした流れこそが、このフォークの明確な動機だと思う。今突然持ち上がった新しい論争や事件というより、方向性がはっきり表れていて、多くの人が気に入っていない、そういう点だ
  • 今回のフォークは github discussion で触発されたように思う
  • ZedはVC投資を受けている。一方で、プライバシー/ローカルファーストのフォークは、そうした機能が不足しているというだけでそれ自体に正当性がある。Zedが誇る多くの機能を削ることにはなるだろうが、rugpullと呼ぶのは少し微妙だ
• 関連する議論スレッドの一覧
  • Zed for Windowsが遅れている理由
  • SequoiaがZedに投資
• このフォークがどんな結果を生むのか気になる。以前、node.jsのフォークであるIO.jsがnodeの開発の流れを変えたことを思い出す。テレメトリやAIがいたるところで押しつけられる時代に、こうしたことに敏感な開発者集団がいるという点が印象的だ
• Zedに本当に望んでいるのはマルチウィンドウ対応だ。エージェントパネルや他のパネルを別のモニターに出せない。ローカルファースト志向も良いが、私はAIツールも使うので、今のところこのフォークを使うことはなさそうだ。それでも、非テレメトリ、非Contributor Agreementといった方向性は歓迎したい。このフォークのアイデアは気に入っているし、幸運を祈る。ZedのAI機能なしでも1年以上うまく使えていたので、いつかAIに飽きたらこのフォークに移るかもしれない
  • 私も同じ経験をした。Zedをめぐる多くの議論を見てインストールしてみたが、パネルを出せなかったり、1年以上修正されていない基本設定すら変えられなかったりして、結局削除してしまった
• こういうフォークは、いつか必ず出てくると思っていた。実際に自分で始めようかとも考えたが、メンテナンス負担が大きくてやめた。名前もzim(zed improved, vimみたいに)を考えていた。実際にプロジェクトが世に出たのはうれしい
• 投稿者コメント: Lobsters原文, フォークプロジェクトはこちら, 私は自分に不要だと思うテレメトリ、自動更新、クラウド専用AI統合、node.js依存、言語サーバーの自動ダウンロード、追加購入の誘導、ログインボタンなどを段階的に削除している。Zeta editのクラウド専用機能についても、可能なら自前でホストできるようにするのが目標だ（例: llama.cpp や vLLM インスタンスでZeta editの予測を実行する）。現状でもメインエディタとして使える程度には機能しているが、コード変更が多く、マージコンフリクトを避けるのには限界がある。そこでtree-sitterを使ってASTレベルで自動修正する実験も行っている。この実験は、「個人向けにunshittifiedされた」バージョンのZedを作れるツールに発展するかもしれない
  • node.js依存について質問したいのだが、いつから人々はnodeを嫌うようになったのか、そして理由は何なのか気になる
• この種のフォークは、実質的にはZedのAI機能をコンパイルフラグで隠すpull requestで十分ではないかと思う。わざわざ「フォーク」にしなくても、ビルドコマンドが違うだけで同じコードからAIなしのZedを作れるのではないか