スイナシア(XOOPS) 「XOOPS」なエントリー suin 2010-07-31T10:11:04Z http://example.com/atom1.xml CMS Theme Finderの発表します！ CMS Theme Finderについて発表をすることになったのでお知らせします。 2010-07-18T04:09:45Z 2010-07-18T03:57:53Z http://suin.asia/2010/07/18/saturday_labo_cms_theme_finder CMS Theme Finderについて発表をすることになったのでお知らせします。無料ですので、ぜひ聞きに来てください。

日時：7月24日（土曜）17:00〜

場所：株式会社RYUS　東京都千代田区神田須田町2-15 KSYビル4F

発表者：わたくしSuin

内容（予定）：

  • CMS Theme Finderとは？
  • CMS Theme Finderの誕生背景
  • CMS Theme Finderを使ったXOOPS Cube用テーマの《画期的な》探し方
  • CMS Theme Finderの機能紹介
  • CMS Theme Finderの今後の展開

発表時間：30分

発表資料：パワーポイントのスライドをプロジェクターで投影します

-----------------------------

7月24日（土曜）17時より当社ミーティングスペースにて、第8回XOOPS Cubeサタデーラボを開催いたします。

今回のゲストスピーカーは下記の方達です。

　○株式会社RYUS suin

弊社のsuinは、CMS Theme Finderの紹介とCMS Theme Finderを使ったXOOPS Cubeテーマの探し方について話します。

　○日本ピー・アイ株式会社 中畑氏

個人のサイトでXOOPSを利用されている中畑氏には、照明のサイトをつくって自分がやりたいとおもっていたこと。その方法がxoopsとの出会いによって実現できたこと。実際の運用している状況の紹介。今、できていないこと。将来的にしたいこと、現状の問題点。などのことを話して頂きます。

　○kudok氏

文系のためのXOOPS入門、XOOPS Cube Legacy カスタマイズ 文系出張所を運営されているkudok氏には、「コンテンツホルダーの立場からXOOPSの良さを語る＋訪問者との安定したコミュニケーションを保つための、カスタマイズの取捨選択」という内容で話して頂きます。

7/06 16:15 追記 3人目のスピーカーとして、kudok氏が参加されることになりました！

■XOOPS Cubeサタデーラボとは XOOPS Cube サタデーラボは、以前行われていた、Cubeナイト、CMSナイト同様に、勉強会+懇親会という形で、これから毎月第4土曜日に開催予定のゆるーい勉強会です（かっちりしたセミナーをご希望の方は参加をご遠慮ください）

■会場 当社ミーティングスペース ※当社オフィスは2009年11月13日に下記所在地に移転しました。お間違えの無いようにお願いします。

〒101-0041　東京都千代田区神田須田町2-15 KSYビル4F (地図) 地図の画像右側にある工事中の建物がKSYビルとなります 当日はエレベータホールの扉が閉まっておりますので、1階のインターフォンで「401」を呼び出して下さい

■受付開始16時半 会場での受け付け開始は16時半から17時です。

■勉強会の部（17時開始。参加費無料） ・ミニセッションを3つぐらい行う予定です。 ・時間は、17時開始、2時間程度を予定しています。

■懇親会の部（勉強会の部終了後開始。懇親会費3,000円） ・19時ごろ開始予定。2～3時間程度の予定です。 ※懇親会費は当日受付でお支払いください。

■参加登録のお願い 会場の都合で15人程度までしか参加できませんので、人数把握のために参加申し込みをお願いします。

■お願い 今後のサタデーラボで聞いてみたい発表・スピーカー、もしくは自分が発表してみたい等ありましたら、是非参加申し込み時にコメント欄に記入をお願い致します。

2010-07-24 (土) 7月24日(土) 第8回XOOPS Cubeサタデーラボ開催

https://ryus.co.jp/modules/eguide/event.php?eid=14

]]> CMS Theme Finder : 不評の「自分のサイトで見る」機能を改良してみた 自分のサイトでテーマのプレビューを見られる点で評価をいただき幸いです。しかし、中にはうまく使えなかった方がいらっしゃるようで、残念でもあります。うまく使えなかった原因は様 2010-05-11T07:26:33Z 2010-05-11T07:20:01Z http://suin.asia/2010/05/11/preview_at_your_xoops_cube

