このFAQを読んだあと、フリーソフトウェア のライセンシングに関するご自分の知識をクイズでたしかめることができます 。
「プログラムをGNUソフトウェアにする」とは、そのプログラムをGNUプロジェ クトに明示的に寄贈することです。プログラムの開発者とGNUプロジェクトが 寄贈に同意すると、そのプログラムはGNUソフトウェアになります。プログラ ムをGNUプロジェクトに寄贈することに興味がある方は、<maintainers@gnu.org>まで ぜひご一報ください。
GPLの代替案として、改変されたバージョンは原作者の許可を必要とする、と いうような条件を提案した人がいました。実際問題として、このやり方は原作 者がメンテナンスの必要に対応し切れている間はうまく行くでしょうが、もし 作者が(多かれ少なかれ)何か作業をすることを止めてしまったり、ユーザのニー ズすべての面倒を見なくなったりしたら、このやり方は行き詰まってしまいま す。実際上の問題は別としても、このやり方はユーザが互いに助け合うことを 許可していません。
ユーザによって作られた様々なバージョン間での混乱を避けるための手段とし て、改変されたバージョンをコントロールすることが提案されることがありま す。しかし、私たちの経験では、この種の混乱は大きな問題ではありません。 Emacsの多くのバージョンがGNUプロジェクトの外部で作られて来ましたが、ユー ザはそれらを別々のものとして見分けることができています。GPLでは、他の バージョンと見分けがつくようにして他の管理者たちの名声を守るため、ある バージョンの作者には彼または彼女の名前を載せることを要求しています。
しかし、もしあなたが改変されたバージョンを何らかの形で公にす るならば、GPLはあなたが改変したソースコードをユーザがGPLの下で入手でき るようにすることを要求します。
すなわち、GPLは改変されたプログラムを特定のやり方で公開する許可を与え ていますが、別の形での公開は許可していないのです。しかし、公開するかど うかはあなた次第です。
GPLには、バイナリをソースコード抜きで商業的に頒布する場合、あなたが後 にソースコードを頒布する旨書かれた書面によるオファーを提供しなければな らないとあります。ユーザがあなたから受け取ったバイナリを非商業的に再頒 布するときには、この書面によるオファーの複製を一緒に渡さなければなりま せん。これは、バイナリを直接あなたから入手しなかった人々も、書面による オファーと一緒にソースコードの複製を受け取ることができるということを意 味します。
私たちが、オファーがいかなる第三者にとっても法的に有効であることを要求 するのは、そうすることによって、バイナリを間接的に受け取った人々もソー スコードをあなたに注文することができるからです。
著作権を主張するかしないかに関わらず、あなたは自分が改変したバージョン を全体としてはGPLの下で公開しなければなりません。
GPLはフリーソフトウェアライセンスの一つですから、誰かに料金を払うこと なく、人々がソフトウェアを使うこと、そして再頒布することさえ許可してい ます。
また、あなたはクライアントに対して自分の改変した点をGPLの下で公開し、 しかしそれらをクライアントがOKと言うまで他の人には公開しないということ に合意することもできます。この場合も、GPLで保護されたコードがNDAや他の 追加的な制限の下で頒布されるということにはなりません。
GPLはクライアントがあなたのバージョンを再頒布する権利を与えます。しか しこの筋書きでは、クライアントがその権利を行使しないと決定しているわけ です。
ライセンス自体の代わりに、ライセンスの在処を指すURLを含めたくなるかも 知れませんが、URLが今後5年、10年とずっと有効であり続けるという確証はあ りません。20年も経てば、今日私たちがURLとして知っているものそのものが もはや存在しないかもしれないのです。
ネットワークの世界で将来起こる全ての変化にもかかわらず、プログラムの複 製を持つ人々がずっとライセンスを見ることができることを保証する唯一の方 法は、ライセンスの複製をプログラムの中に含めることです。
前文と適用方法の説明は5000文字あまりに過ぎず、GPL全体のサイズの1/3以下 を占めるに過ぎません。ソフトウェアパッケージ自体が相当小さいので無い限 り、前文と説明はパッケージのサイズに実質的なわずかな変化をもたらさない でしょう。もしソフトウェアパッケージが小さいのであれば、GNU GPLではな く単純で何でも許可しているようなライセンスを適用したほうがいいでしょう。
いくつかのライセンスでは、結合の方法がそれらが矛盾しないかどうかに影響 することがあります。例えば、あるライセンスの組は二つのモジュールを一緒 にリンクすることは許可しているが、コードをマージして一つのモジュールに することは許可していない、といったたぐいです。
GPLでは、そのような結合著作物がGNU 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>)に教 えてください。私たちは、人々が同じ仕事をするフリーなライブラリを開発す るよう奨励することができるかもしれません。
しかしながら、アメリカ合衆国で著作権を登録するのは非常に良い考えです。 これによって、アメリカ国内での侵害者に対抗する上でより強い権力が与えら れます。
誰か他人が著作権を主張する可能性があるのは、あなたが従業員や生徒だった 場合です。その場合、雇用者や学校はその作業はあなたが彼らのために行った もので、著作権は彼らに帰属すると主張する可能性があります。その主張が正 当なものかどうかは、あなたがお住まいの場所の法律や雇用契約、どのような 種類の仕事をあなたがしているかなど、状況に依ります。疑いの可能性がある 場合には弁護士に相談するのが最善です。
もし雇用者や学校が著作権を主張するようなことがあり得ると思うのでしたら、 企業や学校の適切な権限のある役員や幹部によって署名された著作権放棄声明 (copyright disclaimer)を得ることで、この問題をはっきり解決することがで きます。(あなたの直接の上司や教授には、普通そのような声明にサインする 権限は*ありません*)。
あなたの学校が、ご自分のプログラムをフリーソフトウェアとして公開するこ とを許可しないかも知れないという危険性を察知したら、その問題をできる限 り早い段階で提起することが最善です。プログラムが便利に動くように近づけ ば近づくほど、学校当局側はそれをあなたから取り上げてあなた抜きで仕上げ ようという誘惑に駆られることになります。初期の段階であれば、あなたはよ り強い影響力を振るえます。
そこで、私たちは、プログラムがまだ半分できかかったような状態に過ぎない ときに学校側に近づき、こう言うことをおすすめします。「もしあなたがたが これをフリーソフトウェアとして公開することに同意するならば、仕上げます」。 これを脅しと考えてはいけません。説得するには、こう言う勇気が必要です。 「私のプログラムは自由を持つか、あるいは決して生まれないか、どちらかだ。」
それが著作権者によって含められたと考えられ、またあなたがその複製を 合法的に手に入れたならば、あなたが持つ複製と一緒に手に入ったライセンス が、あなたの複製に適用されるライセンスです。
しかし、開発者が誰か他の人間によって行われたならばGPL違反となりそうな ことをする場合、開発者はもちろんコミュニティにおける倫理的名声を失なう ことになるでしょう。
プログラムによっては、技術的な都合から自身の一部を出力結果にコピーする ものがあります。例えば、Bisonは標準パーサプログラムを出力ファイルにコ ピーします。そのような場合、出力結果にコピーされたテキストはそのソース コードを保護しているのと同じライセンスによって保護されます。一方、プロ グラムに与えられた入力から派生した出力結果の一部は入力側の著作権状態を 継承します。
たまたま、Bisonはフリーではないプログラムを開発するのにも使うことがで きます。これは、私たちがBisonの出力結果に含まれるBisonの標準パーサプロ グラムは制限無しに利用できるということを明確に認めているからです。私た ちがこう決めたのは、Bisonと同様の他のツールでフリーではないプログラム での利用を認めているものがすでに存在したからです。
「公正使用」について世界的な原則は存在しないということに注意してくださ い。どのような利用が「公正」であるとみなされるかは国によって様々です。
ですから、あなたが出力結果の利用に関して発言権を持つ唯一のケースは、出 力結果の本質的な部分が(多かれ少なかれ)あなたのプログラムのテキストから 複製されている場合です。例えば、Bison(前の項参照)の出力結果は、もし私 たちがこの特定のケースに関して例外を設けなければ、GNU GPLで保護されて いたでしょう。
そうする技術的な理由が無くても、無理矢理プログラムの出力にテキストをコ ピーするようにさせることはできますが、複製されたテキストは実用的な目的 を何ら果さないでしょうから、ユーザは単にそのテキストを出力結果から削除 して残りだけを使うということができます。そうすれば、複製されたテキスト の再頒布に課せられた条件に従う必要は無いわけです。
しかし、あなたが自分のコードの利用に関して追加的な許可を与えることは可 能です。そうしたければ、自分のプログラムを、GPLより制約が緩いが、GPLと は矛盾しないライセンスの下で公開してください。ライセンス一覧のページには、 GPLと矛盾しないライセンスの(不完全な)リストが用意されています。
しかし、インタープリタが他の機能(多くの場合ライブラリですが、ライブラ リである必要はありません)への「バインディング」を提供するように拡張さ れている場合、解釈されるプログラムはバインディングを使うことによって事 実上それらの機能とリンクされることになります。ですから、もしそういった 機能がGPLの下で公開されているならば、機能を利用した解釈されるプログラ ムはGPLと矛盾しないような形で公開されなければなりません。JNI(Javaネイ ティヴインターフェース)はそのような機能の一例です。JNIによってアクセス されるライブラリは、それらを呼ぶJavaプログラムと動的にリンクされていま す。
上とよく似た、非常に一般的な例としては他に、ライブラリをそれら自身が解 釈されるインタープリタと一緒に提供するという場合があります。例えば、 Perlは多くのPerlモジュールと一緒に頒布されており、またJava実装は多くの Javaクラスを含んでいます。これらのライブラリとライブラリを呼ぶプログラ ムは常に一緒に動的リンクされています。
結果として、あなたのプログラムでGPLが適用されたPerlモジュールやJavaク ラスを利用することにした場合、GPLと矛盾しないような形でプログラムを公 開しなければならないということがありえます。この場合、結合されたPerlや Javaプログラムが実行されるPerlなりJavaなりのインタープリタに適用されて いるライセンスが何であるかは関係ありません。
You may not impose any further restrictions on the recipients' exercise of the rights granted herein.
(訳: あなたは受領者に、ここで認められた権利の行使に関して更なる制限を課し てはならない。)
オリジナルBSDの宣伝条項はまさしくそのような「更なる制限」を提供してお り、よってGPLと矛盾します。
改訂BSDライセンスには宣伝条項がありませんから、問題ありません。
もしプログラムがプラグインと動的にリンクされており、お互いにファンクショ ンコールを使ってデータ構造を共有している場合、それらは単一のプログラム を形成していると見なされますので、プラグインはメインプログラムの拡張部 分として扱われなければなりません。すなわち、それらはGPLかGPLと矛盾しな いフリーソフトウェアライセンスの下で公開されなければならないということ です。
プログラムがプラグインと動的にリンクされているが、それらの間のコミュニ ケーションはいくつかのオプションとともにプラグインの「main」関数を呼び 出して返値を待つだけという場合は、境界線上で微妙なケースとなります。
プログラムがプラグインと動的にリンクされ、お互いにファンクションコール を使ってデータ構造を共有している場合、それらは単一のプログラムを形成し ていると見なされますので、プラグインはメインプログラムの拡張部分として 扱われなければなりません。このことは、GPLで保護されたプラグインをメイ ンプログラムとリンクするのは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一般公衆許諾契約書はこの例外無しで改 変されたバージョンを公開する許可を与えており、またこの例外は、改変 されたバージョンをこの例外をそのまま含む形で改変したバージョンを公 開することも可能としています。)
二つのモジュールを結合するとは、それらを一緒に接続しそれらが単一のより 大規模なプログラムを形成することを意味します。もしいずれかの部分がGPL で保護されているならば、結合物全体もGPLの下で発表しなければなりません。 もしそうできなければ、あるいはそうするつもりが無ければ、あなたはそれら を結合することはできません。
二つの部分を一つのプログラムに結合する要件とはなんでしょう? これは法的 な質問であり、究極的には裁判官が決めることです。私たちは、適切な基準は コミュニケーションのメカニズム(exec、パイプ、rpc、共有アドレス空間での ファンクションコールなど)とコミュニケーションのセマンティクス(どのよう な種の情報が相互交換されるか)の両方に依ると考えています。
モジュールが同じ実行ファイルに含まれている場合、それらは言うまでもなく 一つのプログラムに結合されています。もしモジュールが共有アドレス空間で いっしょにリンクされて実行されるよう設計されているならば、それらが一つ のプログラムに結合されているのはほぼ間違いないでしょう。
逆に、パイプやソケット、コマンドライン引数は通常二つの分離したプログラ ムの間で使われるコミュニケーションメカニズムです。ですからそれらがコミュ ニケーションのために使われるときには、モジュールは通常別々のプログラム です。しかしコミュニケーションのセマンティクスが親密であったり、複雑な 内部データ構造を交換したりする場合は、それらも二つの部分がより大規模な プログラムに結合されていると考える基準となりうるでしょう。
また、私たちは個々の貢献者が彼らの雇用者(もしいれば)からの著作権放棄声 明を得て、そういった雇用者たちが将来になって貢献を所有していると主張す ることがないよう保証することもお願いしています。
もちろん、すべての貢献者が彼らのコードをパブリックドメインに置いたなら ば、GPLを強制すべき著作権は存在しません。ですから私たちは、大量のコー ドを貢献して下さった場合は著作権を譲渡し、小さな改変点に関してはパブリッ クドメインに置くことを推奨しています。
あなたのプログラムに関してGPLを強制したいならば、同じようなポリシーに 従うのはおそらくあなたにとっても良い考えでしょう。詳しくは<licensing@gnu.org>にご連絡 下さい。
これらは、あなたが入手したGPLで保護されたコードをあなた自身のプログラ ムに含める上での要件です。
しかし、マニュアルや教科書、あるいはより一般的に何かについて教えること を意図している著作物に対しては、GPLではなくGFDLを適用することを推奨し ます。
GPLで保護されたプログラムを組み入れたシステムは、そのプログラムの派生 バージョンとなります。GPLによれば、あるプログラムの派生バージョンは、 それを公開するならばGPLの下で公開されなければならないとされています。 これは二つの理由があります。一つには、ソフトウェアを入手したユーザが彼 らが持つべき自由を得ることが保証されるということ、もう一つは、人々が行っ た改良点が作者に還元されるのを奨励するということです。
しかし多くの場合、GPLで保護されたソフトウェアを独占的なシステムと一緒 に頒布することは可能です。これを妥当な形で行うには、フリーなプログラム とフリーではないプログラムとがそれぞれ独立を保った形でコミュニケートし、 それらが事実上単一のプログラムとなってしまうような方法で結合されていな いことを確認しなければなりません。
GPLで保護されたソフトウェアを一緒に頒布することと「組み込む」こととの 違いは、ある点では実質的な問題であり、ある点では形式的な問題です。実質 的な問題とは、二つのプログラムが結合され、それらが事実上一つのプログラ ムの二つの部分となるならば、あなたはそれらを二つの別々のプログラムとし て扱うことができないということです。よって、この場合GPLが全体を保護す るということになります。
コンパイラとカーネル、あるいはエディタとシェルというように、二つのプロ グラムがきちんと分離されたままであれば、あなたはそれらを二つの別々のプ ログラムとして扱うことができます。しかし扱いには気を付けなければなりま せん。ここで問題となるのは、あなたが何をしているのかちゃんと記述すると いう単純に形式的なことですが、どうして私たちはこんなことに気を使うので しょう? それは、私たちはユーザに対し、あるソフトウェアのコレクションに 収められたGPLで保護されたソフトウェアがフリーであるということをユーザ が明らかに理解することを保証したいからです。
人々が、GPLで保護されたソフトウェアをその一部が独占的であるとユーザが 知っているシステムの「一部」と呼んで頒布しようとしている場合、ユーザは GPLで保護されたソフトウェアに関する彼らの権利について自信が持てないか もしれません。しかし彼らが受け取ったものがフリーなプログラムにそうでな いものを並べて追加しただけのものだということが分かれば、彼らの権利は明 確になるでしょう。
まず、一般論からご説明しましょう。私たちが企業Aに対して独占的なファイ ルを作ることを認め、さらに企業BがそのファイルとGPLで保護されたソフトウェ アをリンクしたものを頒布することを認めたとすると、それはGPLにトラック が悠々通れるほど大きな抜け穴を開けてしまうということに他なりません。こ れは、GPLで保護されたソフトウェアへのあらゆる種類の改変や拡張に必要な ソースコードを与えず留保するということに関して、企業に白紙委任状を渡す に等しいからです。
すべてのユーザにソースコードへのアクセスを提供するということは私たちの 主な目標の一つであり、上記のような状況はもちろん私たちが避けたいもので す。
より具体的に言えば、カネヨコセ社のライブラリとリンクされているプログラ ムのあるバージョンは、実際のところ私たちが理解するところの「フリーソフ トウェア」ではありません。ユーザがプログラムを改変や再コンパイルするこ とを可能とする完全なソースコードと共に提供されていないソフトウェアは、 フリーソフトウェアとは呼ばないからです。
モジュールQのライセンスがそうすることを許可しているならば、それはGPLと 矛盾しませんが、そうでなければQのライセンスはGPLと矛盾します。
Qのライセンスが、Qをそれ単体で再頒布する際に何か(GPLと矛盾すること)を しなければならないとはっきりと規定している場合には、QのライセンスはQを GPLの下で頒布することを許可していません。よってあなたはP+QをGPLの下で 頒布すること自体ができません。ですからあなたはPをQとリンクしたり結合し たりすることはできないのです。
ユーザがソースを注文したとき、あなたはそのユーザがソースを得られるよう 保証しなければなりません。ある特定のユーザが、あなたから匿名 FTPでソー スを便利に入手できるなら、FTPは期待された役割を果たしているということ で大いに結構です。しかしすべてのユーザがネットワークにつながっているわ けではありません。そういったユーザたちもあなたからソースコードを得る権 利は他の人同様持っているわけですから、あなたは彼らにソースを郵便経由で 送るよう準備しておかなければなりません。
FTPアクセスが十分便利ならば、おそらく誰もメールオーダーでソースを取り 寄せようとは思わないでしょうから、ソースを郵便で発送しなければならない ということはまずないでしょう。しかしそう決めてかかることはできません。
もちろん、そもそも最初からバイナリといっしょにソースを送ればこういった 面倒は起こりません。
しかし、注意すべきなのは、たまたま今日は適切なソースコードをおいている とあるサイトを見つけて、人々にそっちを見ろと言うだけでは不十分だという ことです。明日になればそのサイトはソースコードを削除してしまうかもしれ ませんし、あるいは単に同じプログラムの新しいバージョンで置き換えてしま うかもしれません。そうするとあなたはもはやGPLの要件を満たしているとは 言えなくなります。GPLの要件を満たすべく相当な努力を払ったと主張するに は、あなたは他のサイトとはっきりした協定を結び、あなたがバイナリを入手 可能にしておく期間中はソースがそこで入手可能であるということを保証しな ければなりません。
フリーソフトウェアという考え方の一部分は、ユーザが*彼らが使うプログラ ム*のソースコードへのアクセスを得るべきだということです。あなたのバー ジョンを使っている人々はあなたのバージョンのソースコードへのアクセスを 得るべきなのです。
GPLの主な目標は、フリーなプログラムへの改良がそれら自身フリーであるこ とを保証することにより、自由な世界を構築することです。もしあなたがGPL で保護されたプログラムの改良されたバージョンを公開したならば、あなたは GPLの下で改良されたソースコードを公開しなければなりません。
今から一年後にソースを欲しいと思うユーザは、その時点で他のサイトから適 切なバージョンを入手できなくなっているかもしれません。標準頒布サイトに は新しいバージョンがあるかもしれませんが、同じ差分はおそらくそのバージョ ンには当たらなかったり、うまく動作しなかったりするでしょう。
ですから、あなたは差分ではなく、完全なソースをバイナリと共に頒布しなけ ればなりません。
ですから、あなたがバイナリを匿名 FTPで頒布したいならば、あなたはソース をそれらと一緒に頒布しなければなりません。これはそんなに難しいことでは ないはずです。プログラムを頒布するサイトを見つけられたのですから、ソー スを置く余地のあるサイトだって見つけられるでしょう。
あなたが提供するソースは正確にバイナリと対応していなければなりません。 特に、あなたはそれらがプログラムの同じバージョンのソースであることを保 証しなければなりません。古くても新しくてもダメです。
ソースとバイナリをそれぞれ別のマシンで入手可能にすることができますが、 それらを入手するのが等しく容易であること、バイナリのとなりにどこでソー スを見つけられるか情報を用意しておくことが条件です。
再頒布者への私たちの要求は、ユーザがソースコードを入手できるということ を保証するということを意図しているのであって、ユーザが欲しくもないのに ソースコードをダウンロードするよう強制しろということではありません。
局地的な後退が良い戦略であることもあります。場合によっては、LGPLをライ ブラリに適用すればそのライブラリがより広く使われるようになり、改良がよ り多く加えられ、ソフトウェアへのより広汎なサポートが得られる、といった ことが起こるかもしれません。これは、もし華々しい成果が得られるならばフ リーソフトウェアにとって良いことと言えるでしょう。しかしこれがどの程度 起こるのか、私たちにできるのは予想することだけです。
LGPLをそれぞれのライブラリにしばらく適用してみて、それが助けになるかし ばらく様子を見た上で、LGPLが助けにならなければGPLに戻すということがで きればそれが良いのでしょうが、いったんLGPLをある特定のライブラリに適用 すると戻すのは至難なので、これは不可能です。
ですから私たちはそれぞれのライブラリにどのライセンスを適用するか、ケー スバイケースで決めています。この問題をどう判断しているかについては、以 下に長い説明があります。
ユーザ数を最大化することが私たちの目標なのではありません。どちらかとい えば、私たちはできる限り多くのユーザに重要な自由を与えようと努力してい ます。一般的にいって、独占的なソフトウェアプロジェクトは自由の主張を助 けるものではなく、妨げるものです。
場合によってはライセンスに例外を設け、GPL以外のライセンスの下で公開さ れたフリーソフトウェアを作っているプロジェクトを支援することもあります が、しかしそのためには、なぜそれがフリーソフトウェアの主張を促進させる のかについてきちんとした理由が無いといけません。
また、私たちはときたまパッケージの頒布条件を改変することもありますが、 それは改変が明らかにフリーソフトウェアの主張を満たす正しい道であるよう に考えられるときに限ります。しかし頒布条件の改変に関しては私たちは非常 に慎重なので、あなたは私たちを納得させられるだけの十分説得力ある理由を 示す必要があるでしょう。
それぞれのプログラムが「間接的ポインタ」の形でGPLを指定していないと、 私たちは数多くの著作権者と延々と改変について議論せざるを得なくなり、 また事実上これは不可能です。現実的には、GNUソフトウェアが一様な頒布条 件を持つと言う可能性はゼロとなってしまうでしょう。
あるプログラムが「GPLのバージョン2かそれ以降のどれか」が適用されると指 定しており、GPLの新バージョンが公開されたとしましょう。新しいGPLが追加 的な許可を与えるものであれば、その許可は即座にプログラムのすべてのユー ザに対して与えられることになります。新GPLがより厳格な要件を課したとし ても、そのプログラムは依然としてGPLバージョン2の下で利用できますから、 プログラムの現在のバージョンの利用が制限されることにはなりません。プロ グラムが「GPLバージョン2かそれ以降のどれか」と指定していれば、GPLのよ り新しいバージョンが利用可能となった後でも、ユーザはGPLバージョン2の条 項に従い常にそのプログラムを利用したり、それを改変したりすることさえで きるのです。
GPLの新バージョンが指定するより厳格な要件に既存のソフトウェアが従う必 要がないならば、そんな条件に意味があるのでしょうか? いったんGPLバージョ ン3が利用可能になれば、ほとんどのGPLで保護されたプログラムの開発者は彼 らのプログラムのそれ以降のバージョンを「GPLのバージョン3かそれ以降のど れか」と指定して公開するでしょうから、ユーザもその後に公開されたプログ ラムに関してはGPLバージョン3のより厳格な要件に従わなければならなくなる というわけです。
しかし、開発者たちにこうすることが義務づけられているわけではありません。 開発者は、そうしたければGPLの以前のバージョンに従った利用を許可し続け ることができます。
GPLはプログラム向けに設計されたものですから、プログラムにとっては重要 な複雑な条項を数多く含んでいます。そういった条項は、書籍やマニュアルに は不要でじゃまなものです。一方、GFDLにはフリーなマニュアルの出版者が出 版によって利益を上げることを助ける条項が含まれています。
私たちは技術的なトピックを扱うテキストの改変は許可していますが、法的、 政治的あるいは倫理的な立場を述べた節の改変は認めていません。私たちはそ ういった改変してはならない節を明示的に列挙することで改変を禁止していま す。GFDLにはこのような「改変不可部分」に関する条項が用意されていますが、 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 the original GPL (in English).
(訳: このGPLの翻訳は非公式なものであり、フリーソフトウェア財団によっ て法的効力があると承認されたものではありません。何が許可されている か厳密に確認するためには、(英語で書かれた)オリジナルのGPLを参照し て下さい。)
承認されていない翻訳であっても、英語版のGPLをどう理解するかのヒントと して役に立ちます。多くのユーザにとってはこれで十分です。
しかし、GNUソフトウェアを商業活動に利用する企業や、ftpによる公開の頒布 を行う人々は、実際の英語版GPLをチェックしてそれが何を許可しているのか 確かめるべきでしょう。
私たちは現在、正式に法的効力があるとされる翻訳の発表はある一つの国での み有効とするということを検討しています。こうすれば、もし誤訳があったと しても、影響はその国にのみ限定されますから、ダメージがそんなに大きくな ることはないでしょう。
いずれにせよ、そのような翻訳が現実のものとなるには力量と私たちへの共感 を兼ね備えた弁護士の相当な専門知識と努力が必要となるので、そのような翻 訳が近いうちに出るとはお約束できません。
一部のライブラリはGNU 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 $