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のライセンスと配布が必要です。

個別のプロセスを使用すると（A）GPLを回避できますが、これは不明確な根拠です。エンドアプリケーションが外部プロセスに依存していて、それなしでは適切に機能しない場合は、AGPLソフトウェアの派生著作物と見なされます。

クローズドソースプログラムで別々のGPLアプリケーションを使用するほとんどの場合、GPLの作業をオプションの拡張機能として、または他のコードの代替バックエンドなどとして提供します。

（A）GPLの作品は、別のアプリとしても最終アプリケーションと一緒に配布することはできません（たとえば、それらを同じアーカイブまたはリポジトリに配置します）。あなたのアプリ。

AGPLはGPLと同じです。したがって、アプリでAGPLコードを使用している場合は、AGPLライセンスを取得する必要があります。

GPLに加えてAGPLが行うことは、ユーザーの再定義です。サーバーで実行されているGPLプログラムの場合はユーザーであり、AGPLの場合、アプリの実際のユーザーはWebサイトまたはサービスのユーザーです。したがって、あなた以外の誰かがそれを使用している場合、あなたはアプリを配布しています。そして、それはもちろんすべての標準GPL要件を意味します。

Mongoについては、それを使用するアプリはコードを使用せず、AGPLライセンスではない一部のAPIのみを使用すると想定しています。