以前、紹介した「自分のサイトで見る」機能ですが、自分のサイトでテーマのプレビューを見られる点で評価をいただき幸いです。しかし、中にはうまく使えなかった方がいらっしゃるようで、残念でもあります。うまく使えなかった原因は様々ですが、その根本的な原因は、あまりシンプルじゃなかった点と、それゆえ説明不足になっていた点が考えられました。そこで、「自分のサイトで見る」機能をシンプルに改善し、できるだけ分かりやすく説明するよう努力してみました。

改良版は、前よりましだと思いますが、私の方では十分にテストできていません。サイトによって状況が環境が変わってくると思います。なので、これをお試しになってくださった方からのコメントや質問をいただければ幸いです。

よりシンプルに、より高機能に、よりセキュアに

  • 設置するファイルが多い → プリロード1個だけになりました
  • プレビューURLがわかりにくい → XOOPSのURLを入力するだけ
  • 閉鎖中のサイトで使えない → 使えるようにしました
  • トップページしか見れない → 他のページも見られるようにしました
  • ユーザごとにトークンを発行することで、前よりセキュアになりました

プリロード設置側のシステム要件

  • XOOPS Cube Legacy 2.1 以上
  • XOOPS Cubeがオンライン上にある(イントラネット上などは利用できません。)
  • PHP5 以上

セットアップ手順(改訂)

  1. CMS Theme Finderのアカウントをお持ちでない場合、新規登録を済ませます
  2. 個人設定から、プリロードをダウンロードします

  3. ダウンロードしたプリロードをあなたのXOOPSCubeに設置します

  4. CMS Theme Finderにログインします
  5. 個人設定の「プレビューURL」に、あなたのXOOPSCubeのトップページのURLを入力します

  6. セットアップ完了です

この改善版へのアップデート方法

以前紹介した記事で、既に「自分のサイトで見る」機能をご利用の方は、以下の手順でアップデートしてください。

  1. あなたのサイトに設置した古いプリロード(/preload/CmsThemeFinderPreviewer.class.php)とテーマ(/themes/ctfp_theme/)を削除します。
  2. 個人設定から、プリロードをダウンロードします
  3. プリロードをあなたのXOOPSCubeに設置します
  4. CMS Theme Finderにログインします
  5. 個人設定の「プレビューURL」に、あなたのXOOPSCubeのトップページのURLを入力します
  6. アップデート完了です
]]> CMS Theme Finderの新機能 : あなたのXOOPS Cubeでテーマをプレビューを図解 有償テーマ作者は、プレビュー機能で対価を受け取ることなく、ユーザ側にテーマが渡ってしまうのではないかと危惧するかもしれません。Previewerの仕組みは、テーマの情報をユーザにまる 2010-05-05T13:20:44Z 2010-05-05T13:01:15Z http://suin.asia/2010/05/05/cms_theme_finder_previewer 今までのXOOPS Cubeテーマの試し方

CMS Theme Finder Previewerを使ったテーマの試し方

CMS Theme Finder Previewerを導入してテーマを探すのと、そうでないのでは手間のかかりかたが全く異なります。

有償テーマの売り込みも視野に入れて

テーマは、XOOPSにおいて有償の文化が、モジュールと比べて発達しています。オープンソースの世界で金儲けするとなると、悪魔に魂を売るようなことだと避難する人がいます。しかし、私はそう思いません。オープンソースは無償である義務はありませんし、対価を支払うことで質の高いCMSの文化を作ることも可能だと考えているからです。したがって、CMS Theme Finderでは、有償テーマを歓迎し、Previewerが有償テーマの発表の場になればと思っています。

ユーザが有償テーマを選択する場合、ダウンロードするたびにコストがかかることがあります。一方、Previewerを使った場合、ダウンロードの必要がないのでコストをかけることなくテーマを自分のサイトで試すことができる利点があります。テーマ作者は今後、CMS Theme Finderで有償テーマのプレビューを許可することで、ユーザにテーマを試してもらえることになり、有償テーマの売り込みがより活発化できるのではと考えています。

