hotchpotch/wikipedia-multilingual-ir-pairs huggingface dataset:
ジャン・ルノワール 来歴
1894年9月15日、パリのモンマルトルに父・ピエール＝オーギュスト・ルノワールと母・アリーヌの次男として生まれる。幼いころに南フランスに移住し、父の絵のモデルを務めさせられていた。各地の学校を転々とし、ニースの大学で数学と哲学を学ぶ。第一次世界大戦には騎兵少尉として参戦し、後に偵察飛行隊のパイロットを務めたが、偵察中に片足を銃撃され、終生まで傷の痛みに悩まされていた。その療養中にD・W・グリフィスやチャールズ・チャップリンらの作品を観て、映画に興味を持つ。1920年、前年に亡くなった父の絵のモデルをしていたカトリーヌ・エスランと結婚。大戦終結後は陶器を作っていたが、イワン・モジューヒンの『火花する恋』やエリッヒ・フォン・シュトロハイムの『愚なる妻』などの影響を受けて、映画監督を志す。
ジャン・ルノワール 来歴
1924年、カトリーヌ主演の映画『カトリーヌ』に出資し、脚本を執筆する。同年にカトリーヌ主演の『水の娘』で監督デビューを果たす。1926年、『女優ナナ』を監督。高い評価を得、彼のサイレント期の代表作としたが、興行的には失敗し負債を抱え、父の絵を売却して借金返済を行う。1934年、季節労働者の姿をドキュメンタリータッチで描いた『トニ』を発表。徹底したリアリズムで描き、のちのネオレアリズモに影響を与えた。1937年には反戦映画の名作『大いなる幻影』を監督。他にも『のらくら兵』（1928年）、『どん底』（1936年）、『ゲームの規則』（1939年）など、興行的には失敗が多いものの傑作と評価されるべき作品を発表していき、ルネ・クレール、ジャック・フェデー、ジュリアン・デュヴィヴィエ、マルセル・カルネとともに戦前期のフランス映画界を代表する映画監督となった。
ジャン・ルノワール 来歴
1939年、イタリアに渡って『トニ』『ピクニック』で助手を務めた当時32歳のルキノ・ヴィスコンティを助監督にして『トスカ』の撮影を行ったが、撮影中にイタリアが第二次世界大戦に参戦したため、製作を放棄してフランスに戻った。1940年にドイツがフランスに侵攻したため、戦火を避けるべく12月にマルセイユとポルトガルを経由して、シボニー号に乗ってアメリカに渡った。この船でサン＝テグジュペリと相部屋になり、親交を結ぶ（『人間の土地』を製作しようとしたが、ハリウッド上層部の無理解で実現しなかった）。12月31日にアメリカに到着し、ロバート・フラハティに迎えられる。同じ頃、ルネ・クレールやジュリアン・デュヴィヴィエも渡米し、ジャック・フェデールはスイスに逃れていた。20世紀フォックスと契約を結び、ハリウッドの撮影システムに困惑しながらも『南部の人』や『自由への闘い』などの作品を創り上げた。1946年に市民権を獲得するが、フランス国籍は捨てなかった。
1949年にインドに渡り、1951年に彼の初のカラー映画『河』を撮る。父親譲りの美しい色彩感覚が評価され、ヴェネツィア国際映画祭国際賞を受賞した。1952年にイタリアで『黄金の馬車』を撮った後、フランスに戻り、『フレンチ・カンカン』を発表する。商業的な成功を収めることができたが、戦前のように作品は当たらず映画を撮る機会が次第になくなっていった。
ジャン・ルノワール 来歴
1969年のテレビ映画『ジャン・ルノワールの小劇場』が最後の監督作品となり、その後は亡命時代の知己を訪ねアメリカで暮らし、終生フランスに戻ることはなかった。
1974年に『ジャン・ルノワール自伝』を出版。翌1975年にアカデミー賞名誉賞をハワード・ホークスとともに受賞。同年、レジオンドヌール勲章コマンドゥールを受章。
1979年2月12日、ビバリーヒルズの自宅で死去。アメリカで失意の底にあったルノワールを精神面で支えていたのは、ルノワールを師と仰ぐヌーヴェル・ヴァーグの旗手フランソワ・トリュフォーだった。オーブ県エソイエのエソイエ墓地に、両親と共に埋葬されている。
ジャン＝リュック・ゴダールやトリュフォーなどのヌーヴェルヴァーグ、ロベルト・ロッセリーニやルキノ・ヴィスコンティらのネオレアリズモ、他にロバート・アルトマンやダニエル・シュミットなど、多くの映画作家に影響を与えた。また、ジャック・ベッケル、ジャック・リヴェット、ヴィスコンティやロバート・アルドリッチなど、後に各国を代表する映画監督が、ルノワールの下で助監督を務めている。著名な写真家のアンリ・カルティエ＝ブレッソンも、写真家としてデビューする前にジャン・ルノワールのもとで助監督を務めていたことがある。
ジャン・ルノワール 家族
ジャンの作品で編集を務めていたマルグリット・ウーレとは恋愛関係にあったが、1939年頃に関係が薄れている。
LAN
LAN
local area network
局所漸近正規性 (local asymptotic normality)
昇交点黄経 (longitude of the ascending node)
イギリス・ランカシャーの行政区分コード（ISO 3166-2:GB）
ランカスター駅 (イギリス)の駅コード
ランシング首都圏国際空港のIATA空港コード
LAN航空 - LATAM チリの旧称
ラン (台風の名前)
GNU General Public License
GNU一般公衆ライセンス（GNU General Public License、GNU GPLまたは、単にGPL) とは、GNUプロジェクトのためにリチャード・ストールマンにより作成された自由ソフトウェアライセンスである。八田真行の日本語訳ではGNU 一般公衆利用許諾書と呼んでいる。現在、GNU公式サイト日本語ページではGNU一般公衆ライセンスと表記されている。
GNU General Public License 概要
GPLは、プログラム（日本国著作権法ではプログラムの著作物）の複製物を所持している者に対し、概ね以下のことを許諾するライセンスである。
GPLは二次的著作物についても上記4点の権利を保護しようとする。この仕組みはコピーレフトと呼ばれ、GPLでライセンスされた著作物は、その二次的著作物に関してもGPLでライセンスされなければならない。これはBSDライセンスをはじめとするパーミッシブ・ライセンスが、二次的著作物を独占的なものとして再頒布することを許しているのとは対照的である。GPLはコピーレフトのソフトウェアライセンスとしては初めてのものであり、そのもっとも代表的なものである。
GPLはフリーソフトウェア財団 (以下FSFと略称) によって公開され、その管理が行われている。GPLでライセンスされている傑出した自由ソフトウェアのプログラムには、LinuxカーネルやGNUコンパイラコレクション (GCC) がある。
FSFが公開、管理する他のライセンスには、GNU Lesser General Public License (GNU LGPL)、GNU Free Documentation License (GNU FDL、またはGFDL) そしてGNU Affero General Public Licenseバージョン3 (GNU AGPLv3) がある。
GNU General Public License 意義
ストールマンは、ソフトウェアに対する自由とは何かという問題を提起し、そのひとつの答えを提示した。GPLは、「自由なソフトウェア」を、有償・無償に関係なく、頒布できるようにした、という単純な意味だけでなく、「ソフトウェアは自由であるべき」という思想が存在することを一般に認知させたという意味において極めて重要な意義がある。
GPLにより付与される強力なコピーレフトはGNU/Linuxの成功にとって重要な役割を果たしているとも言われる。なぜなら、コミュニティに全く還元しようとしないソフトウェア企業にただ搾取されるのではなく、著作物が世界全体に貢献し、自由であり続けるという確証をGPLはプログラマに与えたからである。
GNU General Public License 歴史
GPL誕生以前、Emacsの頒布条件となっていたライセンスが生まれたきっかけは、ジェームズ・ゴスリンが作成し、当初自由な利用が認められていたGosling Emacsのコードに突如ゴスリンが独占的な許諾条件を附してしまったことが契機となっている。この許諾条件の変更の影響により、ストールマンは自身のEmacsのコードを書き換えなければならなくなった。
またGPL、GNUプロジェクトの誕生について、次のような逸話もある。
当時、ストールマンはMIT人工知能研究所でSymbolics社製のLISPマシンで動くソフトウェアを開発していたが、ストールマンが作りSymbolics社に対して提供したパブリックドメイン版であるソースコードの改変版について、同社が著作権を根拠にソースコードを開示しなかったことに腹を立てGPLを考案したといわれる。いずれにせよ、これ以降いかにしてソースコードの自由な利用を保証するかということにストールマンは腐心するようになる。
GNU General Public License 歴史
GPLは1989年にリチャード・ストールマンによって、GNUプロジェクトのソフトウェアの配布を目的に作られた。オリジナルのGPLは、初期のGNU Emacs、GNUデバッガそしてGNU Cコンパイラの配布に利用していた類似のライセンスを基に、それらを組み合わせたものをベースとしている。前記3つのライセンスは、現在のGPLと似たような条文を含んでいる。しかし、それらは各プログラム固有のライセンスであり、似通っているとはいえ、互いの互換性は全くなかった。ストールマンの目標は、いかなるプロジェクトでも使用可能で、それゆえ多くのプロジェクトがコードを共有することを可能にさせる単一の汎用的なライセンスを作り出すことだった。
GNU General Public License 歴史
GPLは幾度か改訂されており、1991年にはバージョン2がリリースされている。バージョン3がリリースされるまで、それに従うこと15年間、FOSSコミュニティの幾人かは、GPLでライセンスされているプログラムを、ライセンスの意図に反し、搾取する事につながる抜け道 (loopholes; 抜け穴、ループホール) に対し懸念を抱くようになった。これらの懸念の中には、TiVo化（Tivoization。GPLでライセンスされたプログラムが含まれているにも関わらず、改変版ソフトウェアの稼動を拒絶するハードウェアについての問題）、Webインタフェースの裏側に隠れ公開されることのない改変版GPLソフトウェアの利用、AGPLバージョン1と同等の互換性問題、GNU/Linuxコミュニティと敵対するための武器として特許を行使する企てと見なされる、マイクロソフトとGNU/Linuxディストリビュータとの特許契約などがある。
GNU General Public License 歴史
FSFならびにFLOSSコミュニティは、これら懸念に対し真剣に取り組むべく、バージョン3への改訂作業を始めた。2005年後半、FSFは、GPLバージョン3 (GPLv3) の策定に関するアナウンスを行った。2005年の時点でGPLは様々なFOSSプロジェクトのソフトウェアに採用されていたこともあり、FSFが単独で改訂することにより起こりえる問題を回避するため、改訂プロセスは公開で行うことが同時に発表された。2006年1月16日、GPLv3の最初の議論用草稿 (discussion draft) が公開され、公開協議プロセスを開始した。当初公開協議は9ヶ月から15ヶ月を想定していたが、終わってみると、4つの草稿公開に延べ18ヶ月にまで要した。公式のGPLv3は2007年6月29日、FSFにより発表された。GPLv3は、リチャード・ストールマンにより起草され、エベン・モグレンならびにSoftware Freedom Law Center (SLFC) による法的助言を受けている。
GNU General Public License 歴史
公開協議プロセスは、FSFを調整役、SFLC・Free Software Foundation Europe (FSFE)その他自由ソフトウェア開発組織による支援のもと進められた。この間、gplv3.fsf.orgというウェブポータルサイトが立ち上げられ、ここを経由し多くの一般からのコメントが集められた。このポータルサイトは、策定プロセスのために開発されたstetというソフトウェア上で稼働している。これらコメントは、およそ130名ほどから成る4つの協議グループ (committee)に渡された。この130名はFSFの目標に対しそれを支持する人物並びにそれと対立する人物双方が含まれている。これら協議グループは一般から提示されたコメントを精査し、新しいライセンスがどうあるべきか決定するため、ストールマンにその要約を回付した。
公開協議プロセスを経て、初回の草稿には962ものコメントが提出された。終わってみると、延べ2,636ものコメントが提出されていた。
初版の草稿公開ののち、GPLv2とGPLv3の非公式な差分（但し、これはdiff出力による行単位ごとの単純な差分）が、FLOSSコミュニティ向け法律サイトGroklawにより公開された。
GNU General Public License 歴史
2006年7月27日、GPLv3の討議用第2次草稿が、LGPL第3版 (GNU LGPLv3) の初版草稿とともに公開された。初稿と第2稿の差分は、FSFとFSFEからそれぞれ提示されている。第2稿ではDRMに対抗する明確な目標が取り入れられている。
第3稿は2007年3月28日に公開された。この草稿は、かの物議を醸したマイクロソフトとノベルが締結したような特許相互ライセンス (patent cross-license)を排除する意図を持つ文言を含んでおり、反TiVo化条項 (anti-tivoization clauses) はユーザ製品 (User Product)・コンシューマ製品 (Consumer Product) といった一般家庭で使用される製品に限定する旨定めている。また、公開協議開始時点で削除が予告されていた地理的 (頒布) 制限 (Geographical Limitations)の項については、明白に削除されている。
最終稿となった第4の議論草稿は2007年5月31日に公開された。この草稿では、Apache Licenseとの組み合わせを可能にする条項が導入された他、外部契約者 (contractor) の役割を明確化し、マイクロソフト–ノベル間の契約のような明白な問題を回避する例外条項を加えている。この最後の例外条項は、第11項第7段落に次のように記載されている（条文は正式公開版と同一である）。
You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license [...]
これは、そのような契約を将来に渡って無効化することを目的としている。また本ライセンスは、マイクロソフトが、あるGPLv3ソフトウェアを利用するノベルの顧客に許諾したような特許契約（特許ライセンス、特許許諾、パテントライセンス）を、まさにそのGPLv3ソフトウェアを利用するユーザーすべてにまで（ユーザーの行為如何に全く関わらず）自動的に拡大適用することを意味する。ただし、マイクロソフトが法的にGPLv3ソフトウェアの伝達者 (conveyor; 譲渡者) でもない限り、それは不可能である。これはある種、特許契約に対しそれを他者に無制限に提供してしまうことから、ポイズンピルのような働きを持つとの意見もある。ただし本条項導入の直接の契機となった、ノベルの行為そのものに対しては、本項第7段落最後に例外を設け、既得権条項を適用している。
GNU General Public License バージョン履歴
バージョン1は、1989年2月にリリースされた。ソフトウェア頒布者が自由を制限する手段の主に2つから、自由ソフトウェアの定義たる自由を守る働きを、このライセンスは持っていた。
第一の手段は、頒布者がバイナリ（実行ファイル）のみを公開することである。バイナリを受け取っても人間は基本的に読んだり改変したりすることができない。これを防ぐため、GPLv1では、いかなるベンダーもバイナリを頒布するならば、ソースコードも利用できるようにしなければならないとしている。
第二の手段は、ライセンスに追加の制限を加えることである。直接でなくても、別の制限があるソフトウェアを組み合わせて頒布すれば、制限は2つの集合の和になる。すなわち、受け入れられない制限が加えられたことに等しい。これを避けるため、改変版も、GPLv1の下で頒布されなければならないと、GPLv1では規定している。このため、GPLv1よりも厳しいライセンスで頒布されるソフトウェアを組み合わせることはできない。ただし、GPLv1よりもパーミッシブ・ライセンスで保護されるソフトウェアと組み合わせて頒布することが可能である。なぜなら、組み合わせによって全体を通して頒布に係るライセンス条項に変化はないからである。
GNU General Public License バージョン履歴
バージョン2は、1991年6月にリリースされた。
リチャード・ストールマンによれば、GPLv2で最大の変更は第7節、彼に言わせると、パトリック・ヘンリーの名文句「自由か然らずんば死を」("Liberty or Death") の一節である。他の利用者の自由を尊重するような方法で、GPLで保護されたソフトウェアの頒布が妨げられる場合（たとえば、法的規制によりソフトウェアをバイナリ形式でしか頒布できないとき）、この節に従えば、頒布は一切できない。GPLv3でも同様の条項が存在し、幾分簡素化されたうえ主旨が明確になっている。これは、自由ソフトウェア開発者や、自由ソフトウェアを単に使用する者から金を脅し取ろうと特許を行使する企業の企みをすこしでも減らすことを見込んでいる。
GNU General Public License バージョン履歴
1990年までには、現存するプロプライエタリなライブラリと本質的には同等な機能を持つCライブラリや、その他のソフトウェア・ライブラリに対しては、制限の緩いライセンスのほうが戦略的に有効なことが明らかになってきた。1991年6月にGPL第2版がリリースされた際、Library General Public License (LGPL) が、初版にもかかわらずGPLと相補的なことを示すため第2版として同時に導入された。GNUの思想における位置づけを反映させるため、Lesser General Public Licenseと名を変え、1999年、LGPL2.1がリリースされた。
バージョン3は、2007年6月にリリースされた。GPLv3は、ソフトウェア（プログラム・ライブラリなど）を含む著作物に対し、著作者・著作権者やライセンス受諾者[A]の権利や、プログラムの受領者のためにライセンス許諾者が与える権利、またソフトウェアの自由と衝突する法や法的権利（DRM、特許の利用、他者を差別するような特許ライセンスの排除）などに関する基本理念を以前のバージョンより明文化している。
GNU General Public License バージョン履歴
ストールマンによると、もっとも重要な改訂点は、ソフトウェア特許、他の自由ソフトウェアライセンスとの両立性(compatibility; 互換性)、「ソースコード」とは何を指すのかの定義[A]、ソフトウェアの改変に関するハードウェアの制限(TiVo化)そしてデジタル著作権管理 (Digital Rights Management, DRM) との関連がある。その他の改訂点は、国際化[A]、ライセンス違反時の対処手段そして可能ならば著作権者により追加的条項（additional terms）を与える手段に関連している。
他、注目に値する改訂点としては、GPLv3で保護された著作物の著作権者が、パッチなどを提供しそれに改変を加えた貢献者 (contributor) に対し、ある種の条件または要求を課すことを許諾する条項が加えられている。これらに加えて、新しく導入された要件の一つには、時折Affero条項 (Affero clause、Affero節) とも呼ばれるが、Software as a Service (SaaS) のようなASPモデルによるGPLの条項を回避しようとする試み(ASP loophole; ASPの抜け道)に対し、これを封じようと意図しているものも含まれる。この条項が追加された結果、GNU Affero General Public Licenseバージョン3 (GNU AGPLv3) が作成されている。GPLv3とAGPLv3は互いに両立はしないが、リンクや結合のみを認める相補的な条項を共に持っている。
また、GPLv3で許諾されるソフトウェアは、米国のDMCAや日本の著作権法、不正競争防止法が規定している「技術的制限手段」（技術的保護手段、例: DRM）の「解除」を認める条項が追加されている（詳細はセクション"技術的保護手段回避を禁ずる法への対抗措置"を参照）。
GNU General Public License 利用条件
「GPLが適用された著作物の複製を受け取る全ての者」（Recipients; 受領者）は、GPLの条項と条件 (terms and conditions; 利用条件) を遵守しなければならない。利用条件を遵守するライセンシー（the licensee; 被許諾者、ライセンシー）は著作物を改変する許諾を与えられるのと同時に著作物または二次的著作 (派生 derivative) 物の複製と頒布を許諾される。ライセンシーは、このようなサービスを提供するのに料金を課してもよいし、また無料で行ってもよい。この後者の許諾は、GPLと商用再頒布禁止のソフトウェアライセンスとの相違点である。FSFは、自由ソフトウェアは商用利用を制限するべきではないと主張している。また、GPLは、GPLが適用された著作物を如何なる値段で販売しても良い旨、明確に述べてある。
GNU General Public License 利用条件
加えて、GPLは、頒布者がGPLにより許諾される以上のさらなる権利制限 (further restrictions on the rights granted by the GPL) を課してはならないと述べている（GPLv2第6節、GPLv3第10項）。これは（純粋に契約である）秘密保持契約 (non-disclosure agreement, non-disclosure contract) のもとソフトウェアを頒布するような手法を禁ずる。GPLのもと、頒布者はまた、GPLなソフトウェアにおける特許を行使するために、ソフトウェアにより行使されるいかなる特許をも「ライセンス」（特許ライセンス）として許諾する。
GPLv2の第3節とGPLv3の第6項によると、事前コンパイルされたバイナリとして頒布されるプログラムは次のいずれかを満たさなければならない。
GNU General Public License 利用条件
また、GPLv2の第1節とGPLv3の第4項は、プログラムの受領者すべてにプログラムと共にGPLの複製を (all recipients a copy of this License along with the Program) 与えなければならないと規定している。GPLv3ではその第6項を満たす限りにおいて、ソースコードを利用可能な状態にするために、GPLv2で指定された物理媒体以外にも、明示的に追加の手段を講じても良いとする。コンパイル済みコードを取得する方法とソースコードのありかが明確に分かる場合、近くのネットワークサーバからまたはP2P送信によりソースコードをダウンロードさせる手段などもこの追加の手段に含まれる。
改変された著作物を頒布する権利は、GPLにより無制限に付与されるわけではない。頒布者自身による改変が加えられたGPLによる著作物を頒布する際に、著作物全体を頒布するための要件は、GPLよりも強い要件であってはならない。
その要件とは、コピーレフト (Copyleft) として知られている。これは、ソフトウェアプログラムに関し、著作権 (copyright) を利用した法的な権能をもたらす効果がある。GPLで保護される著作物もまた、著作権で保護されているため、改変された形態でなくとも、ライセンスで規定されている場合を除き、ライセンシーはその著作物の再頒布の権利を持たない（フェアユースを除く。ただし、その記事やGPL FAQで述べられている通り、フェアユースにworld-wide principle; 世界的な原則、統一見解などない）。再頒布のような、通常著作権法で制限される権利をある人物が行使しようと考える場合、その人物はGPLの条項をただ従う必要がある。逆に、GPLの条項を遵守せず（例えば、ソースコードを開示しない）著作物の複製を頒布すると、著作権法に基づき著作権者から頒布の差止め等で提訴される可能性がある。
GNU General Public License コピーレフト
コピーレフトは、著作権法を本来の使用目的と正反対の目的を実現するために利用する。すなわち制限を課す代わりに、コピーレフトは、権利がのちに消失しないような方法で、他者への権利を許諾する。コピーレフトはまた、ライセンシーに対し再頒布の権利を無制限に許諾するのではなく、コピーレフトが主張する点において発見されるのは法律上の任意の欠陥であるべきことを保証している。
コピーレフトライセンスで保護されるプログラムを頒布する多くの者は、ソースコードと共に実行ファイルを添付する。コピーレフトを満たす別の方法は、要求に応じて（CDのような）物理媒体を用いてソースコードを提供するという文書を提示することである。また事実としてコピーレフトライセンスで保護されるプログラムの多くは、インターネット上で頒布されており、ソースコードはFTPまたはHTTPなどを用いてソースコードを遣り取りできるようにしているものが多い。インターネット上での頒布は本ライセンスを満たしている。
GNU General Public License コピーレフト
コピーレフトが適用されるのは、ある人物がプログラムを再頒布しようと求める場合にのみである。改変したソフトウェアを他の誰にも頒布しない限り、改変箇所を公開しなければならない如何なる義務も免ぜられ、その改変版を私的な物とすることは許される。また、コピーレフトはソフトウェア自身のみに適用されるのであって、ソフトウェアの出力 (outputs, アウトプット) には適用されないことには注意しておきたい（ただし、そのアウトプット自身がプログラム自体の二次的著作物ではない場合）。例えば 、GPLで保護されたコンテンツ管理システム ("Contents Management Systems"; CMS) に対しその改変した派生版を動作させる一般ウェブポータル（ブログソフトウェアなど）は、その出力自体はプログラム自体の派生物ではないから、土台としたソフトウェアならびにその改変部分を頒布する必要はない。反例は、GPLで保護されたソフトウェア"GNU bison"である。この構文解析器の出力は、その派生物の一部をまさに含んでおり、そのため、この事実に対しGNU bisonにより許諾される特殊な例外条項 (a special exception) が仮に存在しないならば、出力結果はGPLで保護される派生物となっていたであろう。最新のGNU bisonでは、事実として、出力コードのヘッダにAs a special exception...という特殊例外条項が記述されている。
GNU General Public License コピーレフト
なお（GPLに従う著作物に限ったことではないが）、コピーレフトのもとで公開された著作物の著作権は、前述の通り譲渡しなければ個々のコードの著作権者が保有している。従ってコピーレフトを無視した再頒布に対して、頒布の差止めやコピーレフト違反是正（エンフォースメント）を求める権利があるのはプログラムの著作権者だけであり、一般のライセンシーにはない。ただ、大規模なFOSS開発プロジェクトは一般的にワールドワイドであり、開発者の居住国が多岐に渡るため、多かれ少なかれ差異がある各国の著作権法にプロジェクト全体で合致させるのは困難を要す。このため一部のFLOSSプロジェクトでは各著作権者に代わり、コードの著作権を一括してプロジェクト（またはそれを統括する団体・法人組織）が引き受ける場合もある。GNUプロジェクトは、コードの受け入れに関し、米国著作権法の庇護を享受するため、ライセンス如何に関わらず、寄贈されたコードの著作権を原著作者より明示的にFSFに譲渡する場合にのみ受け入れている。CMSのPloneならびにPlone財団(Plone Foundation)も似たような形式を採用している。
GNU General Public License コピーレフト
FSFによると、「GPLは改変版、もしくは改変版の一部のリリースを要求することは述べていない。改変版を一切公開せず、改変を加えることや、私的に利用することは自由である。」と主張している。しかしながら、仮にある人物がGPLでライセンスされたオブジェクトを公開するならば、ライブラリリンクに関する問題が提起される。すなわち、もし、プロプライエタリなプログラムがGPLなライブラリを使用するならば、そのプロプライエタリなプログラムは（一般にプロプライエタリソフトウェアはソースコードが自由な許諾の下利用できない為）GPLに違反する、はたまたそうではないのか、という問題がある。
GNU General Public License コピーレフト
この重要な論点は、非GPLソフトウェアがライセンス的、すなわち著作権法的に、GPLなライブラリに静的リンクまたは動的リンク可能であるか否かという問題に行き着く。この問題に関して、異なるいくつかの見解が存在する。GPLのもとリリースされるコードの二次的著作物が全て、それら自身もまた、GPLに従わなければならないとの要求は明白である。しかし、GPLなライブラリを使用する、そして、GPLなソフトウェアをより巨大なパッケージと組み合わせる (bundle, バンドルする)（概ね静的リンクによりバイナリを混合する場合などを想定すればよい）点に関しては、曖昧さが惹起する。これは究極的には、GPLそれ自体 (per se, in itself) とは無関係の問題であるが、著作権法が二次的著作物をどう定義するかということと関連した問題である。この議論に関して、次のようないくつかの異なる見解が存在する。
GPLのライセンス条文自体の著作権を保持する法人組織でもあり、GPLでライセンスされる著名なソフトウェア製品を多数提供しているFSFは、動的リンクされたライブラリを利用する実行ファイルは、実際には二次的著作物である、と強く主張している。しかしながら、このことは、お互いを「結合する」(連携する、communicate) だけの分離された別個のプログラムには適用されないとしている。
GNU General Public License コピーレフト
FSFはまた、コピーレフトという点で、GPLとはほぼ同一であるが、「ライブラリ利用」という目的のために、リンクの許諾を追加的に与える、LGPLというライセンスも作成した。
リチャード・ストールマンとFSFは、プロプライエタリな世界と比較し、より豊富なツールを提供することにより自由ソフトウェアな世界を護持することを目的として、ライブラリ作者に対し、GPLの下でのライブラリのライセンシングを明確に促している。これは、ソースコードを公開しないならば、プロプライエタリ・プログラムがGPLで保護されたライブラリを一切使用できないようにすることを狙っている。
FSFは、プラグインの呼び出し方法についてはまた別であると認識している。もし、プラグインが動的リンクにより呼び出され、関数呼び出しをGPLプログラムに提供するならば、その時には、プラグインは、概ね二次的著作物であると見なされる。
静的リンクは二次的著作物を生じるが、他方、GPLコードに動的リンクされた実行ファイルが二次的著作物であると考慮されるべきか否かははっきりしないとする意見もある。詳細は (Weak copyleft) を参照せよ（ライセンス感染#相互運用性も参考になるかもしれない）。Linuxカーネルの著作権者リーナス・トーバルズは、状況により、動的リンクは派生物を生じ得るとの見解に同意する場合と同意しない場合があるとしている。
GNU General Public License コピーレフト
ノベルの弁護士は、動的リンクが二次的著作物でないのは「もっともらしい」が「断言」はできないとし、善意による動的リンクの証拠として、プロプライエタリなLinuxカーネルドライバの存在に見てとれる、と文書にて記載している。
ガルーブ対任天堂訴訟において、アメリカ合衆国第9連邦巡回区控訴裁判所は、二次的著作物を「『形式』または永続性」を所持するものと定義し、「当件における侵害された著作物が、ある形式で著作権の適用された著作物の一部と協働しなければならない」と言い渡した。しかし、特にこの対立を解決する明白な法廷判断は出ていない。
GNU General Public License コピーレフト
Linux Journal誌の記事によれば、IP法の専門家でOSIの法務顧問 (General counsel) も務めるローレンス・ローゼンは、リンクの動的・静的を含む種別は、ある種のソフトウェアが二次的著作物であるか否かについての問題とは概ね関係がない、すなわち、そのソフトウェアが、クライアントソフトウェアとライブラリ、またはそれら個別とのインタフェースが意図されているか否かについての問題のほうがより重要である、と主張している。彼は、「新規のプログラムが二次的著作物であるか否かの主な指標は、原著作物のプログラムのソースコードが、『複製と添付(コピーアンドペースト)』する意図をもって利用され、新たなプログラムを作成する任意の手段において、改変、翻案またはその他の変更を加えたか否かに係っている。もしそうでないならば、私はその新規のプログラムは二次的著作物ではないと主張するだろう」と述べる。また、彼はこの記事の中で、ソフトウェアの組み合わせ・バンドリング、リンクのメカニズムなど、その他関連する多くの指摘意図を挙げている。さらに、彼は、彼の弁護士事務所のウェブサイトにて、このような「市場原理」的要素はライブラリリンクの原理といった技術的な要素よりも重要であると主張している。
GNU General Public License コピーレフト
プラグインまたはモジュール（例えば、フリーなドライバ"nouveau"とは別個に存在する、NVIDIAのプロプライエタリなデバイスドライバ、またATI FireGL RXなどのグラフィックカード用カーネルモジュールがその一例）が固有の著作物と合理的に見なされる際、それらライブラリがGPLに従わなければならないか否かという、別個の問題もある。これに対する見解は、著作物がGPLv2ならば、分離していると合理的に理解されるプラグインまたは、プラグインを利用するために設計されたソフトウェア用のプラグインは、任意のライセンスで許諾され得る。GPLv2の条文段落において特に注目される箇所は以下の条文である。
GNU General Public License コピーレフト
You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
...
b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.
...
GNU General Public License コピーレフト
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
GNU General Public License コピーレフト
実際にはGPLv3でも同じであり、条項の文面は多少異なっているが、上記と同様の内容が、以下となる（詳しくはセクション"改変版ソースの伝達"を参照）。
You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
...
GNU General Public License コピーレフト
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
...
GNU General Public License コピーレフト
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
GNU General Public License コピーレフト
事例分析として挙げると、DrupalやWordPressのようなGPLv2でリリースされていたCMSに対し、それらに提供されていたプロプライエタリと想定されるプラグイン、テーマ、スキンなどは、両プロジェクトサイドにて議論が巻き起こる共に、非難されるようになってしまった。
一方、Linuxカーネルではこのような結合の状況分析を行うことなく、カーネルの著作権の影響範囲とユーザ空間プログラムが派生物ではないことをライセンステキスト冒頭で述べている。
参考訳:
前述のセクションの実例を挙げる。GPLソフトウェアへのパッチを提供した場合は、そのパッチが「適用したGPLソフトウェアとは別の著作物」とみなされる可能性も含んでいる。これは、前述の通り、
や
GNU General Public License コピーレフト
に規定されている。即ちGPLソフトウェアを含む「集積物 (aggregate) の他の部分」と認められれば、GPLに反しない、言い換えればGPLよりパーミッシブ・ライセンスでパッチを公開しても良い。例えばパッチが単なる修正ではなく、単体で再利用可能な全く別種の機能強化と見なされればそれは集積物の別の部分と規定でき、そのパッチのみに対しGPLと矛盾せずかつGPL以外のライセンス（BSDライセンスやzlib Licenseなど）を適用する事も可能である。一例をあげると、MySQLは、「リンク例外条項付きGPLv2」と商用ライセンスとでデュアルライセンシングされている。これに対しGoogleはMySQL向けのパッチをBSDライセンスで提供していた。このパッチはオリジナルのMySQLに由来しないコードのため、GPLで保護されたMySQLの「集積物とは別の部分」となる。BSDライセンスは独占的なライセンスであろうとも両立するので、結果的にこのパッチは、MySQLをGPLで利用するライセンシーと共に商用ライセンスで利用する者も適用可能である。また同時にそのパッチからサブルーチンのみを取り出し、BSDライセンスされたソフトウェアにも同様のルーチンを導入する事も可能となる。
GPLなソフトウェアと別のプログラムが単に結合している場合は、本来、全てのソフトウェアをGPLにすることも要求されない、そしてGPLなソフトウェアを非GPLソフトウェアとともに頒布することも要求されない。しかし、稀な条件において、GPLの権利を保証することを妨げる障害が取り除かれるであろう。次の文は、GNU.org ウェブサイトに存在するGPL FAQからの引用である。これは、ソフトウェアが、バンドルされたGPLプログラムと結合を許される範囲がどこまでかを記述している。
'What is the difference between an “aggregate” and other kinds of “modified versions”?
An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media. The GPL permits you to create and distribute an aggregate, even when the licenses of the other software are non-free or GPL-incompatible. The only condition is that you cannot release the aggregate under a license that prohibits users from exercising rights that each program's individual license would grant them.
Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.
このように、FSFは「ライブラリ」と「その他のプログラム」とを、次の2つの観点双方を用いて線引きしている。
しかし、FSFは、この問題は明確な結論はなく、複雑さの条件について判例 ("case law") により決められる必要があるだろう、と譲歩している。
GPL FAQでは「結合メカニズム」（「コミュニケーションのメカニズム」）の例として、プロセス間通信、遠隔手続き呼出し (RPC)、カーネル空間・ユーザー空間の通信やシステムコール、パイプ、execによるプロセス起動などを挙げている。これら「結合メカニズム」を用いてGPLなソフトウェアと接続する場合は、個別のプログラムであるため結合ではないとも見なせるが、そのやり取りするデータの如何によって接続先が二次的著作物であると見なされる余地も残されている(「コミュニケーションのセマンティクス」)。これに対する明確な法廷判断はまだない。
GNU General Public License ライセンス条文の著作権者
GPLの条文自体はGFDLやGPLの下に自由に配布されているわけではなく、ライセンス著作者は条文の改変 (modifications) を許可していない（GPLの条文自体の著作権はフリーソフトウェア財団が持つ）。GPLはプログラムの受領者に（本ライセンスの直接の対象となる）本プログラムと共に本ライセンスの複製を (a copy of this License along with the Program) 得る権利を与えているため、未改変のライセンスの複製と頒布 (distribution; 配布) は許されている。GPL FAQによると、仮に改変する場合は、別の名前とし、「GNU」について言及せず、フリーソフトウェア財団から許諾を得ている場合を除いて改変版ライセンスからGPLの前文 (Preamble) を削除した場合に限り、GPLの改変版を利用して新たなライセンスを作成しても良い。そのようにして作成された派生ライセンスに対し、FSFは一切の法的異議申し立てを行うことはないが、そういったライセンスは一般にGPLと両立しない (互換性が無い、incompatible) ので、FSFは推奨していない 。
GNU General Public License ライセンス条文の著作権者
前述のとおり、GPLの条文自体は著作権で管理されており、その保持者はFSFである。しかしながら、FSFはGPLのもとリリースされた著作物の著作権は保持しない。これも前述したが、例外は、著作権者が明示的にFSFに著作権を譲渡した場合である。ただし、そのような事例はGNUプロジェクトに属するプログラムや寄贈されたプログラムを除いてあまりない。ライセンス違反が発生した場合、個々の著作権者のみが、訴訟を起こす権限を持つ。
FSFは、FSFの許可なくGPLの前文 (Preamble) を含めた、派生ライセンスを使用しない限り、GPLに基づいた新しいライセンスを作成することを許可する。しかしながら、このようなライセンスはGPLと両立しない (incompatible) 場合があるので、作成しないほうがよい。またそれは、明らかにライセンスの氾濫を生じさせる。翻訳も翻案権の行使であるため、ライセンスの翻訳は原則認められないが、その翻訳が非公式であることを明記し、FSFの求めに応じて翻訳をアップデートできるならば翻訳を許可される。
その他、GNUプロジェクトにより作成されたライセンスには、GNU Lesser General Public License、GNU Free Documentation Licenseが含まれる。
GNU General Public License 両立性とマルチライセンス
あるオープンソースソフトウェアでライセンス上考慮すべき点があるなどして、またはもっと極端な例では、GPLの思想的な面に反発があるなどして、GPLと両立性を欠くようなライセンスを著作物に敢えて採用するケースがあるかもしれない。しかし、GPLを採用する自由ソフトウェア、オープンソースソフトウェアが多数存在するため（セクション"採用実績"を参照）、現実問題としてそのような行為はコードの再利用性を著しく欠く結果につながる（記事"ライセンスの氾濫"を参照）。このため、自身の採用するライセンスをGPLと非互換にしないよう、GPLとのライセンス両立性を考慮することは重要である。
著作物全体として影響を受けるライセンスの持つ制限の組み合わせにより、GPLが許諾する事項を越えるいかなる追加的制限が課されない限り、他のライセンスで許諾されたコードは、GPLで許諾されたプログラムと衝突することなく組み合わせることも可能である。また二次的著作物の観点として、互換性のある自由ソフトウェアライセンス/オープンソースソフトウェアライセンスで許諾されるコードを組み合わせる場合は、原則コードの組み合わせ全体に、そのコピーレフト性が最も強くなるライセンスの影響を受ける。GPLの正規の条項に加えて、追加的な制限や許諾を適用することができる組み合わせは以下の通りである。
GNU General Public License 両立性とマルチライセンス
LGPLのもとライセンスされるコードは、そのコードのライセンス如何に関わらず（独占的なコードでさえも）、いかなるその他のコードともリンク可能である。組み合わせた全体の著作物がGPLv2またはGPLv3でライセンスされる場合において、LGPLv2でライセンスされたコードに"any later version" statementが存在しない場合はコードを当該ライセンスで再ライセンスすることができる。
GNU General Public License 両立性とマルチライセンス
上述1.について、よくある表明文の例は、"either version 2 of the License, or (at your option) any later version" (「本ライセンスのバージョン2、または（あなたの選択で）任意の以後のバージョン」) である。これと対照的な例はLinuxカーネルや、バージョン1.9.2までのプログラミング言語Rubyの処理系（インタプリタ）である。これらは"any later version" statementなしのGPLv2単独でライセンスもしくはGPLv2を内部的に参照する形式を採るRubyライセンスである（後者はデュアルライセンスに類似する）。従ってGPLv3のコードを組み合わせることはできないので注意を要する。しかし、Rubyの処理系はデュアルライセンスのGPLを、バージョン1.9.3より、GPLよりパーミッシブ・ライセンスである2条項BSDライセンスに変更したため、以後のバージョンのRubyの処理系ではGPLv3で保護されるプログラムを組み合わせることも可能である。このような許諾変更が許されるのは、デュアルライセンスの片方であるRubyライセンスには著作権者（Rubyの処理系の場合はまつもと）に許諾変更を一任する条項（2.(d)）が存在する為である。一般的に、ソフトウェアのライセンスを非互換なライセンスに変更する場合は、コードの全著作権者からライセンス変更の同意を取り付けなければならない。LinuxカーネルのライセンスはGPLv2単独であり、Ruby処理系のような特殊な規定を持っているわけではないので、仮に変更する場合はそうせざるを得ない。GNUプロジェクトはこのような事態に陥ることを回避するため、前述の通り著作権者からコードの著作権をFSFに譲渡するよう勧め、またソフトウェアのライセンスほぼ全てに"any later version"表明文を付したGPLを適用している。