GNU GPL v2.0に関してよく聞かれる質問

“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のようなより緩いライセンスが適用されています。これには、わたしたちの戦略が関係しています。

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は改変されたプログラムを特定のやり方でリリースする許可を与えていますが、別の形でのリリースは許可していないのです。しかし、リリースするかどうかはあなた次第です。

あるGPLの及ぶプログラムと、それと関係のない不自由なプログラムを同じコンピュータに置いても問題ありませんか?

はい。GPLの条項の「単に集めたもの」がこれに対する許可を明確に与えています。しかし、これは、いずれにしろ正しいとわたしたちが考えていることを強化しているにすぎません。

GPLの及ぶプログラムのコピーを誰かが持っていると知っている場合、わたしはかれにコピーを下さいと要求できますか?

いいえ。GPLは、かれにかれがそれを選んだ場合、その時に、プログラムのコピーを作成し、再配布する許可を与えます。それをかれが選ぶとき、かれは、プログラムを再配布しない権利も持つのです。

この「いかなる第三者に対しても法的に有効な書面による申し出」とは何のことですか? これは、世界中の誰もが、GPLが適用されたどんなプログラムのソースでも手に入れられるということなのでしょうか?

あなたがソースコードを書面による申し出で提供することを選択した場合、ソースコードをあなたに要求するすべての人にそれを受領する資格があります。

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

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

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

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

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

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

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

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

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

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

はい。GPLは、誰もが販売することを許可しています。複製を販売する権利は自由ソフトウェアの定義の一部です。一つの特別な状況を除いて、請求できる値段に制限はありません。(ひとつの例外とは、バイナリのみのリリースに要請されるソースコードを提供する書面による申し出(におけるソースコードの提供に関する料金)です。)

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

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

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

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

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

あなたは、あなたからコピーを得る人に料金を課すことができます。ほかの誰かからコピーを得るときに、その人があなたに支払うことを要求はできません。

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

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

GPLは、複製物を機密保持契約(NDA)のもとで配布することを許可していますか?

いいえ。GPLは、あなたから複製を入手した人は皆、その複製を、改変ありでも、なしでも、再配布する権利を有していると述べています。あなたには、著作物の配布に関して、より厳しい制限をかけることは、認められません。

もし、誰かが、あなたにFSFのGPLの及ぶソフトウェアを受けとるのにNDAにサインすることを求めるのであれば、すぐにわたしたちに知らせてください。連絡先は、license-violation@fsf.orgです。

もし、違反が誰か他の著作権者のGPLの及ぶコードを含むならば、その著作権者に知らせてください。あなたが、他の種類のGPLの違反に対するのと同じように。

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

いいえ。GPLは、あなたの改変したバージョンはGPLに述べられたすべての自由を持たなければならないと述べています。ですから、あなたからあなたのバージョンを受け取った誰もが、そのバージョンの複製を(改変しても、改変なしでも)再配布する権利を有しているのです。あなたは、著作物のどのバージョンであっても、より厳しい制限をつけて配布することはできません。

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

はい。たとえば、あなたはあるプログラムに改変を加え、そのあなたの変更をクライアントが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全体のそのままの複製のみ許可しています。(法的な条項を使って別のライセンスを作ることはできるでしょうが、それはGNU GPLではないでしょう。)

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

二つのライセンスが「両立する」とはどういう意味ですか?

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

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

単に二つの別々のプログラムを同じシステムにインストールする場合、それらのライセンスが両立する必要はありません。なぜなら、これは別々のプログラムを一つの大きな著作物に組み合わせてはいないからです。

ライセンスが「GPLと両立する」とはどういう意味ですか?

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

GPLでは、そのような結合著作物がGNU GPLのもとでリリースされる限り、結合を許可しています。他のライセンスもそれを許可しているならば、そのライセンスは GPLと両立します。

自由でないライブラリを利用する自由ソフトウェアを書けますか?

もし、そうすると、あなたのプログラムは自由な環境のもとでは完全に使用できるわけではありません。あなたのプログラムがある特定の作業をするために自由でないライブラリに依存している場合、自由な世界ではそのプログラムはその作業ができないということになります。自由でないライブラリがなければ実行することすらできないならば、そのプログラムはGNUのような自由なオペレーティングシステムの一部となることができません。プログラムは自由な世界には完全に出入り禁止とされてしまいます。

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