CMS Theme Finder Previewerの仕組み

有償テーマ作者は、プレビュー機能で対価を受け取ることなく、ユーザ側にテーマが渡ってしまうのではないかと危惧するかもしれません。Previewerの仕組みは、テーマの情報をユーザにまるまる投げるのではなく、テーマのプレビューに必要な情報をユーザのXOOPS Cube Legacyから提供してもらい、CMS Theme Finder上でテーマのプレビューを生成する仕組みをとりました。なので、有償テーマを含め、無償再配布不可のテーマの情報がCMS Theme Finderからユーザに流れることはありません。この仕組は、ユーザにとっても利があり、テーマ作者にとっても利があると考えています。

]]> CMS Theme Finderの新機能 : あなたのXOOPS Cubeでテーマをプレビュー CMS Theme Finderでは、あなたのXOOPS Cubeでテーマをプレビューできる「自分のサイトで見る」機能を提供しています。この機能は、テーマをダウンロードしたり、自分のサーバーにアップロード 2010-05-11T07:30:24Z 2010-05-04T14:08:55Z http://suin.asia/2010/05/04/preview_at_your_xoops_cube CMS Theme Finderでは、テーマをプレビューする機能があります。ユーザはテーマが実際にどのような見た目になるのか知ることができます。そして、そのテーマが気に入ったら、ダウンロードすることができます。ところが、いざ自分のサイトに適用してみると、「思ったようなデザインと違った」ということもしばしばあります。

そこで、CMS Theme Finderでは、あなたのXOOPS Cubeでテーマをプレビューできる「自分のサイトで見る」機能を提供しています。この機能は、テーマをダウンロードしたり、自分のサーバーにアップロードしたりする手間がありません。ただ、「自分のサイトで見る」を１回クリックするだけで、あなたのXOOPS Cubeにテーマを適用した結果を見ることができます。

以下の情報は古いです。CMS Theme Finder : 不評の「自分のサイトで見る」機能を改良してみたを御覧下さい。[追記 2010/05/11]

利用要件

  • XOOPS Cube Legacy 2.1 以上
  • XOOPS Cubeがオンライン上にある(イントラネット上などは利用できません。)

セットアップ

「自分のサイトで見る」機能を使うには、セットアップをしていただく必要があります。決して難しいものでも、手間のかかるものでもありませんので、ご安心ください。

1. CMS Theme Finder Previewerをダウンロードし、解凍します。
2. 展開されたファイルの中のpreloadとthemesをあなたのXOOPS Cubeにアップロードします。

3. CMS Theme Finderのアカウントを持っている
はい
↓		 いいえ
新規アカウント登録してください。
4. 個人設定で「プレビューURL」を設定します。

プレビューURLは、あなたのXOOPS CubeのURLの末尾に「?ctfp」をつけたものになります。
たとえば、http://xoops.example.com/というURLで運用中のXOOPS Cubeであれば、http://xoops.example.com/?ctfpのように入力します。
5. セットアップ完了です。
]]> CMS Theme Finder テーマまとめサイト この度、XOOPS・XOOPS Cube Legacyのテーマ情報をまとめるサイトを立ち上げました。CMS Theme Finderというサイトです。 2010-05-01T17:08:30Z 2010-05-01T17:06:43Z http://suin.asia/2010/05/02/cms_theme_finder この度、XOOPS・XOOPS Cube Legacyのテーマ情報をまとめるサイトを立ち上げました。CMS Theme Finderというサイトです。

XOOPS、XCLのテーマをいざ探そうと思うと、テーマ作者さんのサイトごとに見に行かなければならず、サイトによってはテーマのプレビューが見れない、見づらいところもあります。また、テーマの情報をまとめているサイトもありますが、視覚的に探すという点であまり使い勝手が良くないなどの問題がありました。

そこで、テーマを総括的・視覚的に探すことができるサービスとしてCMS Theme Finderを作りました。

