John Paul『Insights into Why Hyperbola GNU/Linux is Turning into Hyperbola BSD』の日本語訳です。

Hyperbola GNU/LinuxがHyperbola BSDへ転向する理由とは?

最終更新日 2020年1月16日 John Paul

2019年12月下旬、Hyperbolaプロジェクトに対する重大な変更を発表しました。OpenBSDカーネルを支持しLinuxカーネルを使わないと決断したのです。この発表はProject TridentがBSDからLinuxへ移行すると発表してからわずか一ヶ月後のことです。

またHyperbolaはGPLv3に準拠していないソフトウェアをすべて一新する計画もしています。

この真新しいプロジェクトの未来についてもっとよく理解するため、わたしはHyperbola創設者のAndreにインタビューしました。


なぜHyperbola GNU/LinuxはHyperbola BSDへ切り替えるのか

It's FOSS:「あなたがたの発表では、Linuxカーネルは『ぐらついた道を駆け足で進んでいる』状態とのことですが、どういうことなのか説明していただけないでしょうか?」

Andre:「まずはじめに、この言葉はHDCP(High-bandwidth Digital Content Protection)のようなDRM機能に適応していることを含意しています。現在この機能をビルド時に無効化するオプションが存在するものの、永久にオプションのままでいてくれると保証するポリシーはありません。

歴史的に、いくつかの実装は完璧な機能性にいたるまでは選択可能なものとして扱われます。その後は強制的に使わされ、パッチで取り除くのは難しくなります。仮にHDCPではそのような事態に陥らないとしても、わたしたちとしてはこのような実装に対して慎重にならざるを得ません。

そのほかにも、Linuxカーネルはセキュリティの脆弱性に対して適切に対処しなくなりました。数年前にGrsecurityは公開パッチを提供しなくなりましたが、わたしたちのシステムのセキュリティはそのパッチが頼りだったのです。高価なサブスクリプションを契約しているあいだはGrsecurityのパッチを使い続けられます。ただ、パッチを公開してしまうとそのサブスクリプション契約は中止されてしまいます。

これらのような制約は、完全なソースコードの提供やプロプライエタリ・ソフトウェアの排除[1]、ソースコードの利用に制約がないことを要件とするFSDG[2]の原則に反しています。

KSPP[3]はGrsecurityと競合するプロジェクトですが、GrsecurityやPaX[4]とは見劣りします。最近はあまり開発が活発でもないので、ほとんど停滞したプロジェクトになってしまっただろうと考えています。

最後に、カーネルへRustモジュールを組み込められるようになったのはわたしたちにとって不都合です。なぜならRustの商標の制約事項では、特別な許可なしにディストリビューションへパッチを適用することを禁止しているからです。わたしたちは自由でないソフトウェアや認可されていないファイルを取り除き、ユーザのプライバシの保護を強めるために改良を加えます。また、わたしたちのユーザが制約事項や許可を求めることなくわたしたちのソースコードを利用できるよう望んでいます。

これはわたしたちがUXP[5]という自由でRust不使用のブラウザエンジンを採用している理由にもなっています。

以上のような制限と、いずれHDCPが強制的にビルドに含まれてしまうかもしれないという懸念から、わたしたちには別の選択肢が必要となったのです」

It's FOSS:「あなたはOpenBSDカーネルからフォークすると発表しましたね。なぜFreeBSDやDragonflyBSDあるいはMidnightBSDではなくOpenBSDを選んだのでしょうか?」

Andre:「OpenBSDをもとにしたのは、高品質なコードで実装されていて、セキュリティを念頭に置いているからです。

わたしたちを強く惹きつけたのは、pledgeunveilという、ユーザ空間をよりセキュアにしてsystraceによるポリシー強制ツール(policy-enforcement tool)を使わずに済むOpenBSDのアイデアです。

また、OpenBSDはGNU/Linux-libreにも採用されているXenocaraLibreSSLでも知られています。わたしたちはこれらのソフトウェアがXorgやOpenSSLよりもうまく実装されていて、ほとんどの場合、より安定していることに気づきました。

