GNUライセンスに関してよく聞かれる質問

“GPL”とは何の略ですか? (#WhatDoesGPLStandFor)

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

自由ソフトウェアとは、GPLを使っているという意味ですか?(#DoesFreeSoftwareMeanUsingTheGPL)

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

他の自由ソフトウェア・ライセンスではなく、GNU GPLを使ったほうが良いのはなぜですか? (#WhyUseGPL)

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

すべてのGNUソフトウェアにはライセンスとしてGNU GPLが使われているのですか? (#DoesAllGNUSoftwareUseTheGNUGPLAsItsLicense)

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

GPLを使うとそのプログラムはGNUソフトウェアになるのですか? (#DoesUsingTheGPLForAProgramMakeItGNUSoftware)

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

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

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

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

GPLがユーザの改変した版の公開を許可しているのはなぜですか? (#WhyDoesTheGPLPermitUsersToPublishTheirModifiedVersions)

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

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

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

GPLは、改変された版のソースコードを公に発表することを要求しますか? (#GPLRequireSourcePostedPublic)

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

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

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

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

その通りです。

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

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

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

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

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

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

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

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

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

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

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

あるコードを異なるプログラミング言語に翻訳することについてGPLはどう言ってますか? (#TranslateCode)

著作権法では、作品の翻訳は改変の一種であると考えられています。ですから、GPLが改変版について言っていることが翻訳版にも当てはまります。翻訳はオリジナルのプログラムの著作権にカバーされます。

オリジナルのプログラムが自由なライセンスを持つ場合、そのライセンスはそのプログラムを翻訳する許可を与えるでしょう。あなたがどのように翻訳したプログラムを使い、また、ライセンスできるかは、そのライセンスによって決まります。オリジナルのプログラムがあるバージョンのGNU GPLでライセンスされている場合、翻訳されたプログラムは同じバージョンのGNU GPLでカバーされなければなりません。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GPLはクライアントがあなたのバージョンを再配布する権利を与えます。しかし、この筋書きでは、クライアントはおそらく、その権利を行使しないことを選択するでしょうが、その権利は有しているわけです。

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

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

研究論文でGPLの及ぶソフトウェアとその出力を使った際に、引用や謝辞を要求する条項を追加することを、GPLは、許可していますか?(#RequireCitation)

いいえ、GPLの条項ではこれは許されません。正しい引用はアカデミックな発表の重要な部分であることは認識しますが、GPLに追加要求として引用を追加することはできません。GPLのソフトウェアの使用をする研究論文に引用を要求することは、GPLv3のセクション7(b)における容認できる追加条項を越えたものとなり、ですから、GPLのセクション7における追加の制限と考えられます。そして、GPLの条項でライセンスされているか、ほかのライセンスでかに関係なく、著作権法は、そのようにソフトウェアの出力への要求を認めていません。

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

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

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

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

GNU GPLのコピーをわたしのリポジトリに入れておくだけでGPLを適用するに充分でしょうか? (#LicenseCopyOnly)

単にGNU GPLの入ったファイルのコピーをリポジトリに置くだけでは、同一のリポジトリにあるコードがGNU GPLで使えるか明示的に述べるわけではありません。明言がなければ、ライセンスの許可がどの具体的なソースファイルに実際に適用されるのか、まったく明確であるわけではありません。明示された文章で述べることがすべての疑念を除去します。

ライセンスだけが入ったファイルがあり、そのライセンスでカバーされる特定のほかのファイルについて述べられた文章がないままで置かれている、という状況は、どこからも決して呼ばれないサブルーチンが入っているファイルに似ています。この相似は完全ではありません: 弁護士と法廷は、常識を適用し、GNU GPLのコピーを置いたのは、そのコードをそれでライセンスしたかったからに違いないと結論づけるかもしれません。もしくは、そうしないかもしれません。しかし、不確実性をそのままにしておく理由があるでしょうか?

この文章はそれぞれのソースファイルにあるべきです。プログラムのREADMEファイルに明確に述べられた文章で法的には充分です(そのコードとともにREADMEがついてくる限りにおいて)。しかし、コードとREADMEは容易に別々になりがちです。なぜ、あなたのコードのライセンスの不確実性のリスクを取る必要があるでしょうか?

これはGNU GPL特有のことでは、まったくありません。どんな自由なライセンスにも当てはまります。

なぜ、個々のソースファイルそれぞれにライセンス告知を置くべきなのでしょう? (#NoticeInSourceFile)

ライセンス告知をそれぞれのソースファイルの最初に置き、どのライセンスを運んでいるか述べるべきです。そのライセンスと切り離されてしまうリスクを避けるためです。リポジトリのREADMEがソースファイルがGNU GPLの元にあると言っている場合、そのソースファイルを他のプログラムに誰かがコピーした場合どうなるでしょうか? そういった他の文脈では、そのファイルのライセンスが何か示せないかもしれません。なにか他のライセンスであるか、あるいはライセンスが全くないか と見えてしまうかもしれません(そうするとコードを不自由にしてしまうでしょう)。

それぞれのソースファイルの最初に著作権表示とライセンス告知を加えることは、容易であり、こういった混乱を起こりにくくします。

これはGNU GPL特有のことでは、まったくありません。どんな自由なライセンスにも当てはまります。

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

もし全体のソフトウェアパッケージがそんなに小さいコードしかない(300行がわたしたちの使う基準です)短いならば、GNU GPLのようなコピーレフトのライセンスではなく、より緩い寛容なライセンスを適用したほうが良いでしょう。(そのコードが特に重要でなければ。) わたしたちは、そのような場合、Apache ライセンス2.0を推奨します。

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

前文と適用方法の説明はGNU GPLの不可欠な一部であり、省略することはできません。実際のところ、GPLには著作権が主張されており、そのライセンスではGPL全体のそのままの複製のみ許可しています。(法的な条項を使って別のライセンスを作ることはできるでしょうが、それはGNU GPLではないでしょう。)

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

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

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

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

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

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

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

すべてのGPLの版は、プライベートなそのような結合著作物を許可しています。また、そのような結合著作物の配布も同一のGNU GPLの版のもとでリリースされる限り、許可しています。ほかのライセンスもこれを許可しているならば、そのライセンスは GPLと両立します。

GPLv3はGPLv2よりも多くのライセンスと両立します。GPLv3は、GPLv3自身にはないある種の追加の要求をもったコードとの組み合わせを許します。第7節に、これについてもっと情報があり、許される追加の要求の一覧もあります。

不自由なライブラリを利用する自由ソフトウェアを書けますか? (#FSWithNFLibs)

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

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

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

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

GPLのプログラムをプロプライエタリのシステム・ライブラリとリンクしてよいでしょうか? (#SystemLibraryException)

GPLの両方のバージョンがコピーレフトに対する例外を有しています。一般にシステムライブラリ例外と呼ばれるものです。使いたいGPLと両立しないライブラリがこのシステムライブラリの範疇にある場合、これを使うのになにか特別のことは必要ありません。たとえこのライブラリを含むリンクされた実行形式を配布したとしても、全体のプログラムのソースコードを配布する要求にはこのライブラリは含まれません。

「システムライブラリ」になにがあたるかという範疇はGPLの異なるバージョン間で異なります。GPLv3は「システムライブラリ」を第一節で明確に定義して、「対応するソース」の定義から除外しています。GPLv2では第3節の終わり近くで少し違ったやり方でこの問題を扱っています。

AGPLv3の及ぶコードとGPLv3の及ぶコードをリンクあるいは組み合わせることがどのような方法で可能でしょうか?(#AGPLGPL)

このライセンスはそれぞれ明確にほかのライセンスのコードとリンクすることを認めています。GPLv3の及ぶモジュールとAGPLv3の及ぶモジュールをリンクするのは(あるいはその逆)は常に可能です。モジュールのうちいくつかがライブラリであってもなくてもそうです。

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

システムライブラリ例外には含まれないライブラリに対してプログラムをリンクしたい場合、その許可を与える必要があります。以下に二つのライセンス表示の例をあげますので、そうするのに使うことができます。一つはGPLv3のためでもうひとつはGPLv2のためです。いずれのケースでも、この許可を与えるそれぞれのファイルに対してこの文章を足すべきです。

プログラムの著作権者だけが、このような条項で法的にソフトウェアをリリースすることができます。あなたがプログラム全体を自分自身で書き、また雇用者あるいは学校が著作権を主張しないと仮定すれば、あなたが著作権者です。よって、あなたは例外を認可することができます。しかし、ほかの作者によるGPLの及ぶプログラムの一部分をあなたのコードで使いたいからといって、あなたが自分でそれらのための例外を認可することはできません。それらのプログラムの著作権者の承認を得る必要があります。

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

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

GPLv3を使っている場合、第7節に関する追加の許可を認めることによってこの目的を達成することができます。以下のライセンス表示がそれを行います。この文章の中のすべての角括弧の中の文をあなたのプログラムに適したものに置き換える必要があります。あなたがリンクしようと考えているライブラリのソースを誰もが配布できるわけではない場合、中括弧の文を削除すべきです。そうでない場合、中括弧だけを削除します。

Copyright (C) [年] [著作権者の名前]

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, see <http://www.gnu.org/licenses>. 日本語訳: あなたは、GNU一般公衆ライセンスの複製をこのプログラムとともに受け取っているべきです。もし、受け取ってない場合、<https://www.gnu.org/licenses>をご覧下さい。

Additional permission under GNU GPL version 3 section 7 日本語訳: GNU GPLバージョン3、第7節に関する追加の許可

If you modify this Program, or any covered work, by linking or combining it with [name of library] (or a modified version of that library), containing parts covered by the terms of [name of library's license], the licensors of this Program grant you additional permission to convey the resulting work. {Corresponding Source for a non-source form of such a combination shall include the source code for the parts of [name of library] used as well as that of the covered work.} 日本語訳: [ライブラリのライセンスの名前]の条項が及ぶ部分を持つ、[ライブラリの名前](またはそのライブラリの改変バージョン)とリンクまたは組み合わせることによって、この「プログラム」または対象を含む作品を改変する場合、この「プログラム」のライセンサは、結果の作品を運搬するために追加の許可を与えます。{このような組み合わせのソースではない形態の「対応するソース」には、[ライブラリの名前]の使われている部分のソースコードを、対象を含む作品のソースコードと同様に含みます。}

GPLv2を使っている場合、ライセンスの条項にあなた独自の例外を提供することができます。以下のライセンス表示がそれを行います。ここでも、この文章の中のすべての角括弧の中の文をあなたのプログラムに適したものに置き換える必要があります。あなたがリンクしようと考えているライブラリのソースを誰もが配布できるわけではない場合、中括弧の文を削除すべきです。そうでない場合、中括弧だけを削除します。

Copyright (C) [年] [著作権者の名前]

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, see <http://www.gnu.org/licenses>. 日本語訳: あなたは、GNU一般公衆ライセンスの複製をこのプログラムとともに受け取っているべきです。もし、受け取ってない場合、<https://www.gnu.org/licenses>をご覧下さい。

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

In addition, as a special exception, the copyright holders of [name of your program] give you permission to combine [name of your program] with free software programs or libraries that are released under the GNU LGPL and with code included in the standard release of [name of library] under the [name of library's 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 [name of your program] 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}. 日本語訳: 加えて、特別の例外として、[プログラムの名前]の著作権者は、[プログラムの名前]プログラムを、自由ソフトウェア・プログラムもしくはGNU LGPLでリリースされている自由ソフトウェア・ライブラリ、そして、[ライブラリのライセンスの名前]の[ライブラリの名前]の標準リリースに含まれるコード(もしくは、ライセンスの変更されていない、そのコードの改変バージョン)と結合することを許可します。そのようなシステムを、[プログラムの名前]に対するGNU GPLの条項と、その他の関係するコードのライセンスに従って、コピーし、配布することができます。{ただし、GNU GPLがソースコードの配布を要求する時は、それに従って、その他のコードのソースコードを含める必要があります。}

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

GPLのもとでリリースするために、わたしのプログラムに対する著作権を得るにはどうしたら良いですか? (#HowIGetCopyright)

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

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

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

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

わたしの学校が、わたしのプログラムを学校自身のプロプライエタリ・ソフトウェア製品にしたいと思ったらどうしましょう? (#WhatIfSchool)

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

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

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

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

こちらのGPLの手順の説明をご覧ください。

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

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

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

自分が書いたプログラムをGNU GPLのもとでリリースしたいのですが、同じコードを不自由なプログラムでも使いたいのです。(#ReleaseUnderGPLAndNF)

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

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

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

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

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

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

不自由なプログラムを開発するために、GNU EmacsのようなGPLの及ぶエディタを使っても良いでしょうか? GCCのようなGPLの及ぶツールを使って自由でないプログラムをコンパイルすることはできますか? (#CanIUseGPLToolsForNF)

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

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

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

GPLの及ぶプログラムのソースコードを「公正使用(fair use)」する権利はありますか? (#GPLFairUse)

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

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

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

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

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

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

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

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

(GPLの)及ぶ作品に対し、静的 vs 動的にリンクされたモジュールについて、GPLには異なる要求がありますか? (#GPLStaticVsDynamic)

いいえ。GPLの及ぶ作品に静的もしくは動的にほかのモジュールとリンクすることは、GPLの及ぶ作品をもとにして結合著作物を作成することです。ですから、全体としての結合には、GNU一般公衆ライセンスの条項が及びます。GPLソフトウェアにGPLと両立しないライブラリを用いた場合、どのような法的問題が発生するでしょうか?もご覧ください。

(LGPLの)及ぶ作品に対し、静的 vs 動的にリンクされたモジュールについて、LGPLには異なる要求がありますか? (#LGPLStaticVsDynamic)

LGPL (現存のどのバージョンでも: v2, v2.1, or v3)に適合する目的では:

(1) LGPLのライブラリに対し静的にリンクする場合、ユーザがライブラリを改変してアプリケーションと再リンクできる機会のために、あなたは、あなたのアプリケーションを、オブジェクト(ソースの必要は必ずしもありません)フォーマットでも提供する必要があります。

(2) ユーザのコンピュータに既に存在するLGPLのライブラリに対し動的にリンクする場合、あなたは、ライブラリのソースを運搬する必要はありません。一方、あなたのアプリケーションと一緒にLGPLのライブラリの実行形式をあなた自身が運搬する場合、それが静的、あるいは動的にリンクされているかによらず、LGPLが提供する方法の一つでライブラリのソースを運搬する必要があります。

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

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

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

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

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

プログラムの出力は、一般的に、プログラムのコードに対する著作権でカバーされません。ですから、プログラムのコードのライセンスはその出力には及びません。ファイルへパイプ出力する、スクリーンショットを取る、スクリーンを放映する、ビデオに撮るにしろ、なんにしろです。

例外は、プログラムがプログラムについてくるテキストや芸術作品のフルスクリーンを表示する場合でしょう。この場合、テキストや芸術作品の著作権が出力に及びます。音楽を出力するビデオゲームのようなプログラムも、この例外にあたるでしょう。

芸術作品/音楽がGPLである場合、どのようにコピーするかに関わらず、コピーした際にGPLは適用されます。しかしながら、フェアユースは、なお、適用されます。

あるプログラムは、特にビデオゲームでは、下に敷かれるGPLedのゲームとは別に芸術作品/音楽がありうるということを、忘れないようにしてください。このケースでは、芸術作品/音楽のライセンスが、動画/ストリーミングが生じる場合の条項を決定するでしょう。GPLをソフトウェア以外のものに使うことはできますか?もご覧ください。

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

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

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

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

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

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

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

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

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

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

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

このようなライブラリとあなたのプログラムをリンクしコンパイルしたプログラムを他人に配布することは可能です。このとき、ランタイムライブラリはGPLv3が定義する、「システム・ライブラリ」です。これは、そのプログラムの「対応するソース」としてその(ライブラリの)ソースコードを含めることについて気にしなくてよいことを意味します。GPLv2は同様の例外を第3節で提供しています。

このようなライブラリをコンパイルされたDLLの形態でそのプログラムとともに配布することはできません。良心的でないディストリビュータが「システムライブラリ例外」を抜け穴として使おうとすることを禁止するために、GPLは、プログラムそれ自身とともに配布されないときに限り、そのライブラリがシステムライブラリとしての資格があると述べています。DLLをプログラムと配布する場合、この例外にはもはやあたりませんので、GPLに適合する唯一の方法は、そのソースコードを提供することですが、これはあなたにできないことです。

Windowsでだけ動く自由なプログラムを書くことは可能ですが、良い考えではありません。これらのプログラムはWindowsの“罠に陥っています”。ですから、自由な世界になにも貢献しません。

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

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

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

GPLv3は同様なことを第10節で述べています。宣伝条項はまさしくそのような、さらなる制限、を規定していて、よってGPLと両立しません。

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

あるプログラムとそのプラグインが単一の結合されたプログラムと考えられるのはどのようなときですか?(#GPLPlugins)

それはプログラムがどのようにプラグインを呼び出すかに依ります。メイン・プログラムがforkやexecでプラグインを呼び出し、複雑なデータ構造を共有することで密接な通信をしたり、複雑なデータ構造をやりとりする場合、単一の結合されたプログラムとなるでしょう。メイン・プログラムが単純なforkやexecを使ってプラグインを呼び出し、密接な通信を確立しないのであれば、プラグインは別のプログラムと言えるでしょう。

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

共有メモリを使い、複雑なデータ構造で通信することは、動的なリンクとほとんど同等です。

GPLの及ぶプログラムで使うためにプラグインをわたしが書いたとして、わたしのプラグインの配布に際して、わたしが使えるライセンスにはどのような要請がありますか? (#GPLAndPlugins)

この質問を、あるプログラムとそのプラグインが単一の結合されたプログラムと考えられるときと、別々の作品と考えられるときを決定するために読んでください。

もしメインプログラムとプラグインが単一の結合されたプログラムの場合、あなたはそのプラグインをGPLかGPLと両立する自由ソフトウェア・ライセンスでライセンスしなければならず、GPLの条項に従ってソースコードとともに配布する必要があります。そのプラグインと分かれているメインプログラムは、そのプラグインになんの要請もしません。

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

この質問を、あるプログラムとそのプラグインが単一の結合されたプログラムと考えられるときと、別々のプログラムと考えられるときを決定するために読んでください。

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

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

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

この質問を、あるプログラムとそのプラグインが単一の結合されたプログラムと考えられるときと、別々のプログラムと考えられるときを決定するために読んでください。

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

しかし、それらが別々の作品であれば、そのプラグインのライセンスは、そのメインプログラムについて、なんの要求もなさないでしょう。

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

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

正確には違います。あなたのプログラムをGPLと両立するライセンスのでリリースしなければならないことを意味します。(より正確には、あなたのリンクする結合における残りのすべてのコードに認められる、ひとつあるいは複数のGPLのバージョンと両立、です)。この結合それ自身は、その場合、それらのGPLのバージョンで利用可能です。

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

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

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

カーネルLinuxとリンクすることを意図した不自由なドライバを配布することはGPLに違反しますか? (#NonfreeDriverKernelLinux)

Linux (GNU/Linux オペレーティング・システムのカーネル)はGNU GPLバージョン2のもとで配布されています。Linuxとリンクすることを意図した不自由なドライバを配布することはGPLに違反しますか?

はい。これは違反です。なぜなら結果としてこれはより大きな組み合わせの作品を作るからです。ユーザがこれらの部品を組み合わせることが期待されるという事実は、実際はなにも関係しません。

コードの重要な部分の著作権を持つLinuxのめいめいの貢献者は、GPLを行使でき、わたしたちは、めいめいが不自由なLinuxのドライバを配布するものに対して行動を起こすことを推奨します。

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

パッケージに含まれるそれぞれのファイルのライセンス表示でそのファイルが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一般公衆ライセンスの条項が適用されます。

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 and provided that you do not modify the ABCDEF interface. 日本語訳: 特別の例外として、ABCの著作権者は、ABCプログラムを、自由ソフトウェア・プログラムもしくはGNU LGPLでリリースされている自由ソフトウェア・ライブラリ、そしてABCとABCDEFインタフェースを通じてのみ通信する独立のモジュールと結合することを許可します。そのようなシステムを、ABCに対するGNU GPLの条項と、そのほかの関係するコードのライセンスに従って、コピーし、配布することができます。ただし、GNU GPLがソースコードの配布を要求する時は、それに従って、そのほかのコードのソースコードを含める必要があります。また、ABCDEFインタフェースを改変していないものとします。

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.If you modify the ABCDEF interface, this exception does not apply to your modified version of ABC, and you must remove this exception when you distribute your modified version. 日本語訳: ABCの改変バージョンを作成する人々はこの特別の例外をかれらの改変バージョンで許す義務はないことに注意ください。そうするかどうかは、はかれらの選択です。GNU一般公衆ライセンスは改変したバージョンを、この例外なしにリリースすることを許可しています。この例外は、また、改変バージョンが、この例外をそのまま持つことも可能としています。ABCDEFインタフェースを改変した場合、この例外はABCの改変したバージョンには適用されず、改変バージョンを配布する際には、この例外を削除しなくてはなりません。

この例外はGNU一般公衆ライセンス、バージョン3 (“GPLv3”)の第7節の追加の許可です。

この例外は、指定したインタフェース(“ABCDEF”)を通じて、異なってライセンスされたモジュールとリンクすることを可能としつつ、ユーザが通常にGPLの場合にそうであるようにソースコードを受けとることを確実にしています。

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

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

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

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

「集積物」とそのほかの種類の「改変されたバージョン」の違いは何ですか? (#MereAggregation)

「集積物」はいくつかの別々のプログラムからなり、それらは同じCD-ROMやそのほかのメディアにいっしょに入れられて配布されます。GPLは集積物を作成し配布することを認めています。たとえ、ほかのソフトウェアが不自由あるいはGPLと両立しないものである場合でもです。ただ一つの条件は、あなたは、それぞれのプログラムの個別のライセンスが許す権限をユーザが行使することを妨げるような、あるライセンスのもとで集積物をリリースすることはできないということです。

二つの別々のプログラムと二つの部分の一つのプログラムを分ける線はどこにあるでしょうか? これは法的な問題であり、最終的には裁判官が決めることです。わたしたちは、適切な基準はコミュニケーションのメカニズム(exec、パイプ、rpc、共有アドレス空間での関数呼び出し、など)とコミュニケーションのセマンティクス(どのような種の情報が相互交換されるか)の両方によると考えています。

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

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

二つのソフトウェアが単一の作品をなすかどうかを決定する際、そのコードが一つあるいはもっと多くのコンテナにあることはなにか影響しますか?(#AggregateContainers)

いいえ、単一の作品か集積物かどうかの分析はコンテナの関与によって変わることはありません。

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

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

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

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

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

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

GPLの修正バージョンを作ることはできますが、実際にはある決まった結果になる傾向があります。

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

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

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

GPLを修正するよりは、むしろGPLバージョン3によって提供されている例外メカニズムを使ってください。

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

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

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

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

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

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

LGPLはJavaにどう働きますか? (#LGPLJava)

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

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

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

わたしのプロプライエタリ・システムに、GPLの及ぶソフトウェアを組み入れたいのです。わたしには、このソフトウェアを使う許可はGPLが与えてくれるもの以外にはなにもありません。わたしはできますか?(#GPLInProprietarySystem)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GCCランタイムライブラリ例外についてもっと知りたいのですが、どこを見ればよいでしょう? (#LibGCCException)

GCCランタイムライブラリ例外はlibgcc, libstdc++, libfortran, libgomp, libdecnumber およびGCCで配布されるほかのライブラリに及びます。この例外は、これらのライブラリの一部がコンパイルのプロセスの一分として実行形式に含まれたとしても、人々がGCCでコンパイルしたプログラムをかれらの選択する条項で配布することを認める意図があります。もっと詳しく知るには、GCCランタイムライブラリ例外についてのFAQをご覧ください。

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

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

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

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

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

プログラム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の及ぶプログラムの改変したバージョンをバイナリ形態のみでリリースできますか? (#ModifiedJustBinary)

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

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

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

バイナリを、対応するソース抜きで物理的媒体で配布したいのですが、FTPでソースコードを提供してもよいでしょうか? (#DistributeWithSourceOnInternet)

バージョン3のGPLでは、これを認めます。詳しくは、オプション6(b)をご覧ください。バージョン2では、ソースをFTPで提供することはたしかに自由ですし、ほとんどのユーザがそこからソースを取得するでしょう。しかしながら、ユーザの誰かがむしろソースを物理的なメディア上で、郵便で取得したい場合、あなたはそれを提供する必要があります。

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

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

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

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

はい。6(d)節がこれを許します。しかし、人々がソースを獲得できるように明確に手順を示す必要があり、オブジェクトコードを配布する限り、ソースが利用可能のままであることを確実にするよう気をつける必要があります。

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

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

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

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

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

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

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

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

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

ネットワークサーバにオブジェクトコードを置いて利用可能とする場合、「対応するソース」を同様にネットワークサーバで提供する必要があります。もっとも簡便な方法は、同じサーバにおいて公開することでしょう、しかし、あなたが望むならば、代わりに別のサーバから、もしくは、バージョン・コントロール・システムであっても、ソースを取得する手順を提供することが可能です。いずれにしても、そのソースは、オブジェクトコードと同じようにアクセスが容易であるべきです。これはGPLv3の第6(d)節に規程されています。

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

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

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

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

GPLは、配布しているバイナリと正確に一致するハッシュ値のものをビルドできるソースコードを提供することを要請しますか? (#MustSourceBuildToMatchExactHashOfBinary)

完全な対応するソースとは、バイナリが作成されたソースを意味します。しかし、これは、ツールが配布しているバイナリと正確に一致するハッシュ値のバイナリを作成できなければならないことを意味するとは限りません。いくつかのケースでは、配布されているバイナリとハッシュ値が正確に一致するバイナリをソースからビルドすることは(ほとんど)不可能でしょう。以下の例を考えてみてください: システムはバイナリにタイムスタンプを入れるかもしれませんし、そのプログラムは異なるコンパイラのバージョン(リリースされてないもののことさえあり得ます)でビルドされているかもしれません。

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

GPLは誰もが改変したバージョンを作成し、他に配布することなく、使うことを許しています。この会社が行っているのはこの特別な場合です。ですから、この会社が改変したソースコードをリリースする必要はありません。改変されたプログラムがGNUアフェロGPLの条項のもとでライセンスされているときには、この状況は異なります。

この状況を、ユーザがこのウェブサイトを訪れた際にユーザに対して別のGPLプログラムが配信されるような状況(よくJavaScriptで書かれますが、ほかの言語も使われます)と比較してみてください。別のGPLプログラムが配信される状況では、配信されるプログラムのソースコードは、ユーザーに対してGPLの条項の元でリリースされる必要があります。

ある会社がGNUアフェロGPLのライセンスのプログラムのの改変バージョンをウェブサイトで動かしています。AGPLは、かれらは改変したソースコードをリリースしなければならないと言ってますか? (#UnreleasedModsAGPL)

GNUアフェロGPLは、改変したバージョンのソフトウェアが、そのソフトウェアとコンピュータネットワークを通じてやりとりするすべてのユーザに対して、ソースを受け取る機会を提供することを要請します。その会社が行っていることはこの意味で考えられますから、その会社は改変したソースコードをリリースしなければなりません。

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

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

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

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

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

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

ある会社がほかの開発者のGPLが及ぶ作品のコピーをわたしに対してトレード・シークレットとして配布したらどうですか?　(#TradeSecretRelease)

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

ある会社が自身のGPLが及ぶ作品のコピーをわたしに対してトレード・シークレットとして配布したらどうですか? (#TradeSecretRelease2)

その配布されたプログラムがほかの誰かのGPLの及ぶ作品を組み込んでいない場合、その会社はGPLに違反してはいません(詳しくはGPLの及ぶプログラムの開発者はGPLによって束縛されますか?をごらんください)。しかし、それは、あなたがそのプログラムについて何ができるかについて、ふたつの矛盾する言明をしています。一方では再配布できると言い、一方ではできないと言うのです。コピーを受領する前に、そのプログラムの利用に関する条項について説明を求めることが妥当でしょう。

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

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

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

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

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

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

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

それぞれのプログラムに間接的ポインタがないと、数多くの著作権者と変更について長々と議論せざるを得なくなるかも知れず、また事実上これは不可能でしょう。実際には、GNUソフトウェアが一様な配布条件を持つ可能性はゼロとなってしまうでしょう。

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

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

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

あるプログラムが最新バージョンのGNU GPLでだけ使えると述べるライセンスを使うことはよい考えでしょうか? (#OnlyLatestVersion)

こうすべきでない理由は、ユーザが以前に有していたある許可をいつの日か、自動的に取り下げる結果になりうるからです。

あるプログラムが2000年に「最新のGPLバージョン」でリリースされたとしましょう。その時点ではGPLv2で使うことができました。2007年にGPLv3が発行された日、すべての人が突然にそれを代わりにGPLv3で使うことを強いられるかもしれないのです。

あるユーザはGPLバージョン3について知らないかもしれませんが、それを使うことを要求されてしまうかもしれません。ニュースを知らなかったために、意図せずにプログラムのライセンスに違反してしまうこともありえます。それは人々に対するのによい方法ではありません。

違反した際は例外ですが、すでに与えられた許可を取り下げるのは間違いだとわたしたちは考えます。もし、自由が取り消されうる場合、それは本当の自由ではありません。ですから、あるバージョンのライセンスであるプログラムのバージョンのコピーを入手した場合、いつもそのバージョンのライセンスで与えられた権限をあなたは有するべきなのです。「GPLバージョンNあるいはそれ以降のバージョン」でリリースするのはこの原則に従っています。

どうしてマニュアルにはGPLを使わないのですか? (#WhyNotGPLForManuals)

マニュアルにGPLを適用することは可能ですが、マニュアル向けにはGNU自由文書ライセンス(GFDL)のほうがはるかに優れています。

GPLはプログラムのために設計され、プログラムにとって重要なたくさんの複雑な条項があります。これは、煩雑で本やマニュアルには必要ないものでしょう。たとえば、(もしGPLを適用すると)紙の本を出版する誰もが、本の印刷されたコピー毎に、機械可読の「ソースコード」を含めるか、「ソースコード」を後日送る書面での申し出を提供しなければならないことになります。

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

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

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

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

フォントのライセンシングは複雑な問題で真剣な考察が必要です。以下のライセンス例外は実験的ですが、一般の利用に承認されています。これに関する提案を歓迎します。こちらの説明を読み、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一般公衆ライセンスが文書に及ぶ、その他の理由を無効とはしません。このフォントを改変したとき、あなたはこの例外をあなたのバージョンのフォントにも拡張できますが、その義務はありません。そうしたくない場合は、この例外の文をあなたのバージョンから削ってください。

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

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

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

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

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

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

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

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

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

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の及ぶプログラムを実行することは可能でしょうか? (#InterpreterIncompat)

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

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

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

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

GPLを行使する力があるのは誰ですか? (#WhoHasThePower)

GPLは著作権のライセンスですから、GPLを行使する力を持つのはソフトウェアの著作権者です。GPLに違反した事例を発見した場合、あなたは関係するGPLの及ぶソフトウェアの開発者たちに知らせるべきです。かれらは自身著作権者であるか、著作権者とつながりがあるでしょう。GPL違反の報告に関してもっと知る。

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

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

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

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

一部のライブラリはGNU GPLのみのもとでリリースされていますので、そういったライブラリを使いたいならばあなたはGPLと両立するライセンスを自分のソフトウェアに適用しなければなりません。しかし通常そういったライブラリはより特別なライブラリであり、ほかのプラットフォームでそのようなものはあまりないようなものですから、単なるポーティングでそういったライブラリを利用しようと思うことはまずないでしょう。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GPLソフトウェアのあるディストリビュータが、かれらのEULAのもとで、もしくはかれらのダウンロードの手順の一部として、わたしに対して、合衆国にいること、あるいは、そのソフトウェアを関係する輸出規制の法律に従って配布することを意図している、と「表明し保証する」と要求します。なぜ、かれらはこうするのでしょうか、そしてこれはディストリビュータのGPLの義務に対する違反ではないでしょうか? (#ExportWarranties)

これはGPL違反ではありません。このディストリビュータ(自由ソフトウェアのディストリビューションと関連サービスを販売する商用ビジネスのほとんどがそうですが)は、かれら自身の法的リスクを減らそうと試みているのです、あなたの行動をコントロールしようとしているわけではありません。合衆国の輸出規制は、かれらが知りながらソフトウェアをある国に輸出した場合、もしくはそのような輸出をすると知っている団体にソフトウェアを与えた場合、かれらが責任を問われるかもしれないとしています。顧客やソフトウェアを配布する対象のほかの人にこういった文章を尋ねることで、かれらは規制当局に後日、かれらが配布したソフトウェアがどこに行き着いたか知っていることを問われる機会において、かれら自身を守っているのです。これは、ソフトウェアでできることを制限しておらず、あなたが行う何かに関してかれらが非難されないよう防御するに過ぎません。ソフトウェアに追加の制限を置くものではないので、GPLv3の第10節あるいはGPLv2の第6節には違反しません。

FSFは自由ソフトウェアについて、合衆国輸出規制法の適用に反対します。このような法律がソフトウェアの自由の一般的目的と両立しないというだけでなく、それが意味のある政府の目的を何も達成しないからです。なぜなら、自由ソフトウェアは、ほとんどすべての国の団体から(輸出規制がなにもなく、合衆国の主導する通商停止に参加しない国々を含めて)現在において利用可能であり、そしていつでもそうであるべき、だからです。ですから、合衆国輸出規制法によって、どの政府も実際のところ自由ソフトウェアを奪われることはなく、かれらの政府の政策がどうあっても、わたしたちに関する限り、どの国の市民も自由ソフトウェアを奪われるべきではありません。FSFによって公開されたGPLでライセンスされたソフトウェアのすべての複製は、あなたがどこにすんでいるかまたはあなたがどうするつもりかを示すことなく、わたしたちから入手することができます。同時に、FSFは合衆国に位置する商用ディストリビュータの、合衆国法を守りたいという願いも理解します。かれらは自由ソフトウェアの特定のコピーを誰に配布したいか選択する権利があります。この権利の行使は、GPLで許されたものを越えて契約上の制限を加えない限り、GPLに違反しません。

顧客がサブスクリプション・フィーを支払うことを継続しない場合、動作しなくなるデバイスにGPLのソフトウェアを使えますか? (#SubscriptionFee)

いいえ。このシナリオでは、料金を支払うことを継続するという要求がユーザがプログラムを実行する能力を制限します。これはGPLの上への追加の要求でライセンスはこれを禁止しています。

(L)GPLv2から(L)GPLv3にどのようにしてアップグレードできますか? (#v3HowToUpgrade)

第一に、新しいライセンスをあなたのパッケージに含めます。もし、LGPLv3をあなたのプロジェクトに使う場合、GPLv3とLGPLv3の両方のコピーを含めることを確実にしてください。これは、今、LGPLv3はGPLv3の上に一組の追加の許可をする形で書かれているからです。

次に、現在のv2のライセンス表示(通常、それぞれのファイルの一番上)を、GNUライセンスHOWTOで利用可能な新しい推奨の文章に置き換えます。これは、より将来にわたり安心なものとなっています。なぜなら、FSFの郵便の住所がもはや含まれないからです。

もちろん、パッケージのライセンスについて述べる(READMEのような)説明文章も対応して更新するべきです。

どのようにGPLv3はBitTorrentでの配布を容易にしていますか? (#BitTorrent)

GPLv2はP2Pのソフトウェア配布が普通になる以前に書かれたので、このような方法でコードを共有するときにその要求を満たすことは難しくなっています。BitTorrentでGPLv2のオブジェクト・コードを配布するときに適合するのに確実な最適の方法は、同じtorrentにすべての対応するソースを含めることでしょう。これは手が出ないほど高価なものですが。

GPLv3はこの問題を二つの方法で扱っています。第一に、このtorrentをダウンロードしそのプロセスの一部としてデータをほかの人に送る人々は、なにも要求されません。なぜならば、第9節が「単にコピーを受け取るためにP2P転送を用いる結果として起こる、(GPLv3の及ぶ)作品の付属的な伝播は同様に[ライセンスの]同意を必要としません」と述べているからです。

第二に、GPLv3の第6(e)節はディストリビュータ(最初にtorrentを始める人)にソースを提供する明確で簡単な方法を与えています。それは、受け取った人にどこの公開のネットワークサーバにそれ(ソース)があるかを伝えるということです。これは、ソースを受け取りたいすべての人がそうできることを確実にし、ディストリビュータをほとんど何も悩ますこともないでしょう。

Tivoizationとはなんですか? GPLv3はどうやってこれを防止しますか? (#Tivoization)

あるデバイスは自由ソフトウェアを使い、アップグレードが可能です。しかし、そのソフトウェアをユーザが改変することを認めないように設計されています。こうするにはたくさんの異なる方法があります。たとえば、インストールされるソフトウェアに対しハードウェアがチェックサムを確認して、署名が期待されたものと一致しない場合、シャットダウンするのです。ソースコードを与えることによって製造業者はGPLv2に適合しますが、使っているソフトウェアを改変する自由はありません。わたしたちはこの慣習をTivoizationと呼びます。

GPLv3のプログラムを含むUser Productを人々が配布する時、第6節により、ソフトウェアを改変するのに必要な情報を提供する必要があります。User Productはこのライセンスで特に定義された用語です。User Productの例には、ポータブル音楽プレーヤ、ディジタル・ビデオ・レコーダやホームセキュリティ・システムを含みます。

GPLv3はDRMを禁止しますか? (#DRMProhibited)

禁止しません。GPLv3でリリースされたコードを使って、あなたの望むあらゆる種類のDRM技術を開発することが可能です。しかし、こうする場合、第3節は、そのシステムは効果的な技術的「保護」手段とはみなされないことになる、と述べています。これは、だれかがDRMを破った場合、その人はかれのソフトウェアを配布することが自由にでき、DMCAや同様な法律によって妨げられることはないということです。

いつもどおり、GNU GPLはソフトウェアで人々が何をするか制限をせず、(ソフトウェアが)ほかの人を制限することを禁止するだけです。

GPLをハードウェアをライセンスするのに使うことはできますか? (#GPLHardware)

著作権を設定できる何に対してでも、GPLでライセンスすることができます。GPLv3は、また、半導体のマスクのような、著作権のようなほかの法律の及ぶものをライセンスするのにも使うことができます。ですから、例として、物理的なオブジェクトの製図や回路をGPLでリリースすることが可能です。

製図から物理的なハードウェアを作成することについて、ほとんどの状況で、著作権はおよびません。このような状況では、製図のライセンスは、どのようなライセンスを使ったとしても、物理的なハードウェアを作成したり販売することについて、なんのコントロールも働かせることはできません。ハードウェアを作成するのに著作権が及ぶ場合、たとえばICマスクの場合、GPLは有用な形でそのケースを取り扱うでしょう。

出所の正しさを証明できるよう、公開鍵暗号を使って、わたしのコードに署名します。わたしが秘密鍵をリリースするようGPLv3が強制するというのは本当ですか? (#GiveUpKeys)

いいえ。署名鍵をリリースする必要があるかもしれないただ一つのケースは、GPLのソフトウェアをUser Productの中に運搬し、そのハードウェアが、そのソフトウェアを動作させる前に有効な暗号署名を確認する場合です。この特定のケースでは、そのデバイスを所有する誰もに対して、要求があれば、署名し、そのデバイスに改変したソフトウェアをインストールし実行できるよう、鍵を提供する必要があるでしょう。デバイスの個々が異なる鍵を使っている場合、それぞれの購入者には、そのデバイスの鍵だけを与える必要があります。

GPLv3は投票者が投票マシンで動いているソフトウェアを改変することを要請しますか? (#v3VotingMachine)

いいえ。最大限、GPLのソフトウェアを含むデバイスを配布する会社が、オブジェクトコードのコピーを持つ人々に対し、そのソフトウェアのソースと「インストール情報」を提供することが要請されます。(ほかのどのようなキオスク端末も同様に)投票マシンを使う投票者は一時的にも、それを所有しませんから、投票者はその中のバイナリを所有もしないでしょう。

しかし、投票はとても特別な場合です。コンピュータのなかのソフトウェアが自由であるといって、あなたが投票のコンピュータを信用できるとは言えません。投票のためにコンピュータを信頼することはできない、とわたしたちは考えます。投票は紙で行われるべきです。

GPLv3には「特許報復条項」がありますか? (#v3PatentRetaliation)

効果としては、はい、あります。第10項がそのソフトウェアを運搬する人々がそのほかのライセンスに対し、特許訴訟を起こすことを禁止しています。それでも誰かが訴訟を起こした場合、第8項で、かれらがそのライセンスとそれに付随する特許のライセンスをどのように失うかを説明しています。

GPLの及ぶソースコードの一部をGPLとは両立しないあるライセンスの文書の中で使うことはできるでしょうか? (#SourceCodeInDocumentation)

フェアユースもしくは同様な法律のもとでそれを含めることができるほどそのコードの一部が小さいならば、イエス、です。そうでなければ、ノー、です。

GPLv3の第6節の始めでは、「第4節と第5節の条項により」オプジェクト・コードの形態で(GPLv3の及ぶ)作品を運搬できる(第6節の条件を満たす限り)としています。これはどういう意味でしょうか? (#v3Under4and5)

これはソースコードを運搬するためのすべての許可と条件がオブジェクト・コードを運搬する時にも適用されるということを意味します。料金を課すこともできますし、著作権表示をそのまま損なわずに保持しなければならない、などです。

わたしの会社はたくさんの特許を所有しています。“GPL version 2 or any later version”の(複数の)プロジェクトに対し、数年に渡り、わたしたちはコードを貢献してきました。そして、あるプロジェクトも同一の条項で配布されてきました。あるユーザがそのプロジェクトのコードを(わたしの貢献を含めて)、GPLv3で扱うと決めたとき、わたしがGPLv3の明示特許ライセンスをそのユーザに自動的に与えることを意味しますか? (#v2OrLaterPatentLicense)

いいえ。GPLとされたソフトウェアを運搬するとき、ある特定のバージョンのライセンスの条項に従う必要があります。そうしたとき、そのバージョンがあなたが従うべき義務を定義します。ユーザはより新しいバージョンのGPLを使うことを選ぶこともできますが、その場合、かれらに単に追加の許可をもたらすのみです。あなたが、ユーザと同じのより新しいバージョンのGPLの条項を守ることを要求するのではありません。

あなたの特許によってコミュニティを脅かすことができる、とこれを受け取らないでください。多くの国で、GPLv2でソフトウェアを配布することは、受け取った人にGPLのもとでその権利を行使する暗黙の特許ライセンスが与えられることを意味します。そうでなかったとしても、攻撃的に特許を行使することを考える誰もがコミュニティの敵であり、そのような攻撃に対しては、わたしたちは自分自身を守るでしょう。

LGPLv3の及ぶわたしが改変したライブラリとリンクしたプロプライエタリのプログラムをわたしが配布した場合、わたしが明示された特許のライセンスの許可を与える範囲を決定するための「貢献者のバージョン」とはなんでしょうか? ライブラリだけですか、それとも全体の組み合わせですか? (#LGPLv3ContributorVersion)

「貢献者のバージョン」とはあなたのバージョンのライブラリだけです。

GPLv3はGPLv2と両立しますか? (#v2v3Compatibility)

いいえ。GPLv2からGPLv3で多くの要求が変更されました。これは、GPLv2の正確な要求はGPLv3に存在しないこと(その逆も)を意味します。たとえば、GPLv3の停止条件はGPLv2のものよりもだいぶ許容的ですから、GPLv2の停止条件とは異なります。

こういった差異のため、この二つのライセンスは両立しません: GPLv2でリリースされたコードとGPLv3でリリースされたコードを結合しようとすると、GPLv2の第6項に違反することになるでしょう。

しかし、コードがGPL “version 2 or later,” でリリースされていれば、それはGPLv3と両立します。なぜならGPLv3はそれが許す選択肢の一つだからです。

GPLv2はインストール情報の配布について要求がありますか? (#InstInfo)

GPLv3は明示的に必要な「インストール情報」のすべてを含むことを再配布に要求します。GPLv2はこの用語を用いていませんが、再配布にコンパイルと実行形式のインストールに用いたスクリプトを含めることを要求しています。これはGPLv3が「インストール情報」と呼ぶものの一部(すべてではない)をカバーします。ですからGPLv3の要求はインストール情報についてより強いと言えます。

GPLv3違反を「解決する」とはどういう意味ですか? (#Cure)

違反を解決するという意味は、ライセンスの要請に適合するよう、あなたの慣習を修正するということです。

GPLv3の保証と責任の否認は合衆国の法律に特定のものだと思われます。わたしのコードにわたし独自の否認を加えてもよいですか? (#v3InternationalDisclaimers)

はい。第7節はあなた独自の否認を加える許可を与えています。

わたしのプログラムは視覚的ではない性質のインタラクティブなユーザ・インタフェースを有します。GPLv3の「適切な法律上の告知」(Appropriate Legal Notices)の要請をどのようにして満たせばよいでしょうか?(#NonvisualLegalNotices)

あなたが必要なことのすべては、あなたのインタフェースで、ユーザに対し、「適切な法律上の告知」が容易に利用可能となることを確実にすることです。たとえば、音声インタフェースを書いた場合、告知を音読するコマンドを含むことができるでしょう。

GPLv3の及ぶプログラムのコピーを会社の同僚にあげた場合、そのコピーをその人に「運搬」したことになりますか? (#v3CoworkerConveying)

あなたたち双方が個人としてではなくその会社の仕事でソフトウェアを使っている限り、答えは、いいえ、です。そのコピーは会社に属し、あなたや同僚には属しません。このコピーは伝播であり、運搬ではありません。なぜならその会社はそのほかへと利用可能になるようにコピーを作成してないからです。

GPLv3が及ぶプログラムを配布した場合、ユーザがそのプログラムを改変したら無効となるような保証を提供することはできますか? (#v3ConditionalWarranty)

はい。ユーザが内部のソフトウェアを改変したら保証する必要がないデバイスと同様に、GPLv3が及ぶソフトウェアに誰かが行いうるすべての活動に対して保証を提供する必要はありません。

なぜGNUアフェロGPLv3を別のライセンスとして書くことを決めたのですか? (#SeparateAffero)

GPLv3の早い段階のドラフトでは、ライセンサがソースを公開するためにアフェロのような要求を第7節に加えることを認めていました。しかし、自由ソフトウェアを開発し、それに依存しているいくつかの会社がその要求はかなり厳しいと考えました。かれらは、この要求のあるコードを避けたいとし、この追加の要求があるかどうかコードを確認する管理上のコストに関する懸念を表明しました。GNUアフェロGPLv3を別のライセンスとして公開することで、その規程とGPLv3で、それらのライセンスのコードが、それぞれとリンクできることを認め、わたしたちの初期の目的のすべてを達成し、かつ、ソース公開の要求があるのはどのコードかを決めるのを簡単にしたのです。

GPLv3で “propagate” (伝播)と “convey” (運搬)という新しい用語を創出したのはなぜですか? (#WhyPropagateAndConvey)

GPLv2で使われていた “distribute” (配布)という用語は合衆国の著作権法から借りてきたものです。ある管轄の著作権法では、これと同じ言葉が使われていますが、違う意味を持つことがあることを、わたしたちは数年に渡り知りました。わたしたちはこれらの新しい用語を創出し、どこでライセンスが解釈されても問題ないようにできる限りわたしたちの意図を明確としました。この用語は世界のどの著作権法でも使われておらず、わたしたちはこのライセンスで直接その定義を与えています。

わたしのコードをGPLでライセンスしたいと思いますが、軍事利用や商用利用をさせないようにはっきりしたいと考えています。これは可能ですか? (#NoMilitary)

いいえ、その二つの目的は互いに矛盾しますから。GNU GPLは、さらなる制限を加えることを妨げるよう特に設計されています。GPLv3は、第7節で、とても限定された制限の追加を認めていますが、そのほかのあらゆる加えられた制限はユーザによって削除されることが可能です。

より一般的には、誰が、もしくは、何のためにプログラムを使えるかについて制限するライセンスは自由ソフトウェア・ライセンスではありません。

GPLv3での“convey” (運搬)はGPLv2が “distribute” (配布)によって意味しているものと同じものですか? (#ConveyVsDistribute)

はい、多かれ少なかれ。GPLv2の強制の過程において、ある管轄が違った意味で“distribute”をその独自の著作権法で使っていることを知りました。新しい用語を創出し、わたしたちの意図を明確にし、こうした差異によって生ずるであろう問題を避けています。

GPLv3は伝播の例として「一般公衆に利用可能とする」をあげています。これは何を意味しますか? 利用可能とすることは運搬の一形態ではありませんか? (#v3MakingAvailable)

「一般公衆に利用可能とする」一つの例は、ソフトウェアを一般向けのwebやFTPサーバに置くことです。置いた後に、誰もそのソフトウェアを実際に入手しない前に、ある時間が経過することがありえます。しかし、「一般公衆に利用可能とする」ということは(置いた)その時点で起きることで、GPLの義務にその時点で従う必要があります。ですから、わたしたちは運搬にこの活動を含むと定義しました。

GPLv3で、配布と一般公衆に利用可能とすることは伝播の一形態であり、運搬でもあります。運搬ではない、伝播の例はなんでしょうか? (#PropagationNotConveying)

自分のためにソフトウェアのコピーを作成することは、運搬ではない伝播の主な形態です。複数のコンピュータにそのソフトウェアをインストールしたり、バックアップを作成することがこれにあたります。

GPLバイナリをパフォーマンスの最適化のためにシステムのさまざまなライブラリとプリリンクすることは改変にあたるでしょうか? (#Prelinking)

いいえ。プリリンクはコンパイルのプロセスの一部です。ほかのコンパイルの様相がもたらすそれ以上の要請をこれがもたらすことはありません。もし、あるライブラリをあるプログラムとリンクすることが許されているならば、プリリンクも同様によいでしょう。もし、プレリンクされたオブジェクトコードを配布する場合、第6節の条項にしたがう必要があります。

誰かがGPLのソフトウェアをラップトップにインストールし、そのソフトウェアのソースコードを提供することなくそのラップトップをある友達に貸した場合、かれらはGPLに違反したでしょうか? (#LaptopLoan)

いいえ。この問題を調査した管轄において、この種の貸出は運搬にあたらないでしょう。ラップトップの所有者はGPLのなんの義務も負わないと考えられます。

二つの会社が「インストール情報」(Installation Information)を提供することの要請を回避するべく、一方の会社が署名付きソフトウェアをリリースし、もう一方が、第一の会社の署名付きソフトウェアでだけ実行できる「ユーザ製品」(User Product)をリリースしたとしましょう。これはGPLv3違反でしょうか? (#TwoPartyTivoization)

はい。もし、二つの団体がGPLの要請を回避しようと結託しようとする場合、両方が著作権侵害として追及されることがありえます。誰かが二次的侵害に関して責任を問われる活動について、明確に運搬の定義に含まれますので、これは特に正しいと言えます。

もし、わたしがFTPサーバでバイナリを提供し、ソースは、CVSやSubversionのようなバージョン・コントロール・システムのソースコード・リポジトリへのリンクによって提供した場合、わたしはGPLv3を遵守しているでしょうか? (#SourceInCVS)

ソースのチェックアウトのプロセスが苦痛になったり制限となったりしない限り、これは容認されます。オブジェクトコードをダウンロードできる誰もが、一般に利用可能な自由ソフトウェアのクライアントを用いて、ソースをバージョン・コントロール・システムからチェックアウトすることができるべきです。ユーザはダウンロードしたそのオブジェクトコードにまさに対応したソースを得るやり方を、明確で簡便な手順で提供されるべきです。最新の開発コードをユーザが欲しがるとは必ずしも限りません。

>GPLv3の及ぶソフトウェアをUser Productの中で運搬したある人が、あるユーザがそのソフトウェアを改変できないように外部の検証機関を使うことはできますか? (#RemoteAttestation)

いいえ。ソフトウェアをUser Productの中に運搬する際にソースとともに提供しなければならないInstallation Informationの定義では、明示的にこう述べています: 「改変されたオブジェクトコードが単に改変されたということだけで継続して動作することが禁止されたり妨げられたりすることが決してないよう、十分な情報でなければなりません。」 もしそのデバイスが外部の検証機関を何らかの形で使う場合、Installation Informationは変更したソフトウェアが正当であると報告する方法を提供しなければなりません。

GPLv3で「ネットワークの通信の規約とプロトコル」とは何を意味しますか? (#RulesProtocols)

これは、ネットワーク上であなたが送ることができる通信量についての規約を指します。たとえば、サーバに送る要求の数に制限がある場合や、どこかにアップロードできるファイルのサイズに制限がある場合、あなたがそういった制限を守らない場合、それらの資源へのあなたのアクセスは、拒否されてしまうかもしれません。

これらの規約にはネットワークを行き来するデータに関して直接関係しないものをなにも含みません。たとえば、ネットワークのサーバがユーザのためのメッセージをあなたのデバイスに送る場合、あなたのネットワークへのアクセスがあなたがソフトウェアを改変したというだけを理由として拒否され、そのメッセージが表示されないということがあってはなりません。

GPLv3のもとでInstallation Informationを提供するデストリビュータは、製品の「サポートサービス」を提供する必要はないとされています。どのような種類の「サポートサービス」を意味していますか? (#SupportService)

これには、多くのデバイスの製造者が提供するような、製品のインストール、利用、問題解決を手助けするサービスの種類を含みます。もし、デバイスが適切に機能するためにウェブサービスや同様の技術に依存している場合、ネットワークに対するアクセスに関する第6節の条項により、それは、通常は改変されたバージョンに対してであっても利用可能であるべきです。

GPLv3とAGPLv3で「このライセンスのいかなるほかの規定にもかかわらず」というとき、それはどういう意味ですか? (#v3Notwithstanding)

これは単純にこれらと衝突する可能性があるライセンスの中の他の何にでも対し、続く条項が優先することを意味しています。たとえば、この文がなければ、あなたはAGPLv3のコードとGPLv3のコードを組み合わせることができないと、ある人々が主張するかもしれません。なぜならAGPLの追加の要求はGPLv3の第7節の「さらなる制限」に該当するかもしれないからです。この文は、わたしたちの意図する解釈が正しいものであることを明確にし、あなたは、この組み合わせを作成することができます。

この文はライセンスの異なる条項の間の衝突を解決するだけです。二つの条件に衝突がないとき、両方の条件を満たす必要があります。これらのパラグラフはライセンスの残りの部分を無視する白紙委任をあなたに与えているのではありません。そうではなく、とても限定的な例外を取り除いているのです。

AGPLv3でProgramを第13節に従って変更した場合、提供しなければならない対応するソースは何でしょうか? (#AGPLv3CorrespondingSource)

「対応するソース」はライセンスの第1節で定義され、それらであげられているものを提供するべきです。改変したバージョンが、ExpatライセンスやGPLv3など、別のライセンスのライブラリに依存する場合、対応するソースはそれらのライブラリを含みます(それらがシステムライブラリでない限り)。それらのライブラリを改変してある場合、それらに対しての改変したソースコードを提供する必要があります。

第13節の最初のパラグラフの最後の文は、ほとんどの人々が自然に仮定していることを強めているだけの意味です。GPLv3のコードとの組み合わせは第13節の特別な例外を通じて扱われますが、それでも対応するソースには、「プログラム」とこの方法で組み合わせたものを含めるべきです。この文は、GPLv3の及ぶソースを提供する必要があるだけを意味しているのではなく、そのようなコードは対応するソースの定義から除外されないと意味しているのです。

AGPLv3で「コンピュータネットワークを介して[ソフトウェアと]遠隔からやりとりする」にあたるのはなんでしょうか? (#AGPLv3InteractingRemotely)

そのプログラムが、ネットワークを通じてユーザの要求を受け取り、応答を返すように明白に設計されている場合、この範疇に入ります。このカテゴリに入るプログラムのよくある例には、Webやメールサーバ、インタラクティブなwebベースのアプリケーション、そしてオンラインで遊ぶゲームのサーバがあるでしょう。

ネットワークを通じてユーザとやりとりするようにプログラムが明白に設計されてはいないがたまたまそのような場所で、そのような環境で実行されている場合、このカテゴリには入りません。たとえば、そのユーザがSSHや遠隔Xセッションを通じて実行しているからといって、それだけであるアプリケーションはソースを提供する必要がある、とはなりません。

GPLv3の“you”のコンセプトはApacheライセンス2.0における“Legal Entity”の定義と比較してどうでしょうか? (#ApacheLegalEntity)

実効的にはそれらは同一です。Apacheライセンス2.0における“Legal Entity”の定義は、さまざまな種類の法律上の契約のとても標準的なものです。それはとても標準的で、法廷において、その用語が明示された定義がない場合と同様に解釈されないことがあったら驚きのほかない、というようなものです。GPLv3をみて、ライセンスされる人を考えた場合、同じように扱われることを全面的にわたしたちは期待します。

GPLv3で「プログラム」“the Program” はなにを指しますか? GPLv3でリリースされたすべてのプログラムですか? (#v3TheProgram)

「プログラム」という用語は、GPLv3でライセンスされるひとつの特定の作品を意味し、ある上流のライセンスする者あるいは配布者から、特定のライセンスされる者によって、受領されたものです。「プログラム」は特定のソフトウェアの作品で、あなたが受領したとき、GPLv3のライセンシングの実例として受領したものです。

「プログラム」が「GPLv3でリリースされたすべてのプログラム」を意味することはできません。その解釈はいくつもの理由で意味を持ちません。わたしたちは「プログラム」“the Program”の用語の解析を載せていますので、もっと知りたい方はそれをご覧ください。

GPLの及ぶプログラムの複製を作成し、ほかの人に配布したり運搬せずに、実行させただけの場合、ライセンスが要求することはなんでしょうか? (#NoDistributionRequirements)

なにもありません。GPLはその活動になんの条件も置いていません。

あるネットワーク・クライアントのソフトウェアがAGPLv3でリリースされた場合、やりとりするサーバにソースコードを提供できるようにしなければなりませんか? (#AGPLv3ServerAsUser)

AGPLv3は「コンピュータネットワークを通じて遠隔でそれとやりとりするすべてのユーザ」に対し、あるプログラムがソースコードを提供することを要求します。そのプログラムを「クライアント」もしくは「サーバ」と呼ぶかどうかは関係しません。問うべき問題は、ある人がネットワークを通じて遠隔でそのプログラムでやりとりするかどうかです。

プロキシサーバを実行するソフトウェアがAGPLでライセンスされているとします。そのコードとやりとりするユーザに、どのようにソースの申し出を提供できるでしょうか?(#AGPLProxy)

プロキシサーバ上のソフトウェアについては、そういった種類のユーザにメッセージを送る通常の方法を通じてソースの申し出を提供することが可能です。たとえば、ウェブプロキシは、起動のページを使えます。ユーザがプロキシの利用を最初に開始したとき、ユーザをそのページに向かわせて、提供しようと決めた情報とともにソースの申し出を説明することができます。

AGPLは「すべてのユーザ」に申し出を行わなければならない、と言っています。あるユーザが申し出を既に見せられていることを知っているならば、現行のバージョンのそのソフトウェアについて、そのユーザに再度繰り返す必要はありません。

さまざまなGNUライセンスはどのようにして互いに両立しますか? (#AllCompatibility)

さまざまなGNUライセンスが互いに広い両立性を持ちます。二つのこれらのライセンスのコードを組み合わせることができないただ一つの場合は、古いバージョンのあるライセンスだけのコードと新しいバージョンの(ライセンスの)コードを使いたいときだけです。

下記に示すのがGNUライセンスのさまざまな組み合わせの詳細な両立性のマトリックスで、特定の場合について使いやすい参照を提供します。これは、ある人があるソフトウェアをこれらのライセンスの一つのもとで書き、そのコードを、あなたがリリースしようとしている、あるプロジェクト(あなたのオリジナル作品あるいは別の誰かのソフトウェアの改変バージョン)に、どうにか取り込みたいという場合を仮定しています。表の一番上の列で、あなたのプロジェクトのためのライセンスを見つけ、行の左でその他のコードのライセンスを見つけてください。行と列で指定されるセルが、組み合わせが許されるかどうかを示します。

「コードをコピーする」とわたしたちがいうとき、それはあるソースから、ある部分を、改変ありまたはなしで、取り出し、あなた自身のプログラムに挿入し、この部分をもとにした作品を形成する、ことを意味します。「ライブラリを使用する」とは、ソースを直接にはなにもコピーせず、リンク、インポート、もしくはコンパイルして実行する際のソースを組み合わせるそのほかの典型的なメカニズムでやりとりする、ことを意味します。

このマトリックスでGPLv3と述べてある場所では、AGPLv3に対する両立性のステートメントが真となります。

両立性のマトリックスをスキップする

脚注をスキップする

1: コードを組み合わせるこの場合は、GPLv2の条項に従う必要があります。GPLの以降のバージョンの条項の利点を使うことはできません。

2: この場合、あなたのオリジナルの作品そして/あるいはあなたがGPLv2-or-laterで受け取り改変した作品、その両方をGPLv2-or-laterでリリースすることは可能ですが、あなたの使っているGPLv2だけのコードはGPLv2だけのままでなければならないことに注意ください。あなたのプロジェクトがそのコードに依存する限り、あなたのプロジェクトのライセンスをGPLv3-or-laterにすることはできず、全体としての作品(あなたのプロジェクトとそのほかのコードの両方のいかなる組み合わせも)はGPLv2の条項のもと運搬されることだけができます。

3: GPLv2もしくは以降のどのバージョンのもとでプロジェクトをリリースする能力がある場合、GPLv3もしくは以降のどのバージョンでも選択してリリースすることができます。そして一旦そうしたら、あなたはそのGPLv3でリリースされたコードを取り込むことができます。

4: LGPLv2.1もしくは以降のどのバージョンのもとでプロジェクトをリリースする能力がある場合、LGPLv3もしくは以降のどのバージョンでも選択してリリースすることができます。そして一旦そうしたら、あなたはそのLGPLv3でリリースされたコードを取り込むことができます。

5: この場合、コードを取り込むときLGPLv2.1の条項に従う必要があります。LGPLの以降のバージョンの条項の利点を使うことはできません。

6: こうする場合、プロジェクトがLGPLv2.1だけのコードを含む限り、プロジェクトのライセンスをLGPLv3以降にアップグレードすることはできません。

7: LGPLv2.1はコードをGPLv2以降のどのバージョンにでもリライセンスするすることを認めています。この場合のLGPLのコードを代わりに適当なバージョンのGPLを使うと変更すれば(このテーブルで示されているとおり)、この組み合わせを作成することができます。

8: LGPLv3はGPLv3に別の許可が加わったものですが、その許可についてはこのケースでは無視できます。

9: GPLv2はLGPLv3との組み合わせを許さないので、この場合、プロジェクトをGPLv3の条項で運搬する必要があります。GPLv3はその組み合わせを許します。