XOOPSを始める人は、必ずと言っていいほどテーマを探しますので、テーマが探しやすければXOOPSを選択する人や、XOOPSのコミュニティに少しながら貢献できると考えています。

今後は検索機能などを追加し、視覚的に探せる仕組みを作り上げていく計画です。今のところ、色でテーマを絞り込めるような機能を考えています

サイト名はCMS Theme Finderですが、今登録されているテーマはすべてXOOPS、XCLのものです。今後（いつになるか分かりませんが^^;;）、ImpressCMSなどXOOPSの親戚から、WordPress、Concrete5などのテーマも追加していきます。テーマは比較的移植が容易ですし、CMSを超えてテーマを探せるメリットは大きいものになると思います。

CMS Theme Finder

http://cmsthemefinder.com/

]]> Google Analyticsのトラッキングコードを追加するプリロード Google Analyticsは無料で利用できる高機能なアクセス解析サービスです。利用する場合は、サイトにトラッキングコードを追加します。XOOPS Cubeで、トラッキングコードを追加するには、普通は 2010-05-01T16:24:12Z 2010-05-01T16:17:39Z http://suin.asia/2010/05/02/google_analytics_preload Google Analyticsは無料で利用できる高機能なアクセス解析サービスです。利用する場合は、サイトにトラッキングコードを追加します。XOOPS Cubeで、トラッキングコードを追加するには、普通はテーマにトラッキングコードを書き込んでしまうのが早いです。しかし、テーマを変更することが想定される場合は、プリロードにしておくと便利です。テーマが変わってもトラッキングコードが抜ける心配がないからです。

下のプリロードはGoogleAnalytics.class.phpというファイル名で保存します。トラッキングコードを所定の場所にコピペするだけです。Google Analytics以外に、HTMLのヘッダに貼りつけたいコードがある時にも、応用できると思います。

<?php

class GoogleAnalytics extends XCube_ActionFilter
{
	public function preBlockFilter()
	{
		$this->mRoot->mDelegateManager->add('XoopsTpl.New', array(&$this, 'hook'));
	}

	public function hook(&$xoopsTpl)
	{
		$trackingCode = <<< DOC_END
//トラッキングコードをここに貼付け。
DOC_END;

		$xoopsModuleHeader = $xoopsTpl->get_template_vars('xoops_module_header');
		$xoopsTpl->assign('xoops_module_header', $xoopsModuleHeader.$trackingCode);
	}
}

?>
]]> DynamicThemeChanger 1.0.0 URLで動的にテーマを切り替えるプリロード DynamicThemeChangerはURLで指定したテーマに切り替えるプリロードです。テーマ配布サイトがテーマのプレビューを示すことを想定して作りました。プリロードをアップロードすることで、URLで?t 2010-04-21T14:48:50Z 2010-04-21T14:43:47Z http://suin.asia/2010/04/21/dynamic_theme_changer_100 ダウンロード

DynamicThemeChangerはURLで指定したテーマに切り替えるプリロードです。テーマ配布サイトがテーマのプレビューを示すことを想定して作りました。プリロードをアップロードすることで、URLで?theme={テーマディレクトリ名}の形でテーマを指定すると、そのテーマに切り替わります。

]]> XOOPSがUTF-8に統一するメリット・デメリット XOOPSがUTF-8に統一するメリット・デメリット 2010-04-07T15:30:25Z 2010-04-06T03:43:39Z http://suin.asia/2010/04/06/xoops_utf-8 開発者のメリット
  • 日本語の場合、ja-utf8とjapanese(EUC-JP)の２つの言語ファイルを用意する手間が省ける
  • AjaxはデフォルトがUTF-8なので、Ajaxの開発が加速する
  • 外部との通信規格(RSS、XML、APIなど)で、UTF-8がデフォルトだったりする
  • mb_convert_encodingの失敗などの不安が減る
  • 様々な規格がUTF-8に移行しつつある(XHTMLはデフォルトでUTF-8か16)
  • テーマをUTF-8で作って、さくっと全世界に向けてリリースできる

