GNU GPLに関して良く聞かれる質問

 [グニューの頭の画像] [ チェコ語 | 英語 | フランス語 | イタリア語 | 日本語 | 韓国語 | ポーランド語 | ポルトガル語 ]
このページには、GNU一般公衆利用許諾契約書(GPL)に関してよく聞かれる質問 への答えがまとめてあります。フリーソフトウェア財団の他のライセンスにつ いてより詳しく知るには、ライセンスの ページをご覧下さい。

このFAQを読んだあと、フリーソフトウェア のライセンシングに関するご自分の知識をクイズでたしかめることができます

もくじ


「GPL」とは何の略ですか?

「GPL」は「一般公衆利用許諾契約書(General Public License)」の略で す。この種のライセンスで最も普及しているのが「GNU一般公衆利用許諾契約 書(GNU General Public License)」であり、短くGNU GPLと呼ばれることもあ ります。GNU GPLの話をしているのが明らかな場合には、さらに「GPL」と縮め てもかまいません。

「フリーソフトウェアである」とは、GPLが適用されているという意味ですか?

そんなことはありません。フリーソフトウェアのライセンスは、GPLの他にも 多数存在します。全てを網羅しているわけではありませんが、ライセンスの一覧を用意してい ますのでご覧ください。ユーザに ある特定の自由を提供するライセンスはすべてフリーソフトウェアのライ センスです。

他のフリーソフトウェアライセンスではなく、GNU GPLを適用したほうが良いのはなぜですか?

GNU GPLを適用することによって、公 開される改良バージョンがすべてフリーソフトウェアであることを要求す ることができます。これにより、元はと言えば自分の著作物なのに、それに独 占的な改変が行われたバージョンと自分が競争しなければならなくなるといっ た事態に陥るリスクを回避することができます。しかし、特別な場合にはより制約の緩いライセンスを適 用したほうが良いこともあります。

すべてのGNUソフトウェアにはライセンスとしてGNU GPLが適用されているのですか?

ほとんどのGNUソフトウェアパッケージにはGNU GPLが適用されていますが、い くつかのGNUプログラム(およびその一部)には、劣等GPL(Lesser GPL, LGPL)の ようなより緩いライセンスが適用されています。これには、私たちの戦略が関係しています。

GPLを適用するとそのプログラムはGNUソフトウェアになるのですか?

GNU GPLの下でプログラムを公開するのは誰にでも出来ますが、それによって そのプログラムがGNUパッケージの一つになるということではありません。

「プログラムをGNUソフトウェアにする」とは、そのプログラムをGNUプロジェ クトに明示的に寄贈することです。プログラムの開発者とGNUプロジェクトが 寄贈に同意すると、そのプログラムはGNUソフトウェアになります。プログラ ムをGNUプロジェクトに寄贈することに興味がある方は、<maintainers@gnu.org>まで ぜひご一報ください。

GPL違反の可能性がある事例を見つけたら、どうすれば良いですか?

その旨報告してください。 まず事実をできるだけ注意深く調べ、その上で問題となっているGPLで保護さ れたプログラムの出版者や著作権者に事態を伝えましょう。著作権者 がフリーソフトウェア財団ならば、<license-violation@gnu.org> までご一報ください。 著作権者がフリーソフトウェア財団以外の場合に は、プログラムの管理者が著作権者であることもありますし、そうでなけ ればどうすれば著作権者に連絡できるか教えてくれるでしょうから、管理 者に連絡しましょう。

GPLがユーザの改変したバージョンの公表を許可しているのはなぜですか?

フリーソフトウェアのきわめて重要なポイントは、ユーザが自由に協力できる ということです。バグフィックスや改良を他のユーザと共有することによって、 お互いに助け合いたいと望むユーザの願いを叶えることは絶対に必要なことな のです。

GPLの代替案として、改変されたバージョンは原作者の許可を必要とする、と いうような条件を提案した人がいました。実際問題として、このやり方は原作 者がメンテナンスの必要に対応し切れている間はうまく行くでしょうが、もし 作者が(多かれ少なかれ)何か作業をすることを止めてしまったり、ユーザのニー ズすべての面倒を見なくなったりしたら、このやり方は行き詰まってしまいま す。実際上の問題は別としても、このやり方はユーザが互いに助け合うことを 許可していません。

ユーザによって作られた様々なバージョン間での混乱を避けるための手段とし て、改変されたバージョンをコントロールすることが提案されることがありま す。しかし、私たちの経験では、この種の混乱は大きな問題ではありません。 Emacsの多くのバージョンがGNUプロジェクトの外部で作られて来ましたが、ユー ザはそれらを別々のものとして見分けることができています。GPLでは、他の バージョンと見分けがつくようにして他の管理者たちの名声を守るため、ある バージョンの作者には彼または彼女の名前を載せることを要求しています。

GPLは、改変されたバージョンのソースコードを公に発表することを要求しますか?

GPLでは、あなたが改変したバージョンを公開することは要求してはいません。 改変を加えて、公開せずに個人的に使うのはあなたの自由です。これは組織( 企業を含む)でも同様で、ある組織は、改変したバージョンを用意してそれを 組織外に公開することなく内部的に利用することができます。

しかし、もしあなたが改変されたバージョンを何らかの形で公にす るならば、GPLはあなたが改変したソースコードをユーザがGPLの下で入手でき るようにすることを要求します。

すなわち、GPLは改変されたプログラムを特定のやり方で公開する許可を与え ていますが、別の形での公開は許可していないのです。しかし、公開するかど うかはあなた次第です。

この「いかなる第三者に対しても法的に有効な書面によるオファー(written offer valid for any third party)」とは何のことですか? これは、世界中の誰もが、GPLが適用されていればどんなプログラムのソースでも手に入れられるということなのでしょうか?

「いかなる第三者に対しても法的に有効」とは、そのオファーを持つ誰もが、 あなたにオファーの内容に応じるよう要求する権利があるということです。

GPLには、バイナリをソースコード抜きで商業的に頒布する場合、あなたが後 にソースコードを頒布する旨書かれた書面によるオファーを提供しなければな らないとあります。ユーザがあなたから受け取ったバイナリを非商業的に再頒 布するときには、この書面によるオファーの複製を一緒に渡さなければなりま せん。これは、バイナリを直接あなたから入手しなかった人々も、書面による オファーと一緒にソースコードの複製を受け取ることができるということを意 味します。

私たちが、オファーがいかなる第三者にとっても法的に有効であることを要求 するのは、そうすることによって、バイナリを間接的に受け取った人々もソー スコードをあなたに注文することができるからです。

GPLによると、改変されたバージョンは、公開された場合「すべての第三者に...ライセンスされ」なければならないとされています。この場合第三者とは誰のことですか?

GPLの第2節では、改変されたバージョンを頒布する場合にはすべての第三者に 対しGPLの下でライセンスされなければならないと述べています。「すべての 第三者」とは、誰にでも無条件で、ということです。しかしこれは、あなたが 彼らのために何か物質的に*してあげる*ことを要求するものではありません。 これは、彼らがあなたのバージョンに関して、あなたからGPLの下でライセン スされているということだけを意味します。

GPLで保護されたプログラムに改変を加えた場合、自分が改変した点に関して著作権を主張する必要はありますか?

あなたが改変した点に関して著作権を主張する必要はありませんが、多くの国々 では著作権は何もしなくても自動的に生じることになるので、あなたが改変し た点に著作権を主張したくないならば、明示的にパブリックドメインに置く必 要があります。

著作権を主張するかしないかに関わらず、あなたは自分が改変したバージョン を全体としてはGPLの下で公開しなければなりません。

あるプログラムがパブリックドメインに置かれたコードとGPLで保護されたコードから構成されていたとして、パブリックドメインな部分を取り出してパブリックドメインなコードとして利用することができますか?

どの部分がパブリックドメインに置かれているか見分けがつき、それを残りの 部分から分離できるならば可能です。もしコードがその開発者によってパブリッ クドメインに置かれていたならば、コードがどこにあろうとそれはパブリック ドメインだからです。

GPLは金銭目的でプログラムの複製を販売することを許可していますか?

はい。GPLは、誰もが販売することを許可しています。複製を販売する権利 はフリーソフ トウェアの定義の一部です。

GPLは、私のサイトからプログラムをダウンロードする人に料金を課すことを許可していますか?

はい。あなたはプログラムの複製を頒布するにあたり、望むだけの手数料を課 すことができます。ただし、もしあなたがバイナリをダウンロードによって頒 布するならば、あなたはソースのダウンロードに関しても「同等のアクセス」 を提供しなければなりませんので、ソースのダウンロードに課す手数料はバイ ナリをダウンロードするための手数料よりも高くなってはならないということ になります。

