このエントリーはSayanさんによるUnderstanding the AGPL: The Most Misunderstood Licenseの日本語訳になります。

オープンソースの出現は、ソフトウェア産業全体を一変させました。しかし、オープンソースのコードを使って誰が何をできるかを管理することは課題でしたし、今も解決していません。オープンソースライセンスはそこに救いの手を差し伸べました。しかし、常に次のことを忘れないでください：石のない土地はなく、骨のない肉はありません。OSI（オープンソースイニシアチブ: オープンソースを促進することを目的とする組織）が承認したライセンスは80以上あり、その数はさらに増加しています。それぞれのライセンスには利点と欠点があるため、オープンソースの開発者は自分のプロジェクトにあったライセンスを選ぶのは簡単ではありません。Affero General Public Licenseの略称であるAGPLはこれらのライセンスの1つで、より具体的には強いコピーレフト・ライセンスであり、間違いなく最も誤解されているライセンスの1つでしょう。

なぜ別のGPLが必要なのか?

待って、待って? もう1つのGPL? うーん、そうです。AGPLはGPLは以下の内容が第13節に追加されている点を除くとほとんど同じです。

八田真行さんのAGPLライセンス訳から引用

本許諾書に含まれる他の条件に関わらず、あなたが『プログラム』を改変した場合、改変したバージョンは、そのバージョンとリモートでコンピュータネットワークを介し対話的にやりとりする（あなたのソフトウェアがそのようなインタラクションをサポートしている場合）すべてのユーザに対して、ネットワークサーバから、あなたのバージョンに『対応するソース』にアクセスする手段を、無償、かつソフトウェアのコピーを円滑に行う上で標準的、慣習的に用いられる方法で提供することにより、ユーザが『対応するソース』を受け取る機会を明示的に与えなければなければならない。[…]

これは1つの直接的な意味を持ちます。もしあなたがユーザにネットワークを通じてAGPLでライセンスされたソフトウェアにアクセスさせるならば、それは配布の一形態と見なすということです。これは、GPLが見落としていた点です。クラウドがブームになる時代となり、SaaSは爆発的に普及し、開発者とベンダーはソフトウェアを直接配布する代わりに、ソフトウェアをデジタルで配布するようになりました。

ボブが開発したバイナリアプリケーション（ライブラリではない）を例にとって考えてみよう。表現の都合上、これをXBinと呼ぶことにします。このアプリケーションは、ウェブアプリがリソースを使い切ったときに、自動的に追加のリソースを割り当てる機能があります(追記: これはサンプルです)。

ステップ1：ボブがGPLを使う

ボブはGPLを使うことにしました。ユーザーはみな、バグを見つけたり、機能を追加してほしいときはいつでも、彼にパッチを送ることができ、ボブにとっては最高のライセンスでした。ボブは喜んで彼らのコードをマージし、幸せな気分に浸っていました。しかしある日、彼は大手クラウドプロバイダーであるProviderXが、XBinにより多くの機能を追加した上で、自社のプロジェクト管理スイートの一部として提供していることを知りました。しかし、XBinを改善するためのパッチをProviderXに送ってもらうことを望んでいたボブには嬉しくありません。GPLがネットワークを通じた配布を考慮していないため、今はボブには合法的に何かを行うことはできません。

ステップ2: ボブがAGPLに切り替える

GPLライセンスの欠点に気づいたボブは、次のリリースからAGPLに切り替えました。これで、ProviderXが何か変更を加え、それをサービスとしてユーザに配布したときは、いつでも、同じライセンスのもとでソース形式で変更を利用できるようにしなければならなくなりました。したがって、ボブはProviderXによってなされた改良を彼自身のソースコードにマージできるのです。これはフェアプレーです。それ以来、ボブはずっと幸せにコーディングをしています。

受け入れの問題

しかし、クラウドの大物はこれが気に入りませんでした。いくつかの会社はAGPLに対して独自のポリシーを持っていて、AGPLの採用や使用に反対し、有害だと声を上げる者まで出始めました。しかし、AGPLの採用はいくつかのSaaSプロバイダーの間で増え続けており、DBaaSプロバイダーは最も積極的に適用しています。ほとんどの人が見逃していますが、AGPLはネットワーク配布も配布としている点だけが異なるGPLのスーパーセットに過ぎません。

さて、AGPLでライセンスされたバイナリを使う場合の賛成と反対を見てみましょう。私のプロジェクト、Skytableを例にとって説明します。

シナリオ1: 改変せずにAGPLバイナリを使う

再びボブに登場してもらいましょう。しかし、今回は逆にAGPLライセンスのデータベースであるSkytableをデータの保存に使う、ウェブアプリを構築しようとしています。彼のアプリは、人々がサインアップして自分の好きな本を保存できます。このデータはAGPLライセンスのデータベースに保存されます。

ボブの悩み: 自分のアプリのコードをオープンソースにしなければならないのか？
答え: いいえ！ AGPLはボブのアプリとは何の関係もありません! ボブはデータベースに手を加えておらず、単にバイナリ形式で「そのまま」使っているだけなので、彼は自分のアプリを改良する以外に何もする必要がありません!

シナリオ2: 改変されたAGPLバイナリを使う

ボブは今、SkytableがクエリータイプXを持っていればもっと良くなり、自分の開発がもっと便利になると気づきました。そこで彼は、ソースコードをダウンロードし、それを修正しました。今、彼は派生物(derivative work)と呼ばれるものを作りましたが、それを直接配布したわけではありません。

ボブの悩み: 自分のアプリのコードをオープンソースにしなければならないのか？
答え: いいえ！ユーザーが直接データベースにアクセスできるようにしていないので、彼がデータベースに加えた変更を返す必要すらありません。また、彼のアプリのコードは、彼自身のものであることに変わりはありません。

シナリオ3: プライベートで変更したバージョンを使う

ボブの職場の人々は、Skytableの修正版を気に入り、職場内で使いたいと考えています。ボブの同僚は、職場のユーザーが自分自身を認証できるように、Skytableに認証機能をさらに追加しました。しかし、このコードはSkytableの作者（つまり、私です！）に返すのは安全ではありません。

ボブの悩み: 変更内容を公開しなければならないのでしょうか？
答え: いいえ！ボブは自分の組織内でのみ使っているだけなので、他の人に配布しているわけではありません。そのようなAGPLソフトウェアの複製は、変更を開示することなく、保持できます。

これらの事例を見ていけば十分でしょう。あなたのアプリケーションやサービスが、AGPLバイナリをバックエンドとして使っていたとしても、AGPLはそれには興味を持ちません。しかし、その代わりにAGPLでライセンスされたバイナリにあなたが加えた変更が何かという点のみに興味を持っているということをはっきりと理解できたと思います。

まとめ

1行にシンプルまとめると、もしあなたがAGPLでライセンスされたバイナリを「そのまま」、何の変更も加えずに使うのであれば、あなたはあまり考える必要はありません。自分自身のコードにフォーカスすべきです。しかし、もしあなたがAGPLのコードに変更を加えて配布する場合は、あなたが行った改変をソースコードとしてユーザに提供することで、法的に正しい状態を維持できます。

あなたがコメント欄を荒らす前にひとつお伝えすると、これは法的なアドバイスではありません。もしあなた（や私自身）を誤解させるようなところがあれば、遠慮なく訂正してください。

AGPLを理解する: もっとも誤解されたライセンス