LAST MODIFIED: 2011/08/15 16:02:04 UTC
不定期更新の日記です。ディスクスペースの関係上、 あまりに古くなったものは順次消していきます。 この日記の更新は、今野さんの *BSD Diary Links から取得することが可能です。
この GPLv2 に関する blog 記事の視点は、なかなか興味深い。
GPLv2 Section 4 によると、ソースコード配布義務等の GPLv2 が規定する義務に一度でも違反した場合、その GPLv2 で保護されたソフトウェアの使用権、複製権、配布権等々を自動的に失う、とされている。 じゃあ、その失った権利は、取り戻すことができるのだろうか。
GPL が実際に法廷で争われたケースは、 2007 年の BusyBox 訴訟が有名だ。 ファームウェアに BusyBox のコードが入っていたにも関わらず、 ソースコードが公開されていなかったことに、開発者が噛みついた。 開発者の代理人として SFLC (Software Freedom Law Center) が 3 件の訴訟を起こし、 いずれも 1 年以内に、示談の形で決着している（賠償金額は非公開）。 それだけに留まらず、2009 年までに、家電企業 14 社に対して訴訟を行なった。 まだ決着がついていないものがあるが、おおむね SFLC 側に有利な情勢である。
さて、こうやって GPL 違反が判明し、それが示談として決着した場合、 その製品をつくっていた企業は、ソースコードを公開して同製品の販売を継続することは許されるだろうか。 「示談をして争点に決着がついたのだから、問題はない」と思いがちだが、 実は GPLv2 Section 4 によると、それは許されないという解釈が可能である。 その企業は、当該 GPL ソフトウェアの権利を「自動的に」失っており、 そのソフトウェアを使うことは許可されない。GPL には、それを回復させる条件の記載がないので、 将来にわたっても回復することはない、というわけだ。
実際に、そういう主張を元に発生した訴訟が存在する。SFLC が 2009 年に起こした訴訟相手には、 米国の家電量販店 Best Buy が含まれていた。Best Buy は独自の製品を販売しており、 その中に BusyBox を使ったものがあったからである。
この訴訟の過程で、SFLC は販売差し止め請求を行なった。そこで使ったのが、 「Best Buy は GPL 違反によって、BusyBox に関する権利をすべて失っている」という論理である。 この請求は Best Buy の案件に関する書類を閲覧すると詳細が分かる。まだ進行中なので、 おそらく Best Buy は反論することが予想されるが、 これを合理的に論破するのはかなり難しいだろう。
こう考えると、GPL に入っている license termination 条項は、曲者である。 SFLC は、この失った権利について、 「法的には著作権保持者全員の同意のもと、GPL 以外のライセンスでの使用・配布を認めること以外に、回復する方法はないだろう」 と指摘している。つまり Best Buy がこの請求を覆すには、 「過去に GPL 違反をしていないことを明確に証明する」か、もしくは 「今後は著作権保持者の同意のもと、GPL 以外のライセンスで BusyBox を使うので問題ないと主張する」という、2 択を迫られることになる。 どちらも、言うまでもなく困難なことである。 もし対象が Linux カーネル単体だったとしたら、著作権保持者は数千人にのぼる。 そうなると、後者は事実上不可能だ。
Android は大きなプロジェクトであり、非 GPL なソフトウェアも多く含まれるが、カーネルは Linux である。 したがって、このカーネルのソースコードは、遅延なく公開されていなければならず、 公開されていなかった時期が過去に少しでもあれば、 配布者はその瞬間に Linux の使用権を失ってしまう危険性がある。 Linux カーネル部分について OEM 供給を受けていても、 責任は配布している側に存在する。 カーネルの配布権を失ってしまえば、製品として成立しなくなってしまう。
「何をそんな神経質な」と、一見現実味がないような話に見えるけれども、 Android 製品のベンダにとって、これは具体的な脅威となり得ることだ。 訴訟は、Linux にコードを提供したことがある人なら、誰でも起こすことができる。 たとえば、最近 Apple が起こした Galaxy Tab に対する販売差し止めの訴えは、 侵害された特許がすべて解決されることを条件として解除されることになっている。 これと同様に、「GPL 違反が解消されるまで Android 製品の販売を差し止める」という類の訴えを起こして認められてしまえば、 その状況の解消は、困難を究めることになるだろう。 だって、一度でも違反状態が発生すれば、 その時点で権利が消失してしまって回復しないのだから、 「違反してましたごめんなさい、今はちゃんと守ってます」という言い訳が使えない。
GPL 違反の潜在的なリスクはいろいろなところで議論されているが、 違反によって恒久的に権利を失うという論点が、 実際の訴訟の中で現れたのは非常に興味深い。
正式なアナウンスを出しました。たとえば FreeBSD/i386 の ISO イメージは、国内のミラーサイトだと ftp://ftp.jp.freebsd.org/pub/FreeBSD/releases/i386/ISO-IMAGES/9.0/ にあります。
その 1 は先月のエントリを参照のこと。
FreeBSD のストレージサブシステムには、 ATA 規格 HDD 用の ata(4) デバイスドライバと、 SCSI 規格 HDD 用のデバイスドライバが用意されています。 どちらも、ストレージ装置をブロックデバイスとして抽象化する機能を持ったものです。ユーザにはおなじみの、/dev/ad0 などの特殊ファイルとして見せる機能の中核を担っています。
大昔の HDD は、 単にストレージ装置が繋がってるだけの単純なものだったのですが、SCSI 規格や SATA 規格は、信号バスとしての機能が複雑化しています。たとえば複数のストレージ装置を複雑なトポロジでつなぐこともできますし、活線挿抜もできます。SCSI バスは、マルチイニシエータ構成をとることも可能です。
このようにバスが高機能化・複雑化してくると、 デバイスドライバをつくるのが大変になってきます。 そこで、信号バスの部分だけ共通化しましょう、 という考えが自然と生じました。
ATA と SCSI の両方とも、それぞれで共通に使える信号バスの 通信プロトコル部分と、制御用チップセット固有のコードが分離されています。ata(4)の場合、src/sys/dev/ata/chipsets/ にあるソースファイル群がチップセット固有のものです。チップセットの種類が異なっていても /dev/ad0 のように同じ特殊ファイル名で ATA HDD にアクセスできるのは、このようにコードが共通部分とチップセット固有部分に分かれていて、共通部分で同じように見せる処理を行なっていることが理由です。
たとえば、ハードウェアとしては HDD が 2 台接続されているシステムがあったとしましょう。固有部分はチップセットへのアクセス方法を知っているので、 HDD の存在や性能情報を獲得することができます。そこで得た情報を、決められた手順で共通部分のコードに渡します。共通部分は、その情報を元に /dev/ad0 と /dev/ad1 としてユーザに見せる等の機能を提供する、といった役割分担があるわけです。種類の違うチップセットがあったとしても、共通部分に適切に情報を渡すことができれば、ユーザからは同じように見えます。
こうやってコードを分離するには、 チップセット固有部分と共通部分の間で、 情報をやりとりする方法を決めなければなりません。 どちらも C 言語で書かれたソースですから、 具体的には相互に関数を呼び出すことで情報をやりとりするわけですが、 どういった関数が用意されていて、どういう風に呼び出せば良いのかを 決める必要があるわけです。 分離した 2 つのサブシステム間のソースファイルレベルでやりとりの方法は、一般に API (application programming interface) と呼ばれています。
で、FreeBSD では長い間、ATA 用のドライバと SCSI 用のドライバの 中間 API に、異なるものを使っていました。
ATA は BSD 由来の wdc(4) ドライバ（当時は ATA ではなく IDE）まで遡ることができます。もともと特定のチップセット、特定のバス構造への依存が強いデバイスドライバで、接続される機器も HDD のみという低機能なものでしたが、1995 年を過ぎたあたりから CD-ROM ドライブ等の多様なデバイスが IDE 経由で接続されるようになり、wdc(4) ドライバを再利用しつつ、すべてをカバーすることは難しくなってきました。そこで、1999 年から 2000 年のあたり、時期的には FreeBSD 4.X が登場したあたりに、このドライバを捨て、ata(4) という名前の、より汎用的な新しい実装に置き換えました。この前後で、/dev/wd0 という HDD のデバイスノード名が、/dev/ad0 という名前に変わったことを覚えている人もいるでしょう。
この ata(4) は、前述の中間 API を定義しており、共通部分と、バスやチップセットに依存する部分でソースファイルが簡単に分離できる構造になっています。新しいハードウェアへの対応＝そのハードウェア固有部分を追加するだけ、というように、労力が格段に下がったわけですね。
一方の SCSI 規格も、デバイスドライバの状況はあまり変わりませんでした。それぞれの機器に対してデバイスドライバがあり、同じような処理を重複して抱えていました。しかし、SCSI 機器は多くのワークステーションで使われていたこともあり、中間 API の重要性は IDE 規格よりも早い時期に認識されていました。
SCSI 機器の分野で大きな市場シェアを持っていた Adaptec は、主に PC 向けの仕様として Adaptec SCSI Programming Interface (ASPI) という名前の API を発表しました。これは実際に、MS-DOS や Windows, OS/2 で使われています。また、DEC が自社の UNIX (OSF/1, その後の Digital UNIX) 向けに Digital UNIX SCSI Common Access Method (CAM) という API を発表しています。CAM は性能の高い業務用機器をターゲットに入れた非常に高機能な仕様です。ANSI 規格化への強い働きかけがあったことから、仕様が公開されているという特徴があります。
FreeBSD に SCSI 規格の中間 API が導入されたのは 1998 年、FreeBSD 3.X の頃です。具体的には CAM が導入され、すべての SCSI デバイスドライバが CAM を使うように書き換えられました。この前後で、HDD に相当するデバイスノード名 /dev/sd0 が、/dev/da0 という名前に変わっています。
長々と前置きが続きましたが、本題の 9.0 で変わった点に入りましょう。 簡単に言うと、「ata(4) の中間 API が変更され、 共通部分として CAM を使うように変更」されました。 開発者の間では、ATA_CAM と呼ばれています。
CAM はもともと SCSI 機器向けに設計されたもので、 コマンドをパケットベースでやりとりする構造を持っています。 ATA は直接 DMA でデータを転送するだけの作業が多く、 複雑な操作もなかったため、ata(4) はコントローラを CPU から直接操作していました。
しかし、SATA になって FIS (frame information structure) と呼ばれるデータフレームが、ATA バス上を流れるデータの単位として導入され、 ATA でもコマンドのやりとりを抽象化する必要性が生じます。 ata(4) ドライバでは、ATAPI 対応や SATA 対応を入れるたびに、 そういったコマンドのやりとりを行なう部分を拡張してきたのですが、 そもそも ata(4) の基礎的な設計が、 コントローラを直接制御することに基軸を置いたものであるため、 そういった新しい機能の追加が非常に難しくなってきてしまったのです。
前述のとおり、CAM は基本設計がコマンドパケットベースになっています。 「SCSI 用のフレームワークなのに、ATA 用に使えるの?」 という疑問が湧いてきますが、技術的には ATA, SATA のそれぞれに対応する CAM SIM 層を追加する形をとっています。 「ATA HDD, SATA HDD を、あたかも SCSI HDD のように見せるエミュレーションをしているんだ」 というイメージだと思ってもらって、問題ないと思います。 アプリケーションからのアクセス要求は、 CAM のフレームワークが持つコマンドパケットの形でデバイスドライバに届きます。通常、それは SCSI バスプロトコルに変換して SCSI 機器に送ることになるのですが、そこに SATA のバスプロトコルに変換して SATA 機器に送る機能を追加したわけです。
中間 API が変わっただけで、 機器にアクセスするデバイスドライバそのものは変わらないため、 これで機能が増えたり、性能が向上したり、 といったことが直接的に得られるわけではありません。 もし、そういう話が書かれているのを見かけたら、 それは嘘だと思いましょう。残念ながら、「新しければ何でも性能が良い」 というわけではありません。
ユーザから見える違いは、共通部分が SCSI と同じになったことから、 デバイスノード名がまだ変わることになった点です。面倒ですね。
今まで /dev/ad0 だった ATA HDD は、/dev/ada0 という名前になります。互換性を維持するため、自動的に /dev/ad0 という名前へのシンボリックリンクも生成されますが、 アップグレードする際には、/etc/fstab の書き換えが必要になることを覚えておきましょう。
コマンドベースの処理が簡単になったことから、 新しいチップセットへの対応、PMP (ポートマルチプライヤ) などのハードウェアへの対応、NCQ への対応などが追加されています。 1 度に転送するデータ長の調整なども行なうようになりました。 つまり、チップセットによっては、性能が向上したり、 新たな機能が使えるようになっています。
ata(4) で従来から使えていた、すべてのチップセットは、 ATA_CAM 導入後も（デバイスノード名が変わるということを除いて） 同じように使えます。PMP や NCQ などの機能は使えません。
この変更によるメリットは、 開発者にとって新しいハードウェアへの対応が 容易になったことが一番大きいでしょう。 同じような機能を持つサブシステムが統合されたことから、 バグの修正や性能のチューニングがやりやすくなりました。 反面、ユーザ側には、 デバイスノード名の非互換性が見えてしまうことになり、 あまり嬉しくない側面があります。 ATA_CAM はデフォルトで有効になっていますので、 古いリリースからの移行時には、 デバイスノード名に十分に注意してください。
ata(4) が提供していた機能のうち、ataraid(4) と atacontrol(8) が使えなくなっています。
ataraid(4) は、ソフトウェア RAID の機能です。 HDD 上の特定の部分にメタデータ（RAID 構成情報）を記録しておいて、 チップセット、もしくは ata(4) の処理で RAID を実現します。 メタデータが記録された HDD を接続すると、/dev/ar0 という名前で領域にアクセスできるようになっていました。
この機能は graid(8) という名前の GEOM クラスに移行し、 デバイスノード名が /dev/raid/r0 という名前に変わることになりました。 管理も graid(8) ユーティリティを使って、gmirror(8) などと同様、 GEOM のフレームワークで行なうことになります。
atacontrol(8) は廃止されます。代わりに、 camcontrol(8) を使いましょう。このコマンドは新しいものではなく、 SCSI 接続の機器を操作するために用意されているものです。 ATA_CAM の導入によって、すべて CAM の管理下におかれましたので、 SCSI 機器も、ATA 機器も、すべて camcontrol(8) で操作可能です。
LAST MODIFIED: 2011/08/15 16:02:04 UTC