GNU/Linuxにおける次世代のディスプレイサーバーが揺れている。Waylandか、Mirか、果たしてどちらが勝利するのか。あるいは、両者とも使われるのか。
昨日、CanonicalはMirを来年には完全にデフォルトにすると宣言した。
本の虫: CanonicalがMirの方針を決定、13.10でフォールバック付きXMirデフォルト、14.04でフォールバック削除、14.10でUnity移行
Waylandはというと、Fedoraが近い将来にWaylandをデフォルトに切り替えるのではないかと言われている。
Unix風OSでGUIのデスクトップ環境を実現するためのプロトコルとしては、長らくX Window System、あるいはX11と呼ばれるプロトコルが使われてきた。単にXとも呼ばれる。Xの実装には、プロプライエタリなものもかつてあったが、いずれも広く使われていない。最も広く使われている実装は、幸いなことに自由ソフトウェアで、XFree86と呼ばれていた。ただし、ライセンス変更などのいろいろな紆余曲折を経て、今ではforkされたX.Orgが最も広く使われている。
Xは動くが、何分相当に古いプロトコルであり、拡張に拡張を重ねて限界が来ている。特に、最近の主流であるCompositing window managerを実装するには、相当に無理をしなければならない。今の技術にあった、全く新しく設計されたプロトコルがほしい。誰もがそう考えたため、Waylandが設計されはじめた。
Waylandの開発は、将来も長く使うことができる、しっかりとしたプロトコル設計から始まった。ツギハギをかさね、もはや現代には不要な部分もあるXプロトコルの轍は踏みたくない。Waylandは、皆が同意するプロトコルを時間をかけて設計していった。
Waylandの価値は、しっかりとした将来にわたって使え、変更されないことが保証されたプロトコル設計にある。
Waylandは将来的にXを置き換えるプロトコルと期待され、Waylandの多くのウインドウマネージャー、デスクトップ環境、GUIライブラリなどのプロジェクトが賛同し、Wayland対応が進められている。
Waylandは、下位互換性もおろそかにしていない。WaylandにはXWaylandという仕組みがある。これはX.OrgをそのままWaylandの管理下で動作させ、X互換レイヤーとして機能させるものだ。したがって、既存のXに依存したソフトウェアも、変更なしにそのまま動作させることができる。
強固なプロトコル設計のWayland。既存のデスクトップ環境やGUIライブラリのプロジェクトが皆賛同するWayland。まだ時間はかかるが、いずれはXを置き換えるだろう。
ところで、Ubuntuを開発するCanonical社は、デスクトップやラップトップから携帯電話まで、幅広く使えるOSを開発したがっていた。それには新しいディスプレイサーバーが必要だ。Xプロトコルは設計的に無理が来ている。すでにWaylandのプロトコル設計がほぼ完了し、またGoogleのSurfaceFlingerといった実装もある。Canonicalは、表向きには将来はWaylandに移行することを表明していたが、内部でWaylandやSurfaceFlingerを試した結果、どれにも満足せず、自前開発しかないと判断したようだ。
どうやらCanonicalは、Waylandのプロトコルには基本的には賛成するものの、満足できない部分もあったらしい。そこで、Canonicalは注意深く設計されたWaylandのプロトコルを流用し、自前のディスプレイサーバーであるMirを開発した。また、XWaylandを流用して、XMirとした。
Mirの興味深い点は、Waylandから派生したプロトコルを使っているものの、プロトコルの互換性保証をしていないところにある。プロトコルはいつでも変更されうるとしている。これは、Canonical外部でMirを使う際に問題になる。なにしろ、プロトコルが変更されない保証がないのだから、Canonicalの都合でプロトコルが変更されて、既存のソフトウェアが動かなくなってしまう。Canonical自身は、自分で管理しているのでそのような問題は起こらない。変更するときには関連部署と相談して決めればいいだけだ。
したがって、Waylandは多くのディストリビューションで選択され、GNOMEやKDEを始めとした多くのデスクトップ環境で対応され、GTK+やQtを始めとした多くのGUIライブラリで対応されているが、Mirは上流での対応の動きは一切ない。そもそも、発表されたのが今年に入ってからで、まだようやく動くといった段階なので、対応する理由がない。従って下流Canonicalが自前で対応しなければならない。
MirはCanonical独自のプロトコルと実装であり、そのライセンスは自由なソフトウェアであるとはいえ、その変更規模の大きさから(たとえばmesaとかにも独自パッチを当てないといけない)、おそらく他のディストリビューションやデスクトップ環境やGUIライブラリでは対応されないだろう。結果的にUbuntuのみが使う。また、他のデスクトップ環境への対応は、既存のXプロトコルの互換レイヤーであるXMirで行い、GUIライブラリの対応は、上流ではなくCanonicalが自前でパッチを作成して保守しなければならない。X互換レイヤーがあるため、何も対応しなくても、現時点で一応は既存のソフトウェアをなんでも動かせる。Xがobsoleteになるには、まだまだ相当の時間がかかるだろうから、しばらくは時間を稼げる。
変更されないことが保証された、しっかりと設計されたプロトコルであり、多くのプロジェクトが安心して依存することができるWayland。柔軟に変更できるが、Canonical一社の都合でいつでも破壊的変更がされうるため、外部から安心して依存できないMir。さて、どちらが勝利するのだろうか。
Mirのライセンスの問題はよく議論される。MirのライセンスはGPLv3である。これはすばらしいライセンスであり、GPLv2の問題をいくつも修正している。しかし、CanonicalにはCLA(Contributor License Agreement)もある。CLAとは一般的な名称であり、特定の契約文ではない。共通しているのは、開発の貢献者は権利をプロジェクト管理団体に引き渡すというものだ。これはCanonicalだけではなく、ほとんどの大規模な自由ソフトウェア開発プロジェクトならば行なっている。
すると当然浮かび上がる懸念は、CanonicalはいつでもMirをプロプライエタリとして使えるという事だ。ソースコード自体はGPLv3で公開されるかもしれないが、たとえば実際の携帯電話の製品に搭載されるソフトウェアはプロプライエタリなバイナリブロブで、悪名高いTivoization(利用者がソフトウェアの改変版に差し替えることを不可能にすること)を行うかもしれない。これでは時代遅れのライセンスであるGPLv2に逆戻りだ。せっかくGPLv3である意味がない。
また、十分な市場シェアを獲得した後に、急に不自由ソフトウェアになりさがるかもしれない。この邪悪な戦略はとても効果的で、しばしば使われている。
一部のバカがGPLv3は制限的だと主張しているが、彼らはGPLv3の意義が分かっていない。もし、あるハードウェアで使われているソフトウェアを改変して差し替えることができなければ、たとえソフトウェア自体は自由ソフトウェアであっても意味がない。これはTivo社の例にちなんで、Tivoizationと呼ばれている。ソフトウェア自体は自由だと言いながら、自由なのは著作権だけで、別に特許権で不自由にする可能性もある。そのため、ソフトウェアを自由にするには、著作権だけではなくあらゆる権利の利用許諾を与えるべきで、そこに特許権が含まれるのは当然である。
さて、Waylandはどうかというと、MITライセンスである。MITライセンスは許諾的なライセンスであり、誰でも不自由なソフトウェアとして使うことを許してしまっている。
MirはCanonical社がいつでも不自由に使える。Waylandは誰でもいつでも不自由に使える。どちらも好ましくないので、ライセンス的には引き分けと言える。
ソフトウェアのデファクトスタンダード化の歴史を振り返ると、先に動くものを出したほうが勝ちだという気がする。「動く」の定義は、読者のカーチャンでも使える状況になるということだ(ただし読者のカーチャンがカーネルハッカーやロケット科学者である場合を除く)。gitで落としてビルドして設定ファイルを書き換えてというのは、「動く」の定義にはあてはまらない。
したがって、インストールしただけでWaylandなりMirなりが使える実用目的のディストリビューションが現れなければならない。いや、それでは筆者のカーチャンは使えない。やはりプレインストールされたコンピューターが近所の店で販売されていなければならない。
WaylandとMir、どちらが勝つのだろうか。
参考
Mir in Kubuntu | Martin's Blog
[Updated] Mir – An outpost envisioned as a new home | tvoss@work
3 comments:
RebeccaBlackOSやMauiなどWaylandがデフォルトになっているディストリはすでに存在しますよ。
Arch LinuxではGTKやQtのWaylandバックポートが有効になっていて標準的にWaylandが入るようになっています。
> また、十分な市場シェアを獲得した後に、急に不自由ソフトウェアになりさがるかもしれない。
それを言ったらFSFがトチ狂ってライセンスをすべて不自由なものに変更する可能性だってゼロではありませんよ。そもそもFSFがソフトウェアのライセンスをGPLv2から互換性のないGPLv3に変更できたのは、CLAを結んでいたからです。
もちろんそうです。
だから
「これはCanonicalだけではなく、ほとんどの大規模な自由ソフトウェア開発プロジェクトならば行なっている。」
と書いています。
Post a Comment