GPLは、ソフトウェアを受け取った人間が私に料金を支払うこと、あるいは受け取った旨通知することを義務づけることを許可していますか?

いいえ。実際のところ、そのような要求はプログラムをフリーではなくしてし まいます。もし人々がプログラムの複製を手に入れたときに料金を支払ったり、 誰か特定の人物にそのことを知らせたりしなければならないなら、そのプログ ラムはフリーではありません。 フリーソフトウェアの定義を参照してください。

GPLはフリーソフトウェアライセンスの一つですから、誰かに料金を払うこと なく、人々がソフトウェアを使うこと、そして再頒布することさえ許可してい ます。

GPLが適用されたソフトウェアを手数料を取って頒布する場合、私は公衆が手数料無しでもソフトウェアを手に入れられるようにしなければならないでしょうか?

そんなことはありませんが、もし誰かがあなたに手数料を払って複製を手に入 れたならば、GPLはその人が公衆にその複製を、手数料の有無に関わらず公開 する自由を与えています。例えば、誰かがあなたに手数料を払ったならば、そ の人は複製を一般公衆に向けてウェブサイトで公開することが可能です。

GPLは、改変されたバージョン、あるいはベータ版を機密保持契約(NDA)の下で頒布することを許可していますか?

いいえ。GPLは、あなたからあなたのバージョンの複製を入手した人は皆その バージョンの複製を(改変の有無を問わず)再頒布する権利を有していると規定 しています。あなたには、著作物の頒布に関してGPLより厳しい制限をかける 権限はありません。

GPLは、私が機密保持契約の下で改変されたバージョンを開発することを許可していますか?

はい。たとえば、あなたはあるプログラムに改変を加え、そのあなたの改 変した点をクライアントがOKを出すまで公開しないことに同意するとい う契約を受諾することができます。この場合、GPLによって保護されているコー ドがNDAの下で頒布されているということにはなりませんので、こういったこ とが可能になるのです。

また、あなたはクライアントに対して自分の改変した点をGPLの下で公開し、 しかしそれらをクライアントがOKと言うまで他の人には公開しないということ に合意することもできます。この場合も、GPLで保護されたコードがNDAや他の 追加的な制限の下で頒布されるということにはなりません。

GPLはクライアントがあなたのバージョンを再頒布する権利を与えます。しか しこの筋書きでは、クライアントがその権利を行使しないと決定しているわけ です。

私は、自分の著作物によって名声を得たいし、人々に自分が書いたもののことを知って欲しいのです。GPLを適用しても、私はそのような名声を得ることができますか?

もちろんあなたはご自分の著作物について名声を得ることができます。あなた 自身の名前(ここではあなたが著作権者と仮定)を著作権表示に書くのは、 GPLの下でプログラムを公開することの一部です。GPLでは、すべての複製に適 切な著作権表示を載せることを要求しています。

GPLが、プログラムの複製すべてにGPLの複製を含めることを要求するのはなぜですか?

著作物にライセンスの複製を含めることは、そのプログラムの複製を入手した 誰もが自分の権利の内容について知ることができるという点でとても重要です。

ライセンス自体の代わりに、ライセンスの在処を指すURLを含めたくなるかも 知れませんが、URLが今後5年、10年とずっと有効であり続けるという確証はあ りません。20年も経てば、今日私たちがURLとして知っているものそのものが もはや存在しないかもしれないのです。

ネットワークの世界で将来起こる全ての変化にもかかわらず、プログラムの複 製を持つ人々がずっとライセンスを見ることができることを保証する唯一の方 法は、ライセンスの複製をプログラムの中に含めることです。

著作物がライセンス自身よりもそんなに長くない場合はどうしたらよいですか?

もし単一のプログラムでその程度の短さならば、GNU GPLではない、より単純 でどんなことでも許可しているようなライセンスを適用したほうが良いでしょ う。

スペース節約のため、GPLの前文か自分のプログラムへの適用方法の説明を省いても良いですか?

前文と適用方法の説明はGNU GPLの不可欠な一部であり、省略することはでき ません。完全なGPLを適用してください。実際のところ、GPLには著作権が主張 されており、そのライセンスではGPL全体の一字一句忠実な複製のみ許可して います。

前文と適用方法の説明は5000文字あまりに過ぎず、GPL全体のサイズの1/3以下 を占めるに過ぎません。ソフトウェアパッケージ自体が相当小さいので無い限 り、前文と説明はパッケージのサイズに実質的なわずかな変化をもたらさない でしょう。もしソフトウェアパッケージが小さいのであれば、GNU GPLではな く単純で何でも許可しているようなライセンスを適用したほうがいいでしょう。

二つのライセンスが「矛盾しない(compatible)」とはどういう意味ですか?

二つのプログラム(あるいは両者の本質的な部分)を結合して一つの大きな著 作物にするためには、そういったやり方で両方のプログラムを利用する許可を 得ていなければなりません。二つのプログラムのライセンスが結合することを 許可していれば、それらのライセンスは矛盾しません。両方のライセンスを同 時に満たす手段が存在しない場合、それらは矛盾します。

いくつかのライセンスでは、結合の方法がそれらが矛盾しないかどうかに影響 することがあります。例えば、あるライセンスの組は二つのモジュールを一緒 にリンクすることは許可しているが、コードをマージして一つのモジュールに することは許可していない、といったたぐいです。

ライセンスが「GPLと矛盾しない」とはどういう意味ですか?

他のライセンスとGNU GPLが矛盾しないという意味です。あなたは、他のライ センスの下で公開されたコードをGNU GPLの下で公開されたコードと結合して 一つの大きなプログラムにすることができます。

GPLでは、そのような結合著作物がGNU GPLの下で公開される限り、結合を許可 しています。他のライセンスもそれを許可しているならば、そのライセンスは GPLと矛盾しません。

フリーではないライブラリを利用するフリーソフトウェアを書いているのですが、GPLを適用した場合どのような法的問題が発生するでしょうか?

あなたがリンクするライブラリが以下のようなGPLの例外条項に当てはまる場 合:

     However, as a special exception, the source code distributed need not
     include anything that is normally distributed (in either source or
     binary form) with the major components (compiler, kernel, and so on) of
     the operating system on which the executable runs, unless that
     component itself accompanies the executable.
     (訳: しかしながら、特別な例外として、頒布されるソースコードに当該
     プログラムの実行形式が実行されるオペレーティングシステムの主要な
     コンポーネント(コンパイラやカーネルなど)に通常付随して(ソースある
     いはバイナリ形式で)頒布されるものが含まれている必要はないとする。
     ただし、コンポーネント自体が実行形式と一緒に頒布される場合は除く。)

上記にあてはまれば、そういったライブラリを使う上で何か特別なことをする 必要はありません。言い換えれば、あなたが必要とするライブラリが独占的な オペレーティングシステムの主要な一部として提供されるならば、GPLは人々 があなたのプログラムをそういったライブラリとリンクすることができると規 定しています。

上記の例外の範囲に含まれないライブラリとあなたのプログラムをリンクした い場合には、あなたは自分自身で、GPLとは完全に別に例外を設ける必要があ ります。以下の著作権表示とライセンス表示によって、プログラムFOOとリン クする許可を与えることができます:

   Copyright (C) yyyy  <name of copyright holder>

    This program is free software; you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation; either version 2 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program; if not, write to the Free Software
    Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA

    In addition, as a special exception, <name of copyright
    holder> gives permission to link the code of this program with
    the FOO library (or with modified versions of FOO that use the
    same license as FOO), and distribute linked combinations including
    the two.  You must obey the GNU General Public License in all
    respects for all of the code used other than FOO.  If you modify
    this file, you may extend this exception to your version of the
    file, but you are not obligated to do so.  If you do not wish to
    do so, delete this exception statement from your version.
   (訳: Copyright (C) 西暦年  <著作権者の名前>

    このプログラムはフリーソフトウェアです。あなたはこれを、フリーソフ
    トウェア財団によって発行された GNU一般公衆利用許諾契約書(バージョ
    ン2か、希望によってはそれ以降のバージョンのうちどれか)の定める条件
    の下で再頒布または改変することができます。

    このプログラムは有用であることを願って配布されますが、*全くの無保
    証* です。*商業可能性の保証*や*特定の目的への適合性*は、言外に示さ
    れたものも含め全く存在しません。詳しくはGNU一般公衆利用許諾契約書
    をご覧ください。

    あなたはこのプログラムと共に、GNU一般公衆利用許諾契約書の複製を一
    部受け取ったはずです。もし受け取っていなければ、フリーソフトウェア
    財団まで請求してください(宛先は the Free Software Foundation,
    Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA)。

    加えて、特別な例外として、<著作権者の名前>はこのプログラ
    ムのコードをFOOライブラリ(あるいはFOOと同じライセンスが適用された
    FOOの改変されたバージョン)とリンクし、リンクされた両者を含む結合著
    作物を頒布する許可を与えます。あなたはFOO以外で使われているすべて
    のコードに関しては全面的にGNU一般公衆利用許諾契約書に従わなければ
    なりません。あなたがこのファイルを改変したならば、あなたはこの例外
    をあなたのバージョンのファイルに引き続き設けることもできますが、そ
    うする義務はありません。もし例外を設けたくなければ、この例外条項を
    あなたのバージョンからは削除してください。)

