「GPLの守護神」E・モグレンが守り続けるもの - (page 2)

文:Stephen Shankland(CNET News.com)
編集校正:坂和敏(編集部)
2006年01月30日 16時02分

--フリーソフトウェアを取り巻く社会環境はよい方向に変化したとおっしゃいました。フリーソフトウェア・ムーブメントとフリーソフトウェアがまずまずの成功を収めたことは、今回の改訂にどう関係しているのですか。

 フリーソフトウェアは地理的にも、文化的にも驚くほど多様になりました。このムーブメントがグローバル化した結果、GPLが利用される場所や目的、利用者は拡大し、より完璧かつ強力に機能しなければならなくなっています。今回の改訂では、多くの条項を書き直し、米国中心的な表現や法的概念を排除することで、GPLの文言を中立化すると共に、法的なあいまいさを減らし、より多くの国で効果的に利用できるようにしました。

 また、最近はGPLと互換性のないライセンスに基づいて配布されるフリーなプログラムが増えているので、技術的な連携を促進するために、相互運用性に関する条項を拡大し、より多くの人が、より多くのプロジェクトで、より多くのコードを共有できるようにしました。「Eclipse License」や「Apache License」を適用したソフトウェアとコードを共有できるようになれば、GPLはかつてないほど多くのプログラムやプロジェクトと連携できるようになります。これはライセンスの乱立を解消するための措置であり、他の人々にも同様の行動を期待したいと思っています。互換性が拡大すれば、ユーザーは今よりも少ない数のライセンスで、同じ量の仕事を処理できるようになります。これもフリーソフトウェアの成功がもたらした変更点のひとつです。

--GPLバージョン3の草案は、Apache Software Licenseに準拠したソフトウェアに、GPLソフトウェアを利用することを認めていますか。

 いいえ。GPLは依然としてコピーレフトのライセンスであり、Apache Software LicenseとEclipse Licenseは制限の緩い非コピーレフトのライセンスです。Apache Software LicenseとEclipse Licenseは、これらのライセンスのもとで公開されているコードを使って、プロプライエタリなソフトウェアを作成することを認めています。ですから、GPLと双方向の関係を構築することはできません。

--GPLに関する問題のひとつは、GPLコードと非GPLコードの連携です。たとえば、GPLプログラムをコンパイルするときは、ソフトウェアライブラリ内の別のコードを利用します。GPLコードと非GPLコードの連携の程度について、明確な定義は行われたのでしょうか。どのような場合は連携が認められ、どのような場合は認められないのでしょうか。

 バージョン3では、絶対的なルールと考えられるものを明確にしました。GPLコードと動的に連携しているコード--つまり任意ではなく、必ずGPLコードに組み込まなければならないコードは、GPLに基づいて公開されるプログラムのソースコードの一部と見なし、公開が義務づけられます。この点を改めて主張しました。

--連携が問題になる例のひとつはLinuxカーネルです。Linuxカーネルはプロプライエタリなビデオドライバをモジュールとして取り込んでいます。また、オペレーティングシステムからプロプライエタリなファームウェアを取り込むネットワークドライバを利用する際も、連携の問題が生じます(こうしたファームウェアは「blob」とも呼ばれ、ハードウェアを使う際にOSのカーネルから取り込まれる16進数列からなる)。

 正直なところ、何ともいえません。そのカーネルが純粋なGPLコードなら、動的であろうと、静的であろうと、プロプライエタリなビデオドライバと連携させることはできません。プロプライエタリなライセンスが適用されているドライバと連携させることもできません。

 一方、カーネルに含まれるオブジェクトコードのblobは、別の複雑な問題を引き起こします。カーネルにとって、blobはデータです。このデータはあちこちを動き回り、コードを含む機器--たとえば電話やUSB機器に利用されます。この場合、blobはGPLソフトウェアの一部とは見なされません。Blobは別のコンピュータの、別のチップ上で走るプログラムです。

 blobと、カーネルのプロプライエタリなドライバは区別して考える必要があります。カーネルが明らかにGPLコードであるなら--もちろん、そのようなことはないのですが--(プロプライエタリなドライバと連携させることは)できません。しかし、blobであれば話は別です。blobは別のコンピュータで走る別のプログラムです。Linuxカーネルを呼び出したGPLソフトウェアから見れば、blobはデータにすぎません。ただし、FSFはユーザーは自分のマシンで何が走っているのかを知っているべきだと考えていますので、blobは倫理上好ましくないと考えています。

--GPLで保護されたソフトウェアを利用した製品を提供している企業として、Richard StallmanはTiVoの名前を挙げたことがあります。TiVoのビデオレコーダーにはLinuxが利用されています。GPLバージョン3の草案では、新しいDRM条項のために、こうしたことは不可能になるのでしょうか。

 TiVoはハードウェアとソフトウェアを組み合わせて、消費者向けの製品を提供しています。TiVoにはユーザーとしての権利がありますが、それと同時に、同社の製品を買うユーザーの権利も尊重しなければなりません。ユーザーがリモコンでどのボタンを押したのかを逐一本社に報告するようなビデオレコーダー--行動を詮索されないよう、ユーザーが機器に手を加えようものなら、ソフトウェアが動かなくなるような製品を売ることは、ユーザーを尊重した行為とはいえません。(TiVoは)GPL2に準拠していますが、それは非常にきわどいものでした。

 TiVoに限らず、すべての電子機器メーカーは、映画会社を助けるために、ユーザーを傷つけるような真似をやめるべきです。ユーザーをないがしろにして、どこかの誰かを喜ばせるような方法でGPLソフトウェアが利用されることは、われわれの望むところではありません。われわれの目標はユーザーの権利を守ることであって、映画の権利を守ることではないからです。TiVoの問題はここにあります。GPLバージョン2ではこの点が問題になり、われわれはTiVoが当該条項を満たすことができるよう支援しました。

 TiVoがGPLバージョン3を満たすことはさらに難しくなるでしょう。バージョン3は討議草案をもとに、自由の世界とDRMの世界を分離することを目指しているからです。これはTiVoが不得手とする分野です。TiVoは自由と不自由の境界線上の、きわめて微妙な部分を綱渡りしています。

CNET Japanの記事を毎朝メールでまとめ読み(無料)

-PR-企画特集

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]