Dixlaseの思想

現時点(v0.x)では、本格的な本番運用を強くお勧めする段階にはありません。コア機能と一部の公式プラグインは動作しますが、APIの安定化やドキュメントの整備を進めている最中です。v0.x の間は、今後のリリースで互換性のない変更(破壊的変更)が入ることがあります。変更は CHANGELOG でお知らせします。

評価・検証用途、社内ツール、プラグイン開発の練習用途などには問題なく使えます。本番運用は v1.0 リリース以降 を推奨します。早期にお試しいただいた方からのフィードバックは、開発に直接反映していきます。

はい、無料です。Dixlase の コアは AGPL ライセンスで無料公開 しており、誰でも自由に利用・改変・再配布できます。公式プラグインも GPL で無料提供 されます。

ただし、コアを改変 して使う場合で、以下のように改変したソースコードを非公開のまま運用したいケースでは、別途 商用ライセンス のご検討が必要です。

• 改変版をベースにした SaaS提供、ホスティング事業
• コアを改変して構築する受託案件で、公開サイトでも改変版を非公開にしたい場合
• クローズドソースを前提とした商用製品への組み込み
• コアを改変した上で、セキュリティ要件により改変版を非公開のまま運用する必要がある企業・自治体

コアを改変せず、機能追加はプラグインやテーマで行う通常の運用であれば、ソースコードの公開義務は発生しません。

AGPL(Affero General Public License)は、GPL に「ネットワーク条項」を加えたコピーレフト型のオープンソースライセンスです。Dixlase のコアはこの AGPL バージョン3で公開されています。

通常の GPL では、改変版を「頒布(配布)」したときにソースコードの公開義務が生じます。しかし改変版を配布せず、ネットワーク越しのサービスとして提供する場合は頒布とみなされないため、改変版を非公開のまま運用できてしまいます。AGPL 第13条「Remote Network Interaction」は、改変版をネットワーク経由で利用できる状態にした場合にもソース取得手段の提供を義務化することで、この抜け穴を塞ぎます。

正確な条件は AGPL 第13条「Remote Network Interaction」に定められています。詳しくは GNU AGPL-3.0 の原文(英語) をご参照ください。

Dixlase のコアは、改良が公開され続ける状態を保つために AGPL を選びました。

GPL のコピーレフトは「頒布(配布)」を引き金にするため、改変版を配布せず、ネットワーク越しのサービスとして提供する場合には、ソースを公開する義務が生じません。この形が広がると、改良が公開されないまま使われ続けることになります。AGPL 第13条は、改変版をネットワーク越しに利用させる場合にも、利用者にソースの取得手段を提供することを求め、この差を埋めます。

この第13条が関わるのは、コアを改変した版を、ネットワーク越しに利用させる場合です。コアを改変せずに導入し、プラグインやテーマで機能を加える制作会社や一般の利用者に、この条項による公開義務は生じません(プラグインやテーマ自体のライセンスについては FAQ「プラグイン・テーマ例外条項(LICENSE-EXCEPTIONS)とは何ですか?」をご覧ください)。

将来的には、非公開のまま利用する道を商用ライセンスで用意する計画です(初期リリース時点では未提供。詳しくは FAQ「商用ライセンスはいつ提供されますか?」をご覧ください)。

Dixlase コアを改変し、その改変版をネットワーク越しに利用できる状態にすると、AGPL 第13条により、その稼働サイトのネットワーク利用者全員にソースコードの取得手段を提供する義務が生じます。この「利用者」には管理者やログインユーザーだけでなく、公開ページを閲覧するだけの一般訪問者も含まれます。コアを改変している限りサイト全体が「改変版」となるため、フロントページやプラグイン生成ページを見ているだけの訪問者も対象です。

開示義務が生じるかどうかは、コアを改変したかと、改変版をネットワーク越しに使う利用者がいるかの2点で決まります。具体的には次のとおりです。

