前回翻訳したAGPLを理解する: もっとも誤解されたライセンスでは、実体以上に強いライセンスであると思われているケースについての紹介がありました。
もちろん、使い方次第ではアプリケーションコードの開示が必要になってしまうケースもあるかと思います。前回のエントリーはわかりやすい切り口で書いてくれていますが、いくつか、やはりプロダクトコード側へ制約が出るケースが考えられるので、その点についてまとめてみます。
AGPLの特徴を2行でまとめると以下の通りかと思います
- ネットワーク越しに利用することも配布とみなし、AGPLで書かれたアプリケーションのソースにアクセスする権利が伝わる
- ネットワーク越しの利用することはリンクではないため、ネットワークで通信するアプリケーションのライセンスをAGPLにする必要はない
配布とリンクがごっちゃにされるのが、よくされる誤解の原因かと思います。もしネットワークアクセスでもライセンスが伝播するなら、商用のルーターとかそこで動くOSのネットワークスタックとか、ブラウザとかもAGPLにしないといけない、ということになります。
AGPLもリンクではGPL同等
AGPLを使った場合に、アプリケーションコードの開示が必要かつアプリケーションもAGPLにしなければならないケースは、AGPLのコードをリンクする場合です。たとえば、ライブラリとして提供されるものや、サーバー製品のドライバやSDKがAGPLの場合、もしくはAGPLのアプリケーションの一部を取り出して組み込んだ場合は、アプリケーションもAGPLになります。これはAGPLというよりも、そこにリンクするコードの扱いに関しては今まであったGPLとほぼ同一条件になります。
なお、全利用者というのは、社内限定利用であれば社内ユーザーへの開示だけなので、前回翻訳したエントリーで説明されているように、AGPLになったからといって全世界に公開しないといけないということはありません。
ライブラリ/SDK/ドライバでは使わない方が無難
結論としては、ライセンスを選択できる自由があったとしてもAGPLを適用するのは、単独で動くサーバーアプリケーションとしての形態で提供するソフトウェアに限定した方が良さそうです。
アプリケーションが(A)GPLになるということは、プロプラなライブラリとのリンクもできなくなってしまうため、利用者の自由度が下がってしまいます。そのような状況で今まで良く使われていたのがLGPLというライセンスです。LGPLのライブラリとリンクするアプリケーションはコードの公開は不要です。ですが、残念ながらAGPLのLGPL版というのはありません。AGPLのように成果物に対する修正を（ネットワーク越しの配布でも）公開して欲しい、かつ広く使って欲しいというニーズを満たすのはAGPLで実現するのは簡単ではないことがわかります。
良く知られているように、MongoDBも、本体がAGPLだった時代から、SDKやドライバーはApache 2を採用していました。
なお、LGPLですが、LGPLはリンク対象となるコードには何も制限がないかというとそんなことはなく、いくつかのルールがあります。例えばリバースエンジニアリングを許可しなければならない、またLGPLを使うアプリケーションユーザーが、LGPLのコード部分だけを修正して自分で再ビルドできるようにしなければならない、というものです。実際、これを守る難易度はやや高い気がします。
AGPLのツールが生成するソース/AGPLのソースから作られるソースコードも除外した方が無難
AGPL製ツールが何かしらのソースコードを生成する場合もあるかと思います。何も注記がなければこの生成されるコードもAGPLになると思います。だいたい生成されたソースの実行には何かしらのランタイムが必要で、そのランタイムがAGPLだからです。そのため、何かしらの「生成を行う」ツールや一部ライブラリは例外条項を設けています。GCCやBisonは不自由なライセンス（とフリーソフトウェア派の人が呼ぶクローズドソース）とのリンクを許可しています。
この辺りの意図とかが書かれている貴重な資料としてはBisonの使用条件のドキュメントがあります。
サーバーアプリケーションがOpenAPIとかGraphQLとかgRPCのAPI定義を用意していて、クライアントがそれをもとにクライアントを生成して使う場合は悩ましいですね。設定からソースの生成はある種のコンパイルであり、生成されるソースもGPL系であれば同じライセンスになりそうな気がするので、これらの設定ファイルもドライバとみなして、別ライセンス化するか、例外を規定しておく方が無難な気がします。
CLIツールもあまりAGPLにする必要は（本来は）なさそう
僕とDeNAでもフューチャーでも同僚だったknqyf263さんが書いてめちゃくちゃバズった記事が以下のやつです。
Trivyは当初AGPLで、買収後にApache 2になったと記憶しています。
本来はこの手のCLIツールはAGPLにしても、単にツールとして単独実行する場合はネットワーク越しに直接叩くことをしないため、AGPLにしてもソースを提供する義務は発生しなくなってしまいます。
とはいえ、エージェントとしてこの手の定期的に実行して情報収集するツールで、実行頻度をネットワーク越しに制御したり、結果を閲覧するウェブサービスを提供する場合は、下記の説明を解釈すればTCPで繋がっているサービスとかとなんら変わらず、AGPLとしての配布の条件にマッチする気がします。
GNU Affero 一般公衆利用許諾書の八田さんの翻訳の引用
改変したバージョンは、そのバージョンとリモートでコンピュータネットワークを介し対話的にやりとりする（あなたのソフトウェアがそのようなインタラクションをサポートしている場合）すべてのユーザに対して、(中略)『対応するソース』を受け取る機会を明示的に与えなければなければならない。
商用ライセンスとGPL系ライセンスのデュアルライセンス
近年ではコミットの前にContributor License Agreement(CLA)を締結してコードを自由にする権利とともにPull Requestを受け付けるというのが多くなってきました。これはオリジナルの著者にライセンスを変更できる権限を残した状態でコミットをしてもらうためのものです。これにより、GPLなコードであっても、状況が変わって商用サービス化したい場合に自由にできるようになります。MongoDBが商用ライセンスとAGPLのデュアルライセンスを維持したり、Server Side Public LicenseやBusiness Source Licenseで出し直すことができているのはこれによるものです。
GPL系ライセンスとして公開したコードを別ライセンスで出し直すのは、例え開発者本人であっても容易ではありません。多くの人のコントリビュートがあったとして、送られてきたパッチのコード片もGPL系ライセンスのはずで、ライセンス変更にあたってはコードにコミットした人の許可が必要とされています。MeCabが以前、AppleのiPhoneにバンドルされる前に、Appleから要望を受けてライセンスを変更したという話がありました。ブログはちょっとネガティブな方向性ですが・・・
SaaSタダ乗り問題をばっちり解決するライセンスというのはまだみんな模索している感じはありますが、いざというときのライセンス変更を考えると、OSS開発ではCLAを用意しておくのは業務開発では必要かもしれません。
まとめ
AGPLのように成果物に対する修正を（ネットワーク越しの配布でも）公開して欲しい、かつ広く使って欲しいというニーズを満たすには単独動作するサーバーアプリケーション、およびサーバーに組み込みで使われるエージェント形式のCLIツール等で利用するのがベストかな、と思います。その形態で配布されているアプリケーションであれば、そのAGPLのコードを修正しない限りは別にコード公開とかはないため、前回のエントリーで説明された範囲で利用できます。
LGPL版のAGPLがないということで、直接リンクして使う利用方法では、従来のGPLと同じように、リンクするコードもライセンスをAGPLにする必要があります。ここは別のライセンスを提供するか例外とした方が良さそうです。
OSSを開発する個人としては、AGPLにはTrivyのように一攫千金チャンスもありつつ、広く使ってもらえるという点が魅力的かと思います。一方で、企業開発するコードでAGPLにするには、CLAにして、自分の方でコードのライセンスを自由にして、AGPLと自社でプロプラコードとして使うためのデュアルライセンスを許可しつつ、パッチを受け入れるといったことが必要になるかもしれません。
AGPLアレルギー的な反応をする人が周りにも多かったので、前回のエントリーの翻訳をしつつ、今回のまとめ記事も書いてみました。AGPLを正しく理解して、面白いソフトウェアが日本からももっと出てきつつ、開発した人がもっとフィーチャーされるようになって欲しいな、と思います。