AGPLはどう機能しますか？
AGPLはコピーレフトです。ソフトウェアやその改変版を配布する場合は、変更点を同じライセンスで公開し、対応するソースを提供しなければなりません。ここまではGPLも同じです。AGPLが加えるのは、ネットワーク利用をきっかけとする義務です。ユーザーがホスト型のサービスとしてソフトウェアを利用し、コピーが一度も手渡されないケースを対象にします。オープンソースのマーケティングオートメーションをはじめ、サーバーソフトウェアをつくるプロジェクトがAGPLを選ぶのは、この1点の追加があるからです。
ネットワーク利用条項（第13条）は何を求めていますか？
第13条は、AGPLのソフトウェアを改変し、その改変版とユーザーがネットワーク越しにリモートでやり取りできるようにする場合、そのユーザーに対して、改変版の対応するソースを無償でダウンロードできる形で、目立つように提供しなければならないと定めています。対象は改変部分です。改変していないコピーをサービスとして動かすだけでは、それ自体で新たに何かを公開する義務は生じません。義務の相手は、バイナリを手渡した相手だけではなく、ネットワークサービスを利用する人々です。
AGPL、GPL、MITの違いは？
| ライセンス | コピーレフトの強さ | ネットワーク利用で義務が発生 | プロジェクトの例 |
|---|---|---|---|
| MIT | なし（寛容型） | なし | Novu、Dittofeed |
| GPLv3 | 強い（配布時） | なし | Mautic |
| AGPL-3.0 | 強い（配布時とネットワーク利用時） | あり（第13条） | listmonk、fromHello |
小さなチームにとってなぜ重要か
2〜3人のチームにとって、ライセンスは事務手続きではなく戦略上の選択です。AGPLなら、コードを公開しつつ、より大きな競合が自社とまったく同じサービスをクローズドソースで動かすことを思いとどまらせられます。競合は、加えた変更のソースをユーザーに提供する義務を負うからです。中身を確かめてセルフホストしたい購入者にも安心を与えます。ソースは好意ではなく、権利だからです。オープンソースとSaaSのマーケティングツールの比較を読みながら、寛容型ライセンスと比べて検討してください。トレードオフは、普及の広さか、互恵性かです。ここではライセンスの書かれ方を説明しており、法的な助言ではありません。