もしプログラムがすでに自由でないライブラリを利用して書かれていたならば、おそらく決断を変えるには遅すぎるでしょうから、リリースしないよりは、プログラムをそのままリリースした方がいいでしょう。しかしREADMEにおいて、自由でないライブラリが必要であることは欠点であることに言及し、プログラムを改変して同じ作業を自由でないライブラリ抜きで行えるようにするということを提案してください。このプログラムになにか重要な仕事をさらに進めることを考える誰かに対して、まず、自由でないライブラリに対する依存から脱却することを提案してください。

GPLの及ぶ自由ソフトウェアとある自由でないライブラリを結合することに関して、法的問題があるかも知れないことに注意ください。詳しくは、GPLソフトウェアにGPLと両立しないライブラリを用いた場合の質問をご覧ください。

GPLソフトウェアにGPLと両立しないライブラリを用いた場合どのような法的問題が発生するでしょうか?

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

しかしながら、特別な例外として、配布されるソースコードに当該プログラムの実行形式が実行されるオペレーティングシステムの主要なコンポーネント(コンパイラやカーネルなど)に通常付随して(ソースあるいはバイナリ形式で)配布されるものが含まれている必要はないとします。ただし、コンポーネント自体が実行形式と一緒に配布される場合は除く。

上記にあてはまれば、そういったライブラリを使う上で何か特別なことをする必要はありません。言い換えれば、あなたが必要とするライブラリがプロプライエタリ・オペレーティングシステムの主要な一部として提供されるならば、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.
日本語訳: このプログラムは自由ソフトウェアです。フリーソフトウェアファウンデーションにより発行されたGNU一般公衆ライセンス(バージョン2のライセンスあるいは、(あなたの選択として)それ以降のバージョンのどれでも)の条項のもとで、あなたは、再配布、およびまたは、改変することができます。

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.
日本語訳: このプログラムは有用であることを願って配布されていますが、まったくの **無保証** です。商品性または特定の目的に対する適合性の暗黙の保証さえも **ありません** 。詳細は、GNU一般公衆ライセンスをご覧ください。

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
日本語訳: あなたは、GNU一般公衆ライセンスの複製をこのプログラムとともに受け取っているべきです。もし、受け取ってない場合、Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA まで連絡ください。

Linking ABC statically or dynamically with other modules is making a combined work based on ABC. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
日本語訳: ABCを静的もしくは動的にほかのモジュールとリンクすることは、ABCをもとにして結合著作物を作成することです。ですから、全体として、GNU一般公衆ライセンスの条項が適用されます。

In addition, as a special exception, the copyright holders of ABC give you permission to combine ABC program with free software programs or libraries that are released under the GNU LGPL and with code included in the standard release of DEF under the XYZ license (or modified versions of such code, with unchanged license). You may copy and distribute such a system following the terms of the GNU GPL for ABC and the licenses of the other code concerned, provided that you include the source code of that other code when and as the GNU GPL requires distribution of source code.
日本語訳: 加えて、特別の例外として、ABCの著作権者は、ABCプログラムを、自由ソフトウェア・プログラムもしくはGNU LGPLでリリースされている自由ソフトウェア・ライブラリ、そして、XYZライセンスのDEFの標準リリースに含まれるコード(もしくは、ライセンスの変更されていない、そのコードの改変バージョン)と結合することを許可します。そのようなシステムを、ABCに対するGNU GPLの条項と、その他の関係するコードのライセンスに従って、コピーし、配布することができます。ただし、GNU GPLがソースコードの配布を要求する時は、それに従って、その他のコードのソースコードを含める必要があります。

Note that people who make modified versions of ABC 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.
日本語訳: ABCの改変バージョンを作成する人々はこの特別の例外をかれらの改変バージョンで許す義務はないことに注意ください。そうするかどうかは、はかれらの選択です。GNU一般公衆ライセンスは改変したバージョンを、この例外なしにリリースすることを許可しています。この例外は、また、改変バージョンが、この例外をそのまま持つことも可能としています。

この文面を例外が適用されるそれぞれのファイルに書きます。

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

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

もし、ライブラリを不自由なものとリンクすることを考えているのであれば、自由でないライブラリを利用する自由ソフトウェアを書くには、の節もご覧ください。

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であろうが他の自由ソフトウェア・ライセンスであろうが、あなたは「公正使用」することができます。

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

合衆国政府はプログラムをGNU GPLでリリースできますか?

