AGPLのOSSをSaaSで提供できるのか

01まず条文を読む

AGPL-3.0が GPL-3.0 に対して追加している条項は、実質的に第13条ひとつだけです。その第1文がこれです。

Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge ...

— GNU Affero General Public License v3.0 §13 第1文

短い文ですが、条件と範囲が全部ここに入っています。分解します。

比較すると分かりやすいので、MongoDBが後から作った SSPL の第13条を並べます。SSPLは同じ「第13条」に、まったく違うことを書きました。

そして重要なのは、MongoDB自身がその理由を公式に説明していることです。

The only additional requirement of AGPL is in section 13: if you run a modified program on a server and let other users communicate with it there, you must open source the source code corresponding to your modified version... There is some confusion in the marketplace about the trigger and scope of the Remote Network Interaction provision of AGPL. As a result, we decided to base the SSPL on GPL v3 and to add a new section 13 ...

— MongoDB「Server Side Public License FAQ」

02では「改変」とは何か

発動条件が改変だと分かると、次の問いは当然「どこからが改変か」になります。ここは条文にも判例にも答えがありません。正直に、はっきりしている端と、分からない真ん中を分けて書きます。

03公開する相手と、公開する範囲

仮に改変して第13条が発動したとして、次は「何を、誰に」です。

相手

条文は "all users interacting with it remotely through a computer network" です。そのサービスをネットワーク越しに使っている人であって、全世界ではありません。GitHubで一般公開するのは、個別に配る手間を省くための運用上の簡便策であって、条文がそれを求めているわけではありません。

範囲＝Corresponding Source

GPL-3.0 §1 の定義がそのまま使われます。

The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work.

— GNU General Public License v3.0 §1

なお実務上は、Corresponding Sourceの大部分は既に公開されている上流のコードです。つまり新たに開示することになるのは、実質的に自分が加えた差分です。

04実際に、無改変でやっている事業者

条文の読み方だけでは机上論なので、実際にAGPLのソフトをホスティング提供している事業者を2つ調べました。

Hetzner Storage Share（Nextcloud）

ドイツのHetznerは、Nextcloud（AGPL）ベースのマネージドサービスを月額€4.29（税別・1TB）から提供しています。同社は製品ページのFAQで、機能追加の要望に対してこう答えています。

Unfortunately, we at Hetzner Online cannot add any features to Storage Share since we have not developed this software ourselves. Storage Share is based on the open source software from Nextcloud. However, you can make a feature request by going to the official Github repository ...

— Hetzner Storage Share 製品ページ FAQ

※この文は「自社で開発していないので機能追加できない」であって、「ソースを一切改変していない」と明言したものではありません。そのまま引用しています。

Masto.host（Mastodon）— ここで自分の想定が外れました

Mastodonのホスティング事業者 Masto.host について、私たちは当初「フォークをAGPLで公開して第13条に準拠している例」として紹介するつもりでした。確認したら違いました。

同社の記述もこれと一致します。利用規約に「All installations will be made using the base Mastodon repository」、ヘルプに「All plans will use the latest stable release of Mastodon」「Custom Mastodon forks, other Activity Pub software and code changes are not supported」とあります。

05争いのある論点（断定を避けます）

ネット上で「こうすれば大丈夫」と説明されがちだが、実は決着していない論点を挙げます。

「集合著作物（aggregate）だから大丈夫」は言い過ぎ

「課金機能や管理画面は別プロセスにすれば §5 の集合著作物になるから義務が及ばない」——私たち自身、以前この説明を書いていました。条文を読むと、そこまで言い切れません。

§5の当該部分は、「in or on a volume of a storage or distribution medium（記録媒体または頒布媒体の上で）」のコンパイルについて述べており、条文の見出しも "Conveying Modified Source Versions"（改変ソース版の頒布） です。つまり頒布についてのセーフハーバーであって、文面上は「別コンテナで並べて動かす運用」を扱った規定ではありません。

そしてFSF自身が、この境界について答えを持っていないことを認めています。

Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide.

— GNU ライセンスFAQ「Mere aggregation」

その他、答えの無い論点

• デプロイ設定・IaCがCorresponding Sourceに含まれるか（条文にその語は無い・裁判例なし）
• 設定変更・テーマ・プラグインが「改変」に当たるか（同上）
• 義務が一般公衆に及ぶか、利用者に留まるか（条文は後者を支持するが、判断した裁判所は無い）

06判例はあるのか

AGPL関連でよく引かれる Neo4j 対 PureThink 訴訟は、この問題を扱っていません。実際の中身はこうでした。

07では、なぜAGPLを避けるのか

ここまでの話をまとめると、「AGPLだから法的に危険」という理由は、思っていたより薄いことになります。では避ける理由は何か。調べた結論は法務ではなく競争構造でした。

理由①：AGPL化の目的が「第三者のSaaS化を止めること」なので、必ず本家のクラウドがある

実例が並びます。Grafana Labs は 2021年4月21日に Grafana / Loki / Tempo を Apache-2.0 から AGPLv3 へ変更しました。Zitadel は 2025年3月13日に発表し、v3.0（2025年3月31日）から AGPL になりました。いずれも自社クラウドを持っています。

理由②：実際に競合を止めているのは、ライセンスではなく商標

これがいちばん実務的に効く発見でした。Plausible Analytics の例です。

理由③：導入先がAGPLを禁止していることがある

Googleは公式に全社禁止を明記しています。

WARNING: Code licensed under the GNU Affero General Public License (AGPL) MUST NOT be used at Google.

— Google Open Source Documentation「AGPL Policy」

そしてここも正直に書きます。「大手はどこもAGPLを禁止している」と語られがちですが、実際に方針を公開している企業は限られます。

08判断フロー

ここまでを実務の手順に落とします。各段階で「条文に書いてあること」と「解釈」を分けているのがポイントです。