このような例外を設けることについて法的な権限を持っているのはプログラム の著作権者のみです。あなたがプログラム全体を自分自身で書き、また雇 用者あるいは学校が著作権を主張しないと仮定すれば、あなたが著作権者 です。よって、あなたは例外を正式に許可することができます。しかしあなた が、他の作者の手によるGPLで保護された他のプログラムの一部分をあなたの コードで使いたいからといって、あなたが自分でそれらのための例外を正式に 許可することはできません。それらのプログラムの著作権者の承認を得る 必要があります。

他の人々がプログラムを改変した場合、彼らは自分のコードにまで同じ例外を 設ける必要はありません。そうするかどうかは彼らの選択に任されています。

この例外を設けることによって法的な問題は無くなりますが、フリーではない ライブラリを利用することによって発生するもっと深刻な問題は何も改善され ません。あなたのプログラムは自由な環境の下では完全に使用できるわけでは ないのです。あなたのプログラムがある特定の作業をするためにフリーではな いライブラリに依存している場合、自由な世界ではそのプログラムはその作業 ができないということになります。フリーではないライブラリが無ければ実行 することすらできないならば、そのプログラムはGNUのような自由なオペレー ティングシステムの一部となることができません。プログラムは自由な世界に は完全に出入り禁止とされてしまいます。

ですから、どうか考えてください。その作業を、このフリーではないライブラ リを利用せずに行うことはできませんか? あなたはそのライブラリのフリーな 代替品を書くことはできませんか?

もしプログラムがすでにフリーではないライブラリを利用して書かれていたな らば、おそらく決断を変えるには遅すぎるでしょうから、公開しないよりは、 プログラムをそのまま公開した方がいいでしょう。しかしREADMEにおいて、フ リーではないライブラリが必要であることは欠点であることに言及し、プログ ラムを改変して同じ作業をフリーではないライブラリ抜きで行えるようにする ということを提案してください。

また、フリーではないライブラリについて、そしてそれがする作業について是 非私たち(<tasks@gnu.org>)に教 えてください。私たちは、人々が同じ仕事をするフリーなライブラリを開発す るよう奨励することができるかもしれません。

GPLの下で公開するために、私のプログラムに対する著作権を得るにはどうしたら良いですか?

ベルヌ条約によると、書かれたものには、それが確固たる形式に置かれた時か らすべて自動的に著作権が発生することになっています。ですから、誰かがあ なたの著作物の所有権を主張しない限り、あなたは自分が書いたものに関して 著作権を「得る」ために何かしなければならないということはありません。

しかしながら、アメリカ合衆国で著作権を登録するのは非常に良い考えです。 これによって、アメリカ国内での侵害者に対抗する上でより強い権力が与えら れます。

誰か他人が著作権を主張する可能性があるのは、あなたが従業員や生徒だった 場合です。その場合、雇用者や学校はその作業はあなたが彼らのために行った もので、著作権は彼らに帰属すると主張する可能性があります。その主張が正 当なものかどうかは、あなたがお住まいの場所の法律や雇用契約、どのような 種類の仕事をあなたがしているかなど、状況に依ります。疑いの可能性がある 場合には弁護士に相談するのが最善です。

もし雇用者や学校が著作権を主張するようなことがあり得ると思うのでしたら、 企業や学校の適切な権限のある役員や幹部によって署名された著作権放棄声明 (copyright disclaimer)を得ることで、この問題をはっきり解決することがで きます。(あなたの直接の上司や教授には、普通そのような声明にサインする 権限は*ありません*)。

私の学校が、私のプログラムを学校自身の独占的なソフトウェア製品にしたいと思ったらどうしましょう?

今日、多くの大学は自身が開発した知識や情報の利用を制限することによって 資金を集めようとしており、事実上営利企業と大差ありません。(この問題と その影響に関する一般的な議論については、2000年3月のAtlantic Monthlyに 載った「The Kept University」をご覧ください)。

あなたの学校が、ご自分のプログラムをフリーソフトウェアとして公開するこ とを許可しないかも知れないという危険性を察知したら、その問題をできる限 り早い段階で提起することが最善です。プログラムが便利に動くように近づけ ば近づくほど、学校当局側はそれをあなたから取り上げてあなた抜きで仕上げ ようという誘惑に駆られることになります。初期の段階であれば、あなたはよ り強い影響力を振るえます。

そこで、私たちは、プログラムがまだ半分できかかったような状態に過ぎない ときに学校側に近づき、こう言うことをおすすめします。「もしあなたがたが これをフリーソフトウェアとして公開することに同意するならば、仕上げます」。 これを脅しと考えてはいけません。説得するには、こう言う勇気が必要です。 「私のプログラムは自由を持つか、あるいは決して生まれないか、どちらかだ。」

GPLを私のプログラムに適用するにはどうしたらよいか、逐一説明していただけませんか?

GPLの説明ページをご覧ください。

GPLで保護されたプログラムの複製を、他のライセンスの下で手に入れた人がいると聞きました。こんなことはあり得るのでしょうか?

GNU GPLは、ユーザが他のライセンスをプログラムに添加することを認めてい ません。しかしプログラムの著作権者はプログラムをいくつかの異なるラ イセンスの下で並行して公開することができます。その一つがGNU GPLなのか も知れません。

それが著作権者によって含められたと考えられ、またあなたがその複製を 合法的に手に入れたならば、あなたが持つ複製と一緒に手に入ったライセンス が、あなたの複製に適用されるライセンスです。

自分が書いたプログラムをGNU GPLの下で公開したいのですが、同じコードをフリーではないプログラムでも使いたいのです。

フリーではないプログラムを公開するのは常に道徳的に堕落した所業ですが、 法的にはあなたがそうすることについて何の障害もありません。あなたがコー ドの著作権者ならば、あなたは場合に応じて様々な異なる非排他的ライセ ンスの下で公開することができます。

GPLで保護されたプログラムの開発者はGPLによって束縛されますか? 開発者がGPL違反を犯すことはあり得るでしょうか?

厳密に言えば、GPLは開発者が他の人のプログラムの利用や頒布、改変に関し て示すライセンスです。開発者自身はそれによって束縛されることはありませ んので、開発者が何をしようと、それはGPLの「違反」ではありません。

しかし、開発者が誰か他の人間によって行われたならばGPL違反となりそうな ことをする場合、開発者はもちろんコミュニティにおける倫理的名声を失なう ことになるでしょう。

GPLで頒布されているあるプログラムの開発者が、後になって他の人に排他的利用を認めるということはあり得ますか?

いいえ、公衆はすでにプログラムをGPLの下で利用する権利を得ていますので、 この権利を撤回することはできません。

フリーではないプログラムを開発するために、GNU EmacsのようなGPLで保護されたエディタを使っても良いでしょうか? GCCのようなGPLで保護されたツールを使ってフリーではないプログラムをコンパイルすることはできますか?

はい、なぜならばエディタやツールの著作権はあなたが書くコードは保護しな いからです。法的には、あなたがどんなツールを使っても、あなたがご自分の コードに適用するライセンスに関しては何の制限も課されません。

プログラムによっては、技術的な都合から自身の一部を出力結果にコピーする ものがあります。例えば、Bisonは標準パーサプログラムを出力ファイルにコ ピーします。そのような場合、出力結果にコピーされたテキストはそのソース コードを保護しているのと同じライセンスによって保護されます。一方、プロ グラムに与えられた入力から派生した出力結果の一部は入力側の著作権状態を 継承します。

たまたま、Bisonはフリーではないプログラムを開発するのにも使うことがで きます。これは、私たちがBisonの出力結果に含まれるBisonの標準パーサプロ グラムは制限無しに利用できるということを明確に認めているからです。私た ちがこう決めたのは、Bisonと同様の他のツールでフリーではないプログラム での利用を認めているものがすでに存在したからです。

GPLが適用されたプログラムのソースコードを「公正使用(fair use)」する権利はありますか?