もし合衆国連邦政府の被雇用者にその雇用の内で、そのプログラムが書かれたのであれば、それはパブリックドメインであり、著作権が主張されないことを意味します。GNU GPLは著作権をもとにしているので、そのようなプログラムはGNU GPLのもとではリリースされることはできません。(それは、なお、自由ソフトウェアであることは可能です、パブリックドメインのプログラムは自由だからです。)

しかし、合衆国連邦政府の政府機関がコントラクタを使ってソフトウェアを開発したとき、これは異なる状況です。契約によってコントラクタがGNU GPLでリリースすることを要請できます。(GNU Adaはこのようにして開発されました。) もしくは、契約で、著作権を政府機関に移譲するとして、それでそのソフトウェアをGNU GPLでリリースするとすることが可能です。

合衆国政府はGPLの及ぶプログラムに対して改善をリリースできますか?

はい。もし合衆国政府の被雇用者によってその雇用の内で改善が書かれたのならば、その改善はパブリックドメインです。しかし、改善バージョンには、全体としては、GNUGPLが及びます。この状況では、なんの問題もありません。

もし合衆国政府がその仕事をするのにコントラクタを使っている場合、改善自身にGPLが及ぶようにすることができます。

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

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

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

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

GPLプログラムの出力結果もGPLが及ぶのは、どんな場合ですか?

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

GPLの及ぶプログラムに対してあるモジュールを追加する場合、わたしのモジュールにもライセンスとしてGPLを適用しなければなりませんか?

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

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

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

はい。なぜなら、そのプログラムはそのライブラリにリンクするからです。この際、GPLの条項が全体の組み合わせに適用されます。そのライブラリとリンクするソフトウェアのモジュールはさまざまなGPLと両立するライセンスが可能ですが、作品全体としてはGPLでライセンスされなければなりません。こちらもご覧ください: ライセンスが「GPLと両立する」とはどういう意味ですか?

プログラミング言語のインタープリタがGPLのもとでリリースされていた場合、そのインタープリタで解釈されるように書かれたプログラムは、GPLと両立するライセンスでなければならないでしょうか?

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

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

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

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

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

GPLはこれを許可します。なぜならランタイムライブラリは通常あなたがお使いのコンパイラあるいはインタープリタに付随するからです。ですから、GPL第三節の例外にあたることになります。

Windowsだけで動くプログラムを書くことが良い、とは意味しません。あるプログラムでそうすることは、自由ソフトウェアをもたらしますが、“罠にはまっている”のです(この場合はJavaではなくWindows という罠に。効果は同じです)。(歴史的注釈: 2006年12月、SunはJava プラットフォームをGNU GPLでリリースしている途中です。)

どうしてオリジナルのBSDライセンスはGPLと両立しないのですか?

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

訳: 受領者のここで認められた権利の行使に関して、あなたがさらなる制限を課してはならない。

宣伝条項はまさしくそのような、さらなる制限、を規定していて、よってGPLと両立しません。

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

あるプログラムとそのプラグインが単一の組み合わせのプログラムであると考えられるのはどういった場合ですか?

それはメインプログラムがどのようにプラグインを起動するかに依ります。もし、メインプログラムがforkとexecでプラグインを起動し、複雑なデータ構造を共有することで親密な通信を設立したり、複雑なデータ構造をやりとりする場合、そうしたことはメインプログラムとプラグインを単一の組み合わせのプログラムとします。もし、メインプログラムが単純なforkとexecを使ってプラグインを起動し、その間で親密な通信を設立しない場合には、プラグインは別のプログラムと考えられるでしょう。

もしメインプログラムが動的にプラグインとリンクされており、お互いにファンクションコールを使ってデータ構造を共有している場合、それらは単一の組み合わせのプログラムを形成しているとみなされますので、その単一の組み合わせのプログラムは、メインプログラムとプラグインの両方の拡張部分として扱われなければなりません。もしメインプログラムがプラグインと動的にリンクされており、しかしながら、その間の通信が、プラグインからの‘main’関数のあるオプションでの起動とその返りの待ちに限定されるならば、ボーダーラインのケースです。

共有メモリを複雑なデータ構造の通信に用いるのも動的なリンクとおおよそ等価です。

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

こちらの質問プラグインとメインプログラムが単一の組み合わせのプログラムと考えられるときと別の作品と考えられるときの決定についてをご覧ください。