サイトオーナのメリット

  • 非アルファベット圏の多言語対応が容易になる
    英語と日本語、ロシア語と日本語であればEUC-JPでも対応出来ないことはない。しかし、日本語と韓国語・中国語のようなケースではUTF-8のほうが断然やりやすい
  • ひとつのウェブサイトに多言語を埋込みやすくなる
    ひとつのフォーラムに、日本語のフォーラム、中国語のフォーラムを作ることができる。

デメリット

  • EUC-JPに比べUTF-8は漢字コードのバイト数が1.5倍になる。
    漢字コード100MBの転送量が150MBになる。
  • 古いブラウザ、古いOS、古いエディタを切り捨ててしまう
  • 携帯電話に対応出来ない
  • 稼働中のサイトの場合、EUC-JPからUTF-8に移行するのが手間

こんなもんかな？

]]> WhiteoutRescue 真っ白画面解決支援プリロード WhiteoutRescueプリロードは、ホワイトデイに「真っ白」画面を出さないためのプリロードです。ホワイトデイに真っ白画面に出くわしたサイトオーナーがこのプリロードをアップロードします 2010-03-11T15:59:48Z 2010-03-11T15:19:16Z http://suin.asia/2010/03/12/whiteoutrescue_preload WhiteoutRescue_1.0.zip ホワイトデイ(3月14日)は、一般には男子が女子にクッキーをあげる日ですが、XOOPSユーザにとっては厄日だそうです。XOOPSオーナーが最も嫌うのは、エラーなどでXOOPSの画面が「真っ白」になることです。ホワイトデイの「ホワイト」が「真っ白」を連想させることもあり、ホワイトデイに「真っ白」画面が出ると、その年のXOOPS運が大殺界であることを意味するそうで、縁担ぎのために3月14日の1日だけXOOPSを止めたり、熱心なXOOPS関係のデベロッパーの中にはこの日だけ開発を休んだりするそうです。

WhiteoutRescueプリロードは、ホワイトデイに「真っ白」画面を出さないためのプリロードです。ホワイトデイに真っ白画面に出くわしたサイトオーナーがこのプリロードをアップロードします。そして、真っ白画面のページにアクセスすると、黒背景を基調としたデバッグページが現れます。サイトオーナーはそのデバッグ情報をたよりに真っ白画面を解消します。このように、真っ白画面を直すことで、厄払いの意味になり、その年のXOOPS運が大安になると言われています。

動作要件

  • XOOPS Cube Legacy 2.x
  • PHP 5.1 (5.2からかも)
  • UTF-8環境(EUC-JPでも動くことは動く)

WhiteoutRescueプリロードの使い方

XOOPSオーナーに伝わるWhiteoutRescueプリロードの使い方は以下のようです。

  1. WhiteoutRescue.class.phpを/preloadにアップロードする
  2. 真っ白のページにアクセスする
  3. 表示されたデバッグ情報をもとに問題を解決する
  4. 使い終わったら、WhiteoutRescue.class.phpを削除する

なお、使い終わってもWhiteoutRescueプリロードを削除しないでいると、XOOPSのセキュリティやパフォーマンスが低下し、XOOPSが白い悪魔に取り憑かれるそうなので、必ず削除するようにしましょう。

WhiteoutRescueを使っても真っ白のままの場合、以下のことが考えられます。

  • プリロード読み込み以前にXOOPSがこけてる
  • PHPのパースエラー（セミコロンがダブルコロンだ、など）この場合はPHPのエラーログを参照
  • サーバーの問題 (.htaccessの設定ミスなど)
  • そもそもXOOPS Cube Legacyじゃない
  • しかるべくして真っ白なページ

ライセンス

GNU GPL2ライセンスです。動作無保証です。あなたは、GPL2の条件をみたせばこのプログラムを改変・頒布することができます。

リポジトリ

svn checkout http://suin-xoops.googlecode.com/svn/trunk/WhiteoutRescue suin-xoops-read-only

[訂正 2010/03/12]