はい、あります。「公正使用」とは、特別な許可がなくても認められている利 用のことです。そのような利用に関しては開発者の許可は必要ではありません から、開発者がライセンスその他で何を言おうと、あるいはライセンスがGNU GPLであろうが他のフリーソフトウェアライセンスであろうが、あなたは「公 正使用」することができます。

「公正使用」について世界的な原則は存在しないということに注意してくださ い。どのような利用が「公正」であるとみなされるかは国によって様々です。

人々が私のプログラムを利用して得た出力結果にGPLを適用する方法は無いでしょうか? 例えば、私のプログラムがハードウェアの設計に使われているとして、出来た設計図もフリーでなければならないと要求することはできるでしょうか?

一般的に言って、それは法的に不可能です。著作権法は人々があなたのプログ ラムと彼らのデータを使って作った出力結果の利用に関して、あなたに何の発 言権も与えていません。ユーザがあなたのプログラムを使って彼自身のデータ を入力ないし変換した場合、出力結果の著作権は彼に属すのであって、あなた にではありません。もっと一般的に言えば、あるプログラムが入力を他の形式 に変換する場合、出力結果の著作権の状態は、生成の元となった入力のそれを 継承するのです。

ですから、あなたが出力結果の利用に関して発言権を持つ唯一のケースは、出 力結果の本質的な部分が(多かれ少なかれ)あなたのプログラムのテキストから 複製されている場合です。例えば、Bison(前の項参照)の出力結果は、もし私 たちがこの特定のケースに関して例外を設けなければ、GNU GPLで保護されて いたでしょう。

そうする技術的な理由が無くても、無理矢理プログラムの出力にテキストをコ ピーするようにさせることはできますが、複製されたテキストは実用的な目的 を何ら果さないでしょうから、ユーザは単にそのテキストを出力結果から削除 して残りだけを使うということができます。そうすれば、複製されたテキスト の再頒布に課せられた条件に従う必要は無いわけです。

GPLプログラムの出力結果もGPLによって保護されるのは、どんな場合ですか?

プログラムが、プログラム自身の一部を出力結果にコピーするときのみです。

GPLで保護されたモジュールに対してあるモジュールを追加する場合、私のモジュールにもライセンスとしてGPLを適用しなければなりませんか?

GPLでは、結合されたプログラムの全体はGPLの下で公開されなければならない としています。ですから、あなたのモジュールはGPLの下での利用が可能でな ければなりません。

しかし、あなたが自分のコードの利用に関して追加的な許可を与えることは可 能です。そうしたければ、自分のプログラムを、GPLより制約が緩いが、GPLと は矛盾しないライセンスの下で公開してください。ライセンス一覧のページには、 GPLと矛盾しないライセンスの(不完全な)リストが用意されています。

ライブラリが(LGPLではなく)GPLの下で公開されている場合、そのライブラリを利用するプログラムにはGPLが適用されていなければならないのでしょうか?

はい。なぜなら、実際に実行されるプログラムはライブラリを含んでいるから です。

プログラミング言語のインタープリタがGPLの下で公開されていた場合、そのインタープリタで解釈されるように書かれたプログラムのライセンスはGPLと矛盾してはならないのでしょうか?

インタープリタが単に言語を解釈するだけならば、答はノーです。解釈される プログラムは、インタープリタにとっては単なるデータに過ぎません。GPLの ような著作権法に基づくフリーソフトウェアのライセンスは、あなたがインター プリタ上で利用するデータの種類を限定することはできません。あなたは、好 きなデータ(この場合解釈されるプログラム)を使って、好きなようにインター プリタを実行することができますし、そのデータを誰かにライセンシングする ことについて必要とされる条件は何もありません。

しかし、インタープリタが他の機能(多くの場合ライブラリですが、ライブラ リである必要はありません)への「バインディング」を提供するように拡張さ れている場合、解釈されるプログラムはバインディングを使うことによって事 実上それらの機能とリンクされることになります。ですから、もしそういった 機能がGPLの下で公開されているならば、機能を利用した解釈されるプログラ ムはGPLと矛盾しないような形で公開されなければなりません。JNI(Javaネイ ティヴインターフェース)はそのような機能の一例です。JNIによってアクセス されるライブラリは、それらを呼ぶJavaプログラムと動的にリンクされていま す。

上とよく似た、非常に一般的な例としては他に、ライブラリをそれら自身が解 釈されるインタープリタと一緒に提供するという場合があります。例えば、 Perlは多くのPerlモジュールと一緒に頒布されており、またJava実装は多くの Javaクラスを含んでいます。これらのライブラリとライブラリを呼ぶプログラ ムは常に一緒に動的リンクされています。

結果として、あなたのプログラムでGPLが適用されたPerlモジュールやJavaク ラスを利用することにした場合、GPLと矛盾しないような形でプログラムを公 開しなければならないということがありえます。この場合、結合されたPerlや Javaプログラムが実行されるPerlなりJavaなりのインタープリタに適用されて いるライセンスが何であるかは関係ありません。

Microsoft Visual C++(あるいはVisual Basic)を使ったWindowsアプリケーションを書いているのですが、これをGPLの下で公開する予定です。GPLは、私のプログラムをVisual C++(あるいはVisual Basic)のランタイムライブラリとダイナミックリンクするのを許可していますか?

はい、なぜならランタイムライブラリは通常あなたがお使いのコンパイラある いはインタープリタに付随するからです。

どうしてオリジナルのBSDライセンスはGPLと矛盾するのですか?

オリジナルのBSDライセンスはGPLには無い特定の要件を課すからです。その要 件とは、プログラムの宣伝に関するものです。GPLでは:

    You may not impose any further restrictions on the recipients' exercise
    of the rights granted herein.
    (訳: あなたは受領者に、ここで認められた権利の行使に関して更なる制限を課し
    てはならない。)

オリジナルBSDの宣伝条項はまさしくそのような「更なる制限」を提供してお り、よってGPLと矛盾します。

改訂BSDライセンスには宣伝条項がありませんから、問題ありません。

GPLの下で公開されていたプログラムがプラグインを使うとして、プラグインのライセンスにはどのような条件がありますか?

それはプログラムがどのようにプラグインを呼び出すかに依ります。プログラ ムがforkやexecでプラグインを呼び出すならば、プラグインは別のプログラム であり、メインプログラムのライセンスはそれらにはなんの条件も課しません。

もしプログラムがプラグインと動的にリンクされており、お互いにファンクショ ンコールを使ってデータ構造を共有している場合、それらは単一のプログラム を形成していると見なされますので、プラグインはメインプログラムの拡張部 分として扱われなければなりません。すなわち、それらはGPLかGPLと矛盾しな いフリーソフトウェアライセンスの下で公開されなければならないということ です。

プログラムがプラグインと動的にリンクされているが、それらの間のコミュニ ケーションはいくつかのオプションとともにプラグインの「main」関数を呼び 出して返値を待つだけという場合は、境界線上で微妙なケースとなります。

フリーではないプログラム向けのプラグインにGPLを適用することはできますか?

もしプログラムがforkやexecでプラグインを呼び出すならば、プラグインは別 のプログラムですから、メインプログラムのライセンスは何の条件も課しませ ん。ですからあなたはプラグインにGPLを適用できますし、特別な要件はあり ません。

プログラムがプラグインと動的にリンクされ、お互いにファンクションコール を使ってデータ構造を共有している場合、それらは単一のプログラムを形成し ていると見なされますので、プラグインはメインプログラムの拡張部分として 扱われなければなりません。このことは、GPLで保護されたプラグインをメイ ンプログラムとリンクするのはGPL違反となることを意味しています。しかし、 あなたはこの法的問題を、あなたのプログラムのライセンスにフリーではない メインプログラムとのリンクを許可する例外を加えることで解決できます。

より詳しくは、「フリーではないライブラリを利用するフリーソフトウェアを 書いています」という項目で始まる既出の質問をご覧ください。

GPLが適用されたプログラムを私のコードとリンクして独占的なプログラムをビルドしたいと考えているのですが、私のコードとそのプログラムとをリンクすると私のプログラムにもGPLを適用しなければならなくなるというのは事実でしょうか?

その通りです。

もしそうならば、プログラムを劣等GPLの下でライセンスしてもらうことはできないでしょうか?

頼むことはできますが、作者の多くはきっぱりとノーと言うでしょう。GPLの 考え方とは、あなたが私たちのコードをあなたのプログラムに含めたいならば、 あなたのプログラムもまたフリーソフトウェアでなければならないということ です。これによってあなたに対し、ご自分のプログラムを私たちのコミュニティ の一部とするような方法で公開しなければならないという圧力がかかることが 期待されています。

あなたには、私たちのコードを使わずとも何か他の適法な代替手段があります。