• ローカル環境での試作・カスタマイズ・バグ修正・セキュリティパッチ開発など、手元で動かしているだけの段階 → 開示義務は発生しません
• 社内限定での運用 → 一般大衆への公開義務は発生しません(社内の利用者にソース取得手段を提供する形に限られます)
• 自社サイト・個人サイト・受託案件のいずれであっても、コアを改変したものを一般公開のウェブサイトとして運用 → 訪問者全員への開示義務が発生します(営利・非営利や運営主体は問われません)
• コアを改変せず、機能追加をプラグインやテーマで行う(プラグインやテーマ自体の改変を含む) → 開示義務は発生しません(プラグイン・テーマ例外条項の対象)
• 商用ライセンスを取得 → この開示義務は免除されます

機能追加はプラグインやテーマで行うのが Dixlase の前提であり、通常のクライアント案件でコアそのものを改変する必要が生じることはほとんどありません。コアの改変版を非公開のまま一般公開サイトで運用したい場合は、商用ライセンスの取得をご検討ください。

自社サイトの運用・社内利用・サイト構築の受託案件・OSS貢献を前提とした開発は、コアを改変しない限り AGPL で問題ありません。機能追加はプラグインやテーマで行うのが Dixlase の前提です。

コンテンツ生成機能や問い合わせフォームの追加は 公式プラグインの利用や開発を、デザイン変更は 公式テーマの利用や自作をおすすめします。いずれも GPL と商用ライセンスで提供され、そのまま使っても改変しても、一般大衆へのソース公開義務は発生しません。サードパーティ製を使う場合は配布元のライセンスをご確認ください。

一方、コアを改変したものをソース非公開のまま運用したい場合や、クローズドソース を前提とした商用製品へ組み込む場合は、商用ライセンスをご検討ください。開示義務の発生条件(ローカル開発や社内利用は対象外)は FAQ「コアを改変した場合、どんなときに開示義務が発生しますか?」を、判断に迷う場合はお問い合わせください。

商用ライセンスの提供は予定していますが、現時点では 契約条件・料金体系などを策定中 です。提供準備が整い次第、順次アナウンスいたします。

早期にご検討いただける場合は、お問い合わせください。導入予定の用途やご要望をお聞かせいただければ、提供開始時の優先案内などの対応も可能です。

初期リリース時点では、Dixlase本体に標準搭載される機能(セキュリティ、認証、フロントページ、監査ログなど)に加え、ページ作成・お問い合わせ・メニュー・SEO・Cookie 同意の 5 つの公式プラグインを同時に提供します。ブログ・カスタム投稿・カスタムフィールドなど、より高度な用途に向けたプラグインは、準備が整ったものから順次公開し、v1.0 以降も継続して拡充していきます。

サードパーティのプラグインエコシステムは、これからコミュニティとともに育てるフェーズです。プラグインAPIは公開済みのため、Laravel開発者の方ならすぐに開発を始められます。ベータ期間中の変更は CHANGELOG でお知らせします。

はい、新規開発が可能です。Dixlase では プラグイン・テーマ開発キット をプラグインとして提供予定です。これをインストールすると、雛形生成やビルド支援、APIリファレンスなどの開発支援機能が利用できるようになり、迅速に開発を始められます。

公開済みのプラグインAPIと組み合わせることで、Laravel開発者の方なら慣れ親しんだ書き方でそのまま機能を実装できます。

Plugin API の境界を守って実装する限り、プラグイン・テーマ例外条項により、派生物に該当するか否かにかかわらず AGPL の要件が適用されず、開発者は自身のコードの著作権を保持したまま、GPL・MIT・商用・プロプライエタリなど ライセンスを自由に設定 できます(詳しくは FAQ「プラグイン・テーマ例外条項(LICENSE-EXCEPTIONS)とは何ですか?」をご覧ください)。

サイトの運用者(管理画面からコンテンツを更新する方)にLaravelの知識は必要ありません。GUIだけで操作できます。

Laravelの知識が活きるのは、プラグインやテーマを開発する場合です。Laravel経験者であれば、慣れ親しんだ書き方でそのまま開発を始められます。Laravel未経験でも、PHPに触れたことがある方なら学習コストは比較的低めです。

現時点では、WordPress やほかのCMSからの自動移行ツールは提供していません。記事や固定ページの内容については、各CMSのエクスポート機能を使って書き出したデータを、手動でDixlaseに取り込むことは可能です。ただし、テーマ、プラグイン、ショートコードはそのまま動きません。