わたしたちが把握している中でOpenBSDよりセキュアな実装のBSDはありません。OpenBSDカーネルを自由にする[6]作業をしているLibertyBSDが、わたしたちの開発の取っ掛かりとしてLibertyBSDのパッチを使ってもいいと許可してくれました」

It's FOSS:「なぜ初めにカーネルからforkするのでしょうか?どうやって新しいハードウェアのサポートと同時にカーネルを最新に保つつもりですか?」

Andre:「カーネルはオペレーティングシステムの中でもっとも重要で、盤石な基盤のもと前進し始めるために重要だと感じています。

初版に向けて可能な限りOpenBSDと同期をとっていこうと計画しています。将来的には他のBSDやLinuxカーネルと同じくハードウェアサポートや機能追加が必要な箇所をいじるでしょう。

わたしたちはLibreware Group(ビジネスパーソン向けの代理グループ)と調整し合いながら作業していて、近いうちに財団法人を公開しようとしています。

こうすることで新しいハードウェアのサポートやソースコードの開発を継続させ、開発者を雇用し、新たな愛好家を元気づけるでしょう。わたしたちは不自由なソフトウェアの排除だけでは不十分だとわかっています。なぜなら不自由なソフトウェアの排除は解決策ではなく緩和に過ぎないからです。したがって、わたしたちは自身の体制を強化し、開発を次の段階へと進めなければいけません」

It's FOSS:「あなたはOpenBSDカーネルやユーザ空間のGPL非互換なコードと自由でないコードをGPLに準拠したものに置き換えるつもりだと表明しました。GPLでないコードは何割ほどでしょうか?」

Andre:「OpenBSDカーネルとユーザ空間を合わせて約二割ほどです。

GPL準拠ではないコードのほとんどは、『四条項BSDライセンス』とも呼ばれる旧BSDライセンスで提供されているコードです。このライセンスには『不愉快な宣伝条項』が含まれているという欠点があります。BSDライセンスにとってこの条項を含めることが失敗だったわけではありません。しかしGPLv3やLGPLv3といった、宣伝条項によって互換が失われるライセンスで提供されるコードを開発しているわたしたちにとっては問題です。

OpenBSDの不自由なファイルの中には、適切なライセンス表記が欠けているものや、ライセンス文がディレクトリに含まれていないものもあります。

もしこれらのファイルがユーザに四つの基本的な自由を与えていないライセンスだったり、明示的にパブリック・ドメインとして公開されていなかったりするなら、それらはフリーソフトウェアではありません。開発者の中には、ライセンス表記が無いコードは自動的にパブリック・ドメインとして扱われると考える者もいます。これは誤りです。むしろこんにちの著作権法のもとでは、すべての著作物には自動的に著作権が付与されるのです。

OpenBSDに含まれる不自由なファームウェアの中には、Linuxカーネルにも含まれているものがあります。そういったファームウェアは長年Linuxカーネルの各リリースごとにLinux-libreプロジェクトが手作業で除去してきました。

不自由なファームウェアは16進数エンコード(hex encoded)されたバイナリの形式になっているのが典型で、独占的に設計されたハードウェア向けにソースコードが公開されないままカーネルへ提供されます。このようなバイナリは脆弱性やバックドアを抱えているかもしれず、あなたの自由を侵害する可能性があります。しかしファームウェアのソースコードが公開されていない以上誰もそれがわかりません。ユーザの自由なんかこれっぽっちも気にかけていないんでしょう」

It's FOSS:「HyperbolaBSDについて話していたときHardenedBSDが話題になりました。HyperbolaBSDを検討したことはありますか?」

Andre:「見てみましたよ。けれどもFreeBSDからのforkでしょう。FreeBSDはコードベースが巨大すぎます。たぶんHardenedBSDは良いプロジェクトなんでしょうが、不自由なソフトウェアの排除と全ファイルのライセンスの検証にもっと力を入れるべきです。