独占的なモジュールを、私のGPLで保護されたライブラリと指定したインターフェースの下でのみリンクすることを許可するにはどうしたらよいでしょうか?

以下の文面をパッケージに含まれるそれぞれのファイルのライセンス表示に加 えて下さい。そのファイルがGNU GPLの下で頒布される旨述べた文面の最後に:

    Linking FOO statically or dynamically with other modules is making a
    combined work based on FOO.  Thus, the terms and conditions of the GNU
    General Public License cover the whole combination.

    As a special exception, the copyright holders of FOO give you
    permission to link FOO with independent modules that communicate with
    FOO solely through the FOOBAR interface, regardless of the license
    terms of these independent modules, and to copy and distribute the
    resulting combined work under terms of your choice, provided that
    every copy of the combined work is accompanied by a complete copy of
    the source code of FOO (the version of FOO used to produce the
    combined work), being distributed under the terms of the GNU General
    Public License plus this exception.  An independent module is a module
    which is not derived from or based on FOO.

    Note that people who make modified versions of FOO are not obligated
    to grant this special exception for their modified versions; it is
    their choice whether to do so.  The GNU General Public License gives
    permission to release a modified version without this exception; this
    exception also makes it possible to release a modified version which
    carries forward this exception.
    (訳: FOOを静的ないし動的に他のモジュールとリンクすることはFOOを基
    にした結合著作物を作るということになります。そこで、GNU一般公衆利
    用許諾契約書の指定する要件は結合物全体を保護します。

    特別な例外として、FOOの著作権者はあなたに対し、結合著作物のす
    べての複製にFOOのソースコードの完全な複製(結合著作物を作成するのに
    使ったバージョンのFOOのもの)が付随し、GNU一般公衆許諾契約書にこの
    例外を追加したものの下で頒布される場合に限り、FOOを、FOOBARインター
    フェースを通してのみFOOとコミュニケートする独立モジュールと、その
    独立モジュールのライセンス条件を問わずリンクすること、及び結果とし
    ての結合著作物をあなたの選択した条件の基で複製・頒布することを許可
    します。独立モジュールとはFOOを基にしたものでも派生したものでもな
    いモジュールのことを指しています。

    FOOの改変されたバージョンを作る人々は、この特別な例外を自分が改変
    したバージョンで認める義務はないことに注意して下さい。認めるかどう
    かはご自分の選択次第です。GNU一般公衆許諾契約書はこの例外無しで改
    変されたバージョンを公開する許可を与えており、またこの例外は、改変
    されたバージョンをこの例外をそのまま含む形で改変したバージョンを公
    開することも可能としています。)

私は多くの異なるコンポーネントとリンクするアプリケーションを書いたのですが、それらは様々なライセンスが適用されています。私は自分のプログラムにどのようなライセンシング条件が課されるのがさっぱり分かりません。私が適用できるライセンスを教えて頂けませんか?

この質問に答えるには、私たちはあなたのプログラムが利用するそれぞれのコ ンポーネントとそのコンポーネントのライセンスのリスト、そしてあなたのラ イブラリがそれらのコンポーネントをどう利用するか記述した簡単な(それぞ れに数センテンスで十分)説明を見る必要があります。二つ例を挙げると:

「単なる集積」と「二つのモジュールを一つのプログラムに結合すること」の違いは何ですか?

二つのプログラムの単なる集積物とは、それらを同じCD-ROMやハードディスク に隣り合わせに置くことを意味します。私たちはこの用語をそれらが別々のプ ログラムであるときに使い、単一のプログラムの一部では無いときに用います。 この場合、プログラムの一つがGPLで保護されていても、他のプログラムには 何の影響もありません。

二つのモジュールを結合するとは、それらを一緒に接続しそれらが単一のより 大規模なプログラムを形成することを意味します。もしいずれかの部分がGPL で保護されているならば、結合物全体もGPLの下で発表しなければなりません。 もしそうできなければ、あるいはそうするつもりが無ければ、あなたはそれら を結合することはできません。

二つの部分を一つのプログラムに結合する要件とはなんでしょう? これは法的 な質問であり、究極的には裁判官が決めることです。私たちは、適切な基準は コミュニケーションのメカニズム(exec、パイプ、rpc、共有アドレス空間での ファンクションコールなど)とコミュニケーションのセマンティクス(どのよう な種の情報が相互交換されるか)の両方に依ると考えています。

モジュールが同じ実行ファイルに含まれている場合、それらは言うまでもなく 一つのプログラムに結合されています。もしモジュールが共有アドレス空間で いっしょにリンクされて実行されるよう設計されているならば、それらが一つ のプログラムに結合されているのはほぼ間違いないでしょう。

逆に、パイプやソケット、コマンドライン引数は通常二つの分離したプログラ ムの間で使われるコミュニケーションメカニズムです。ですからそれらがコミュ ニケーションのために使われるときには、モジュールは通常別々のプログラム です。しかしコミュニケーションのセマンティクスが親密であったり、複雑な 内部データ構造を交換したりする場合は、それらも二つの部分がより大規模な プログラムに結合されていると考える基準となりうるでしょう。

どうしてFSFは、FSFが著作権を保有するプログラムへの貢献者が自らの著作権をFSFに譲渡することを要求するのですか? もし私がGPLが適用されたプログラムの著作権を保有しているならば、私も著作権譲渡を要求すべきでしょうか? もしそうなら、どうやって?

私たちの弁護士は、侵害者に対して法廷でGPLを強制する上で最良の立場に立つ には、プログラムの著作権の状態を可能な限り単純に保つべきだと述べていま す。このため、私たちは貢献者のみなさんに対し、FSFに対するご自分の貢献 に関する著作権を譲渡するか、著作権を主張せずパブリックドメインに置くこ とをお願いしています。

また、私たちは個々の貢献者が彼らの雇用者(もしいれば)からの著作権放棄声 明を得て、そういった雇用者たちが将来になって貢献を所有していると主張す ることがないよう保証することもお願いしています。

もちろん、すべての貢献者が彼らのコードをパブリックドメインに置いたなら ば、GPLを強制すべき著作権は存在しません。ですから私たちは、大量のコー ドを貢献して下さった場合は著作権を譲渡し、小さな改変点に関してはパブリッ クドメインに置くことを推奨しています。

あなたのプログラムに関してGPLを強制したいならば、同じようなポリシーに 従うのはおそらくあなたにとっても良い考えでしょう。詳しくは<licensing@gnu.org>にご連絡 下さい。

GNU GPLの下でソフトウェアの一部を入手したとして、私はオリジナルのコードを新しいプログラムに合わせて取り込み、それを商業的に頒布、販売することはできるでしょうか?

改変したプログラムの複製を商業的に売ることは許可されていますが、それは GNU GPLの条項の下でのみです。そこでたとえば、あなたはGPLが指定する通り ソースコードをプログラムのユーザが入手できるようにしなければなりません し、またユーザはGPLに書かれている通りそれを改変したり再頒布したりでき なければなりません。

これらは、あなたが入手したGPLで保護されたコードをあなた自身のプログラ ムに含める上での要件です。

GPLをソフトウェア以外のものにも適用することはできますか?

その著作物にとって「ソースコード」が何にあたるかを明確にするかぎり、 GPLはどんな種類の著作物にでも適用することができます。GPLではソースコー ドを「ある著作物に改変を加える上で好ましい形式」と定義しています。

しかし、マニュアルや教科書、あるいはより一般的に何かについて教えること を意図している著作物に対しては、GPLではなくGFDLを適用することを推奨し ます。

以下のような状況を考えてみましょう:
  • X があるプロジェクトのバージョン1をGPLの下で公開する。
  • Y がバージョン1を基に改変や新規のコードを加え、バージョン2の開発に貢献する。
  • X がバージョン2をGPLではないライセンスに改変しようとする。
この場合XはYの許可を得る必要がありますか?

はい。Xのバージョン1を基にしたということの結果として、Yは自分のバージョ ンをGNU GPLの下で公開することが要求されています。Yは、自分のコードに関 してGPL以外のライセンスに同意する必要は全くありません。そこで、Xはその コードを他のライセンスの基で公開する前にYの許可を取る必要があるのです。

私の独占的なシステムに、GPLで保護されたソフトウェアを組み入れたいのですが、それは可能ですか?

GPLで保護されたソフトウェアを独占的なシステムに組み入れることはできま せん。GPLの目標は、誰に対してもプログラムを複製や再頒布、理解、改変す る自由を与えるということです。フリーではないシステムにGPLで保護された ソフトウェアを組み入れることが可能なら、GPLで保護されたソフトウェアは フリーではなくなってしまうでしょう。

