$modversion['license']があります。しかし、実質的には、XOOPSのモジュールが暗黙のうちにGPL2にライセンシングしています。
これは妙だな、と思って調べてみたら、特殊なケースを覗いて、モジュールのライセンスはXOOPS2に引っ張られてGPL2にしなければならないようです。GPL2では、「プログラム」の派生物（二次的著作物）はGPL2でなければならないと定めています。（GPL3でもだめ。）
いや、ちょっとまてよ。モジュールって別にXOOPSの派生物じゃないじゃん！と思ったのですが、これがどうもGPL2ではモジュールを派生物と捉えるのが妥当のようです。どうしてこうなるかというと、GPL2ではソースコードをつぎのように捉えているからです。
ある実行形式の著作物にとって完全なソースコード とは、それが含むモジュールすべてのソースコード全部に加え、関連するイン ターフェース定義ファイルのすべてとライブラリのコンパイルやインストール を制御するために使われるスクリプトをも加えたものを意味する。 GNU 一般公衆利用許諾契約書
どういうことかというと、「実行時に読み込んでいるライブラリもそのプログラムの一部です」ということ。XOOPSのモジュールの場合、require '../../mainfile.php';を行うので、その時点でXOOPS2のGPL汚染が始まります。現にGPLのFAQで次のようなことが述べられています。
ライブラリが(LGPLではなく)GPLの下で公開されている場合、そのライブラリを利用するプログラムにはGPLが適用されていなければならないのでしょうか?
はい。なぜなら、実際に実行されるプログラムはライブラリを含んでいるから です。
GNU GPLに関して良く聞かれる質問
GPLの下で公開されていたプログラムがプラグインを使うとして、プラグインのライセンスにはどのような条件がありますか?
それはプログラムがどのようにプラグインを呼び出すかに依ります。プログラ ムがforkやexecでプラグインを呼び出すならば、プラグインは別のプログラム であり、メインプログラムのライセンスはそれらにはなんの条件も課しません。
もしプログラムがプラグインと動的にリンクされており、お互いにファンクショ ンコールを使ってデータ構造を共有している場合、それらは単一のプログラム を形成していると見なされますので、プラグインはメインプログラムの拡張部 分として扱われなければなりません。すなわち、それらはGPLかGPLと矛盾しな いフリーソフトウェアライセンスの下で公開されなければならないということ です。
プログラムがプラグインと動的にリンクされているが、それらの間のコミュニ ケーションはいくつかのオプションとともにプラグインの「main」関数を呼び 出して返値を待つだけという場合は、境界線上で微妙なケースとなります。
GNU GPLに関して良く聞かれる質問
このFAQが意味するのは、モジュールがXOOPSのライブラリ（例えば、XoopsTpl, XoopsObject, XoopsUserなど）を使う限り、別個に配布しようが、モジュールはGPL2になるということです。動的にライブラリを使うか場合、GPLは感染しない、なんという主張もありましたが、実際にライブラリを使うのに動的か静的かでGPLの制約が変わるというのも変な話です。
しかし、まったくXOOPSのライブラリに依存せず、なおかつ、XOOPSなしでも完全な実行ができるモジュールであれば、GPL2を名乗る必要もありません。それはGPLのFAQを隅々読みつくせば、このことを暗示する記述が見られます。しかし、そのようなモジュールはXOOPSと互換するようなライブラリを独自で開発するか、単純な機能しかもたないモジュール（例えば、index.phpでphpinfo()だけを出すモジュール）に限られると考えられます。あくまで、理論上可能という話です。XOOPS専用モジュールである限り、GPL汚染からは逃れられそうにありません。
XOOPS Cubeは修正BSDライセンスでリリースされていると聞きます。では、縛りのゆるい修正BSD版XOOPS Cube用にモジュールをリリースすれば、GPL汚染から逃れることができるでしょうか？
そもそも、XOOPS Cubeが修正BSDライセンスだと勘違いしている人がいるように思います。
XOOPS Cube Legacy は、 Cube コアのモジュールのひとつです。当プロジェクトが新作した Cube コアと、 XOOPS2 JP の後継版として働く Legacy の二つが手を繋いで、 XOOPS Cube Legacy （以下XCL）が動作します。XCL は、 ”XOOPS Cube でもあり、 XOOPS2 JP の後継アプリケーションでもある” という、とてもユニークな CMS です。
XOOPS Cube Legacy の真実……？
では、XOOPS Cubeのどこが修正BSDライセンスかというと、XOOPS Cube Coreです。これはXCLでいうところの、XOOPS_ROOT/core/フォルダのみを差します。xoopscube.jpにはXOOPS Cube Coreのみが修正BSDライセンスとの旨を誤解なく書いています。
XOOPS Cube Core
XOOPS Cube Coreは修正BSDライセンスを採用しています。修正BSDライセンスは、元のBSDライセンスから広告条項の部分を削除したものです。
ライセンス
[修正 2010/03/07]正確には、XOOPS CubeとXOOPS Cube Coreは同じものを差します。したがって、XOOPS Cubeは修正BSDライセンスということになります。なお、XOOPS CubeとXOOPS Cube Legacyはライセンスが異なります。XOOPS Cubeは修正BSDライセンス、XOOPS Cube LegacyはGPL2ライセンスです。修正BSDライセンスのXOOPS Cubeというのは、ここで配布されているものです。
coreだけでモジュールを作ればライセンスはGPLに限られません。ところが、coreだけでは通常のモジュールを作れないのが現実です。つまり、XOOPS CubeであってもXCLであっても、GPL2が飛び火してしまうのは避けられないことのようです。
[補足 2010/03/07]minahitoさんによると、「XCコアモジュール（Legacy Base非依存の、コアのサブシステムを差し替えるもの）は修正BSDで出せますよ。」とのことなので、Legacyから独立したベースモジュールの場合、GPL汚染は起こりません。
テーマはモジュールと異なり、CC(クリエティブ・コモンズ)で公開されていることがあります。どうも、テーマはモジュールとは事情が異なるようです。それは、ひとつの考えとして、テーマがそれだけで完結している点が挙げられると思います。
テーマはSmartyに依存していますが、Smarty自体はLGPLです。LGPLは動的にライブラリを使う場合は、GPLやLGPLの制約を受けないというライセンスです。したがって、Smartyに依存するだけでは、GPLの感染の問題はありません。
しかし、XOOPSのSmartyプラグイン(xoops_date_format, xoops_userなど)を使ったテーマを配布する場合は、テーマもGPL2ライセンスにする必要がありそうです。なぜなら、XOOPSのSmartyプラグインはGPLだからです。GPLでは、動的にプラグインを使用する場合でも、その著作物をGPLにライセンシングすることを要求します。
Smartyにもとから入っているプラグインだけで作ったテーマなら、GPLでなくてもいいといったところだと思います。ただし、Smarty変数がXOOPSなしでは定義されない点を考えると、XOOPSに依存しているということになり、GPL2適用の義務が生じるかもしれません。この点で、テーマはGPLと非互換のCCで配布するのは、グレーゾーンでもあります。
[補足 2010/03/07]minahitoさんによると、「あとテーマは、コードとみるかリソースとみるかで解釈が全く変わります。パイプラインがテーマをコンパイルし、結合可状態へ導いて初めてリンクされるので、GPLとコンフリクトしないライセンスなら(コンフリクトするとXCLで使用不可)選べると思います。」とのことです。リソース、つまり「データ」としてテーマを見る場合はGPL以外の選択肢もあるということ。（minahitoさんはGPLと互換性のあるライセンスならOKとしていますが、GPL汚染を受けていないと主張できる独立したテーマなら、非互換のライセンスで配布も可能なはずです。なぜなら、結合の制約は「複製・頒布・改変」のときだけで、実行するときにGPL非互換と結合することは制限していないはず。）ただし、コードかリソースかも解釈に依存していて、もしテーマがリソースだと判断できない場合は、GPL汚染を受けるかもしれないということです。たとえば、ひとつのテーマパッケージにXOOPS依存のPHPコードが混じっている場合など。詳しくはFAQに書いてあります。
]]>