もしメインプログラムとそのプラグインが単一の組み合わせのプログラムであるならば、そのプラグインはGPLもしくはGPLと両立する自由ソフトウェア・ライセンスのもとでライセンスしなければならず、GPLに準拠した形でソースコードとともに配布しないといけないことを意味します。そのプラグインと別れているメインプログラムは、そのプラグインに何の要求もしません。

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

こちらの質問プラグインとメインプログラムが単一の組み合わせのプログラムと考えられるときと別のプログラムと考えられるときの決定についてをご覧ください。

もし、それらが単一の組み合わせのプログラムを形成しているならば、GPLの及ぶプラグインと不自由なメインプログラムとの組み合わせは、GPL違反となるでしょう。しかし、あなたはこの法的問題を、あなたのプログラムのライセンスに自由でないメインプログラムとのリンクを許可する例外を加えることで解決できます。

質問、自由でないライブラリを利用する自由ソフトウェアを書いていますもご覧ください。

GPLの及ぶプラグインをロードするように設計された不自由なプログラムをリリースすることはできるでしょうか?

こちらの質問プラグインとメインプログラムが単一の組み合わせのプログラムと考えられるときと別のプログラムと考えられるときの決定についてをご覧ください。

もし、それらが単一の組み合わせのプログラムを形成しているならば、メインプログラムはGPLかGPLと両立する自由ソフトウェア・ライセンスのもとでリリースされなければならず、メインプログラムがそれらのプラグインの使用のために配布される時には、GPLの条項に従わなければならないということです。

しかし、それらが別の作品であれば、プラグインのライセンスは、メインプログラムになんの条件も課しません。

質問、自由でないライブラリを利用する自由ソフトウェアを書いていますもご覧ください。

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

その通りです。

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

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

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

プロプライエタリ・モジュールを、わたしのGPLの及ぶライブラリと指定したインターフェースのもとでのみリンクすることを許可するにはどうしたらよいでしょうか?

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

Linking ABC statically or dynamically with other modules is making a combined work based on ABC. Thus, the terms and conditions of the GNU General Public License cover the whole combination.
日本語訳: ABCを静的もしくは動的にほかのモジュールとリンクすることは、ABCをもとにして結合著作物を作成することです。ですから、全体として、GNU一般公衆ライセンスの条項が適用されます。

In addition, as a special exception, the copyright holders of ABC give you permission to combine ABC program with free software programs or libraries that are released under the GNU LGPL and with independent modules that communicate with ABC solely through the ABCDEF interface. You may copy and distribute such a system following the terms of the GNU GPL for ABC and the licenses of the other code concerned, provided that you include the source code of that other code when and as the GNU GPL requires distribution of source code.
日本語訳: 特別な例外として、ABCの著作権者はあなたに対し、結合著作物のすべての複製にABCのソースコードの完全な複製(結合著作物を作成するのに使ったバージョンのABCのもの)が付随し、GNU一般公衆ライセンスにこの例外を追加したもののもとで配布される場合に限り、ABC、ABCDEFインターフェースを通してのみABCとコミュニケートする独立モジュールと、その独立モジュールのライセンス条件を問わずリンクすること、及び結果としての結合著作物をあなたの選択した条件のもとで複製・配布することを許可します。独立モジュールとはABCをもとにしたものでも派生したものでもないモジュールのことを指しています。

Note that people who make modified versions of ABC 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.
日本語訳: ABCの改変バージョンを作成する人々はこの特別の例外をかれらの改変バージョンで許す義務はないことに注意ください。そうするかどうかは、はかれらの選択です。GNU一般公衆ライセンスは改変したバージョンを、この例外なしにリリースすることを許可しています。この例外は、また、改変バージョンが、この例外をそのまま持つことも可能としています。

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

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

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

• わたしのソフトウェアを動作させるには、劣等GPLのもとで利用可能なFOOライブラリとリンクしなければなりません。
• わたしのソフトウェアはシステムコールで(わたしがビルトしたコマンドラインとともに)BARプログラムを実行します。BARプログラムは「GPLだが、QUUXとのリンクを許可する特別な例外を認める」とライセンスされています。

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

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

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

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

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

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

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

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

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

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

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

わたしがGPLを修正して修正版のライセンスを作ることはできますか?

あなたのライセンスを別の名前で呼び、GPLの前文を含めないのであれば、GPLの条項を(修正して)別のライセンスに使うことはできるでしょう。ここで、最後にある利用に関する手順を修正して、言い回しは明らかに異なるものとし、GNUについて触れないようにする必要があります(実際の手順は同様となるでしょうが)。