GPLで保護されたプログラムを組み入れたシステムは、そのプログラムの派生 バージョンとなります。GPLによれば、あるプログラムの派生バージョンは、 それを公開するならばGPLの下で公開されなければならないとされています。 これは二つの理由があります。一つには、ソフトウェアを入手したユーザが彼 らが持つべき自由を得ることが保証されるということ、もう一つは、人々が行っ た改良点が作者に還元されるのを奨励するということです。

しかし多くの場合、GPLで保護されたソフトウェアを独占的なシステムと一緒 に頒布することは可能です。これを妥当な形で行うには、フリーなプログラム とフリーではないプログラムとがそれぞれ独立を保った形でコミュニケートし、 それらが事実上単一のプログラムとなってしまうような方法で結合されていな いことを確認しなければなりません。

GPLで保護されたソフトウェアを一緒に頒布することと「組み込む」こととの 違いは、ある点では実質的な問題であり、ある点では形式的な問題です。実質 的な問題とは、二つのプログラムが結合され、それらが事実上一つのプログラ ムの二つの部分となるならば、あなたはそれらを二つの別々のプログラムとし て扱うことができないということです。よって、この場合GPLが全体を保護す るということになります。

コンパイラとカーネル、あるいはエディタとシェルというように、二つのプロ グラムがきちんと分離されたままであれば、あなたはそれらを二つの別々のプ ログラムとして扱うことができます。しかし扱いには気を付けなければなりま せん。ここで問題となるのは、あなたが何をしているのかちゃんと記述すると いう単純に形式的なことですが、どうして私たちはこんなことに気を使うので しょう? それは、私たちはユーザに対し、あるソフトウェアのコレクションに 収められたGPLで保護されたソフトウェアがフリーであるということをユーザ が明らかに理解することを保証したいからです。

人々が、GPLで保護されたソフトウェアをその一部が独占的であるとユーザが 知っているシステムの「一部」と呼んで頒布しようとしている場合、ユーザは GPLで保護されたソフトウェアに関する彼らの権利について自信が持てないか もしれません。しかし彼らが受け取ったものがフリーなプログラムにそうでな いものを並べて追加しただけのものだということが分かれば、彼らの権利は明 確になるでしょう。

GPLで保護されたプログラムを改変し、カネヨコセ社(Money Guzzler Inc.)から出ているポータビリティライブラリとリンクしたいのですが、私はカネヨコセ社のライブラリのソースコードを頒布することができません。そこで、カネヨコセ社のライブラリとリンクしたバージョンを改変したいユーザは、それらのライブラリを別に入手しなければなりません。どうしてGPLはこれを許可していないのですか?

これには二つの理由があります。

まず、一般論からご説明しましょう。私たちが企業Aに対して独占的なファイ ルを作ることを認め、さらに企業BがそのファイルとGPLで保護されたソフトウェ アをリンクしたものを頒布することを認めたとすると、それはGPLにトラック が悠々通れるほど大きな抜け穴を開けてしまうということに他なりません。こ れは、GPLで保護されたソフトウェアへのあらゆる種類の改変や拡張に必要な ソースコードを与えず留保するということに関して、企業に白紙委任状を渡す に等しいからです。

すべてのユーザにソースコードへのアクセスを提供するということは私たちの 主な目標の一つであり、上記のような状況はもちろん私たちが避けたいもので す。

より具体的に言えば、カネヨコセ社のライブラリとリンクされているプログラ ムのあるバージョンは、実際のところ私たちが理解するところの「フリーソフ トウェア」ではありません。ユーザがプログラムを改変や再コンパイルするこ とを可能とする完全なソースコードと共に提供されていないソフトウェアは、 フリーソフトウェアとは呼ばないからです。

あるモジュールQのライセンスの条件がGPLと矛盾しているのですが、しかしその条件はQが単体で頒布されたときのみ適用され、Qがより大規模なプログラムに含まれているときには適用されないというものだったとします。このライセンスはGPLと矛盾しないでしょうか? QをGPLで保護されたプログラムとリンクあるいは結合することができますか?

プログラムPがGPLの下で公開されているということは、*Pのあらゆる部分が *GPLに従って利用できるということを意味します。もしあなたがモジュールQ をPに統合し、結合されたプログラムP+QをGPLの下で公開したならば、P+Qの全 部分がGPLの下で利用できるということになります。P+Qの一部はQです。です から、P+QをGPLの下で公開するということは、Qのいかなる部分ももGPLの下で 利用できるということに他なりません。言い換えれば、あるユーザがP+QをGPL の下で入手してPに相当する部分を削除すれば、Qだけが残り、しかもGPLの下 で利用できるということになるのです。

モジュールQのライセンスがそうすることを許可しているならば、それはGPLと 矛盾しませんが、そうでなければQのライセンスはGPLと矛盾します。

Qのライセンスが、Qをそれ単体で再頒布する際に何か(GPLと矛盾すること)を しなければならないとはっきりと規定している場合には、QのライセンスはQを GPLの下で頒布することを許可していません。よってあなたはP+QをGPLの下で 頒布すること自体ができません。ですからあなたはPをQとリンクしたり結合し たりすることはできないのです。

バイナリを、対応するソース抜きで頒布したいのですが、メールオーダーの代わりに、FTPでソースコードを提供してもよいでしょうか?

誰かが注文してきたならば、あなたはソースコードを物理的媒体に収めてメー ルオーダーで提供しなければなりません。メールオーダーに加えて、人々が対 応するソースコードをFTPで入手できるようにするのは歓迎すべきことですが、 ソースへのFTPアクセスだけではGPLの第3節を満足するに十分ではありません。

ユーザがソースを注文したとき、あなたはそのユーザがソースを得られるよう 保証しなければなりません。ある特定のユーザが、あなたから匿名 FTPでソー スを便利に入手できるなら、FTPは期待された役割を果たしているということ で大いに結構です。しかしすべてのユーザがネットワークにつながっているわ けではありません。そういったユーザたちもあなたからソースコードを得る権 利は他の人同様持っているわけですから、あなたは彼らにソースを郵便経由で 送るよう準備しておかなければなりません。

FTPアクセスが十分便利ならば、おそらく誰もメールオーダーでソースを取り 寄せようとは思わないでしょうから、ソースを郵便で発送しなければならない ということはまずないでしょう。しかしそう決めてかかることはできません。

もちろん、そもそも最初からバイナリといっしょにソースを送ればこういった 面倒は起こりません。

バイナリは私のインターネットサーバに置き、ソースは他のインターネットサイトに置くということはできるでしょうか?

GPLでは、あなたはソースコードをバイナリと「同じ場所から」コピーするた めのアクセスを提供しなければならないと定めています。すなわち、バイナリ のとなりにソースを置けということです。しかし、他のサイトと協定を結んで、 必要なソースコードを入手可能にし続けてもらい、バイナリの近傍にソースコー ドへのリンクやクロスリファレンスを張って置くならば、私たちは「同じ場所 から」と言ってよいと判断します。

しかし、注意すべきなのは、たまたま今日は適切なソースコードをおいている とあるサイトを見つけて、人々にそっちを見ろと言うだけでは不十分だという ことです。明日になればそのサイトはソースコードを削除してしまうかもしれ ませんし、あるいは単に同じプログラムの新しいバージョンで置き換えてしま うかもしれません。そうするとあなたはもはやGPLの要件を満たしているとは 言えなくなります。GPLの要件を満たすべく相当な努力を払ったと主張するに は、あなたは他のサイトとはっきりした協定を結び、あなたがバイナリを入手 可能にしておく期間中はソースがそこで入手可能であるということを保証しな ければなりません。

あるGPLで保護されたプログラムの拡張したバージョンをバイナリ形式で頒布したいのですが、オリジナルバージョンのソースを頒布するだけで十分ですか?

いいえ、あなたはバイナリに対応するソースコードを提供しなければなりませ ん。対応するソースとは、ユーザが同じバイナリを再ビルドできるソースとい うことです。

フリーソフトウェアという考え方の一部分は、ユーザが*彼らが使うプログラ ム*のソースコードへのアクセスを得るべきだということです。あなたのバー ジョンを使っている人々はあなたのバージョンのソースコードへのアクセスを 得るべきなのです。

GPLの主な目標は、フリーなプログラムへの改良がそれら自身フリーであるこ とを保証することにより、自由な世界を構築することです。もしあなたがGPL で保護されたプログラムの改良されたバージョンを公開したならば、あなたは GPLの下で改良されたソースコードを公開しなければなりません。

バイナリを頒布したいのですが、完全なソースを頒布するのは不便です。ユーザに、バイナリといっしょに「標準」バージョンからの差分(diff)を提供するだけで良いですか?

