
2026/05/12 23:54
バンブーラボはオープンソースの社会的契約を濫用している。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Bambu Lab とオープンソース開発者の間における法的紛争が爆発した。改変された印刷ソフトウェアのフォークである「OrcaSlicer-bambulab」に関するものである。この論争の核心は、当該ツールがユーザーにインターネット接続なしでのローカル印刷を可能にし、結果として Bambu のクラウド機能を回避させ、同社へのアクセスや監視を妨げる点にある。開発者は以前、Bambu P1S プリンターをファイアウォールでブロックし、開発者モードにロックするとともに、Bambu Studio を削除、OrcaSlicer をオフライン動作とプライバシーのために導入していた。
OrcaSlicer は AGPLv3 ライセンスのオープンソースプロジェクトである Bambu Studio(それ自体は Prusa Slicer/slic3r のフォーク)のフォークである。通常条件(開発者モードの有無やインターネットブロックの有無なし)において、Bambu Studio を通じて印刷されたファイルは Bambu サーバーを経由するため、Bambu は印刷された全てのものを把握できる。一部のユーザーが利便性のために OrcaSlicer を使用しつつ Bambu クラウドを利用する(例:遠隔での印刷開始など)場合もあるが、著者はこれらの機能を必要とせず、個々の WireGuard VPN を運用している。
Bambu Lab は「OrcaSlicer-bambulab」というフォークを特定し、これを Bambu のクラウド配信メカニズムを回避するものとして見なし、開発者に対して法的措置を警告した。Bambu は、フォークが Bambu Studio の上流コードをそのまま使用しているにもかかわらず、なりすまし攻撃を行っているとして主張した。争点となった改変は、Bambu サーバーとの通信において偽のアイデンティティメタデータを注入し、公式の Bambu Studio クライアントのように振る舞うことを可能にするものである。Bambu は、このようななりすましが広く採用されたり誤構成されたりした場合に、数千台のクライアントが同時に正規トラフィックと見分けられない状態でサーバーに接続してくるという構造的脆弱性を生じさせる可能性があるとして警告した。
この状況は、3D プリンティング業界において特許権に基づく利便性機能とユーザープライバシーの間の緊張関係を浮き彫りにしている。著者は、Bambu が AGPL ライセンスを持つ Linux Bambu Studio のコードを使用しながらなりすましを主張するという点を皮肉だと指摘しており、2022 年の事案で彼ら自身のテレメトリフォークがユーザーデータを Prusa サーバーに転送したにもかかわらず法的な批判を受けなかったことへの言及も行っている。Bambu は、開発者をセキュリティ回避および自社のクライアントのなりすましと位置づける片道性の公的声明を発表し、関連する当事者からの直接回答を拒絶している。これに対し、Louis Rossmann はオープンソース開発者を Bambu の法的脅威から守るために 1 万ドルを提供する動画を公開しており、著者はこの種の貢献が開発者が引き続き Bambu の標的である限りは支援に寄与するのみだと指摘した。
本文
昨年の私、「もう一度 bambu lab のプリンタはお勧めできないかもしれない」という言明がありましたが、現在なお P1S を使用し続けています。しかし、bambu lab が「常時接続型のクラウドソリューション」を新基準として強く推進するようになった後、私は以下の措置を実行に踏み切りました。
- OPNsense ファアウェアールを通じてプリンタへのインターネット接続をブロック。
- ファームウェアのアップデートを停止。
- プリンタを「開発者モード(Developer Mode)」で固定化。
- Bambu Studio を削除し、代わりに OrcaSlicer を利用するよう移行。
これらが必要な措置だったのは、機材に関するコントロールを bambu 社ではなく私自身に維持するためです。ただし私は変わった人間だ承知の上です。購入した製品を「自分の所有物」として扱い、自費で購入したハードウェアの全ての利用状況を企業側に監視させたくないという思想を持つ、そうした少数派の狂信的なユーザーの一人です。
bambu lab は現状をそのまま放置しておく選択もありましたが、そうなればこのブログ記事は書きません。しかし彼らはそうしませんでした。では今回は何が起きたのでしょうか?
まず背景から説明します。OrcaSlicer はオープンソースプロジェクトである Bambu Studio を改修したフォークで、同様に Prusa Slicer のフォークであり、さらに slic3r の派生作品です(いずれも AGPLv3 条項の下でのオープンソースライセンス)。OrcaSlicer ではデフォルト設定において、印刷するファイルがすべて bambu のサーバーを介して処理されるようになっています。これにより、ユーザーが何を印刷したかという全ての履歴が bambu に可視化されてしまいます。ただし、私のようなユーザーであれば「開発者モード」で動作させながら、旧バージョンのファームウェアを用いてインターネット接続を完全に遮断することで回避できます。
一部のユーザーは OrcaSlicer を利用しつつも、bambu のクラウド経由での印刷を受け入れることに満足しています。移動中でありながら自宅にあるプリンタから印刷を開始したい場合など、独自 VPN 管理の手間なしで実現できる利便性は確かにあります。私は自社工営の WireGuard VPN を運用しており、その必要はありませんが、全員が同等のリソースを確保できるわけではありません。
ある時点で、bambu のクラウドルートを経由せず、プリンタの全機能を活用できると主張する OrcaSlicer-bambulab というフォーク版が出現しました。これに対し bambu lab は、「なるほどねえ、その 0.1%のハイレベルユーザーが、我々の AGPL ライセンス下の Linux バージョン(Bambu Studio)にあるクラウド配信機構なしで OrcaSlicer を運用したいなら……やめておいたほうがいいわよ。我々はアプリを使わせるから」という姿勢を示し、開発者に対して法的措置を threat しました。例えば、フォークが実際には upstream コード(即ち Bambu Studio の元のコード)を文字通り使用しているにもかかわらず、「なりすまし攻撃」を行ったという重大な公的指摘を行いました。
bambu lab は、これらの具体的な公的な主張をまず私自身に宛てて書かなかったのです。また、完全なやり取りの公開を拒否し、その代わりに一方通行の公的声明を発表しました。その結果、私は一般大衆の目から「セキュリティ回避行為」「顧客へのなりすまし」「インフラリスクの創出者」という人物像として位置づけられることになります。そのような表征は完全に否定します。「OrcaSlicer-bambulab」開発者の答弁より引用:
bambu lab は、オープンソース文化における社会的契約を違反し、法律力を使って極めて限られたユーザー層を抑制しようとしています。彼らがなぜそんなことを行うのかを知る由もないのですが、何もせず現状維持を選ぶ方がむしろ合理的(かつ収益性が高い)と思えます。実際には、自社インフラとセキュリティの問題の原因を個人のエコシステム開発者に背負わせるようなブログ記事を書き込んでいます。
ここで真の核心が浮上します:問題となっている改修は、ネットワーク通信の中に偽のアイデンティティメタデータを注入することで機能していました。簡単に言えば、「我々のサーバーとの通信において、公式 Bambu Studio クライアントであると pretending する」行為です(bambu lab ブログ記事より)。
私は彼らがオープンソース文化も、セキュリティの重要性も理解していないと考えます。もし公開的な User Agent スリングが DDoS 攻撃に対する唯一の防御手段だったとすれば、生態系上の課題解決やより安全なプラットフォーム構築に努めるべきではありませんでした。その代わりに、フォークの開発者のような熱心なハイレベルユーザーを責め立てる選択をしているのです。前年にも緊張が高まった際、コミュニティからの反発を「不幸な誤情報」として非難するようなブログ記事を執筆しました。おそらく彼らは、ソフトウェアエコシステムと所有モデルが購入後に変質したことに不満を持ったコミュニティメンバー(私を含む)による憶測を指していたのでしょう。今年は、その小さなスライサーフォークの開発者個人が、自社のクラウドインフラ全体に及ぼしうる潜在的な影響を非難しています。これは構造的脆弱性を生みます。もしこの手法が広く採用されたり誤設定されたりした場合、公式クライアントのなりすましを行いながら数千台のクライアントから同時にサーバーへのアクセスがありえます。我々のシステムは、そのトラフィックを見分ける手段を持たないでしょう。リクエストはすべて同一の見かけをした後からです(bambu lab ブログ記事より)。
私は、彼らがそれを「アプリを装ってなろうとする開発者」という枠組みで捉え込んでいることを面白がっていますが、実際にはその AGPL ライセンス下と同じコードを使用しているのだから、さらに皮肉です。2022 年、bambu 社自体のフォークによって bambu ユーザーのテレメトリデータが prusa のサーバーに飛ぶ事態を引き起こした際(私の知る限り)、prusa は C&D を発動しませんでした。その後、ブログ記事の残りの部分を「脆弱性」「バグ」「不安定性」について語りますが、upstream コードをそのまま使用しているフォーク開発者とそれとは全く関係のないように見えます。もしかしたら、最初からエコシステム全体をロックダウンしない新たなアプローチを検討するべきかもしれません。しかし、私は自分に嘘をついてはいません:私が何を言いようとしても、コメント欄での不平不満がどれほど積み上がっても、bambu が自らの過ちを見出すことはなさそうです。
それでも、他社のプリンタを購入して少しコストを追加することは、状況を変えるかもしれません。ルイ・ロスーマン氏は、オープンソース開発者が bambu の法的脅威に立ち向かうための資金として 1 万ドルの寄付を検討すると発言しました。私も喜んで貢献したいのですが、それは開発者が再び bambu の狙撃範囲に入ることを意図している場合のみ有効です。より効果的な戦略は、bambu を完全に避けることでしょう。