原文は英語で、これはその翻訳です。

GCCランタイムライブラリ例外とFAQ

はじめに

2007年6月29日、フリーソフトウェアファウンデーションはGPLv3をリリースしました。それはすぐに15のGNUプロジェクトに採用され、より多くの変更が続く月々でなされました。4.2.2のリリースでGCCのコードベースのほとんどは、この新しいライセンスに移行し、今、わたしたちはこのプロセスを終了させる準備をしています。

GCCに付属するあるライブラリのライセンスはまだ変更されていません。これらのライブラリはGCCが生成するオブジェクトコードによって自動的に使われます。そのため、これらのライブラリが単にGPLの条項だけで配布された場合、GCCが生成するすべてのオブジェクトコードが同じ条項で配布されなければならないでしょう。しかし、FSFは、開発者がGCCのライブラリを、どのようなプログラムに対しても、そのライセンスにかかわらず使うことを許すことを、だいぶ前に決めました。不自由なソフトウェアを開発することは社会に対してよいことではありませんし、それを容易にすることに関して、わたしたちはなんの義務もありません。それを禁止することは、かえって反する結果となるだろうと思われたため、わたしたちはこれを許すことに決めました。また、小さなライブラリをGCCの利用を制限するのに使うことは、いわば下克上のように思えたからでもあります。

ですから、これらのライブラリにはGCCが生成するオブジェクトコードを人々がどのライセンスでも配布することを認めるライセンスの例外が常にありました。わたしたちは、これらのライブラリをGPLv3に今移行するに伴い、これらの例外を更新しています。わたしたちの基本的ポリシーは変わっていません。新しいライセンスは以前に許されていたGCCのすべての利用を許すつもりです。しかしながら、この例外の更新の機会に三つの目標を達成することに決定しました:

  • GPLv3の新しい規定を活用する。GPLv3には新しい用語がいくつもあり、すべてのソフトウェアに活用することができます。これらには第7節のライセンス例外を提供するフレームワークを設立するものが含まれます。GCCがGPLv3をより活用するために、これらの新しい用語を念頭に置き、第7節のパラメータを用いた形で作業するよう、例外を更新する必要があります。

  • GCCのプラグイン・インフラストラクチャの根回しをする。昨今、しばらくの間、GCC開発者はコンパイラにプラグイン・フレームワークを加えることを検討しています。これは、ほかの方々がプロジェクトに貢献することを容易にするでしょうし、GCCのための新しいコンパイル技術の開発を加速させるでしょう。しかし、良心的でない開発者がプロプライエタリなソフトウェアを呼び出し、コンパイルされるコードを変換するプラグインを書くことができ、実効的にGCCのプロプライエタリの拡張を創設し、GPLの目的を打ち破るという懸念もありました。更新された例外はそのような悪用を禁止し、GCCチームがプラグインの開発に期待することができるようにしました。

  • 例外をGCCのコードベースのすみからすみまで一貫したものとする。何年もに渡り、このライセンス例外を運ぶ必要がある新しいファイルがGCCに加えられる際、その言い方をレビューして更新し、明確にし新しい懸念に対応するようにしてきました。結果として、今や、同じ基本的許可を提供する、たくさんの異なる例外の文章がGCCにはあります。今、これらのファイルのすべてが、わたしたちが準備した一つの新しい例外の文章を使うことができ、コードの法的なレビューを実行しやすくさせています。

GPLv3と同じく、草稿の作業中に、わたしたちは様々なユーザの懸念を聞き、適切に扱うよう努力しました。全部で、わたしたちはこのプロセスに一年以上をついやしました。フリーソフトウェアファウンデーションとGCCステアリングコミッティは、Software Freedom Law CenterのRichard Fontana, Bradley Kuhn およびKaren Sandlerにかれらの大変な仕事とこの例外への助力に感謝します。ここでの変更は、GCCのコミュニティを強化するでしょう。それが可能とするコンパイラの開発に、わたしたちは期待しています。

GCCは開発者の生活の重要な部分であるので、この変更について多くの質問があることを予期します。わたしたちは、質問に対して確実に扱いたいと考えています。以下では、ユーザが持つであろうと予期される特定の懸念について扱っています。もし、新しい例外についてここで述べられていない質問があれば、遠慮なく、こちら宛に<licensing@fsf.org>、わたしたちへ連絡してください。

どのように例外は作用するか

必要な許可(これらのGCCライブラリからのオブジェクトコードをあなた自身のプロジェクトのライセンスで運搬する)は主に第1節にあります:

あなたは、「ランタイムライブラリ」と「独立モジュール」を組み合わせる形で形成された「ターゲットコード」の作品を伝搬する許可を有します。たとえ、その伝搬がGPLv3の条項に違反したとしても、すべての「ターゲットコード」が「適格なコンパイルプロセス」で生成されたものである限り、許可されます。そして、あなたは、「独立モジュール」のライセンスと一貫する、あなたの選択する条項でそのような組み合わせを運搬することがでます。

