AGPL-v3ライセンスコードを使用して生成されたデータの使用は配布と見なされますか？
GNU Affero General Public License v （GNU AGPL v3）ライセンスライブラリの一部を商用コンテキストで使用することを検討していますが、コードベース全体をリリースする余裕はありません。
バックエンドのクローラーのようなステップにのみライブラリが必要になります。クローラーでライブラリを使用してデータを生成し、それをデータベースにプッシュし、データベースから読み取る別のプログラム/プロセスによってWebアプリを完全にホストしている場合、ソースコードをリリースすることが法的に義務付けられていますか？ Web向け（「分散」）コードはAGPL-v3ライセンスコードを呼び出さず、生成された出力のみを使用します。
どんな洞察も大歓迎です！
この場合、難しい法的テストは、データを消費するアプリケーションがAGPLデータを生成するアプリケーションと「組み合わされている」と合法的に見なすことができるかどうかを判断することです。 FSFは、2つのプログラムが「 独立企業間原則 」を伝達して、別々の作品と見なす必要があることを提案しています。 （このルールの注意点は、プログラムのアームの長さが完全にわからないことです。）
まず、GPL FAQを参照することで、データ出力を介して転送されるAGPL要件を除外できます。 これに直接対処する質問 （反対側から-生成されたデータにGPLルールを適用しようとして失敗した）：
プログラムの使用から得られる出力をGPLできる方法はありますか？たとえば、私のプログラムを使用してハードウェアデザインを開発する場合、これらのデザインを無料にする必要がありますか？
一般に、これは法的に不可能です。著作権法は、人々があなたのプログラムを使用して彼らのデータから作成する出力の使用についてあなたに何の発言権も与えません。ユーザーがあなたのプログラムを使用して自分のデータを入力または変換する場合、出力の著作権はあなたではなくユーザーに帰属します。より一般的には、プログラムがその入力を他の形式に変換する場合、出力の著作権ステータスは、それが生成された入力の著作権ステータスを継承します。
したがって、出力の使用について意見を述べる唯一の方法は、出力のかなりの部分がプログラムのテキストから（多かれ少なかれ）コピーされるかどうかです...
したがって、AGPLクローラーが出力にGPLライセンスのデータを含まない限り（そして、Webクローラーがそうする理由は何もわかりません）、生成されたデータ自体はAGPLの責任を負いません。
それでも、データ消費コードがAGPLデータ生成コードと同じプログラムの一部と法的に見なされる場合があります。その場合、AGPLは作業全体に適用されます。あなたのアーキテクチャを見ずに（そしておそらく最終的な判断を下さずに）、2つのコンポーネントを1つの作品と呼ぶことができるかどうかを言うことはできませんが、あなたが提示した情報は2つのコンポーネントを強く示唆しています法的に言えば、別々の作品のように見えます。繰り返しますが、 FAQから ：
2つの別々のプログラムと2つの部分からなる1つのプログラムの間の境界線はどこにありますか？これは法的な問題であり、最終的には裁判官が決定します。適切な基準は、通信のメカニズム（exec、パイプ、rpc、共有アドレス空間内の関数呼び出しなど）と通信のセマンティクス（交換される情報の種類）の両方に依存すると考えています。
モジュールが同じ実行可能ファイルに含まれている場合、それらは確実に1つのプログラムに結合されます。モジュールが共有アドレス空間でリンクされて実行されるように設計されている場合、それはほぼ確実にそれらを1つのプログラムに結合することを意味します。
対照的に、パイプ、ソケット、およびコマンドライン引数は、2つの別々のプログラム間で通常使用される通信メカニズムです。したがって、それらが通信に使用される場合、モジュールは通常、別個のプログラムです。しかし、コミュニケーションのセマンティクスが十分に親密で、複雑な内部データ構造を交換している場合、それも2つの部分を組み合わせてより大きなプログラムと見なすための基礎となる可能性があります。
データベースへの書き込みとデータベースからの読み取りは、「パイプ、ソケット、およびコマンドライン引数」と同じ広いカテゴリに分類されるようです。データを消費するコードは、同じコンピューターでデータを生成するコードを実行しなくても実行できます。あるシステムでデータベースを生成し、それを消費する別のシステムにデータベースを渡すことができます。この観点から、プログラムが別個の作業であり、データを消費するWebプロセスを操作するユーザーが、データを生成するAGPLコードも操作していないことは、私には明らかです（法的な確実性はありません）。
著作権については、プログラムとそのプログラムが動作するデータ（またはプログラムから出力されるデータ）は完全に別個の作品と見なされ、一方の著作権ライセンスは、他方のライセンス方法に影響を与えません。
1つの例外は、プログラムがその内部（の一部）を出力にコピーする場合です。次に、出力は、コピーされた入力部分とプログラム部分の両方の派生作業であると見なされ、両方のライセンスが実行できることに影響します。
たとえば、強力なコピーレフトライセンス（GPLやAGPLなど）の下で配布されているエディターを使用して、完全にクローズドソースのアプリケーションを作成することは完全に可能です。エディターのライセンスは、コードのライセンスを取得する方法にはまったく影響しません。
例外的なケースの例は、 Bison を使用してパーサーを生成する場合です。 Bisonからの出力には、Bisonの作成者によって作成されたコードのかなりの部分が含まれているため、その出力をどのように使用できるかについて意見があります。 （ちなみに、Bisonがコピーした部分は、Bisonの残りの部分が該当するGPL要件から明確に免除されています）。
AGPLはAfferoGeneral Public Licenseであり、ユーザーが無料のコードを利用したWebサービスを使用するときに、独自のロックインからユーザーを保護します。
さまざまな作成者（それぞれAffero、IncとFree Software Foundation）からの最近のバージョンがいくつかあります。
- Affero General Public License v2 http://www.affero.org/agpl2.html
- GNU Affero General Public License v3 http://www.gnu.org/licenses/agpl-3.0.html
あなたが対象としているものを知っています。
弁護士は、管轄区域の「配布」の定義を満たしているかどうかだけでなく、コードベース全体が「リンク」の定義を満たしているかどうかも判断する必要があります。ライブラリにリンクするソースコードを公開するだけでよいからです。一般的に、AGPLコードが入力されたデータベースのみを読み取るコードは、そのコードに「リンク」されているとは見なされないため、そのソースを公開する必要はありませんが、その前例や意見はわかりません。 。
UpdateFSF（GNU AGPL）の作者）からのガイダンスがあります：
ただし、多くの場合、GPLで保護されたソフトウェアをプロプライエタリシステムと一緒に配布できます。これを有効に行うには、無料プログラムと非無料プログラムが独立企業間で通信することを確認する必要がありますそれらが効果的に単一のプログラムになるような方法で組み合わされていないこと。
これとGPLでカバーされたソフトウェアを「組み込む」ことの違いは、部分的には実体の問題であり、部分的には形式の問題です。実質的な部分は次のとおりです。2つのプログラムが組み合わされて、事実上1つのプログラムの2つの部分になる場合、それらを2つの別個のプログラムとして扱うことはできません。したがって、GPLはすべてをカバーする必要があります。
コンパイラとカーネルのように、またはエディタとシェルのように2つのプログラムが十分に分離されたままの場合は、それらを2つの別個のプログラムとして扱うことができますが、適切に実行する必要があります。問題は単に形式の1つです：あなたがしていることをどのように説明するか。なぜ私たちはこれを気にするのですか？コレクション内のGPL対象ソフトウェアの無料ステータスをユーザーが明確に理解できるようにするためです。
*（Emphasis mine）GPLからFAQこれはGNU AGPL http://www.gnu.org/licenses /gpl-faq.html#GPLInProprietarySystem *
別の方法は、ライブラリの作成者から、ビジネスにより適した条件で商用ライセンスを購入するか、更新するか、作成者と交渉することです。 （s）それらがあなたの計画された使用を許可することを意図したことを確実にするため。
AGPL-できることとできないこと のより一般的な情報
これは法律上の助言ではなく背景情報であり、私は弁護士ではありません。