移行ツールやコンテンツ引っ越し支援プラグインについては、ご要望があれば提供を検討します。もしくは、ほかのユーザーの方に移行ツールやプラグインを開発していただくのも大歓迎です。

現時点では、GitHub Issues でのバグ報告・質問対応、コミュニティでの議論を歓迎しています。

法人向けの有償サポート(導入支援、優先対応、SLA保証など)は、v1.0 リリース後に体系的に整備していく予定です。早期にサポート契約をご希望の場合は、個別にご相談ください。

Dixlaseは exc-D inc. の中核事業として開発を進めており、AGPLによる無償提供と、商用ライセンス・有償プラグイン・サポート契約を組み合わせた、持続可能な収益モデルを構築していく計画です。

また、ソースコードは GitHub に公開しているため、仮に開発元の体制に変化があったとしても、第三者がフォークして開発を継続することが技術的に可能です。AGPLのソースコード公開義務は、長期利用者にとってのセーフティネットとして機能します。

現時点でサポートする言語は 日本語と英語のみ です。それ以外の言語については、ご要望が一定数集まった段階で順次検討します。

対応してほしい言語があれば、お気軽にご要望をお寄せください。

現在は、コードの Pull Request は外部から受け付けていません。
Issue でのバグ報告・機能提案・議論は引き続き歓迎しています。
機能のご提案の際は、コアに入れるべき機能か、プラグインとして実現できるかもあわせてご検討いただけると、議論がスムーズです。

受付を保留しているのは、次の理由からです。

• コア設計・プラグインAPIの安定化を優先しているため
• 初期リリース後の運用を安定させ、利用者からの反響や利用状況を見極めてから、受付を開始するタイミングを判断したいため

Dixlase のライセンスの性質上、コントリビューションの受付には CLA(コントリビューターライセンス契約)の用意が必要です。法務レビューを経た CLA を整えたうえで受付を開始し、その際に改めてお知らせします。コントリビューションの流れは CONTRIBUTING.md を、CLA については下記の FAQ「CLA とは何ですか?」をご覧ください。

CLA(Contributor License Agreement / コントリビューターライセンス契約)は、Dixlase のデュアルライセンス方式(AGPL + 商用ライセンス)を支えるための仕組みです。コアに取り込むコントリビューションを含めて再ライセンスできるよう、外部コントリビューターから同意をいただく必要があります。コードの著作権はコントリビューターに帰属し、デュアルライセンスを支えるためのライセンス許諾と、その行使を妨げない範囲での同意をいただく形です。

著作権の取り扱いについては COPYRIGHT-POLICY.md をご覧ください。CLA の全文は法務レビュー完了後、受付開始と同時に公開します。

CSP(Content Security Policy)は、Webサイト上で実行できるスクリプトや読み込めるリソースをブラウザレベルで制限する標準の仕組みです。Dixlase は最初から本番運用に耐える水準の CSP を強制送信します。

目的は、プラグイン・テーマやコンテンツに混入しうる悪意あるスクリプトの実行を防ぐ ことです。XSS(クロスサイトスクリプティング)によるサイト改ざん・情報漏えい・認証情報の盗取を未然にブロックします。

Dixlase が標準モードで送信する CSP の特徴:

• nonce ベースのスクリプト制御 — Dixlase 自身が発行したスクリプトのみ実行可能
• インラインイベントハンドラの完全ブロック — onclick 等の属性経由の攻撃を遮断
• 管理画面のクリックジャッキング対策 — 管理画面の iframe 埋め込みを既定で禁止
• 同一オリジン優先 — フォーム送信先・iframe 埋め込み先・ベース URI を自オリジンに限定
• 動的な許可 — CAPTCHA や外部 CDN は使用時のみ許可される
• 違反の可視化 — 違反レポートを管理画面で集約して確認できる

運用者は2つのモードを選べます。開発モードは違反を記録のみ(Report-Only)とし、開発時に違反箇所を発見しやすくします。標準モードは違反を強制ブロックし、本番運用に推奨されます。Dixlase は標準装備で、設定漏れのリスクを最小化します。