わたしたちの前文を修正ライセンスで使いたい場合、<licensing@gnu.org>まで許可を求める連絡をください。この目的のために、承認するかどうか、わたしたちは実際のライセンスの要件を確認したいと思います。

わたしたちは、あなたが修正ライセンスをこうやって作成することに法的な反対をしないでしょうが、わたしたちはあなたが再度検討し、そうしないことを望みます。そのような修正ライセンスは、ほとんど確実にGNU GPLと非互換であり、そのような非互換性はモジュールの有用な組み合わせを阻害します。異なる自由ソフトウェア・ライセンスの単なる増殖は、それ自体負担です。

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

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

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

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

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

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

LGPLはJavaにどう働きますか?

詳細はこちらの小論をご覧ください。LGPLは設計されたように、意図されたように、そして期待されたように働きます。

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

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

わたしのプロプライエタリ・システムに、GPLの及ぶソフトウェアを組み入れたいのですが、それは可能ですか?

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

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

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

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

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

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

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

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

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

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

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

GPLの及ぶソフトウェアをわたしのプロプライエタリ・システムに組み込みたいと考えています。GPLの及ぶ部分とプロプライエタリの部分との間にGPLと両立するゆるい寛容なライセンス(X11ライセンスのような)の「ラッパー」モジュールをはさむことにより、これは可能ですか?

いいえ。X11ライセンスはGPLと両立します。ですから、GPLの及ぶプログラムにモジュールを追加して、そのモジュールはX11ライセンスのもととすることができます。しかし、もし、その両方をひとつの大きなプログラムに組み込むならば、全体はGPLの及ぶ部分を含みますから、全体としてはGNU GPLのもとライセンスされなければならないでしょう。

プロプライエタリのモジュールAがGPLの及ぶモジュールCとX11でライセンスされたモジュールBだけを通じて通信するという事実は、法的には関係ありません。問題なのはモジュールCが全体の中に含まれるという事実です。

libstdc++例外は動的リンクを許可しますか?

はい。例外の意図は、人々がgccを使ってプロプライエタリ・ソフトウェアをコンパイルすることを許可することです。

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とリンクしたり結合したりすることはできないのです。

GPLの及ぶプログラムの改変したバージョンをバイナリ形態のみでリリースできますか?

いいえ。GPLの全体のポイントは、すべての改変バージョンが自由ソフトウェア—でなければならないということです。特にこの場合、改変バージョンのソースコードがユーザに利用可能でなければならないという意味となります。

バイナリだけをネットからダウンロードしました。もし、わたしがコピーを配布するとき、ソースコードを取得してそれも配布しなければなりませんか?

はい。一般的なルールは、バイナリを配布したら、対応する完全なバイナリも配布しなければならない、です。ソースコードの書面による申し出を受け取った場合の例外はとても限定的なものです。

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

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

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

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

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

FTPでバイナリを配布する場合、あなたはソースもFTPで配布するべきです。

わたしの友達がGPLの及ぶバイナリをソースコードの申し出とともに取得しました。そして、ひとつコピーをわたしにくれました。その申し出をわたし自身が使って、ソースを得ることができますか?

はい、できます。申し出はそれと一緒に来たバイナリのコピーを持っている誰に対しても隠し立てのないものでなければなりません。これが、GPLが、バイナリのコピーにそって申し出のコピーを渡さなければならないと言っている理由です。ですから、それを利用することができます。

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

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

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

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

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

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

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

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

これは意味のある要求ですが、このソース提供方法は実のところあまり役に立ちません。

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

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

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

Anonymous FTPでバイナリを配布したいならば、ソースを第3節に挙げられた選択肢の一つのどれかで提供する必要があります。これはそんなに難しいことではないはずです。ソースの書面による申し出は、もし、それを望むならば、提供することができます。第三節(b)がそれを認めています。しかし、プログラムを配布するサイトを見つけられたのですから、ソースを置く余地のあるサイトも見つけられるでしょう。

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

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

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

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

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

ある会社がGPLのプログラムの改変バージョンをウェブサイトで動かしています。GPLはかれらは改変したソースコードを配布しなければならないと言ってますか?

GPLは誰もが改変したバージョンを作成し、他に配布することなく、使うことを許しています。この会社が行っているのはこの特別な場合です。ですから、この会社が改変したソースコードをリリースする必要はありません。