この節はたくさんの定義された用語を使っていて、その特定の意味はこの例外がどのように作用するかに不可欠のものです。この節では、これらの用語がどのように普通のシナリオに関係するかを見ていきます。

ソフトウェアを書いたとき、それはソースコードファイルの集合からなります。GCCライブラリからなんのソースも含まない限り、それぞれのファイルは「独立モジュール」です。

このようなソースコードファイルをコンパイルしたとき、通常、何段階かを経ます: ソースコード生成、プリプロセス、低レベルコードへのコンパイル、アセンブラの処理、そしてリンク、です。すべてのプロジェクトがこれらのすべての段階を経るわけではありません。どの言語を使うか、どのように書かれるかによって異なります。しかし、常に、この順番で進み、GCCを使う誰もが、高レベルのコードを、アセンブリ言語やJavaバイトコードなどの低レベルの言語にコンパイルするプロセスを経るのです。このフェーズが、GCCがあなた自身のコードとGCCライブラリのコードを組み合わせたりリンクする時です。わたしたちは、これを「コンパイルプロセス」と呼びます。これから得る出力は、その出力がコンパイラの中間表現として(もしくは中間表現を生成するために)使われない限り、「ターゲットコード」と呼ばれます。

この許可を利用するためには、「ターゲットコード」を生成する「コンパイルプロセス」は「適格なコンパイルプロセス」でなければなりません。これは、GCCとGPLと両立しないソフトウェアの両方を伴わない、ということを意味します。「コンパイルプロセス」は、なにかの高レベルコードをGCCに入力して開始され、「ターゲットコード」とみなされ得るなにかを生成して終了するということを念頭に置くのが重要です。ですから、GCCが中間表現を出力しない限り、GCCとGPLと両立しないアセンブラやリンカ、高レベルソース生成系と組み合わせて使ったとしても、「コンパイルプロセス」は適格であることが可能です。それらのプログラムはここで定義される「コンパイルプロセス」には該当しません。GCCとGPLと両立しないソフトウェアを使えない唯一の場所は、コンパイルの中心的な仕事を遂行する時です。

ですから、GCCを、GPLと両立する拡張ありで、あるいはなしで使う場合、それは、「適格なコンパイルプロセス」でしょう。GPLと両立しないコンパイラツールだけを用いたときも、「適格なコンパイルプロセス」でしょう。(異なるコンパイラを使ったとしても、GCCライブラリとリンクすることは、GNU/Linuxのためにソフトウェアをビルドする人々にとって、珍しいことではありません。)しかし、GPLと両立しないソフトウェアを組み合わせて、上級コードから低級コードへ変換するプロセスの間にGCCを使う場合、それは「適格なコンパイルプロセス」ではありません。これには、たとえば、GCCをプロプライエタリなプラグインと一緒に使う場合が該当するでしょう。

「適格なコンパイルプロセス」を使う限り、GCCが生成した「ターゲットコード」を得て、「あなたの選択の条項」で伝搬させる許可があります。

GPLと両立しないソフトウェアをコンパイルプロセスでGCCと一緒に使った場合、この許可の利点を利用することはできないでしょう。すべてのGCCが生成するオブジェクトコードはGPLのライブラリから派生しますから、そのオブジェクトコードのどれを伝搬するときでも、GPLの条項に従う必要があることを意味します。あなた自身のGPLと両立しないソフトウェアを開発するために、GCCを使うことはできないでしょう。

よく聞かれる質問

わたしは、標準リリースのGCC(FSFから提供されているものや、わたしのオペレーティングシステムで提供されているもの)を使って、GPLと両立しないソフトウェアをコンパイルします。この変更はわたしにどう影響しますか?

なにも影響するべきではありません。GCCを中間表現を出力するようにコンフィギュアして(これは稀です)いない場合、新しい例外は、古い例外がそうであったのと同じく、コンパイルする際になんのライセンスの義務もないことを確実にするように設計されています。

この変更が影響するのは誰でしょうか?

現在、GCCを使っている誰もがこの変更の影響をまったく受けないべきです。ポリシーの変更は、今後の将来に可能となるであろうある種の改変を開発者がGCCに行うことを禁じることだけを意味します。FSFはGCCの開発者と緊密に作業し、今日、人々がGCCを使う様々な方法について学んできました。そして、FSFは、かれらがこの活動を新しい例外の元で継続できることを確実にするようにしています。

わたしのプログラムをコンパイルするのに、GCCをプロプライエタリなプリプロセッサとソースジェネレータともに使っています。それでも例外の利点を利用できるでしょうか?

はい。「コンパイル・プロセス」は「高レベル、中間言語ではないもの、で全体が表現されたコード」から開始することができます。これにはプリプロセッサやほかのプロプライエタリのソフトウェアで生成されたコードが含まれます。ですから、この場合の「コンパイル・プロセス」はなにもプロプライエタリなソフトウェアとと関係しません。「適格」となりますから、例外は、このプログラムに対して利用可能です。