なお、最も厳しい 厳格モード(strict mode) は初期リリースには含まれていません。Alpine.js のバンドル切替、Trusted Types ポリシーの整備、独自ブートローダーの導入など、エコシステム全体に影響する作業が必要なため、今後のバージョンアップで対応予定です。

プラグインが利用できる API・データベース操作・ファイルアクセス・外部通信などを、プラグインごとに 明示的な権限 として宣言する仕組みです。コアはこの宣言と実際のコードを 静的解析 で照合し、宣言外の API 利用や危険な API 呼び出しを検出します。検出結果は 健全性スコア(0〜100点)に反映され、しきい値を下回るプラグインはインストール・有効化がブロックされます。

この仕組みは以下を目的とした 多層防御モデル です:

• プラグインが使う権限が事前に明示され、運用者が把握できる
• 危険な API(exec、eval など)の利用が静的解析で検出される
• 署名検証と組み合わせ、改ざんやなりすましをインストール前に弾く
• プラグイン作者と利用者の間で「何ができるか」が明示的になり、監査が容易になる

他の CMS では、1つのプラグインの脆弱性でサイト全体が乗っ取られる事例も報告されています。完全な解決には サンドボックス化(WebAssembly や別プロセス分離などの実行隔離)が有効ですが、Dixlase では 現在まだ提供していません。その代わり 権限宣言・静的解析・署名検証・健全性スコア の組み合わせで、リスクのあるプラグインがそもそもインストールされないよう設計レベルでゲートしています。

サンドボックス化については こちらの FAQ をご覧ください。

サンドボックス化とは、プラグインが使える API・ファイル・メモリ・ネットワークなどを、OS・プロセス・仮想マシン・WebAssembly ランタイムなどのレベルで実行時に隔離する 仕組みです。プラグインに脆弱性や悪意あるコードがあっても、隔離環境の外に影響が及ばず、サイト全体やデータベースが構造的に守られます。

Dixlase は PHP ベースの CMS で、プラグインはコアと同じプロセス内で実行されるため(WordPress・Drupal など PHP ベース CMS に共通の特性)、完全なサンドボックス化はまだ提供していません。その代わり 多層防御モデル でリスクを管理しています:

• 権限宣言: プラグインが使う API を plugin.json で明示
• 静的解析: 危険な API 呼び出しと宣言外の権限利用を自動検出
• 署名検証: Ed25519 で改ざんとなりすましを検出
• 健全性スコア: 0〜100点で評価、しきい値以下はインストールをブロック

今後のバージョンアップで、より強固な隔離(サンドボックス化)を段階的に進めてまいります。

プラグインやテーマは外部から入手するため、配布途中で 改ざん される、または なりすまし の偽物が出回るリスクがあります。Dixlase は配布元の電子署名を検証することで、提供されたコードが正規のものかをインストール前に確認します。署名検証に失敗したプラグインはインストールがブロックされます。

他の CMS では、改ざんされた偽物のプラグインやテーマがインストールされたことによる、実際の不正アクセス・情報漏えい・暗号通貨マイニング埋め込みなどの被害事例が報告されています。サプライチェーン攻撃と呼ばれるこの種の攻撃は、運用者が気付きにくいのが特徴です。

署名検証を標準の仕組みとして組み込むことで、こうした攻撃から運用者と訪問者を構造的に守ります。

AGPL のような「コピーレフト」ライセンスでは、AGPL のソフトウェアと連携するコードも AGPL の対象になる(ライセンスの伝搬)のが一般的です。これに対して Dixlase は、Plugin API を介してコアと連携するプラグインやテーマについて、それらが派生物に該当するか否かにかかわらず、AGPL の要件を適用せずに頒布できる という追加許可(例外条項)を独自に設けています。

この例外条項を適用できるプラグイン/テーマは、作者が 完全な著作権を保持 し、GPL、MIT、商用、プロプライエタリなど 独自のライセンスで自由に配布 できます。AGPL の義務を負いません。

ただし、これは 一方向の例外 です。コアコードを直接改変したものを「プラグイン」と再定義することで AGPL の義務を回避することはできません。例外条項の対象になるのは、Plugin API の境界を守って実装されたプラグイン・テーマだけです。

条項の正本は LICENSE-EXCEPTIONS に、Plugin API の境界定義は PLUGIN-API.md に記載されています。