こう聞いてきた頒布者の善意は疑う余地がありませんが、このソース提供方法 は実のところあまり役に立ちません。

今から一年後にソースを欲しいと思うユーザは、その時点で他のサイトから適 切なバージョンを入手できなくなっているかもしれません。標準頒布サイトに は新しいバージョンがあるかもしれませんが、同じ差分はおそらくそのバージョ ンには当たらなかったり、うまく動作しなかったりするでしょう。

ですから、あなたは差分ではなく、完全なソースをバイナリと共に頒布しなけ ればなりません。

匿名(anonymous)FTPでバイナリを入手可能にしたいのですが、ソースはそれを注文した人にのみ送りたいのです。

GPLは、ソース抜きでバイナリを頒布する人は、書面でソースを送るというオ ファーを提供しなければならないと主張します。というのは、それが私たちが ユーザがソースを手に入れることを保証できる唯一の手段だからです。

ですから、あなたがバイナリを匿名 FTPで頒布したいならば、あなたはソース をそれらと一緒に頒布しなければなりません。これはそんなに難しいことでは ないはずです。プログラムを頒布するサイトを見つけられたのですから、ソー スを置く余地のあるサイトだって見つけられるでしょう。

あなたが提供するソースは正確にバイナリと対応していなければなりません。 特に、あなたはそれらがプログラムの同じバージョンのソースであることを保 証しなければなりません。古くても新しくてもダメです。

ソースとバイナリをそれぞれ別のマシンで入手可能にすることができますが、 それらを入手するのが等しく容易であること、バイナリのとなりにどこでソー スを見つけられるか情報を用意しておくことが条件です。

バイナリをダウンロードした各ユーザがソースも入手したということを保証するにはどうしたらいいですか?

これを確かめる必要はありません。ソースとバイナリを入手可能にしておき、 ユーザが何が入手できるか分かって欲しいものが取れるならば、あなたは要求 されたことをやったということになります。ソースをダウンロードするしない はユーザ次第です。

再頒布者への私たちの要求は、ユーザがソースコードを入手できるということ を保証するということを意図しているのであって、ユーザが欲しくもないのに ソースコードをダウンロードするよう強制しろということではありません。

いくつかのGNUライブラリが、劣等GPLではなくふつうのGPLの下で公開されているのはなぜですか?

劣等GPLを特定のライブラリに適用するのは、フリーソフトウェアにとっては 後退を意味します。それは私たちがユーザの自由を守ろうとする試みを部分的 に放棄しているということを意味し、GPLで保護されたソフトウェアの上に築 かれたものを共有するための要件の一部を放棄していることにもなります。本 質的に、それらは良くない変化です。

局地的な後退が良い戦略であることもあります。場合によっては、LGPLをライ ブラリに適用すればそのライブラリがより広く使われるようになり、改良がよ り多く加えられ、ソフトウェアへのより広汎なサポートが得られる、といった ことが起こるかもしれません。これは、もし華々しい成果が得られるならばフ リーソフトウェアにとって良いことと言えるでしょう。しかしこれがどの程度 起こるのか、私たちにできるのは予想することだけです。

LGPLをそれぞれのライブラリにしばらく適用してみて、それが助けになるかし ばらく様子を見た上で、LGPLが助けにならなければGPLに戻すということがで きればそれが良いのでしょうが、いったんLGPLをある特定のライブラリに適用 すると戻すのは至難なので、これは不可能です。

ですから私たちはそれぞれのライブラリにどのライセンスを適用するか、ケー スバイケースで決めています。この問題をどう判断しているかについては、以 下に長い説明があります。

独占的なソフトウェアを作ろうとする私たちのプロジェクトにおいて、あるGPLが適用されたGNUプログラムを使いたいのですが、GPLがそれを許してくれません。私たちのために例外を設けてくれませんか? そうすればそのプログラムはより多くのユーザを得ることになるんです。

申し訳ありませんが、そのような例外を設けることはありません。それは正し いことではありませんので。

ユーザ数を最大化することが私たちの目標なのではありません。どちらかとい えば、私たちはできる限り多くのユーザに重要な自由を与えようと努力してい ます。一般的にいって、独占的なソフトウェアプロジェクトは自由の主張を助 けるものではなく、妨げるものです。

場合によってはライセンスに例外を設け、GPL以外のライセンスの下で公開さ れたフリーソフトウェアを作っているプロジェクトを支援することもあります が、しかしそのためには、なぜそれがフリーソフトウェアの主張を促進させる のかについてきちんとした理由が無いといけません。

また、私たちはときたまパッケージの頒布条件を改変することもありますが、 それは改変が明らかにフリーソフトウェアの主張を満たす正しい道であるよう に考えられるときに限ります。しかし頒布条件の改変に関しては私たちは非常 に慎重なので、あなたは私たちを納得させられるだけの十分説得力ある理由を 示す必要があるでしょう。

プログラムで「GPLのバージョン2かそれ以降のバージョン」というような指定をするのはなぜですか?

時の変遷に従い、数年の間を置いて、私たちはGPLを改変します。何かを明確 化するときもありますし、それまでは許可していなかった特定の類の利用を許 可することもあり、また要件を厳格化することもあります(最後の改変は1991 年に行われました)。この「間接的なポインタ」をそれぞれのプログラムで使 うことで、GPLを更新するだけでGNUソフトウェアコレクション全体の頒布条件 を改変することが可能になります。

それぞれのプログラムが「間接的ポインタ」の形でGPLを指定していないと、 私たちは数多くの著作権者と延々と改変について議論せざるを得なくなり、 また事実上これは不可能です。現実的には、GNUソフトウェアが一様な頒布条 件を持つと言う可能性はゼロとなってしまうでしょう。

あるプログラムが「GPLのバージョン2かそれ以降のどれか」が適用されると指 定しており、GPLの新バージョンが公開されたとしましょう。新しいGPLが追加 的な許可を与えるものであれば、その許可は即座にプログラムのすべてのユー ザに対して与えられることになります。新GPLがより厳格な要件を課したとし ても、そのプログラムは依然としてGPLバージョン2の下で利用できますから、 プログラムの現在のバージョンの利用が制限されることにはなりません。プロ グラムが「GPLバージョン2かそれ以降のどれか」と指定していれば、GPLのよ り新しいバージョンが利用可能となった後でも、ユーザはGPLバージョン2の条 項に従い常にそのプログラムを利用したり、それを改変したりすることさえで きるのです。

GPLの新バージョンが指定するより厳格な要件に既存のソフトウェアが従う必 要がないならば、そんな条件に意味があるのでしょうか? いったんGPLバージョ ン3が利用可能になれば、ほとんどのGPLで保護されたプログラムの開発者は彼 らのプログラムのそれ以降のバージョンを「GPLのバージョン3かそれ以降のど れか」と指定して公開するでしょうから、ユーザもその後に公開されたプログ ラムに関してはGPLバージョン3のより厳格な要件に従わなければならなくなる というわけです。

しかし、開発者たちにこうすることが義務づけられているわけではありません。 開発者は、そうしたければGPLの以前のバージョンに従った利用を許可し続け ることができます。

どうしてマニュアルにはGPLを適用しないのですか?

マニュアルにGPLを適用することは可能ですが、マニュアル向けにはGNUフリー 文書利用許諾契約書(GFDL)のほうがはるかに優れています。

GPLはプログラム向けに設計されたものですから、プログラムにとっては重要 な複雑な条項を数多く含んでいます。そういった条項は、書籍やマニュアルに は不要でじゃまなものです。一方、GFDLにはフリーなマニュアルの出版者が出 版によって利益を上げることを助ける条項が含まれています。

私たちは技術的なトピックを扱うテキストの改変は許可していますが、法的、 政治的あるいは倫理的な立場を述べた節の改変は認めていません。私たちはそ ういった改変してはならない節を明示的に列挙することで改変を禁止していま す。GFDLにはこのような「改変不可部分」に関する条項が用意されていますが、 GPLではこのようなものの存在を許していません。

技術的な内容を扱った部分の改変は許可されていることが重要です。というの は、プログラムを改変する人々はドキュメンテーションも対応して改変しなけ ればならないからです。私たちは彼らがそういう追従作業をすることを要求で きませんが、彼らがそうしてくれることを望んでいますので、そのじゃまをす ることはありません。

GPLを他の言語に翻訳したものはありますか?

GPLを英語以外の言語に翻訳したものは有用ですし、実際に翻訳して私たちに 送って下さる方々もいます。しかし私たちは、そういった翻訳を正式に法的効 力があるものとしてはあえて承認しないことにしています。承認すると、とて も容認できない非常に大きなリスクが持ち込まれてしまうのです。

