GPL静的リンクルールと動的リンクルールはインタプリタ言語にどのように適用されますか？
私の理解では、GPLは非GPLコードからGPLコードへの静的リンクを禁止しますが、非GPLコードからGPLコードへの動的リンクを許可します。それでは、コードがインタプリタ言語（Perlなど）で記述されているため、問題のコードがまったくリンクされていない場合、それはどれですか？
動的リンクと見なされた場合、ルールを悪用するのは簡単すぎるように見えますが、一方で、静的と見なされた場合、非GPLコードからGPLコードを合法的に参照することも不可能に思われます。コンパイルされた言語には少なくとも静的リンクと動的リンクの違いがありますが、すべての「リンク」がスクリプトを実行しているだけの場合、明示的なライセンスがないと、その意図を理解することはできません。
それとも、この問題についての私の理解は正しくないので、質問は議論の余地がありますか？動的リンクを含む「クラスパス例外」についても聞いたことがあります。これはGPLの一部ではなく、GPLに追加できるものなので、ライセンスにこの例外が含まれている場合にのみ動的リンクが許可されますか？
インタプリタ言語に関する特定の質問については、 GPL FAQは非常に明確です ：
インタプリタにとって解釈されるプログラムは単なるデータです。 GPLのようなフリーソフトウェアライセンスは、著作権法に基づいており、インタープリターを使用するデータを制限することはできません。任意のデータ（解釈済みプログラム）で好きな方法で実行でき、そのデータのライセンスを誰にでも与える必要はありません。
動的リンクと静的リンクについての一般的な質問については。まず第一に、FSFとストールマンの見解では、リンクが静的か動的かは問題ではなく、GPLはどちらの方法でも感染します。 FSF GPL FAQから：
プログラムがプラグインを動的にリンクし、それらが相互に関数呼び出しを行い、データ構造を共有する場合、それらは単一のプログラムを形成し、メインプログラムとプラグインの両方の拡張として扱われます。これは、GPLでカバーされているプラグインとnon-freeのメインプログラムの組み合わせがGPLに違反することを意味します。
そして
Linking[プログラムの名前]静的または動的他のモジュールとのリンクは[プログラムの名前]に基づいて組み合わせ作品を作る。したがって、GNU General Public Licenseの条件は、組み合わせ全体をカバーします
しかし、これは法的な観点から疑わしいです。ダイナミックリンクに関して実際に法廷に出された唯一の場合— Galoob v。Nintendo —控訴裁判所は、派生著作物を著作権で保護された著作物の一部を形"。動的リンクの場合はそうではありません。
とにかく、動的リンクが実際に感染するかどうかに関係なく、回避策があります。たとえば、NvidiaがLinux用のバイナリドライバーを提供するために使用します。 （L）GPLラッパーを作成しますが、作成者として、特定のクローズドソースとリンクするための特別な例外を追加できます。ビデオ FSF GPL FAQ 。
注：これは法的な質問です。 Programmers.SEは法的なフォーラムではなく、プログラミングフォーラムです。ここの人々はプログラミングについてかなり知っていますが、法律については何も知りません。法的な質問をしたい場合は、法的なフォーラムで質問する必要があります。そこでは、主題について実際に何かを知っている人がいます。
GPLは静的または動的リンクについては何も述べていません。リンクについては何も書かれていませんまったく。私が話をしたすべての弁護士または裁判官は、静的および動的リンクの問題は完全に無関係であると言います。
著作権は創造性に関するものです。静的リンクと動的リンクは、技術的な実装の詳細です。静的または動的にリンクされているかどうかは創造的な行為ではなく、作品の著作権ステータスを変更することはできません。
あなたの質問では、「解釈された言語」について話します。しかし、その用語は意味がありません。インタプリタ言語のようなものはありません。言語は、数学的なルールと制限の抽象的なセットです。言語は解釈またはコンパイルされません。言語はisだけです。 「解釈された言語」という用語は、単に間違ったではなく、non-sensicalです。英語が型付き言語である場合、それは型エラーになります。
解釈とコンパイルは、言語ではなく、インタプリタまたはコンパイラ（duh！）の特性です。すべての言語はインタープリターで実装でき、すべての言語はコンパイラーで実装できます。ほとんどの言語には両方があります。最近のほとんどの言語実装では、両方を1つの実行エンジンに組み合わせています。
たとえば、Rubinius Ruby実装には、Rubiniusバイトを解釈するインタープリタであるRubiniusバイトコードにRubyコードをコンパイルする静的な事前コンパイラが含まれています。コードと、RubiniusバイトコードをLLVM IRにコンパイルするダイナミックジャストインタイムコンパイラ。LLVMインフラストラクチャは、次にネイティブマシンコードにコンパイルします。MacRubyRuby実装には、インタプリタはすべて、RubyコードをLLVM IRに直接コンパイルし、さらにネイティブマシンコードにコンパイルします。
一方、CまたはC++用のインタープリターがあります。
これらはすべて技術的な詳細です。著作権とは完全に無関係です。
誰かが他の誰かの著作権を侵害しているかどうかが、インタープリターを使用してプログラムを実行するか、最初にコンパイルするかを第三者が選択するかどうかに依存するというだけでは意味がありません。
問題は、作品が別の作品から派生したものかどうかです。動的にリンクされていても派生可能であり、静的にリンクされていてもまったく派生していません。
これ、IANALなどにどれほどの真実があるかはわかりません。しかし私の解釈では、リンクするライブラリが「バイナリ」に含まれている形式であるかどうかが重要です（動的プログラミング言語の場合、「バイナリ」は配布されたソースコードにすぎません）。この文脈での「バイナリ」のFSFの定義について私が行うこと）。
したがって、ディストリビューションに含めずにコードからライブラリを参照する場合、これを「動的リンク」と同等と見なします。一方、ライブラリを製品にバンドルする場合、またはライブラリの一部を独自のコードにコピーして貼り付ける場合、 「静的リンク」シナリオが適用されます。これは、少なくともGPLの精神に基づいています。自由にse（実行、検査、参照）できますが、制限なしにGPL化されたソフトウェアを使用できます派生それから（その一部を独自の配布可能製品にリンクまたはコピーすることによって）、それは口コミで広まり、ソフトウェアもGPLである必要があります。