GPL、LGPLへの対応

nmosh

nmoshはアプリケーションへの組み込みを想定しているので、それなりの配慮事項がある。
まとめ :

  • 違うmosh本体でもアプリケーションが実行できるなら、アプリケーションはライセンスの制約を受けない。
  • ただしmoshに付属しないR6RS/FFIライブラリを使用する場合、そのライブラリのライセンスの制約は依然存在する。

mosh本体

moshはLGPLv3であるGMPに依存しているため、moshを組み込んだ(AND GMPと静的にリンクした)アプリケーションを配布するときは注意する必要がある。

ただ、アプリケーションをスクリプトまたはnmoshのキャッシュとして提供しており、mosh本体を改変せずに利用している場合は、特に何もする必要はない。単に(GPL互換ライセンスを採用している、)moshないしその派生へのリンクを示すことで要件を果たすことができる追記 : ライセンス文の同梱と著作権の明示は依然必要。LGPLとBSDLがこれを要求している。
mosh本体にはGPLでライセンスされたコードは含まれていないため、FFIモジュールそのものには何ら制限は加えられない。しかしモジュールが通常のmoshでロードできない場合は、moshないしその派生へのパッチをGPL互換ライセンスでリリースする必要がある。
moshそのものを改変して配布する必要がある場合、平たく言えばクローズドソースのmosh派生を作ることは出来ない。もしそのような派生を作る場合は注意深く行う必要がある。(追記 不正確なので後で。。要するに通常のLGPLライブラリの注意があてはまる)
追記 : もちろんGMP依存を取り除くのも選択肢の一つとは言える。。
追記 : 微妙な争点は、果たしてVMを経由して利用するようなケースがLGPLの想定する"リンク"と呼べるかどうかという点で、これには現在の所判断が無いのでなんとも言えない。個人的にはこのようなケースはリンクではないと考えている。1) 技術的にはリンクではない。 2) スクリプトが完全なブラックボックスであったとしても、VM側に変更の自由が有ればLGPLの目的(ライブラリの変更の自由の確保)は達成される。

R6RSライブラリ

有力なR6RSライブラリの一部はGPLを採用している。例えばnausicaa( http://github.com/marcomaggi/nausicaa )はGPLなライブラリとBSDLなライブラリが混在している。
通常の解釈では、コードがGPL互換のライセンスを採用しない限り、GPLなR6RSライブラリを使用することは出来ない。例外条項を採用するか、単に他のライセンスを同時に採用するのが好ましい。
box-2d lite(物理シミュレーションライブラリ : http://github.com/dharmatech/box2d-lite )のようにライセンスが不明なものもある。
おそらく、何らかの機械可読なマニフェストをライブラリとともに配布するのが望ましい。これはnopan( http://d.hatena.ne.jp/kazuhooku/20100115/1263532644 )のようなシステムを実現するのに必要となる。
従来のfatmoshブランチには、submodulesでR6RSのgitリポジトリを収集する企画*1が存在した。ライセンスの混在時の取り扱いが難しいのと、submodules自体が比較的マイナーな仕組みなので、リポジトリを分離して再開する予定。
追記 : 平たく言えば、スクリプトがGPLでライセンスされるとキャッシュについて微妙な問題がある。LGPLや他のライセンスが好ましい。

  1. この辺の解釈(下記※)は今のところ定まっていない。
  2. ランタイムをライブラリとして解釈した場合、GPLでは不自由なライブラリにリンクできない。つまり、GPLなスクリプトを実行するVMもGPL互換で無ければならず、そこからロードされる全てのライブラリもGPLと互換性のあるライセンスを採用している必要がある。これはユーザビリティを低下させる。(GPLは使用スタイル自体はカバーしないので、ソフトウェアやその派生物の作者が意図せず独占的なモジュールが使われるのはどうしようもない。問題は、キャッシュシステムが存在すると、利用者が知らないうちにGPLなソフトウェアを、それが認めない形で複製する可能性がある点。)

前者の問題は、少なくとも現状では大きな問題ではない。スクリプトの実行はよく分離されているので、結合した著作物を構成することは無い。ただ、nmoshは今後プログラム全体のキャッシュ機能を付け加える予定なので、ユーザは無意識的に、キャッシュの形で、GPLなコードと不自由なソフトウェアをリンクし、複製してしまう危険性がある。
後者の問題は、controlled interface exceptionをGPLと共に適用することで解決できる。

この例外事項により、独占的なR6RSライブラリ、ないし、FFIライブラリの使用を明示的に許可する。Guileのライセンスも相当する例外条項があった(GuileのライブラリをリンクするソフトウェアはGPLでなくてよい)。http://sourceforge.jp/magazine/06/06/09/1537222
(デフォルトでGPL非互換ライブラリをGPLソフトウェア上で使えないのは、"非常に薄いGPL互換のwrapper"を作ることでGPLなソフトウェアをGPL非互換ソフトウェアから使われるのを防ぐため。http://www.gnu.org/licenses/why-not-lgpl.ja.html )
例外 : "ライブラリとして〜"。GPLは実行環境(Standard Interface, System Libraries)をライセンスの適用対象から外している。このため、GPLなソフトウェアはWin32上でも動作することが出来る。ただ、R6RSがここに相当するかどうかはまだ議論されていない※*2。要するに、スクリプトをmoshに依存することなく記述しmosh以外でも実行できるなら、プログラムをGPLでライセンスしても問題ない(と、考えられる)。また、少なくとも現状のmoshは問題ない。なぜなら、moshやそのランタイムにGPL非互換なものはなく、かつ、明示的に要求しない限りFFIが使われることはない。
追記^2: わかりづらいな。。
例えば、"R6RSで書かれたGPLedアプリケーションがLinuxのディストリビューションに収録された"ケースを考える。

  • ディストリビューションは再配布なので、そのアプリケーションのGPL要件を満たすようにしなければならない。
  • このとき、そのアプリケーションのホストとしてインストールするR6RS実装や依存ライブラリもGPL互換でなければならない。
    • なぜなら、R6RSがGPLの定めるStandard Interfaceかどうかは不明なので、(安全側に倒すとすれば)リンクされるライブラリとみなされるから。
    • これは、例外条項の追加で回避できる。

しかし、通常の実装はスクリプトのコンパイル結果をキャッシュしないので、派生物を作らない。だから実行環境自体のGPL互換性は問題ない。また、今のmoshはGPL互換性のあるライセンスのソフトウェアで構成されているので問題ない。
不明なのは :

  • R6RSのようなコミュニティ標準であっても、GPLのいうStandard Interfaceを構成できるのか。
  • (インストールなどのタイミングで)暗黙に生成されるコンパイルキャッシュは派生著作物なのか。
  • パッケージが分割されている場合はどの単位を著作物とするのか。
    • 例えば、独占的なソフトウェアCODECとGPLプレーヤを(同時利用するように設定して)同梱するようなケースはGPLに反するが、GPLプレーヤが独占的なCODECを自動ダウンロードするケースは？

*1:http://github.com/okuoku/mosh/blob/31c73153050893d5af572b84ef067f58f6983f24/ext/treasures/tabe/DESC.R6RS を解釈するようなインストーラをmosh_configに組み込もうとしていた。

*2:例えばJavaは多くの人がStandard Interfaceであると認識しているが、これは一企業ないしコミュニティの標準でしかない。