非GPL互換スクリプトは、その（GPL）ライブラリ自体によって、実行時にGPLv3ライブラリにリンクできますか？
まず第一に、それはあまり明確ではないので、タイトルを許してください。私が書いているGPLv3のアプリケーションがあり、Javaで書かれています。つまり、クラスファイルが生成され、一般的な操作のためにリンクされます。また、パフォーマンスのために、実行時に実行するスクリプトをプログラムのスクリプトライブラリ（クラスファイル）にリンクするスクリプトエンジンを使用しています。
スクリプトは実行時にリンクする必要があるとすると、GPLv3と互換性のないスクリプトをアプリケーションで実行できますか？代わりに、スクリプトを法的に強制的に解釈することはできますか？明確にするために、GPLと互換性のないライセンスをスクリプトに制限することにGPLv3を関与させようとしています。
問題は、構文解析と機能的に同等の（パフォーマンスを除く）技術的なリンク操作が、実際に法的な意味でリンクしているかどうかです。
明確化：スクリプトは、アプリケーションの相互作用するインスタンスに送信されます。スクリプトは、ECMAScript/JavaScriptのテキスト表現からロードされ、トークン化されて構文解析されてからリンクされます。これが私を混乱させているものです。伝達を考えると、スクリプトはコンパイルおよびリンクされていますか？または、解釈され、パーサーは実際にランタイムリンクしますか？
はい。 GPLは配布/運搬のみを対象としています。他のコメントが示唆しているように、ユーザーを制限したいと考えています。スクリプトがネットワーク経由で送信されるかどうかは関係ありません。運搬（GPLで定義された用語）では、対象となる作品をある法人から別の法人に譲渡する必要があります。コンピューターは法人ではありません。
これはLGPLにとって非常に重要です。これらのライブラリは各ユーザーによって動的にリンクされ、派生した作業（メモリにロードされた）は配布できなくなります。しかし、ユーザーは結果を伝えるのではなく、使用したいので、それは問題ありません。
一般に、GPLおよびプロプライエタリ（非GPL、クローズドソース）コードは、それらが別々のアプリケーションであると合理的に見なすことができる場合にのみ一緒に使用できます。実際には、これが意味することは次のとおりです。
- 2つのアプリケーションは、相互に独立企業間通信で通信する必要があります。
- 各アプリケーションは、他のアプリケーションなしで実行できる必要があります。
したがって、Word文書を何らかの方法で処理するプログラムを作成する場合、上記の2つの要件をまだ満たしているため、WordをGPLにバインドしません。同様に、stdin stoutパイプに入れることができるUnixスタイルのテスト処理プログラムを作成すると、他のテキスト処理プログラムをバインドせずにGPLにすることができますが、それでもパイプで使用できます。
ただし、GPLされたライブラリに静的にリンクする独自のプログラムを作成する場合、プログラムが独立企業間でライブラリと通信しないため、おそらく準拠していません。独立企業間で（たとえば、テキストベースのコマンドインターフェイスまたは多分ダイナミックリンクを使用して）ライブラリと通信する場合、プログラムがないと機能しない場合は、違反する可能性があります。 GPLライブラリ。
さらに読む
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#TOCGPLInProprietarySystem
https://stackoverflow.com/a/1394867
子プロセスとして実行可能ファイルを実行することは、ライブラリをリンクすることと同じですか？
独立して開発されたソフトウェアはいつGPLの下でライセンスされなければならないのですか？