XOOPSオーナーの間で、3月14日が厄日などの記述がありましたが、実際にはそんな習慣はないそうです。教えてくれたwhite_devilさんありがとうございます。

]]> SubversionでのPreloadの管理方法 Preloadをバージョン管理するとき私が行っている方法を紹介しようと思います。ディレクトリごとにバージョン管理する場合、開発中のプリロードを/preloadディレクトリにおいてしまうと、他 2010-03-11T08:54:56Z 2010-03-11T08:14:45Z http://suin.asia/2010/03/11/how_to_manage_preloads_with_subversion Preloadをバージョン管理する便利な方法を紹介しようと思います。ディレクトリごとにバージョン管理する場合、開発中のプリロードを/preloadディレクトリにおいてしまうと、他のプリロードまでバージョンされてしまいます。こういう場合では、/preloadにサブディレクトリを作って、そこでバージョン管理したほうが管理性が向上します。

I will introduce you how to develop preloads with Subversion. If you put your preloads under /preload directory, it is difficult to manage the versions of its. Because, Subversion treats not only your preload but also the other ones. In such a case, you can make subdirectories under /preload. This way helps you to increase your manageability.

配布することを考えれば、サブディレクトリにLicense.txtやReadme.txtを置くといいでしょう。そうしておくと、svn -exportでプリロードの配布パッケージが簡単に生成できます。

If you plan to distribute your preload, you may put License.txt or Readme.txt under the subdirectory. It is a smart way. You only have to command "svn -export" at the subdirectory when you distribute it.

ディレクトリの構成方法

/XOOPS_ROOT_PATH
	/preload
		/VersionedPreload.class.php (a)
		/VersionedPreload
			/.svn
			/VersionedPrelaod.class.php (b)
			/License.txt
			/Readme.txt

VersionedPreload.class.php (a)のソース

<?php

$file = basename(__FILE__);
$dir  = str_replace('.class.php', '', $file);

require $dir.'/'.$file;

?>

(a)はただ、requireするだけです。（プロキシと言ったラインだろうか。）このサンプルソースはどんなプリロードにもそのまま流用できます。なぜなら、ファイル名を動的に取得しているからです。/preloadディレクトリに(a)をひとつ作っておけば、新しくプリロードを作る度に、コピーして名前を変更するだけでいいので便利です。

The (a) only includes your preload. You can apply this sample to your any other preloads. Because, this sample get the file name dynamically. If you create the (a) once, you only have to copy and rename it, when you create a new preload. It is useful.

VersionedPreload.class.php (b)のソース

<?php
/**
 *
 * @package    Versioned Preload
 * @author     Foo Bar <http://example.com/>
 * @copyright  2010 Foo Bar
 * @license    http://www.gnu.org/licenses/gpl-2.0.html GNU GPL v2 or later
 *
 */

if ( !defined('XOOPS_ROOT_PATH') ) exit;

class VersionedPreload extends XCube_ActionFilter
{
	public function preBlockFilter()
	{
		$this->mRoot->mDelegateManager->add('Delegate.Name', array(__CLASS__, 'doSomething'));
	}

	public static funciton doSomething(&$param)
	{
		// Do something here.
	}
}
?>

(b)では、プリロードを作るときの普段どおりの書き方をするだけです。とくに変わったことをする必要もありません。

]]> XOOPS Cubeと他のCMSの用語対比 XOOPS Cube Legacyでは、ブロックでPHPがかけるけど、Joolma!のモジュールのように配布はできない。XOOPS系では言語パッチは特に拡張機能というノリではない。 2010-03-08T15:29:05Z 2010-03-08T15:22:40Z http://suin.asia/2010/03/09/xoops_cube_terms_vs_other_cms XOOPS Cube Drupal Joolma! モジュール モジュール コンポーネント ブロック ブロック モジュール プリロード ? プラグイン 言語 言語 言語 テーマ テーマ テンプレート

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

]]> XOOPSのモジュールはGPL2で配布しないといけない？ 特殊なケースを覗いて、モジュールのライセンスはXOOPS2に引っ張られてGPL2にしなければならないようです。GPL2では、「プログラム」の派生物（二次的著作物）はGPL2でなければならないと定 2010-03-07T07:15:05Z 2010-03-06T16:44:23Z http://suin.asia/2010/03/07/xoops_module_must_be_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に書いてあります。

]]>