EBt は GPL?(PartII)

うーむ。こんなQ&Aがあったんですね（Thanks to taka-hrさん）。

プログラミング言語のインタープリタがGPLの下で公開されていた場合、そのインタープリタで解釈されるように書かれたプログラムのライセンスはGPLと矛盾してはならないのでしょうか?

インタープリタが単に言語を解釈するだけならば、答はノーです。解釈されるプログラムは、インタープリタにとっては単なるデータに過ぎません。GPLのような著作権法に基づくフリーソフトウェアのライセンスは、あなたがインタープリタ上で利用するデータの種類を限定することはできません。あなたは、好きなデータ(この場合解釈されるプログラム)を使って、好きなようにインタープリタを実行することができますし、そのデータを誰かにライセンシングすることについて必要とされる条件は何もありません。
しかし、インタープリタが他の機能(多くの場合ライブラリですが、ライブラリである必要はありません)への「バインディング」を提供するように拡張されている場合、解釈されるプログラムはバインディングを使うことによって事実上それらの機能とリンクされることになります。ですから、もしそういった機能がGPLの下で公開されているならば、機能を利用した解釈されるプログラムはGPLと矛盾しないような形で公開されなければなりません。JNI(Javaネイティヴインターフェース)はそのような機能の一例です。JNIによってアクセスされるライブラリは、それらを呼ぶJavaプログラムと動的にリンクされています。

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

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

これを読むと、EBt は、明らかに Ruby/Qte を呼ぶのでクロ（GPLでないといけない）ですね。

…脳味噌が疲れてきたので今日は寝ます。