わたしのプログラムをコンパイルするのに、GCCをプロプライエタリなアセンブラやリンカとともに使っています。それでも例外の利点を利用できるでしょうか?

はい。「コンパイル・プロセス」は「ターゲット・コード」をコンパイラが生成した時に終了し、「ターゲット・コード」には、「アセンブラ、ローダ、リンカ、そして/または、実行フェーズの入力として適切なもの」の出力を含みます。別の言葉で言えば、この場合の「コンパイル・プロセス」はGCCからアセンブリコードまたはリンクされていないオブジェクトファイルを得た時点で終了し、ですからなにもプロプライエタリソフトウェアは関係しません。「適格」となりますから、例外は、このプログラムに利用可能です。

わたしのプログラムのある部分をコンパイルするのにGCCを使い、プロプライエタリなコンパイラを別の部分のコンパイルに使っています。それから、後に、アセンブラやリンクの段階で組み合わされます。それでも、この例外の利点を利用できるでしょうか?

はい。この場合、それぞれの「独立モジュール」は、「適格なコンパイルプロセス」を通じて、「ターゲットコード」になります。異なるモジュールが異なるプロセスを経るとしても、このプログラムに対して例外はなお利用可能です。

わたしのプログラムをコンパイルするのにGCCをまったく使わずに、プロプライエタリなコンパイラツールチェインを使って、libstdc++とリンクしています。わたしのプログラム自身には、GCCでコンパイルされたプログラムがlibgccを含むのと同じようなランタイムライブラリのコードはまったくありません。それでも、この例外の利点を利用できるでしょうか?

はい。libgccとGCCでコンパイルされたオブジェクトコードを組み合わせることが、おそらく例外が使われるもっともありうる形ですが、GPLもGCCランタイム・ライブラリ例外も、静的リンク、動的リンク、そしてコードを組み合わせるほかの方法を、その状況でなにも区別しません。どの方式を用いたとしても、同じ条項で同じ許可があなたに利用可能です。

libstdc++を独立のライブラリとして配布する場合、配布にあたってはGPLの条項に従う必要があることに注意してください。たとえば、オブジェクトコードの形態でライブラリ自身を配布する場合、ソースコードをGPLv3の第6節にあげられた方法の一つでオブジェクトコードを受け取る人に提供する必要があります。しかし、GCCランタイムライブラリ例外の許可をあなた自身のプログラムに利用することに対してあなたが適格である限り、GPLの条項はそのプログラムには及びません。

なぜコンパイラの中間表現は「ターゲットコード」の定義から除外されているのですか?

最初にプラグインの枠組みをGCCに追加することを検討したとき、わたしたちはGCCの内部、つまり、低レベルのコンパイルのデータ構造を、ディスクへと単に保存するプラグインを誰かが書くことの可能性について深い懸念を持ちました。それがなされると、ほかのソフトウェアがGCCと直接つながらない形でそのコードを最適化あるいは改善することができるようになるでしょう。そのようなプログラムがGPLのコピーレフトに従うべきであるかを論議することは、わたしたちにとって難しいことであり、そのような構成を防止したかったのです。

わたしたちはこれを「ターゲットコード」の定義からそのような出力を除外することで行います。このため、ディスクにこの情報をセーブするプラグインを誰かが書いたとしても、GCCがターゲットコードを書き出す前に構造を変更するいかなるプログラムも、「コンパイル・プロセス」に関係することになります。そのプログラムがプロプライエタリであれば、それでコンパイルされたいかなるソフトウェアにもこの例外は利用可能とはなりません。GCCが最終的に生成するオブジェクトコードはGPLの条項で配布されなければならなくなるでしょう。

もし、あるコードをアセンブリ言語で書いた場合、それを普通にコンパイルされたオブジェクトコードと組み合わせて、それでも例外の利点を利用できるでしょうか?

はい。「適格なコンパイルプロセス」を通じて、すべてのオブジェクトコードがコンパイルされている限り、利用できます。アセンブラで手で書いたアセンブリコードを実行するプロセスは、コンパイルプロセスです。なぜなら、それは、「中間言語ではなく人間が書いたコードで全体が表現されたコードを“ターゲットコード”に変換する」からです。

どのライブラリをGCCランタイムライブラリ例外はカバーしますか?

GCCランタイムライブラリ例外がカバーするのは、そのライセンスヘッダに例外が適用されると述べられた告知があるすべてのファイルです。これには、libgcc, libstdc++, libfortran, libgomp, libdecnumber, libgcov とGCCで配布されるそのほかのライブラリが含まれます。

Classpathはこの新しい例外を使う(予定)ですか?

Classpathの現在の例外は同様な目的に供してますが、今回、これを更新することはありません。自由ソフトウェアのJavaコミュニティの最近の開発では、Classpathのライセンシングのポリシーの優先順位は、ほかのGCCライブラリとは異なり、別に評価しています。