自由を妨げるものとHyperbolaプロジェクト


Arch Linuxベースで、FSDGにしたがったGNU/LinuxディストリビューションのHyperbola GNU/Linux-libreLinuxカーネルからOpenBSDカーネルへ移行し、ユーザランドもOpenBSDベースにすると告知しました。カーネルからライブラリまですべてを一新するということは既存の資産をすべて作り変えなければならないことを意味しています。Hyperbolaプロジェクトはこの大改革へ踏み切った理由を次のように説明しています。

DRMへの反対

HDCPとはHigh-bandwidth Digital Content Protectionの略で「映像再生機器からディスプレイなどの表示機器にデジタル信号を送受信する経路を暗号化し、コンテンツが不正にコピーされるのを防止する著作権保護技術(コピーガード)のひとつ(コピーガードより)」を意味します。DRMはDigital Rights Managementの略で「電子機器上のコンテンツ(映画や音楽、小説など)の無制限な利用を防ぐために、オリジナルのデータを特定のソフトウェアあるいはハードウェアでしか再生できないようにすることで、第三者による複製や再利用を難しくする技術・管理方法(デジタル著作権管理より)」を指します。

Richard StallmanをはじめGNUプロジェクトはDRMに真っ向から反対の立場をとっています。Stallmanは自著『Free Software, Free Society』の中で次のように述べています。

This malicious feature is known as Digital Restrictions Management (DRM) (see our campaign against it, at DefectiveByDesign.org) and is the antithesis in spirit of the freedom that free software aims to provide.
この邪悪な機能は一般にデジタル制限管理(DRM)として知られ、フリーソフトウェアが目指す思想へのアンチテーゼです。
——Richard M. Stallman, Free Software, Free Society Selected Essays of Richard M. Stallman Third Edition, pp.79-80

つまりDRMやHDCPのような、著作権保護を理由にユーザの自由を侵害する機能はフリーソフトウェアとは相容れないと主張しているわけです。この主張は「誰でも海賊版を再頒布できるようにせよ」という意味ではなく、ユーザの(私的利用のような)現行の著作権法において合法の活動ですら制限してしまう機能に反対しているのです。

Rustへの懸念

Rustはセキュアなプログラミング言語で、学習コストは確かに高いものの一定の人気があります。Linux開発チームでは、ドライバの開発にRustを使ってみてはどうかという議論が挙がっています。Hyperbolaプロジェクトの決定はこれに影響されたのだと考えられますが、なぜそうRustを使うことに反発するのでしょうか?

日本語訳された記事では単に「LinuxカーネルはRustの利用を提案されているが、セキュリティ上の懸念がある」と訳されています。ここで言われている「セキュリティ上の懸念」とはRustそのものの潜在的なバグを指しているわけではありません。もともとはRustの商標に関する問題(拙訳は『Rustの不自由』)や、Rustのコードリポジトリへのアクセスにインターネット接続が不可欠かつ、サイバー攻撃が活発な場所でソースコードが管理されている状況を危惧しているのです。Rustパッケージを公開しているcrates.io自体はソースコードを管理していないため、後者はおそらくGitHubを指していると思われます。

Rustプロジェクトは標準ライブラリをなるべく小さく保ち、高機能なライブラリは有志の開発に任せる方針をとっています(Batteries included?)。この方針は標準ライブラリの保守を削減でき、優れたライブラリをコミュニティ開発によってすばやく提供できる点で優れています。しかしそのライブラリへアクセスするにはインターネットを経由しなければならず、ソースコードは多くがGitHubというプラットフォームで集中して管理されています。crates.ioに登録されているライブラリの何割がGitHubで管理されているのか分かりませんが、少なくともcrates.ioからもっとも多くダウンロードされているrand, libc, bitflags, syn, lazy-static, log, serde, quote, unicode-xid, rand_coreといったライブラリのソースコードはすべてGitHubで管理されています(2020年1月3日時点)。問題は、GitHubがサイバー攻撃の対象となりやすいことです。攻撃対象としてポピュラーなサービス上でコアなライブラリを管理しているこの状況は、Hyperbolaプロジェクトにとっては納得のいくものではないようです。

Linuxカーネルのセキュリティ

LinuxカーネルにはKSPP(Kernel Self Protection Project)というLinuxカーネルのセキュリティ向上を目的としたプロジェクトがありますが、Hyperbolaプロジェクト曰くもう活発ではないとのことです。同じくセキュリティを強化する目的でgrsecurityというLinuxカーネルのパッチセットが存在しますが、すでにフリーソフトウェアではなくなったとHyperbolaプロジェクトは主張しています。事実grsecurityはGPLv2に独自の制限を加えてパッチを頒布しており、それを非難する記事を書いたBruce Perensが名誉毀損で訴訟された過去もあります(Perensが敗訴しました)。

ユーザランドの不自由

多くのアプリケーションはPulseAudioやsystemdなどに強く依存しており、ビルドオプションに無効化のフラグすらないほどです。またJavaやRustのようなプログラミング言語にも依存するようになったのにも不満のようです。RustはMozilla Firefoxでもコアの言語として使われるようになってきましたが、Rustへの不信感は前述のとおりです。

GNU/Linuxではinitシステムにsystemdが広く使われるようになりました。しかしその潮流に抗う集団もいます。Devuanはsystemdに対抗するコミュニティのひとつで、initシステムにsystemdを採用したDebian GNU/Linuxから分かれたという経緯があります。Hyperbolaプロジェクトもまたsystemdに対し強い反発を抱いているGNU/Linuxプロジェクトのひとつです。FAQにあるとおり、移植性を考えず後方互換性を無視し、既存のサービスを置き換えさせるようなinitシステムだとしてsystemdを挙げています。