わたしたちはOpenBSDの品質・セキュリティそしてシステムを最小限度に保っている過去の実績から、FreeBSDではなくOpenBSDを使います」

It's FOSS:「UXP(Unified XUL Platform)のことを言っていましたね。Webアプリケーション一式を作るのにMozillaのServo以前のコードベースなMoonchildからのforkを使っていると思いますがどうでしょう?」

Andre:「そうですね。UXPを使うようにしたのにはいくつか理由があります。ここ数年わたしたちはDRMを除去したり、データ収集(telemetry)を無効にしたりプライバシー保護の設定をあらかじめ適用したりするために、FirefoxをIceweaselへと商標変更していました。しかしMozillaが改悪を加え、ユーザの拡張性を損ね、わたしたちの商標登録とプライバシー強化のパッチを壊していくたびにメンテンスはどんどん難しくなる一方です。

WebExtの肩を持つFirefox 52以降、すべてのXUL拡張が削除され、Rustを使うようにコンパイル時に強制されてしまいました。わたしたちがメンテナンスしていたプライバシ保護とセキュリティ強化のための拡張機能は使えなくなってしまいました。インストールされたWebExtアドオンそれぞれが固有のUUIDを持ちますが、このUUIDによってユーザを特定できてしまいます(Bugzilla 1372288)。わたしたちはこういったWebExtが持つプライバシの問題を懸念しています。

調査の結果、UXPを使うことでなにかを新しく実装することなくセキュリティの問題を解決できるとわかりました。UXPはツールキット側でデータ収集を無効にし、すべてのコードベースからデータ収集のコードを削除することに全力を注いでいます。

UXPこそわたしたちの目標によく見合ったソフトウェアだと知りましたが、プライバシ設定を調整したりDRMを除去したりするパッチはいまだに必要です。なのでわたしたちはUXPを基礎としてアプリケーションを開発することにしたのです。

こうして商標の変更やクローズドなバイナリを取り除くといったことを越えてわたしたち独自のアプリケーションを開発できるようになりました。いまわたしたちはUXPに修正を加えたものを使ってIceweasel-UXPIceape-UXPをメンテナンスしています」

It's FOSS:「フォーラムの投稿でHyperRCやHyperBLibC、あとはhypermanについても書いてありますね。BSDのツールをGPL準拠にするためにforkしたり書き直したりするのでしょうか?」

Andre:「どれも既存プロジェクトからのforkです。

Hypermanはpacmanからのforkですが、pacmanはBSDではまだ動作しません。pacmanにはBSDをサポートするためのコードはあったようですが最近のバージョンでは削除されてしまいました。HypermanはLibreSSLを使える実装がありBSDのサポートもされています。

HyperRCはOpenRC initにパッチを加えるものになるでしょう。HyperBLibCはBSDのLibCからforkするつもりです」

It's FOSS:「はじめからLinuxはGPLを、BSDはBSDライセンスを支持していていました。いまHyperbolaはBSDをGPLライセンスで開発しようとしています。BSDコミュニティの中でこの動きに反対する人らに対してどう応えますか?」

Andre:「GPL派とBSD派のあいだで意見の不一致があるのはわかっています。同じく齟齬が生じている話は、わたしたちのLinuxカーネルを使ったHyperbolaディストリビューションのことを単に『Linux』とは呼ばず『GNU/Linux』と呼ぶことですかね。『Linux』という呼び方は、Linus Torvaldsが開発を始めたLinuxカーネルに先立ち、1984年に作られたGNUのユーザランドを無視した定義です。GNUのユーザランドとLinuxカーネルが組み合わさってひとつのシステムとなるのです。

BSDと目立って異なる点は、GPLは将来のバージョンに至るまでソースコードを公開する義務がある点、ライセンスの互換性があるファイルとしか組み合わせて利用できない点です。BSDのシステムはソースコードを公開しなくてもいいですし、様々なライセンスのソフトウェアや自由ではないソフトウェアを制限なく組み込められます。

