GPLの静的リンクルールと動的リンクルールは、インタープリター言語にどのように適用されますか？

私の理解では、GPLは非GPLコードからGPLコードへの静的リンクを禁止していますが、非GPLコードからGPLコードへの動的リンクは許可しています。では、コードはインタプリタ言語（Perlなど）で記述されているため、問題のコードがまったくリンクされていないのはどちらですか？

動的リンクと見なされた場合、ルールを活用するのは簡単すぎるように思えますが、一方で、静的と見なされた場合、非GPLコードからGPLコードを合法的に参照することも不可能と思われます！コンパイルされた言語は、少なくとも静的リンクと動的リンクを区別しますが、すべての「リンク」がスクリプトを実行しているだけの場合、明示的なライセンスなしでは意図が何であるかを伝えることは不可能です。

または、この問題に対する私の理解が間違っており、質問が議論の余地がありますか？動的リンクを含む「クラスパス例外」も聞いたことがあります。それはGPLの一部ではなく、代わりに追加できるものなので、動的リンクはライセンスにこの例外が含まれている場合にのみ許可されますか？

インタプリタ言語に関する特定の質問に関しては、GPL FAQは非常に明確です：

インタプリタにとって、解釈されるプログラムは単なるデータです。著作権法に基づくGPLのようなフリーソフトウェアライセンスでは、インタープリターを使用するデータを制限できません。任意のデータ（解釈されたプログラム）で任意の方法で実行でき、そのデータのライセンスを誰にでも付与する必要はありません。

動的リンクと静的リンクに関する一般的な質問については。まず、FSFとStallmanの見解では、リンクが静的か動的かは問題ではなく、GPLはどちらの方法でも感染します。FSF GPL FAQから：

プログラムがプラグインを動的にリンクし、それらが互いに関数呼び出しを行い、データ構造を共有する場合、それらは単一のプログラムを形成すると考えます。これは、メインプログラムとプラグインの両方の拡張として扱われる必要があります。これは、GPLでカバーされたプラグインとフリーでないメインプログラムの組み合わせがGPLに違反することを意味します。

そして

[プログラムの名前] を他のモジュールと静的または動的にリンクすると、 [プログラムの名前] に基づいて結合された作業が行われます。したがって、GNU General Public Licenseの契約条件はすべての組み合わせをカバーします

ただし、これは法的な観点からは疑問です。動的リンクに関して実際に法廷に行った唯一のケースでは、Galoob v。Nintendo-控訴裁判所は、派生著作物には「著作権で保護された著作物の一部を何らかの形で組み込む必要がある」と裁定しました。動的リンクの場合はそうではありません。

とにかく、動的リンクが実際に感染するかどうかにかかわらず、回避策があります。たとえば、NvidiaがLinux用のバイナリドライバーを提供するために使用します。（L）GPLラッパーを作成しますが、作成者として、特定のクローズドソースとリンクする特別な例外を追加できます。FSF GPL FAQをご覧ください。

注：これは法的質問です。Programmers.SEは法的フォーラムではなく、プログラミングフォーラムです。ここの人々はプログラミングについてかなり知っていますが、法律については何も知りません。法的な質問をしたい場合は、法的なフォーラムで質問する必要があります。そこでは、主題について実際に何かを知っている人がいます。

GPLは静的リンクまたは動的リンクについて何も述べていません。それも、リンクについては何も言っていないすべてのを。私が話をした弁護士や裁判官は皆、静的リンクと動的リンクの問題は完全に無関係だと言っています。

著作権は創造性に関するものです。静的リンクと動的リンクは、技術的な実装の詳細です。何かが静的または動的にリンクされているかどうかは創造的な行為ではありませんが、作品の著作権の状態を変更することはできません。

あなたの質問では、「解釈された言語」について話します。しかし、この用語は意味がありません。インタープリター言語のようなものはありません。言語は、数学的な規則と制限の抽象的なセットです。言語は解釈もコンパイルもされません。言語はただです。「解釈された言語」という用語は単に間違っているだけでなく、無意味です。英語が型付き言語である場合、それは型エラーになります。

解釈とコンパイルは、言語ではなく、インタープリターまたはコンパイラーの特徴です！すべての言語はインタープリターで実装でき、すべての言語はコンパイラーで実装できます。ほとんどの言語には両方があります。最新の言語実装のほとんどは、両方を単一の実行エンジンに組み合わせています。

たとえば、Rubinius Ruby実装には、RubyコードをRubiniusバイトコードにコンパイルする静的事前コンパイラ、Rubiniusバイトコードを解釈するインタープリタ、RubiniusバイトコードをLLVMにコンパイルする動的ジャストインタイムコンパイラが含まれます。 IR。LLVMインフラストラクチャがネイティブマシンコードに順番にコンパイルします。MacRuby Ruby実装にはインタープリターがまったく含まれていません。Rubyコードを直接LLVM IRにコンパイルし、さらにネイティブマシンコードにコンパイルします。

一方、CまたはC ++のインタープリターがあります。

これらはすべて技術的な詳細にすぎません。それは完全に著作権とは無関係です。

誰かが他の人の著作権を侵害するかどうかは、第三者がプログラムをインタープリターで実行するか、最初にコンパイルするかを選択するかどうかに依存するということは意味がありません。

問題は、ある作品が別の作品から派生したものかどうかです。動的にリンクしても導出できますが、静的にリンクしてもまったく導出できません。

これやIANALなどにどれほどの真実があるのか​​わかりません。しかし、私の解釈では、重要なのは、リンクするライブラリが「バイナリ」に含まれている何らかの形式であるかどうかです（動的プログラミング言語の場合、「バイナリ」は単に配布されたソースコードです。これはこのコンテキストでの「バイナリ」のFSFの定義から私が作成したもの）。

したがって、ライブラリをディストリビューションに含めずにコードから参照する場合、これを「動的リンク」と同等と見なします。一方、製品にライブラリをバンドルする場合、またはライブラリの一部を独自のコードにコピーアンドペーストする場合、 「静的リンク」シナリオが適用されます。これは、少なくともGPLの精神に基づいています。GPLされたソフトウェアを制限なく自由に使用（実行、検査、参照）できますが、GPL から派生したらすぐに（その一部をリンクまたはコピーして配布可能な製品を所有している場合）、バイラルになり、ソフトウェアもGPLである必要があります。