にゃあ

XOOPS Cubeと他のCMSの用語対比

XOOPS Cube Drupal Joolma!
モジュール モジュール コンポーネント
ブロック ブロック モジュール
プリロード ? プラグイン
言語 言語 言語
テーマ テーマ テンプレート

XOOPS Cube Legacyでは、ブロックでPHPがかけるけど、Joolma!のモジュールのように配布はできない。XOOPS系では言語パッチは特に拡張機能というノリではない。


XOOPSのモジュールはGPL2で配布しないといけない?

XOOPSのモジュールでは、そのモジュールのライセンスを宣言する変数$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ならどうか?

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でリリースされてる件

テーマはモジュールと異なり、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に書いてあります。


Smarty2.0からSmarty3.0への変更点

Smarty3.0のパッケージに入っている、SMARTY2_BC_NOTESを和訳してみた。

分かっているSmarty2との非互換性

シンタクス

Smarty 3 APIはシンタクスが新しくなりました。Smarty2のシンタクスはサポートしますが、将来サポートが保証されない可能性があります。

PHPのバージョン

Smarty3はPHP5のみ対応します。PHP4では動きません。

{php}タグ

{php}タグはデフォルトでは無効になりました。{php}タグを使うことは非推奨です。$smarty->allow_php_tag=true;{php}タグを有効にすることができます。

しかし、複数の{php}タグにまたがるPHPコードは、これ以上は動かないでしょう。

デリミタとホワイトスペース

ホワイトスペースに囲まれたデリミタは今後、Smartyのタグとして扱われません。したがって、{ foo }はタグとしてコンパイルされません。この場合、コンパイルするには{foo}とする必要があります。この変更により、{literal}が必要とならないので、Javascript/CSSが扱いやすくなります。なお、$smarty->auto_literal = false;でこの設定を無効化できます。

クォートされなかった文字列

Smarty2は、パラメータにクォートしていない文字列が現れたとき、大雑把で曖昧な面がありました。一方、Smarty3はより厳密です。といっても、特別な文字(A-Za-z0-9_以外)を含まない限り、今でもクォーテーションなしの文字列を使うことはできます。

例えば、ファイル名の文字列はクォートしなければなりません。

{include file='path/foo.tpl'}

Smartyクラスの拡張

Smarty3は初期化するのに、__constructメソッドを使います。Smartyクラスを拡張するとき、もし、小クラスが独自のコンストラクタを定義すると、Smartyのコンストラクタは実行されません。Smartyのコンストラクタを実行する必要があれば、小クラスのコンストラクタでparent::__construct()を実行してください。

class MySmarty extends Smarty {
   function __construct() {
       parent::__construct();
    
       // your initialization code goes here

   }
}

オートローダー

Smarty3はspl_autoload_registerで独自のオートローダーを登録します。もしあなたのコード中に__autoload関数が存在するのなら、 それを明示的に__autoloadスタックに登録しなければなりません。 詳しくは、http://us3.php.net/manual/en/function.spl-autoload-register.php を御覧下さい。

プラグインファイル名

Smarty3ではPHP spl_autoloaderをサポートしています。このオートローダーは、ファイル名を小文字にすることを要求しています。したがって、Smartyプラグインのファイル名は小文字である必要があります。Smarty2では、大文字小文字が混在したファイル名でも動作しました。

特別なSmarty変数のスコープ

Smarty2では特別なSmarty変数(例えば、$smarty.section...$smarty.foreach)がグローバルスコープでした。もし、同じ名前のループがサブテンプレートにあると、親テンプレートの変数を上書きしていまします。

Smarty3では特別なSmarty変数は、ループがあるテンプレートのローカルスコープになります。もし、親テンプレートの変数をサブテンプレートに渡す場合は、パラメータにする必要があります。

{include file='path/foo.tpl' index=$smarty.section.foo.index}

SMARTY_RESOURCE_CHAR_SET

Smarty3はutf-8をデフォルトcharsetとして、定数SMARTY_RESOURCE_CHAR_SETに定義します。これは、escapeのような修飾子のデフォルトcharsetとして使われるようになります。もし、utf-8以外のcharsetをテンプレートで使う場合、適宜にSMARTY_RESOURCE_CHAR_SETを定義することに注意してください。そうしなければ、なにも出力されない可能性があります。

改行での{if}タグ

テンプレートのソースに予期される改行の出力を得るために、{if},{else},{elseif},{/if}タグのコンパイル後コードに¥nが追加されました。もし、{if}タグなどが行末にある場合、HTMLの出力結果が改行されます。


ユーザのパスワードに期限をつけるプリロード PasswordLimitter 1.2

ダウンロード

パスワードは定期的に変更するほうがより安全と言われています。PasswordLimitterは、XOOPSのユーザのパスワードに期限を設け、期限がすぎたユーザに対しては、ログイン時にパスワード変更を促すメッセージを表示します。

インストール方法

  1. PasswordLimitter.class.phpを/preloadにアップロード
  2. 管理アカウントで、http://あなたのXOOPS/misc.php?password_limitter=adminにアクセス
  3. 「INSTALL」をクリックしてインストールを実行
  4. その後、設定ページで期限日数を設定する

アンインストール方法

  1. 管理アカウントで、http://あなたのXOOPS/misc.php?password_limitter=adminにアクセス
  2. 「UNINSTALL」をクリックしてインストールを実行
  3. PasswordLimitter.class.phpを/preloadから削除

変更点 1.0 => 1.2

  • ユーザ新規登録時に有効期限がセットされないバグを修正。

1.1とばしてしまった…orz

開発情報


ユーザのパスワードに期限をつけるプリロード PasswordLimitter 1.0

パスワードは定期的に変更するほうがより安全と言われています。PasswordLimitterは、XOOPSのユーザのパスワードに期限を設け、期限がすぎたユーザに対しては、ログイン時にパスワード変更を促すメッセージを表示します。

インストール方法

  1. PasswordLimitter.class.phpを/preloadにアップロード
  2. 管理アカウントで、http://あなたのXOOPS/misc.php?password_limitter=adminにアクセス
  3. 「INSTALL」をクリックしてインストールを実行
  4. その後、設定ページで期限日数を設定する

アンインストール方法

  1. 管理アカウントで、http://あなたのXOOPS/misc.php?password_limitter=adminにアクセス
  2. 「UNINSTALL」をクリックしてインストールを実行
  3. PasswordLimitter.class.phpを/preloadから削除

開発情報



このブログの著者

suin
Suinと申します。

サブメニュー

最近気になるモノ!

WindowsからMacに乗り換えて半年ですが、Macは細かいところまで丁寧に作られていて、親切なユーザーインターフェイスが気に入ってます。iMacはMagic Mouseと洗練されたデザインのBluetoothキーボードがついてくるので、お得だなあ、なんて思ってます。私に買ってもいいという方、いたら教えてください 笑。

最近のエントリ

XOOPS Cube Dev Ring

最近のコメント

最近のトラックバック

http://www15.atpages.jp/~classicalstudio/wordpress/?p=50
getcwd()とdirname(__FILE__)は違う結果になるときがある (12/22)
Re:
CSSのtext-align:center;は<div>には通用しない (12/15)
XOOPS専門-株式会社RYUS - d3blog
Shiori 1.02 (12/02)
9deMaio.com - blog
Koins 1.00 (11/11)
インターネット覚え書き「ビボウログ」
CSSのtext-align:center;は<div>には通用しない (09/16)
hinoeuma1966
CSSのtext-align:center;は<div>には通用しない (07/03)
Suin.org
ブログ作ってみた (03/23)
Suin.org
ブログ作ってみた (03/23)