MeshCore開発チーム、商標権紛争とAI生成コード問題で分裂

 (blog.meshcore.io)
1 ポイント 投稿者 GN⁺ 6 일 전 | 1件のコメント | WhatsAppで共有
  • 急成長したメッシュネットワーキングプロジェクトで、商標出願とAI生成コードの使用の問題が重なり、core teamとAndy Kirbyが袂を分かった
  • Andy KirbyはClaude Codeを広範に使用してstandalone device、モバイルアプリ、web flasher、web configツールにまで拡張し、チームはこれらの作業の大半が vibe coded 形式だったうえ、その事実が隠されていたと記している
  • 分裂の直接のきっかけは、Andyが3月29日にMeshCore商標をチームに知らせず出願したことで、その後は意図をめぐる対話が決裂し、連絡も途絶えた状態となっている
  • core teamは公式MeshCoreをGitHubリポジトリが規定する単一のsource of truthだと明確化し、新たな拠点であるmeshcore.ioを中心にファームウェア開発、アプリリリース、技術文書、開発者向け議論を続けている
  • 2025年1月の開始以来、公式Mapで38,000以上のノード、公式Appで100,000人以上のアクティブユーザーを確保しており、公式情報の場と運営主体を明確にすることがいっそう重要になっている

分裂の背景

  • MeshCore開発チームはプロジェクト開始後、MeshCore Companion、Repeater、Room Serverファームウェアを85回以上リリースし、75種類を超えるハードウェアバリエーションをサポートしてきた
  • チームはAI生成コードに対して常に慎重な姿勢を保ってきたが、Andy KirbyはClaude Codeを広範に使って独自に動き始め、standalone device、モバイルアプリ、web flasher、web configツールまでMeshCoreエコシステム全体へと作業範囲を広げていった
  • Andy Kirbyは、その作業の大半がvibe coded形式であることをチームに隠していたとされている
  • チームはMeshCore DiscordでAIと信頼をテーマにアンケートを実施したが、本文にはアンケートの数値や詳細な結果はテキストとして示されていない
  • 対立が本格化したきっかけとして、Andyが3月29日付でMeshCore商標を出願し、それをチームに知らせなかったと記されている
    • チームは彼の意図を議論しようとしたが対話は決裂し、現在はAndyとの連絡が途絶えている
  • チームはここ数か月この問題の解決に努めてきたが、プロジェクトのために長く働いてきたチームにとっては、内部の人物がロボットと弁護士の側についたように感じられるほど衝撃が大きかった

公式MeshCore

  • 現在争われている核心は**「official」表記の使用権**であり、Andyは自分がブランドを所有していると強く主張しながら、MeshOSラインでこの表現を積極的に使っている
  • チームは実際に唯一の公式MeshCoreをGitHubリポジトリだと定義している
    • そのリポジトリが、何がMeshCoreであるかを決めるsource of truthとして機能する
    • Andyはそのリポジトリに一度も貢献したことがない
  • 内部分裂後、チームは新たにmeshcore.ioを立ち上げたが、Andyがmeshcore.co.ukと元のDiscordサーバーを管理していたため、ほかに選択肢はほとんどなかった
  • 新サイト公開後、AndyはClaudeを使ってそのlook and feelまで複製し、やめてほしいという要請も受け入れなかった

プロジェクトの成長

  • MeshCoreは2025年1月に始まって以来、非常に速いペースで成長してきた
  • 本稿執筆時点で、公式MeshCore Mapには世界中で38,000以上のノードが表示され、公式MeshCore AppはAndroidとiOSで100,000人以上のアクティブユーザーを抱えている
  • プロジェクトの規模が大きくなるほど、core teamが提供する公式情報の場の重要性も高まる
  • 最近は、国別サイトや地域メッシュコミュニティを中心としたMeshCoreウェブサイトの拡散も続いており、以下の例が直接列挙されている
  • Andy Kirbyは個人のYouTubeでMeshCoreの宣伝に大きく貢献したが、現在は自分の製品の宣伝に注力している