無論わたしたちはフリーソフトウェア活動を熱心に支持していて、将来にわたってソースコードが公に残っていてほしいと願っています。だからGPLを選ぶのです」

It's FOSS:「なるほど。HyperbolaBSDの開発を始めているというのはわかりましたが、いつごろ利用できるようになるのでしょうか?」

Andre:「2021年の6〜8月にはalpha版をリリースしたいですね」

It's FOSS:「いまリリースしているGNU/Linux版のHyperbolaはいつまでサポートし続けるのでしょうか?いまのユーザが簡単に移行できるようにする予定ですか?」

Andre:「告知どおり、2022年末までHyperbola GNU/Linux-libreをサポートします。ABIの違いがあるのでシステムの移行は難しそうですが、移行にあたっての告知と情報提供はWikiに載せるつもりです」

It's FOSS:「もし興味を持った誰かがHyperbolaBSDの助けになりたいとしたらどうすればいいのでしょうか?あなたが求めているスキルはなんでしょうか?」

Andre:「Hyperbolaに興味を抱き、向上心がある方を歓迎します。わたしたちはC言語のプログラマと、ソフトウェアのセキュリティとプライバシ保護を強めることに関心があるユーザを求めています。Hyperbolaの開発者はFSDGの原則とYAGNIの原則——必要となったときにだけ新しい機能を追加する原則——にしたがわなければなりません。

ユーザはわたしたちのGitリポジトリをforkしてパッチを提出できます」

It's FOSS:「ZFSをサポートすることについてなにか計画はありますか?なんのファイルシステムをサポートすることになるのでしょうか?」

Andre:「ZFSのサポートはまだ計画にありません。ZFSはCommon Development and Distribution License version 1.0(CDDL)でリリースされています。このライセンスはGPLと互換性がありません。

GPLv3のもとにコードを書き直して新しい名前で(たとえばHyperZFSとか)リリースすることも可能かもしれませんが、現時点ではHyperbolaBSにDZFS互換の機能を含める決定はありません。

ファイルシステムはGPLv3と互換性のあるBTRFS・JFS2・NetBSDのCHFS・DragonFlyBSDのHAMMERおよびHAMMER2・LinuxカーネルのJFFS2を移植するつもりです。長期的には、Ext4・F2FS・ReiserFS・Reiser4もサポートするかもしれないです。ただこれらのファイルシステムはGPLv3を適用できないGPLv2なので書き直さないといけません。ファイルシステムは開発をしよくテストする必要があります。なので最初のバージョンからではなく後々のリリースで使えるようになるでしょう」


わたしの質問に答えHyperbolaBSDの将来を明かすために時間を割いてくれたAndreに感謝します。

HyperbolaがBSDカーネルへ移行することについてどう感じましたか?BSDをGPLライセンスのもとでリリースすると聞いてどう思いましたか?ぜひコメントをください。

もしこの記事が面白ければソーシャルメディアかHacker NewsあるいはRedditでシェアをお願いします。

訳者注

  1. 原文ではdeblobbed。直訳すると「blobを取り除く」になります。英語版Wikipediaによると、FLOSSの文脈では、不自由なソフトウェアはblobbinary blobと呼ばれそしられるようです(blobは小さなインクの染みという意味)。Wikipediaに示されていた参考文献から一部引用します。

    there is still a binary blob -- similar to AMD and their Radeon firmware blobs within the kernel --

    Modern UEFI firmware is a closed-source, proprietary blob of software baked into your PC’s hardware.

  2. Free System Distribution Guidelinesの略。ガイドラインの日本語訳は『自由なシステム・ディストリビューションのガイドライン(GNU FSDG)』です。

  3. Kernel Self Protection Projectの略。

  4. https://pax.grsecurity.net/

  5. Unified XUL Platformの略。調べて真っ先に見つかるのはBasilisk web browserか。

  6. FLOSSの文脈で「自由にする(liberating)」とはクローズドなソフトウェア(自由ではないバイナリやファームウェアなど)をシステムから取り除くことを意味します。システムをdeblobbedにするとも言えるでしょう。