OpenBSD開発者はライセンスと互換性の懸念からuutils coreutilsを却下

DevOpenBSD開発者は、ライセンスと互換性の懸念からuutils coreutilsポートを却下 2026年9月30日、午前9時19分UTC • Marta Kowalska • 4分で読む この記事を共有する 保存する Rustベースのuutils coreutils再実装の提案されたポートが、OpenBSDメーリングリストで激しい議論を巻き起こし、プロジェクト創設者のTheo de Raadt氏とシニア開発者たちは、不要な重複であり、ベースシステムとの動作上の非互換性を導入すると判断し、これを却下しました。 sysutils/uutilsポートの追加提案は、今週、シニア開発者から厳しい批判を受け、Rustの採用、ライセンス哲学、およびベースシステムユーティリティ全体での動作の一貫性に対するプロジェクトのコミットメントに関する緊張を露呈しました。David Uhden Collado氏は9月20日にsysutils/uutilsポートを提出し、GNU coreutilsのRustベース再実装をドロップイン代替としてパッケージ化しました。このポートは、gcat、gls、gcp、gdate、gsort、gstat、gtail、gtimeoutなどのgプレフィックス付きコマンド名を、libexec/uutils下のマルチコールバイナリへのシンボリックリンクとしてインストールします。各パッケージは対応するGNU実装と競合し、GNUポートを二次的な@pkgpathとして宣言します。 応答は即座に、そして冷淡でした。「アジェンダの匂いがする」 長年のOpenBSD開発者であるStuart Henderson氏は懐疑的に始めました。「ポートとして実用的なアプローチだとは思えません。」彼はUbuntu 26.10によるuutils coreutilsの採用を認めましたが、他の再実装は開発途上にあると特徴づけました。OpenBSDの創設者であるTheo de Raadt氏は、さらに直接的でした。「アジェンダの匂いがする」と彼は書き、ライセンスに関する議論を分解しました。「また、これらはGNUユーティリティの代替としてOpenBSDにうまく適合すると考えています。特に、それらは寛容なMITライセンスを使用しているためです。議論は漠然と次のようなものです。すでに寛容なライセンスのユーティリティがあるので、私たちのユーザーベースは、非常に微妙に異なる、寛容なライセンスのユーティリティの2番目のセットを持つことに本当に興味があるのでしょうか。それは意味がありません。」 OpenBSDのベースシステムには、すでに寛容なライセンス（BSDライセンス）の標準ユーティリティ実装が同梱されています。プロジェクトは、これらのツールが互いに予測可能かつ一貫して動作することを保証するために何十年も費やしてきました。de Raadt氏は、微妙に異なる動作をするツールの2番目のセットを導入することは、ユーティリティ間で出力をパイプするユーザーにとって実際の問題を引き起こすと主張しました。 互換性の問題 「ワークフローの一部として微妙に異なる動作をするバイナリを誰も望んでいません」とde Raadt氏は続けました。「もし誰かが、openbsd lsコマンドを、openbsd sed、openbsd cut、または他のopenbsdユーティリティと組み合わせて使用するパイプラインの一部として実行し、偶然非標準化された出力特性を解析した場合、この宇宙のどこにも、そのlsを異なるlsに置き換えて、標準化されていないツール動作の衝突に驚かされることを望む人はいません。」 これはOpenBSDの核となる原則に触れています。ベースシステムは、まとまりのある全体です。ユーティリティは一緒に開発され、テストされます。個々のコンポーネントを再実装（互換性があるものでさえ）に置き換えることは、特定の出力形式、終了コード、またはエッジケースの動作に依存するスクリプトやパイプラインを破損するリスクを伴います。 Rustが火種に Collado氏が、uutilsのメタパッケージ構造とRust実装を引用して、個々のユーティリティを個別のバイナリとしてインストールすることについての不確実性を指摘したとき、de Raadt氏はその言語に飛びつきました。「ああ、Rustで書かれているからか。君のアジェンダが見えてきたよ。」 Rustの問題は、BSDコミュニティで繰り返し浮上しています。FreeBSDはベースシステムでのRustの実験を行っています。OpenBSDは、言語の急速なリリースサイクル、大きな依存関係チェーン、およびOpenBSDがサポートするアーキテクチャでのRustツールチェーンのブートストラップの難しさを理由に、まだ採用していません。プロジェクトは独自のCコンパイラツールチェーンを維持しており、歴史的に新しい言語ランタイムをベースインストールに追加することを避けてきました。 成熟度とメンテナンスの負担 Henderson氏がUbuntuの採用に言及したことは、暗黙の注意点を含んでいました。Ubuntu 26.10は（執筆時点では）まだリリースされておらず、Canonicalが新しいソフトウェアを出荷する意欲は、OpenBSDの保守的なリリースサイクルとは一致しません。OpenBSD 7.6は2024年10月にリリースされ、7.7は2025年4月に予定されています。プロジェクトは新規性よりも安定性を優先します。 成熟度を超えて、ポート構造自体が懸念を引き起こしました。uutilsプロジェクトは、単一のマルチコールバイナリ（argv[0]に基づいて異なるユーティリティをディスパッチする1つの実行可能ファイル）を配布しています。BusyBoxから借用したこの設計は、個別のバイナリを期待するOpenBSDのパッケージング規則と競合します。メタパッケージアプローチは、1つのユーティリティを更新するには、スイート全体を再構築して再配布する必要があることも意味します。 より広い文脈 uutilsプロジェクト（github.com/uutils/coreutilsでホスト）は大きな進歩を遂げています。2024年現在、GNU coreutilsのテストスイートの大部分に合格しており、いくつかのLinuxディストリビューションで特定のユースケースに採用されています。MITライセンスは、GPLライセンスコードを避けたいプロジェクトにアピールします。 しかし、OpenBSDによる却下は、哲学の根本的な乖離を示しています。Linuxディストリビューションはしばしばユーティリティを交換可能なコンポーネントとして扱います。OpenBSDはそれらをキュレーションされた統合システムとして扱います。プロジェクトのls(1)は単なる「lsの実装」ではなく、find(1)、tar(1)、およびシェルスクリプトが長年テストされてきたlsなのです。 今後の展開 このポートはまだ提案段階です。プロジェクト創設者とシニアポート開発者の両方からの反対を考慮すると、大幅な変更がない限り、受け入れられる可能性は低いでしょう。おそらく、マルチコールバイナリを個別のユーティリティに分割し、OpenBSDのベースツールとの動作上の同等性を示し、Rustに関するブートストラップの懸念に対処することになるでしょう。 現時点では、GNU互換ユーティリティを望むOpenBSDユーザーは、実際のGNU実装をパッケージ化している既存のsysutils/coreutilsポートを引き続き使用することになります。uutilsの実験は、少なくともOpenBSDにおいては、哲学的な壁にぶつかったようです。 出典: OpenBSD ports mailing list, September 20, 2026 出典:mail-archive.com#OpenBSD#Rust#CoreUtils#Licensing#uutils コメント 議論に参加するにはログインまたは登録してください ログイン 登録 コメントを読み込み中... ホームに戻る