この決定に対するMichael Larabelの評価

このようにHyperbolaプロジェクトはOSの構成要素がFLOSSだけだとしても、なにかしらの不自由さを強いるソフトウェアには断固反対の姿勢をとるようです。しかしこれらの主張はすべて正しいものなのでしょうか。

Michael LarabelはHyperbolaの決定について『FSF-Approved Hyperbola GNU/Linux Switching Out The Linux Kernel For Hard Fork Of OpenBSD』という記事をPhoronixに投稿しました。その中でLarabelは「DRM/HDCPのサポートはプロプライエタリソフトウェアを実行するのでなければユーザの自由を制限するものではない」とし、Rustについても「ドライバをRustで書くためのフレームワークに関する非公式な議論」「セキュリティについての主張は議論の余地がある」と述べています。最後はかなりの人的資源が求められることに触れています。

感想

このニュースに興味を惹かれ、HyperbolaプロジェクトのWikiを読み彼らのRustとChromiumに対する意見をまずいながらも翻訳しました(『Rustの不自由さ』と『Chromiumの不自由さ』)。絶対誤訳している箇所が少なからずあるので間違いを見つけたら教えてくださいね。

これら2本の文書は面白かったです。現場の開発者からみたフリーソフトウェア運動の実践、どうユーザの自由を担保するかについて書いてくれる人は中々いないので、貴重な資料のひとつだと思います。

しかしGNU/LinuxからOpenBSDベースへの転換はだいぶ苦しい道のりを歩むことになるのではないでしょうか。カーネルやライブラリをまるごと入れ替えるわけですから、systemdから別のinitシステムへ転向したり、不自由なパッケージをシステムにインストールさせない仕組みを作ったりするのとでは比べ物にならない難易度です。

Hyperbolaの主張について

Hyperbolaプロジェクトの主張について僕の意見を書いていきます。はじめに書いておくと、この決定については反対の立場です。賛同できません。

まずDRM/HDCPについて、Linuxカーネルがそのサポートをし始めたことに反発するのなら、どうしてungoogledなChromiumを作るようにunDRMなLinuxカーネルを作ろうとしないのでしょうか?たしかにパッチの保守や改善には人手が要りますが、カーネルを変えることに比べれば大した作業ではないでしょう。その成果を、FSDGに従おうと努力しているほかのGNU/Linuxディストリビューションと共有し、開発の輪を広げることも可能なはずです。

Larabelにも指摘されているとおり、Rustについての判断は正しい理解がされているとは思えず粗っぽいです。確かにLWN.netの投稿を読めば、LinuxカーネルのメンテナGreg Kroah-HartmanがRust実装のドライバについて積極的な姿勢をみせているらしいのは分かりますが、そのあとに続く2つの条件(標準で有効にしないこと、実際にRustによる利点を示すこと)を読み飛ばしてはいけません。あくまでも提案段階で、公式な決定ではないのです。

商標の問題は一利あるにせよ、Rustに限らずGo言語・Python・Perl・Rubyといった現代のほとんどのプログラミング言語を使ったプロダクトはなにかしらの第三者製ライブラリに依存していて、そのライブラリは特定のサービス(crate.io, pypi.org, CPAN, RubyGems.org)によって管理されているのが一般的ではないでしょうか。それらのライブラリが特定のソースコードホスティングサービスに集中しているのが嫌なら、自分たちで別のサーバに必要なリポジトリをcloneすればよいのです。たしかにアップストリームはGitHubに向かってしまいますが、サイバー攻撃による被害を(攻撃の種類によっては)ある程度抑えられるでしょう。そもそもインターネットを経由する必要があるのはOSのパッケージも同じことです。

Linuxカーネル開発のセキュリティに対する意識への批判はあまり説得力があるように思えません。grsecurityはGPLv2に独自の制限を加えてパッチを提供しています。そのせいでgrsecurityがフリーソフトウェアではなくなったことと、Linuxカーネルの開発がセキュリティを意識しなくなったことは別問題のように思えます。またカーネルをOpenBSDへ移行したからといって、現在のLinuxカーネル以上のセキュリティを保てるかどうかを測定できません。

GNU/Linuxにおいて多くのコンポーネントが特定のソフトウェアに依存してしまっている問題は、GNU/Linuxディストリビューションに限った問題ではありません。GNU/Linux上でそれら抜きのシステムを作れないならBSDでも作れないでしょう。現にHyperbolaでは脱systemdを達成できており、なぜBSDへ移行する理由にsystemdを挙げるのか不明です。個人的には、これは単なる不満の後付け・かさ増しでしかないようにみえます。特にJavaに対する批判はPhoronixのコメントでも指摘されているように的外れです。この批判はGNU gettextへのパッチ投稿をもとにされているようですが、パッチ投稿者はgettextのメンテナBruno Haibleの回答になんら反応をしておらず、むしろHyperbolaプロジェクト側の株を落としているようにさえみえます。

おわりに

一見、フリーソフトウェア推進派の戦いの狼煙があがったように見えて、よく読んでみれば論理武装が十分ではなく拍子抜けしました。いくらGNU/Linuxに対し不満を抱えているとはいえ早急すぎる判断だと思います。せめて決定に至るまでの議論が追えるリンクも付け加えて欲しかったものです。

この決定によってHyperbolaBSDが大成功を収め、BSDユーザの増加に寄与し、BSDコミュニティが世界的ににぎやかになるならそれに越したことはありません。しかし現時点では実装よりもフリーソフトウェア主義が先行して物事が決められてしまい、結果として既存のHyperbolaユーザを思想のふるいにかけているだけなのではないかと感じます。