人々にとって、改変を作成し、その改変を公表することなく、プライベートに使う自由を有することは重要なことです。しかしながら、そのプログラムを公衆のためのサーバ・マシンにつなぐために置くことは、「プライベート」の利用と言うことは難しく、この特別の場合にソースコードのリリースを要求することはもっともでしょう。GPLバージョン3になにかこのようなことをすることを検討していますが、まだ、具体的な言い方は考えていません。

それまでは、アフェロGPLをネットワークサーバの利用に設計されたプログラムに使うのが良いかも知れません。

一つの組織あるいは会社で複数のコピーを作成して使うことは「配布」となりますか?

いいえ、そのケースでは、その組織は自分自身のためにコピーを作成しているだけです。結果として、ある会社やほかの組織は、改変されたバージョンを開発したり、そのバージョンを自分自身の設備を通じてインストールできます。これは、そのスタッフに、その改変したバージョンを外部にリリースする許可を与えることなくできます。

しかしながら、その組織がコピーをほかの組織や個人に移したとき、それは配布となります。特に、その場所以外での利用のためにコントラクタにコピーを提供することは、配布です。

誰かがGPLの及ぶプログラムのバージョンが入ったCDを盗みました。GPLは、かれに、このバージョンを再配布する権利を与えますか?

そのバージョンが(盗み以前に)既にどこかにリリースされているのであれば、盗んだ人はおそらくコピーを作成し、再配布する権利をGPLのもとで有するでしょう。しかし、CDを盗んだことで刑務所に入るのならば、かれはそうする前に解放されるまで待つ必要があるかもしれません。

もし、問題のそのバージョンが、発表されていないもので、ある会社によってそのトレード・シークレットと考えられているのならば、その他の状況にもよりますが、それを公表することはトレード・シークレットの法律の違反となる可能性があります。GPLはこれを変更はできません。もし、その会社がそのバージョンをリリースしようとし、それでもなお、トレード・シークレットとみなそうとするのならば、それはGPLに違反するでしょう。しかし、その会社がそのバージョンをリリースしていなければ、そのような違反は起こりません。

ある会社がほかの開発者のGPLでカバーされる作品のコピーを、わたしに対してトレード・シークレットとして配布したらどうですか?

その会社はGPLに違反しており、そのプログラムの配布を停止しなければなりません。これが上述の窃盗のケースと違うのは、その会社は盗まれた場合には意図してコピーを配布したのではないので、そのケースではGPLには違反していないのです。

ある会社が自身のGPLでカバーされる作品のコピーを、わたしに対してトレード・シークレットとして配布したらどうですか?

その配布されたプログラムがほかの誰かのGPLの及ぶ作品を組み入れていない場合、その会社はGPLに違反していません(詳しくは「GPLの及ぶプログラムの開発者はGPLによって束縛されますか? 開発者がGPL違反を犯すことはあり得るでしょうか?」をご覧ください)。しかし、そこでは、あなたがそのプログラムに対してなにができるかについて二つの矛盾する言明がなされています: あなたは再配布できる、そして、あなたはできない、と。コピーを受け取る前に、そのプログラムの利用の条項の明確化を要求することに、意味はあるでしょう。

いくつかのGNUライブラリが、劣等GPLではなくふつうのGPLのもとでリリースされているのはなぜですか?

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

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

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

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

プログラムで「GPLのバージョン2かそれ以降のすべてバージョン」というように述べるべきなのはなぜですか?

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

それぞれのプログラムに間接的ポインタがないと、数多くの著作権者と変更について長々と議論せざるを得なくなるかも知れず、また事実上これは不可能でしょう。実際には、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はプログラムのために設計され、プログラムにとって重要なたくさんの複雑な条項があります。これは、煩雑で本やマニュアルには必要ないものでしょう。たとえば、(もしGPLを適用すると)紙の本を出版する誰もが、本の印刷されたコピー毎に、機械可読の「ソースコード」を含めるか、「ソースコード」を後日送る書面での申し出を提供しなければならないことになります。

一方、GFDLは自由マニュアルの出版社がコピーの販売で利益を得ることを助ける条項があります。たとえば、表紙です。エンドースメント・セクションの特別なルールがGFDLを公式の標準版のために使うことを可能としています。これは、改変されたバージョンを許しますが、改変されたバージョンを「標準版」と呼ぶことはできません。

GFDLを使い、わたしたちはマニュアルの技術的な内容を扱った文面の変更を許可します。技術的な部分の変更ができることは重要です。なぜなら、プログラムを改変する人々はドキュメンテーションも対応して改変しなければならないからです。これが自由にできることは倫理的要請です。

