ハードウェアが販売終了する際、企業はソフトウェアをオープンソースとして公開すべき
(marcia.no)- ハードウェア製品が販売終了（EOL） となる場合、企業はそのソフトウェアを 義務的にオープンソースとして公開すべきだという主張
- Right to Repair運動 は進展してきたが、EUレベルで EOL時のソフトウェア公開を法的に強制 すべきだと提案
- 例として、スマート体重計 がアプリのサポート終了で機能を失った事例や、SpotifyのCar Thing が販売終了後に電子廃棄物と化した事例に言及
- 企業がコードベース全体を公開する必要はなく、ハードウェア仕様と接続プロトコルだけを公開 してコミュニティが独自アプリを開発できるようにすべき
- 持続可能性とユーザーの権利 のために、販売終了したハードウェアを生かせるオープンソースのアプローチが不可欠
ハードウェア販売終了とオープンソースの必要性
-
ハードウェア製品が EOL（End of Life） 状態に達したら、企業は ソフトウェアをオープンソースとして公開すべき
- 販売終了した製品がまだ動作可能であるにもかかわらず、ソフトウェアのサポート終了によって無価値になってしまう問題を指摘
- このような状況を防ぐために 法的な強制力 が必要だと主張
-
Right to Repair運動 はすでに消費者の権利を強化してきたが、それをさらに進めて 欧州連合（EU） が EOL時のソフトウェア公開を義務化 すべきだという提案
- 企業が製品の販売終了時点でソフトウェアを公開するよう 欧州委員会（European Commission） が規制すべきだという立場
個人的な体験と問題事例
-
スマート体重計 の事例では、ハードウェアは正常に動作するがアプリが終了し、データ保存機能が失われた
- Bluetooth接続は可能だが、アプリがもはや開発されていないため、事実上ほとんど使い物にならない 状況
- 完全に動作するハードウェアが企業のサポート終了によって「死んだ」状態になる現実への 不満と浪費の問題 を提起
-
SpotifyのCar Thing の販売終了事例に言及
- 2024年末のサービス終了で、200ドルのハードウェアが一夜にして電子廃棄物へと転落
- Bose がEOL前に SoundTouchスピーカーをオープンソースとして公開した事例 は前向きに評価される一方で、依然として まれな例外的事例 だと指摘
現実的な代替案の提示
-
企業が コードベース全体を公開する必要はない
- その代わりに GitHubリポジトリでハードウェア仕様と接続プロトコル だけを公開すれば十分
- コミュニティはそれを基に 独自アプリを開発 できる
-
vibe-coding などの新しい開発アプローチにより、非専門家でも容易に参加可能
- 一般ユーザーでもハードウェアを直接扱い、改善できる時代が到来
持続可能性とユーザーの権利
- 販売終了したハードウェアを生かせる オープンソースのアプローチは、環境面・倫理面の両方で必要
- 不必要な電子廃棄物の発生を減らし、持続可能な技術エコシステム を維持できる
- すでに「文鎮化」したハードウェアであれば、ソフトウェアを公開してコミュニティに再活用の機会 を与えることが最善
1件のコメント
Hacker Newsの意見
EOL（End-of-Life） なプロジェクトを確実にオープンソース化させる最善の方法は、最初から オープンソースで始めることだ
「目標達成後に公開する」という約束や、会社が潰れたら公開するという宣言には意味がない
オープンソースで始めてこそ、投資家やコミュニティが信頼できる
オープンソース製品やハードウェアを作る会社にお金を使い、自由に配布するアーティストを支援すべきだ
企業がEOL後に公開しないと非難するのは、結局のところポーズにすぎない
大企業であっても、結束した消費者の要求には抗いにくい
FSFが自由ソフトウェアを普及させたように、消費者教育と文化的な転換が必要だ
専門家の意見が素早く共有される 消費者コミュニティ文化 を作るべきだ
シニカルな態度よりも、実際の変化を生み出す努力が重要だ
消費者からの圧力だけでは難しく、規制 が必要だ
ほとんどのシステムはコード署名チェーンに依存し、fail closed で動作する
しかし本来の署名主体が消滅したときには、新たな主体へ署名権限を委譲できる fail open の仕組みが必要だ
単にハードウェア仕様やプロトコルを公開しようという提案は、現実味が薄い
多くの機器は単純な接続プロトコルではなく、PCB解析でも仕様は把握できる
ファームウェアの書き込み方法と最小限のファームウェアさえ公開すれば十分な場合もある
ただし製品ごとに事情が異なるため、ケースバイケース の対応が必要だ
ルーターのように セキュアブート が e-fuse に焼かれている機器は、単純なオープンソース公開だけでは解決しない
こうした場合は、メーカーが署名鍵を エスクロー（escrow） の形で保管し、EOL後でも新しいソフトウェアを実行できるようにすべきだ
期限切れドメインを乗っ取った攻撃者がボットネットを構築することもあり得る
その代わり、ユーザーが明示的にサードパーティ製ファームウェアの導入を承認する 物理ボタン操作 のような手順が必要だ
ユーザーには、メーカーの許可なしに自分の機器を改造する 権利 がある
私も、EOLのせいでまだ使えるハードウェアを捨てなければならない状況にもどかしさを感じる
だが、「電子廃棄物の生産を違法化しよう」というようなアプローチは現実的ではない
例: 製品が主たる機能を果たせなくなった場合は全額返金、ただしメーカーが必要なソフトウェアを パブリックドメイン に置けば免除
こうした法律は、Googleのようにサーバー停止で製品を無力化する大企業を牽制できる
Windows 10をオープンソース化すれば、Microsoftの長期戦略は崩れてしまうだろう
このアイデアは、「オープンソース」そのもの以上に興味深い発想だ
たとえばUBNTがEOLになったブートチェーンを公開してCambiumがそのファームウェアを使えるようになれば、
結果はコミュニティ支援ではなく、永久的な製品アップデート競争 になるかもしれない
少なくとも、ユーザーが望む 代替ソフトウェアの実行を妨げない ようにすべきだ
ほとんどのユーザーはサーバーが消えたらファームウェアを入れ直さず、そのまま捨ててしまう
したがって、外部サーバーに依存しない設計 が必要だ
例: スマートスピーカーはローカルネットワークでのストリーミングに対応し、電球は標準プロトコルのペアリングをサポートすべきだ
幸い、Matter over Thread のような標準はこの方向に進化している
Google Nest Thermostat 第1・第2世代 は代表的な事例だ
No Longer Evil プロジェクトがこの機器を オープンソースのファームウェア で蘇らせた
Googleクラウドへの依存を取り除き、ユーザーが自分でサーバーをホストしたり、独立して制御したりできるようにした
そのおかげで、高価なハードウェアに再び命が吹き込まれた
今はある種の 暗黒時代 にいるように感じる
昔のボイラーは単にピンを1本グランドに落とせば動いたが、その後のモデルでは クローズドなプロトコル に変わってアクセスが難しくなった
しかし最新モデルでは再び OpenTherm 標準をサポートし、ハックしやすくなっている
最近はESP32やRaspberry Piベースのオープンハードウェアも多く、自分で ESPHome + LVGL でGUIを作ってホームオートメーションに統合している
友人たちがブランド製品だと勘違いするほど完成度が高かった
「そんなことは起きない」と思っている
ありがたいことに、AIとAndroid のおかげでプロトコルのリバースエンジニアリングは容易になっている
APK解析だけでも多くの情報が得られるので、Metaに買収される前に購入したLimitless Pendant向けのアプリとサーバーを自作している
コードは一行も自分で書いていない
誰も 永久サポート など期待していない
だが、アプリのバックエンドやロードマップが消えたという理由で 基本機能 まで殺してしまうのは納得しがたい
機器が電気的・機械的に正常なら、少なくとも最低限の利用は保証されるべきだ