AGPL-できることとできないこと
AGPLは、GPL-over-networksに移行することを目的としたかなり新しいライセンスです。しかし、弁護士ではなく、実際にはライセンス全体を読んでいないため、AGPLであなたが自由に何ができるのか、そして何ができないのか正確には理解できません。
私の不確実性は、MongoDB（AGPL）について この投稿 によって、さらには以下のコメントによって提供されます。
コメントに従うと、ライブラリを変更しない限り、AGPLライブラリをクローズドソースの商用サーバー側ソフトウェアで使用できることがわかります。それは事実ですか？または、AGPLライセンスライブラリを使用する場合、アプリケーション全体を配布する必要がありますか？
MongoDBの場合は、クライアントコードにApacheライセンスを使用しているため、別の問題が生じます。 AGPLソフトウェアを使用しているが、クローズドソースの商用アプリケーションとは別のアプリケーションとして展開するとどうなりますか？たとえば、 iText を取得します。これはAGPLライブラリです。
- それを使用して変更する場合、アプリケーション全体をオープンソースにする必要がありますか、それともiTextの変更のみを再配布する必要がありますか？
- それを使用し、変更しない場合、アプリケーション全体をオープンソースにする必要がありますか？
- 別のプロセスとして開始する別のアプリケーションでiTextをラップするが、それをメインアプリケーションから使用する場合、すべてをオープンソースにするか、ラッパーアプリケーションだけにするか？ （ラッパーアプリケーションは、PDFファイルを受け取り、iTextをJSONとして使用した結果を返すHTTPベースのAPIになります）。これを使用してAGPLライセンスを回避できますか？
注：問題はAGPLv3に関するものです
AGPLはLGPLではなくGPLに基づいています。リンクの例外は含まれていません。AGPLコードを使用した作品（リンクされているか、それ以外の場合は、変更されているかどうか）もAGPLライセンスで配布する必要があります。
個別のプロセスを使用するcanは（A）GPLを回避しますが、これは曖昧な根拠です。エンドアプリケーションdependsが外部プロセスに存在し、それがないと適切に機能しない場合、AGPLソフトウェアの派生物と見なされます。
クローズドソースプログラムで個別のGPLアプリケーションを使用するほとんどの場合、オプションの拡張機能としてGPLの機能を提供したり、他のコードの代替のバックエンドなどを提供します。
（A）GPL作業は、個別のアプリとしても（たとえば、同じアーカイブまたはリポジトリに配置するなど）最終的なアプリケーションと一緒に配布することはできませんが、GPL作業の検索場所と使用方法に関する指示を提供することは問題ありませんあなたのアプリ。
AGPLはGPLと同じです。したがって、アプリがAGPLコードを使用している場合は、AGPLライセンスが必要です。
AGPLがGPLに加えて行うことは、ユーザーの再定義です。サーバーで実行されているGPLプログラムの場合はユーザー、AGPLの場合はアプリの実際のユーザーはWebサイトまたはサービスのユーザーです。したがって、あなた以外の誰かがそれを使用している場合、あなたはアプリを配布しています。そしてもちろん、これはすべての標準GPL要件を意味します。
Mongoについては、それを使用するアプリはコードを使用せず、AGPLライセンスが付与されていない一部のAPIのみを使用すると想定しています。