わたしたちのマニュアルにはわたしたちの自由ソフトウェアに関する政治的な見解を述べたセクションもあります。わたしたちは、それを「不変」とマークして、変更したり、削除できないようにします。GFDLは、これらの「不変セクション」を規定します。

GPLはフォントにどのように適用できるでしょうか?

フォントのライセンシングは複雑な問題で重視する必要があります。以下のライセンス例外は実験的ですが、一般の利用に承認されています。これに関する提案を歓迎します。こちらの説明を読み、<licensing@gnu.org>に連絡ください。

この例外を使うには、パッケージに含まれるそれぞれのファイル(可能な範囲で)のライセンス表示でそのファイルがGNU GPLのもとで配布される旨を述べますが、その最後に以下の文面を加えてください:

As a special exception, if you create a document which uses this font, and embed this font or unaltered portions of this font into the document, this font does not by itself cause the resulting document to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the document might be covered by the GNU General Public License. If you modify this font, you may extend this exception to your version of the font, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.
日本語訳:特別な例外として、このフォントを使って文書を作成し、このフォントまたはこのフォントの変更されてない部分を文書に埋め込んだとき、このフォントは、それ自身として、結果の文書を、GNU一般公衆ライセンスの及ぶものとはしません。この例外は、しかしながら、GNU一般公衆ライセンスが文書に及ぶ、その他の理由を無効とはしません。このフォントを改変したとき、あなたはこの例外をあなたのバージョンのフォントにも拡張できますが、その義務はありません。そうしたくない場合は、この例外の文をあなたのバージョンから削ってください。

わたしはウェブサイトの保守のシステムを書いています(“コンテント管理システム”と呼ばれます)が、ほかのアプリケーションがテンプレートからウェブ・ページを生成します。そのようなテンプレートにどのライセンスを使うべきでしょうか?

テンプレートは、コピーレフトを使って保護するに値しない、たいしたことのないものでしょう。たいしたことのない著作物にコピーレフトを使うことは通常、害がありませんが、アプリケーションのユーザの提供したデータと組み合わさって組み合わせたものが配布されるので、テンプレートは特別なケースです。ですから、わたしたちは、テンプレートには簡潔な寛容の条項のライセンスを用いることを推奨します。

あるテンプレートは、Javascriptの関数を呼びます。Javascriptはしばしば、取るに足らないものではなく、コピーレフトとするに値します。テンプレートはユーザのデータと組み合わされますから、テンプレート+ユーザデータ+Javascriptは著作権法のもとで一つの作品とみなされることがありえます。(コピーレフトとされる)Javascriptとユーザ・コード(通常、両立しない条件)の間に線引きがされる必要があります。

Javascriptのコードに対して線引きを行う例外です:

GPLへの特別の例外として、このコードに単に関数呼び出しを行う(あるいはそのために参照として含まれる)いかなるHTMLファイルも、著作権法の趣旨では別の作品と判断されます。加えて、このコードの著作権者は、このコードをGNU LGPLでリリースされた自由ソフトウェアライブラリと組み合わせる許可を与えます。もし、このコードを改変した場合、あなたのバージョンのこのコードに、この例外を拡張することができますが、そうする義務はありません。そうしたくない場合、この例外の文面をあなたのバージョンから削除してください。

不自由なツールを用いて開発したプログラムをGPLでリリースできるでしょうか?

ソースコードを編集する、コンパイルする、研究する、あるいは記録するのにあなたが使ったプログラムは、ソースコードのライセンシングに関した問題に、通常、なんの違いも与えません。

しかしながら、不自由なライブラリをリンクする場合は、取り扱わなければならない問題となります。それは、ソースコードをGPLのもとでリリースすることを妨げませんが、もしライブラリが「システム・ライブラリ」例外に適合しない場合、そのライブラリとあなたのプログラムをリンクする許可を与える明示的な告知を添付するべきです。FSFはあなたにこれに関するアドバイスをすることができます。

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

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

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

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

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

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

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

