AGPLライセンス-このシナリオに適用されますか？
別のソフトウェア（サーバー-商用、クラウドベース）に対して（SOAPを使用して）Webサービス呼び出しを行うAGPLv3ベースのソフトウェア（クライアント）があります。行われるWebサービス呼び出しを除いて、これら2つの間に共通のコードや接続はありません。
私の質問-
サーバーもAGPLである必要がありますか？そうではないと思いますが、確認したいと思います。
サーバーのエンドポイントURLをクライアント側で（XMLファイルを編集することにより）構成して、サーバーを別のサーバーに接続できるとしましょう（ここでも、Webサービス呼び出し以外の接続はありません）。これらのサーバーはAGPLですか？
クライアントをDLLとして実行している場合、ユーザーのデスクトップ上の他の商用アプリケーションによってロードされますか？問題がありますか？これらの他のアプリケーションもAGPLである必要がありますか？
tl; dr：この方法でAGPLを使用しても、期待した効果が得られない場合があります。
- サーバーもAGPLである必要がありますか？私はそうは思わない-確認したい。
クライアントのライセンスに関係なく、クライアントのライセンスがサーバーにライセンスの変更を強制する方法はありません。その法的制限を強制する方法はありません。営利企業は単にそのように拘束することはできません。これがクライアントのライセンスと矛盾する場合、誤ってライセンスされているのはクライアントです（したがって、著作権所有者以外は配布しないでください。標準の著作権規則が適用されます）。
組織の「下流」にいる人々（または組織）が行うことに基づいてライセンスを選択するように組織を説得することは、最善の場合には難しい販売です。完全に自分たちの手に負えないランダムなサードパーティのために、（何らかの理由で）自分たちにとって好ましくないライセンスに切り替えなければならないことを彼らに伝えます。彼らは単にあなたにそのような義務を負わないのです。
- サーバーのエンドポイントURLをクライアント側で（XMLファイルを編集することにより）構成して、サーバーを別のサーバーに接続できるとしましょう（ここでも、Webサービス呼び出し以外の接続はありません）。これらのサーバーはAGPLですか？
それはさらにばかげています。 Microsoft Sharepointのインストールを指すようにそのファイルのURLを編集したとします。それはMSにAGPLの下で彼らの主要な商用製品の1つを認可することを強制するでしょうか？それは完全に笑える。
いいえ、実際に行っているのは、クライアントソフトウェアの使用条件を破ることです。厳密に言えば、それがAGPLである場合は、AGPLサービスのみを指す必要があります（著作権者が明示的な例外を認めている場合を除きます）。
- クライアントをDLLとして実行する際に、ユーザーのデスクトップ上の他の商用アプリケーションによってロードされる問題はありますか？これらの他のアプリケーションもAGPLである必要がありますか？
すべてが適切に正しくなるためには、それが必要ですが、実際にはそうではない可能性が高いです。代わりに、実際に得られるのはusersがライセンス契約に違反することです。 AGPLクライアントが他のプログラムにロードするために無差別にそれ自体を提供していない限り（少なくともWindowsでこれを行う方法がありましたが、OS自体のいくつかの部分を除いて今でははるかにまれです）、その場合は議論される可能性がありますソフトウェアがユーザーを閉じ込めてライセンスを破ろうとしていたこと。ライセンスを実際に適用したい場合はお勧めできません。
しかし、商用ソフトウェアの作成者に変更を促すことはありません（AGPLであることを知っていても、ロードするためにAGPLソフトウェアを意図的に検索している場合を除きます）。商用ソフトウェアは、ユーザーのプロンプトで、任意のDLLをロードし、ある種のイントロスペクションを使用してその内部の関数（そのようなコードが存在する）を呼び出すことができる）は、それ自体ではありません。依存関係を強制するのに十分です。問題を引き起こしているのは、商用企業ではなく、ユーザーです（AGPLによって提示されたAPIを理解するDLLは、それ自体では発生しません）リンク; APIはライセンス制限の対象ではないというかなり最近の裁判所の決定がありました。これはOracleを非常に苛立たせましたIIRC。）
最初の2つの質問に答えるために、 GPL FAQ は「いいえ」と答えます。通常、AGPLライセンスのクライアントは、接続するサービスのライセンス要件に影響を与えることはできません。
一部のネットワーククライアントソフトウェアがAGPLv3でリリースされている場合、相互作用するサーバーにソースを提供できる必要がありますか？
これは、一般的なサーバーとクライアントの関係では必要ありません。 AGPLv3には、「コンピューターネットワークを介してリモートで対話するすべてのユーザー」にソースコードを提供するプログラムが必要です。ほとんどのサーバークライアントアーキテクチャでは、サーバーオペレーターが意味のある意味でクライアントと対話する「ユーザー」であると主張することは単純に合理的ではありません。
例としてHTTPを考えてみましょう。すべてのHTTPクライアントは、サーバーが特定の機能を提供することを期待します。整形式の要求に対して指定された応答を送信する必要があります。逆は当てはまりません。サーバーは、クライアントが送信するデータを使用して、特にクライアントが何かを行うとは想定できません。クライアントは、Webブラウザー、RSSリーダー、スパイダー、ネットワーク監視ツール、または特定の目的のプログラムです。サーバーは、クライアントが何をするかについてまったく想定できないため、サーバーのオペレーターがそのソフトウェアのユーザーと見なされる意味のある方法はありません。
3番目の質問（「商用アプリケーション」とは、実際には「GPL非互換アプリケーション」を意味すると想定）に答える場合、答えは通常のGPLと同じです： 実際に確実なものはありません 。 FSFは、（A）GPLライセンスのライブラリをロードすると、派生物が動的に作成されると考えています。これには、ライブラリを使用するコードをGPLライセンスにする必要があります。確かに、誰もがこの意見を共有しているわけではありませんが、それはGPLの作成者の法的な意見と意図です。
2か月遅れますが、それでも...
まず第一に、IANAL、本当の専門家、そしてすべての通常のものに尋ねます。
3から始めます。
あなたは非常に大きな何かに触れています。 FSFによると、AGPLだけでなく、GPLでさえ、（A）GPLバイナリに動的にリンクされているものはすべてオープンソースにする必要があります。
他の一部の人々によると、あなたは本当にそれをすることを強制されていません。問題のどちらかの見方を確認できる大きな訴訟はありませんでしたが、GPLのspiritは、クライアントをオープンソースする必要があるということですアプリケーション全体。言うまでもなく、AGPLはGPLよりも制限的であるため、これはAGPLにも適用されます。重要な注意：AGPLはこれを許可しているため、クライアントの残りの部分をAGPLではなくGPLとしてライセンスすることができます。
1と2は、ある程度は事実上同じです。どちらの場合も、AGPLの下であなたがやりたいことをすることが許可されていると思います。 AGPLの関連テキスト を見てみましょう。
このライセンスの他の規定にかかわらず、プログラムを変更する場合、変更したバージョンは、コンピュータネットワークを介してリモートで対話するすべてのユーザーに（バージョンがそのような対話をサポートしている場合）、提供することによってバージョンの対応するソースを受け取る機会を目立つように提供する必要がありますソフトウェアのコピーを容易にする標準的または慣習的な手段を介して、ネットワークサーバーから対応するソースに無料でアクセスする。この対応する情報源には、次の段落に従って組み込まれるGNU General PublicLicenseのバージョン3でカバーされるすべての作業の対応する情報源が含まれるものとします。
したがって、AGPLライセンスのクライアントライブラリを変更する場合は、変更されたソースコードを、それと通信するすべての関係者、つまりすべてのサーバーに提供する必要があります。私が理解している限り、クライアントのソースコードを変更しているわけではないので、まったく問題ではありません。
GPLのどのバージョンでも、コードの商用配布と非商用配布の区別はありません。配布する場合は、同じライセンスの下で、ソースコードのコピーを使用して配布する必要があります。
これはAfferoバージョンであるため、Webサイトのサーバー側でalohaを使用する場合でも、配布としてカウントされ、ソースコードを提供する必要があります。ソースコードに独自の変更を加えて非公開にすることはできません。使用しているだけなら、これは簡単なはずです。おそらくアロハを得た場所に人々を向けることで逃げることができるでしょう。
データを配布する必要は一切ありません。これはソースコードのみです。