法的文書はある意味プログラムに似ています。法的文書の翻訳はプログラムを ある言語やオペレーティングシステムから他へ移植するようなものです。二カ 国語に堪能な弁護士のみがそれをすることができます。しかも、そのような弁 護士が行った場合でさえ、バグを持ち込んでしまうリスクは存在するのです。

私たちがあるGPLの翻訳を正式に承認した場合、私たちはすべての人に対して、 彼らがすることができるとその翻訳が述べていることすべてをする許可を与え たことになります。もしそれが完全に正確な翻訳ならば、何も問題ありません が、もし誤訳があった場合、結果は私たちが修復不可能な災厄となりうるので す。

プログラムにバグがある場合、私たちは新しいバージョンを公開できますし、 そうすれば古いバージョンは遅かれ早かれやがては消えることになるでしょう。 しかし私たちがすべての人に対し、ある特定の翻訳に従って行動することを許 可したならば、その後バグがあったことに気づいても私たちはその許可を取り 消すことができないのです。

有能な人々が翻訳作業を行うことを申し出て下さることがあります。問題が、 誰か作業をしてくれる人を捜すというだけのことならば、これで万事解決なの ですが、しかし実際の問題は誤訳のもたらすリスクなので、作業の申し出はリ スクを回避することにはなりません。弁護士ではない人々による翻訳を正式に 承認することは私たちにはどうしてもできないことなのです。

ですから、現状では私たちはGPLの翻訳を世界中で法的に有効かつ拘束力があ るものとは承認していません。代わりに、私たちは以下の二つのことを行って います。

プログラミング言語のインタープリタにGPLと矛盾するライセンスが適用されていた場合、その上でGPLで保護されたプログラムを実行することは可能でしょうか?

インタープリタが単に言語を解釈するだけならば、答えはイエスです。解釈さ れるプログラムは、インタープリタにとっては単なるデータに過ぎません。ま た、GPLはGPLが適用されたプログラムを処理するツールが何であるかまでは規 制しません。 しかし、インタープリタが他の機能(多くの場合ライブラリですが、それだけ とは限りません)への「バインディング」を提供するように拡張されている場 合、解釈されるプログラムはそういったバインディングを通じて事実上それが 使う機能とリンクされることになります。JNI(Javaネイティヴインターフェー ス)はそのような拡張機能の一例です。JNIによってアクセスされるライブラリ は、それらを呼ぶJavaプログラムと動的にリンクされることになります。 ですから、アクセスされる機能がGPLと矛盾するライセンスの下で公開されて いる場合、状況としては他の方法でGPLと矛盾するライブラリとリンクする場 合とほぼ同じです。すなわち、
  1. コードをGPLの下で書いて公開する場合、あなたはGPLと矛盾する機能と のリンクを明示的に許可する例外条項を記載することができます。

  2. プログラム自体はGPLの下で書かれ公開されているが、そういったGPLと 矛盾するライセンスが適用された機能と共に動作するよう設計されているこ とが明白ならば、人々はプログラムをそれらの機能とリンクする許可が暗黙 の例外として与えられていると考える可能性があります。しかしそれがあな たの意図ならば、そうはっきり述べておいたほうが良いでしょう。

  3. 誰か他の人が書いたGPLで保護されたコードを取ってきて、そういうふ うに使ったり、そのような例外を加えたりすることはできません。例外を追 加できるのはそのコードの著作権者だけです。

GPLを強制する権力があるのは誰ですか?

GPLは著作権に基づくライセンスですから、GPLを強制する権力を持つのはソフ トウェアの著作権者です。GPLに違反した事例を発見した場合、あなたは 関係するGPLが保護されたソフトウェアの開発者たちに知らせるべきです。彼 らは自身著作権者であるか、著作権者とつながりがあるかのどちらか でしょうから。

Javaのようなオブジェクト指向言語において、GPLが適用されたあるクラスをそれ自体は改変せず、サブクラス化して利用するとします。このような場合、GPLは結果としてのプログラムにはどのように影響するのでしょうか?

サブクラス化は派生物の作成に他なりません。そこで、GPLが適用されたクラ スのサブクラスが作成されたプログラム全体にGPLの条項が影響します。

自分のプログラムをGNU/Linux上へ移植したら、私はそれをフリーソフトウェアとしてGPLやその他のフリーソフトウェアライセンスの下で公開しなければならないのでしょうか?

一般的に言えば、答えはノーです。これは法的な要件ではありません。個々の ケースという意味では、答えはあなたが使いたいライブラリとそのライセンス に依ります。多くのシステムライブラリはGNU 劣等GPLか、ライブラリを何とリ ンクしてもよいという許可を例外条項として付け加えたGNU GPLが適用されて おり、これらのライブラリはフリーではないプログラム中でも利用できます。 ただし劣等GPLの場合には、従わなければならないいくつかの要件があります ので注意してください。

一部のライブラリはGNU GPLのみの下で公開されていますので、そういったラ イブラリを使いたいならばあなたはGPLと矛盾しないライセンスを自分のソフ トウェアに適用しなければなりません。しかし通常そういったライブラリはよ り特殊な用途向けのものであることが多いので、単なるポーティングでそういっ たライブラリを利用しようと思うことはまずないでしょう。

もちろん、フリーでないあなたのソフトウェアは私たちのコミュニティへの貢 献にはなりませんので、自由を重視する人々は使用を拒否するでしょう。自由 を喜んで放棄する人々のみがあなたのソフトウェアを使うことになるでしょう し、それはあなたのソフトウェアが、人々に自分の自由を失わせてしまう誘因 として有効に機能するということに他なりません。

いつの日かあなたがご自分のキャリアを振り返った時、自分が自由で善なる社 会の成長に何か貢献したと思いたいならば、あなたは自分のソフトウェアをフ リーにしなければなりません。

ある企業がGPLの適用されたプログラムの複製を所有しており、それを入手するためにはお金がかかります。インターネット上で入手できるようにしないという点で、彼らはGPLに違反しているのではないでしょうか?

いいえ。GPLはインターネットを使って頒布することを要件とはしていません。 また、GPLはプログラムを誰か特定の人が再頒布することも要求しません。そ して(ある特別な場合を除いて)、誰かがプログラムを何回に渡って再頒布する 際にも、GPLはその人が特定個人としてのあなたや他の誰か特定の人に頒布し なければならないということを要求していません。

GPLが要求するのは、頒布する人が、もしその人がそうしたければあ なたに複製を頒布できる自由を有しなければならないということです。いった ん著作権者が誰かにプログラムの複製を頒布したら、今度はその誰かが、 自分にできる範囲でプログラムをあなたや誰か他の人に再頒布すれば良いわけ です。

改変を加えたバージョンはGPLの下で配布して良いが、オリジナル自体はGPLの下で頒布してはならない、このようなライセンスを付けてプログラムを公開することは可能でしょうか?

そのようなライセンスは自己矛盾しています。自分が一ユーザのつもりになっ て、その意味するところを考えてみましょう。

オリジナルバージョン(バージョンAと呼びましょう)に改変を加え始めたとし ます。コードを追加し(1000行くらいにしておきましょうか)、改変したバージョ ン(バージョンBとします)をGPLの下で公開します。GPLによれば、誰でも再度 バージョンBを改変して、結果をGPLの下で公開して良いことになっていますか ら、私(あるいは誰か他の人)は追加された1000行のコードを削除しさえすれば、 バージョンAと同じコードでしかもGPLの下で公開されているバージョンCを作 るということが可能になるのです。

バージョンBから追加された部分を削除することにより、バージョンAと同一の 著作物をGPLの下で複製することを明示的に禁止する、というようにライセン スの中でこういったやり方を禁止することもできますが、今度は、そのような ライセンスの下ではバージョンBをGPLが許可するすべての方法で完全に利用す ることができないということになってしまいます。言い換えれば、そのような ライセンスは実際のところユーザがバージョンBのような改変されたバージョ ンをGPLの下で公開することを許可していないということになるのです。


[ チェコ語 | 英語 | フランス語 | イタリア語 | 日本語 | 韓国語 | ポーランド語 | ポルトガル語 ]

FSF および GNU へのご質問、お問い合わせはgnu@gnu.orgまでどうぞ。FSF と連 絡を取るには 他の手段もありま す。

これらのウェブページについてのご意見はwebmasters@gnu.orgまで、 そのほかのご質問はgnu@gnu.orgまでお送りください。

Copyright (C) 2001 Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110, USA

本文に一切改変を加えず、この著作権表示を残す限り、この文章全体のいかな る媒体における複製および頒布も許可する。

翻訳は 八田真行 <mhatta@gnu.org>が行いました。

Based on: 1.34

Updated: $Date: 2005/05/05 19:37:12 $ $Author: novalis $