• 人々に非公式な翻訳を参照させる。これにより、わたしたちは人々がGPLの翻訳を行うことを許可しますが、しかしそれらが法的に有効で拘束力があるとは認めていないことになります。

  承認されていない翻訳は法的効力を持ちませんから、そうはっきりと翻訳中で述べられているべきです。すなわち、以下のように記載することが必要です。

  This translation of the GPL is informal, and not officially approved by the Free Software Foundation as valid. To be completely sure of what is permitted, refer to the original GPL (in English).
  日本語訳: このGPLの翻訳は非公式なもので、フリーソフトウェアファウンデーションによって法的効力があると承認されたものではありません。何が許可されているか厳密に確認するためには、(英語で書かれた)オリジナルのGPLを参照してください。

  承認されていない翻訳であっても、英語版のGPLをどう理解するかのヒントとして役に立ちます。多くのユーザにとってはこれで十分です。

  しかし、GNUソフトウェアを商業活動に利用するビジネスや、ftpによる公開の配布を行う人々は、実際の英語版GPLをチェックしてそれが何を許可しているのか確かめるべきでしょう。

• 翻訳の発表はある単一の国でのみ有効である。

  わたしたちは現在、正式に法的効力があるとされる翻訳の発表はある一つの国でのみ有効とするということを検討しています。こうすれば、もし誤訳があったとしても、影響はその国にのみ限定されますから、ダメージがそんなに大きくなることはないでしょう。

  いずれにせよ、そのような翻訳が現実のものとなるには力量とわたしたちへの共感を兼ね備えた弁護士の相当な専門知識と努力が必要となるので、そのような翻訳が近いうちに出るとはお約束できません。

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

インタープリタが単に言語を解釈するだけならば、答えはイエスです。解釈されるプログラムは、インタープリタにとっては単なるデータに過ぎません。また、GPLはGPLが適用されたプログラムを処理するツールが何であるかまでは規制しません。

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

ですから、アクセスされる機能がGPLと両立しないライセンスのもとでリリースされている場合、状況としては他の方法でGPLと両立しないライブラリとリンクする場合とほぼ同じです。すなわち、

1. コードをGPLのもとで書いてリリースする場合、あなたはGPLと両立しない機能とのリンクを明示的に許可する例外条項を記載することができます。
2. プログラム自体はGPLのもとで書かれリリースされているが、そういったGPLと両立しないライセンスが適用された機能と共に動作するよう設計されていることが明白ならば、人々はプログラムをそれらの機能とリンクする許可が暗黙の例外として与えられていると考える可能性があります。しかしそれがあなたの意図ならば、そうはっきり述べておいたほうが良いでしょう。
3. 誰か他の人が書いたGPLの及ぶコードを取ってきて、そういうふうに使ったり、そのような例外を加えたりすることはできません。例外を追加できるのはそのコードの著作権者だけです。

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のもとでリリースすることを許可していないということになるのです。

(親会社に株の)多数が有されて支えられた子会社にコピーを移すことは配布となりますか?

コピーをこの子会社に移す(または子会社から移す)ことが「配布」にあたるかどうかは、その適切な管轄の著作権法でその場合毎に決定される問題です。GPLはローカルな法律を上書きしたり上書きできるものではありません。合衆国政府の法律はこの点に関して完全に明確というわけではありませんが、これを配布とはみなさないようにみえます。

もし、ある国で、これが配布とみなされ、子会社がそのプログラムを再配布する権利を受け取らなければならないのであっても、実際上は、何の違いもないでしょう。子会社は親会社によってコントロールされ、権利があってもなくても、親会社がそうすることを決定しない限り、そのプログラムを再配布しないでしょう。

ソフトウェア・インストーラが人々にGPLに同意するかクリックさせることはできますか?もし、あるソフトウェアをGPLで入手したとき、何かに同意しないといけないのですか?

あるソフトウェア・パッケージングシステムは、あなたがGPLの条項に同意することをクリックして進む、もしくは示す必要がある場所を用意しています。これは必要もなければ、かといって、禁じられてもいません。クリックして進んでも進まなくても、GPLのルールは同じままです。

単にGPLに同意することは、あなたに何の義務を負わせることはありません。GPLでライセンスされたソフトウェアを単に使うことに関して、なにかに同意する必要はありません。ソフトウェアに改変や配布を行った場合にだけ、義務が生じます。GPLにクリックして進むことがそんなにも面倒であれば、GPLとされたソフトウェアをいじって、それをバイパスするように、あなたがすることを止めるものは何もありません。

GPLのソフトウェアをある種のインストレーション・ソフトウェアと組み合わせたいと思います。このインストーラはGPLと両立するライセンスの必要がありますか?

いいえ。インストーラとインストールされるファイルは別々の著作物です。結果として、GPLの条項はインストレーション・ソフトウェアには適用されません。