今後の運営方針

  • core teamはmeshcore.ioを中心に、ファームウェア機能の開発、バグ修正、PR管理、開発者向け議論を引き続き進めていく
  • 新しいファームウェアとアプリのリリースの変更ログ、ブログ記事、技術文書は、今後は以下のチャネルを通じて配信される
  • ブログに参加する人物と役割もあわせて公開している
    • Scottはプロジェクト創設者でlead firmware engineerであり、Ripple firmwareの開発者でもある
    • Recrofは公式MeshCore Mapの開発者でありFirmware Flasher担当で、MeshCore Map初期開発に関する知見も共有する
    • Liam Cottleは公式MeshCore Appの開発者で、MeshCore Appのスタートガイドを投稿する予定
    • FDLamotteはMeshCore向けPythonツールとSTM32ファームウェアのバリエーション作業を担当している
    • Oltacoはファームウェア更新の信頼性を高める新しいOTA Fix bootloaderの作業を担当している

コアチーム

  • 現在のMeshCoreチームはScott、Liam、Recrof、FDLamotte、Oltacoで構成されている
  • このチームは今後も人が直接書いたソフトウェアを基盤に、高品質な設計と開発を続けていく計画だ

新たな拠点

関連記事

1件のコメント

 
GN⁺ 6 일 전
Hacker News の意見

  • まだ使ったことがないなら、Reticulum はぜひ見ておくことを勧める
    基本プロジェクトは今、新しいメンテナが必要に見えるし、メイン開発者の強い姿勢も多少あるが、分散ネットワーキング・プロトコル層 の設計は本当によく練られている
    デスクトップアプリはインターネット(IP)や既存の LoRA ボードの USB 接続で動作し、最近 https://lilygo.cc/products/t-echo-lilygo を買ってオープンソースのファームウェアを入れて使ってみたが、USB でデスクトップにつなぐか Bluetooth で https://github.com/torlando-tech/columba と接続する体験はとても良かった
    このアプリのおかげで、メッセージング対応という面で Reticulum は本当に 第一級市民 のように感じられ、制限はあるがファイルや画像も送れる
    ネットワークレベルで動作するので、Reticulum 上で自分のアプリを直接作ることもできる

    • すでに LoRa でうまく動いているが、これは伝送媒体に依存しないプロトコルなので、今後は halow、光学、wifi のような別の伝送方式にも合うと思う
      人々もそのうち、LoRa では単純なテキストメッセージングを超える帯域幅・速度要求には絶対に追いつけないと気づくようになるだろう
      それでも Reticulum LoRa 1ホップで リアルタイム音声通話 を試したことがあるが、思ったよりかなりまともに動いた
      入門用の wiki はここ: https://reticulum.miraheze.org/wiki/Welcome
    • Reticulum で何か作ろうとして1か月使ったが、プロトコルを扱う ツール類 があまりにも不足していた
      アプリだけ作りたい立場からすると開発体験はかなり苛立たしいレベルで、概念は格好いいが足を引っ張る落とし穴が多すぎて、ブートストラップするのが持続可能には見えなかった
      特に nrf52 LoRA デバイスで動かそうとして Rust no-std でスタックを移植し、既存の MeshCore ネットワークで reticulum パケットを運ぼうとしたが、自分のパケットが正しく作れているか確認することすら悪夢のようだった
    • 実環境で 動いている Reticulum ネットワーク は一度も見たことがない
      いつもごく小さなテストベッドしか見ない
    • どの 周波数帯 が使えるのか気になる
      それが実際に重要なのかも気になる
    • nomadnet が Go で書き直されてほしい

  • なぜ mesh プロジェクト はこうも商標権の行使が厳しすぎるのかわからない
    Meshtastic も似たようなもので、私が MeshCore に興味を持ったきっかけの一つも、Meshtastic の商標ルールを読んでやりすぎだと感じたことだった

    • 無線界隈の文化は一般的な オープンソース文化 とはかなり違う気がする
      自由で制限のない共有は世界のデフォルトではなく、むしろかなり特殊なものだ
    • 関係者のことはよく知らないが、おそらく アマチュア無線免許 を持っている人たちである可能性が高そうだ
    • この段階で MeshCore を MeshTastic と同レベルの行使事例として比較するのは公平ではないと思う
      現時点では、チームの他メンバーの承認なしに英国で一人が商標登録した事案のように見えるだけで、まだ誰かを実際に攻撃しているわけではない
    • 理由は単純だ。金の匂い がするからだ
      MeshCore はユーザーが10万人を超え、中継器も世界中に雑草のように増えているので、ここを現金化しようとする動機は非常に強い
      特に現金化しようとしていたのは、ファームウェアやアプリ開発ではなくマーケティング側の人間だった
    • プロトコルは CC で、Mark も自由に使っていいと言っていたと聞いた
      ただ、自分の成果物が止めようのない AI 殺傷ネットワーム に貢献するのは望んでいないようだ

  • We have always been wary of AI generated code, but felt everyone is free to do what they want and experiment, etc. But, one of our own, Andy Kirby, decided to branch out and extensively use Claude Code, and has decided to aggressively take over all of the components of the MeshCore ecosystem: standalone devices, mobile app, web flasher and web config tools.
    And, he’s kept that small detail a secret - that it’s all majority vibe coded.
    これ以上の文脈がないと、この フレーミング はかなり疑わしい

    1. 誰かがエコシステムを「掌握する」というのは AI 使用とはまったく別の問題だ。それが正確に何を意味するのかわからないし、単にその人が何かを公開して、人々がそれを使いたがっているという意味なのかもしれない
    2. コードが実際に悪いのかの方が重要だ。チームが彼の AI 使用に気づいていなかったというなら、少なくともコード自体は見た目には問題なかったようにも聞こえる。ならなぜ コードそのものの出来 で判断しないのかわからない
      商標出願は事実なら明らかに敵対的で悪い行為だが、誰かが Claude Code を使ったという理由だけでは怒らない
    • 同意する
      MeshCore を実際に使っていて中継器も複数運用しているが、AI 補助コーディング 自体は気にしない
      ただし特にクローズドソースなら、その事実は公開すべきだと思う
      商標権でエコシステムを奪おうとする試みは狂っているように見えるし、Andy が GitHub プロジェクト自体には貢献せず、個人的な営利的追加物だけを作っていた点も気になる
      同時に MeshCore コアチームも反 AI バイアスを載せて、より強い物語を作ろうとしたのは確かに見える
    • 同意しない
      むしろ、こうして公に問題視したことを 支持 する
      AI が吐き出した雑な1000行を全部きちんとレビューしたと言う人は、自分か他人を欺いているのであって、実際に大規模なコードレビューをした経験もない可能性が高い
      テキスト1000行を読むのと、コードの複雑性への影響やエッジケースを分析するのはまったく別物で、そういう総合レビューには数日かかることもある
      100行の PR ですら数時間かかることがあるのに、「全部確認しました」という態度で流すから 0-day や漏えいが増えているのだと思う
      だから "You are absolutely correct, apologies for the oversight, here's a revised version:" のような出力は絶対に信用できない

    • Is the code bad? It sounds like they had no idea he was using AI. That seems to imply there was nothing wrong with the code as-is. Why not judge it on it's merits?
      AI を少しでも使ったことがあれば、実際はこんなふうにはいかないとわかる
      AI 出力 はもっともらしいが間違った結果を出すのが非常に得意で、そもそももっともらしさに最適化されているので、たまに正しいこともあるが、間違うときは見栄えの良いコードを作るため、かえって 判断が難しくなる
      人が書いたコードは、良いか悪いかの感触を相対的につかみやすい
      もちろん AddressSanitizer のようなオラクルがある、あるいは既存プロジェクトを複製して挙動を直接比較できる、といった例外はあるが、たいていはそんな贅沢はない

  • MeshCore と Meshtastic を少し触ってみたが、面白くはあっても全体として 過大評価 されていると感じた
    ここに入り込む SHTF 系の人たちのせいで、概念そのものがややぼやけている
    センサーネットワーク用途には関心があったが、実際の会話の大半は Hello World のようなテキストをやり取りすることに夢中な人たちの話で、本当の SHTF 状況でこうしたネットワークがどれほどひどく機能しないかはあまり見えていないようだ

    • 自分もほぼ同じ印象だ
      どちらのモバイルアプリもかなり 粗い し、Meshtastic は Android と Apple の UI チームが互いに話していないように見えて、さらにいら立つ
      異なるプラットフォームを使うと、新規ユーザーのオンボーディングや質問への回答があまりに難しい
      安く楽しく構築できたが、少なくともメッセージを安定して取りこぼさないようにする、より良い メッセージ永続化 が欲しい
    • Meshtastic と GPS を使って大きなキャンプ場を歩き回りながら地域を占領するゲームに参加したことがあるが、その用途には本当に合っていてかなり面白かった
      しかし自分の命がこうした メッシュネットワーク にかかっているような深刻な状況なら、非常に不安になると思う
      こうしたものを信頼できる手段として考えるにはまだ不安定すぎるが、まったく何もないよりはましかもしれない
      デバイスセットアップも問題で、インターネットのない場所でも一か所で作業するため raspberry pi 3 に開発環境一式を載せようとしたところ、基本クライアントインターフェースである巨大な Web アプリをビルドしている途中で先にメモリが尽きた
    • だいたい同意で、もう一つ付け加えたい
      標準の不在 も、実際の SHTF 状況では使い勝手を大きく下げると思う
      たとえば、なぜ meshstastic ではなく meshcore を使うべきなのかすら明確ではないし、そんな状況で LoRa 自体が自分の中の優先順位になるとも思えない
    • センサー系を作りたいなら LoRaWAN を見る方がよい
      Mikrotik のベースステーションに Chirpstack バックエンドを組み合わせればよく、この組み合わせは商用環境で非常に多く検証されている
    • SHTF が何なのかわからない

  • この クライアントアプリ はまだクローズドソースなのか
    自分ならその時点で即脱落だし、こんなことが起きたのもまったく驚かない
    これで終わりでもない気がする

    • https://github.com/zjs81/meshcore-open
      もう クローズドなクライアント は必要ない
    • どこでも使いたい base-station radio 向けに、とてもモバイルフレンドリーなオープンソースの self-hosted クライアントを自分で開発している
      MQTT、community observers、bots、webhooks などもサポートしており、無線機に縛られない日常用クライアントが必要で始めたが、今ではパワーユーザー向けのコンパニオンクライアントとしてかなり完成度が上がっている
      無線 API とファームウェアは公開されていて、他の選択肢も非常に多く、時にはクローズドソースの選択肢より機能的に優れていることすらあるので、金を稼ぐために一部ソフトウェアを閉じる選択そのものにはあまり反感はない
      https://github.com/jkingsman/Remote-Terminal-for-MeshCore
    • まだ クローズドソース だと知ってかなり驚いたし、おそらく変わらないだろう
      地元のメッシュでも先週 meshcore を試していたが、これで自分の関心は事実上なくなった

  • YouTube で Andy Kirby を見たことがあるが、動画があまりに煽情的で誇張気味でクリックベイトに見えたので、その人をプロジェクト運営と結びつけて見るようになり、その時点で meshcore に冷めた
    今回の件は、そのときの直感が当たっていたように感じさせる

  • 今の状況を見ると、.io サイト には "MESHCORE" ロゴがあり、.co.uk サイト には "MESHCORE(tm)" ロゴが掲げられている
    [1]: https://meshcore.io
    [2]: https://meshcore.co.uk

  • このプロジェクトを使ったこともなく、関係者も知らない
    ただ、誰かが「全部 AI で書き直す」みたいなことを言い出すたびに、結局かなりの 厄介者 だと判明することがあまりに多くて興味深い
    もちろんこの人だけがそうとは限らないし、自分が背景を全部知っているわけでもないので、この投稿全体を信頼できるかは判断できない
    それでも自分の小さなサンプルでは、信号対雑音比はかなり良いと感じる

  • Would you trust AI generated mesh firmware?
    AI 生成コード の信頼性を心配する前に、自分たちのコード品質の低さの方がひどくてあきれる
    自動テストもなく、テストを追加しようとする試みも無視されてきた
    [0] https://github.com/meshcore-dev/MeshCore/pull/925
    [1] https://github.com/meshcore-dev/MeshCore/issues/1059
    [2] https://github.com/meshcore-dev/MeshCore/pull/1065
    [3] https://github.com/meshcore-dev/meshcore.js/pull/11
    最後に見たときも入力検証がほとんどなく、地球の範囲を外れた GPS 座標 のようなあり得ない値ですらそのままブロードキャストでき、コードはそれをそのまま受け入れていた
    新規プロジェクトが苦戦するのは理解できるが、コード品質には投資しないまま、その問題で他人を説教する態度は鼻につく
    MeshCore を好きになりたいが、運営方針がいつも足を引っ張っており、私が知る主要運営者の二人、Scott Powell と Liam Cottle も、ファームウェアの上に クローズドソースのビジネス層 を載せて事業化しようとしていて、インセンティブが歪んで見える
    オープンコアモデル自体が問題だと言いたいわけではないが、このケースではオープンソースの代替を抑え込んで、自分たちの有料クローズドソース製品を押し出す方向になり得る
    しかも米国向けに推奨されている MeshCore の ブロードキャスト設定 は違法なのに、数か月前に Liam と Scott にメールしても無視された
    [4] https://github.com/meshcore-dev/MeshCore/issues/945

    • #4 は本当に腹立たしい
      自分も ham ではあるが、規則を一度破っただけで FCC に即通報するタイプではない。ただ、なぜそういう規則があるのかを知らない、あるいは気にも留めない態度は心配だ
      まず、その規則解釈が正しいかは確信がないが、ひとまず正しいとして読むと、スレッドの他の人たちも大半がその解釈を正しい前提で話していたように見えた
      私には、「私たちは規則に違反しているので直すべきだ」に対して、「Seattle では不便だからやらない」「Boston でもうまくいかないから無理」と答えているように読めた
      これは規則を任意の選択事項のように扱ってよい話ではない
      公共の電波資源 を使う人たちはたいてい法を守っており、プロジェクトが合法的に使うと性能が落ちるなら、それはプロジェクト側が直すべき問題だ
      こういう理由で、年配の ham たちがなぜだんだん神経質になるのかも理解はできる

    • Would you trust AI generated mesh firmware?
      この質問自体も 誘導的な質問 だ
      ここまで示された具体的事実は、彼が単に Claude Code を使ったということだけだ
      だから、テストは通るのか、セキュリティ欠陥が生じたのか、未検証のリグレッションが入ったのかの方が重要だ

    • 地球の範囲を外れた GPS 座標 が具体的にどんな値なのか気になる
    • そもそもプロトコルに GPS 送受信 がなぜ必要なのかもよくわからない

    • It's ridiculous to me that they're concerned about the trustworthiness of AI-generated code when their code quality is so low.
      同意するが、それでも今のコードは少なくとも構造はある程度筋が通っている
      AI が入ると本当に slopaghetti になりかねない
      自動テストを受け入れないのも、今 issue が 540 件、PR が 270 件開いていて、レビュー担当が 2 人しかいないなら、ある程度は事情がわかる
      こんなドラマまで重なったのだから、外部コントリビューションをさらに信用しづらくなるかもしれない
      実際にコードをマージしてほしいなら、Evo フォーク側の人に行く方がよいかもしれず、私が聞いた限り、関心のある PR をマージしてもらう方法は GitHub issue に十分な数のいいねを集めるか、Discord に入って直接頼むことだけだ
      [1] https://github.com/mattzzw/MeshCore-Evo

  • 開発に AI を使うのは良いことだと思うし、現代の開発で重要だとも考えている
    ただ、AI と人間が直接書いたコードには明確な違いがあるので、その事実は必ず 開示 すべきだ

    • それだけではない
      プロジェクトの大部分を vibe coding で作ったのなら、その人に本当に DCO に同意する権利があるのか、そしてそのコードベースの LICENSE で配布する権利があるのかも曖昧になる
    • その通りだ
      プログラムが何をしているのか把握すること自体も簡単ではないが、人が書いたコードなら少なくとも何らかの 意図 はあったと見なせる
      AI で作ったコードは、なぜそれが入っているのかすらわからない
      インターネット中に vibe coded なプロジェクトを公開しながら、最初はそうした事実を隠して、ただ「自分が作った」と言って賞賛だけを受け取るケースがあまりに多い
      その後になって、自分では何も書いておらず、どう動くのかもわからないと明かしてから、ようやく「AI を使うのは問題ない」と済ませようとする
      しかし、AI をツールとして使うことと、理解せずにそのままコピペし、全部自分の手柄のように装うことはまったく別物だ