だから、私はAGPLを読んでいて、ここに私の理解があります(弁護士ではなく、「自由になりたい」というレンズを通してそれを調べようとしているわけではないので、そうです。 "。私の場合、AGPLライブラリであるitextを使用してPDFファイルをクラックしてテキストを抽出することを検討しています。それだけです。内部デスクトップアプリがあり、 veは、Webサイトで抽出コード(itext dllを使用)を使用して、何年もの間手動で実行していた2階の人々のプロセスを高速化することを提案しました。
定義の下で:
したがって、私の定義の解釈により、対象となる作業は私が使用しているitextコードです。私が個別に作成するコードはitextコードに基づいていないか、それから変更されていないため、厳格にロックダウンしたり、favフォーラムに公開したりすることを含め、私が選択した方法でライセンスを取得できます。著作権で保護されたAGPLコードを直接変更したりコードに組み込んだりしない限り、このライセンスには、ダウンロードした元のバージョンへのリンクを妨げるものはありません。私がしなければならないことのほとんどは、対象となる作品のバージョンのソースを提供することです。
それでは、感情はさておき、合法性のみに焦点を当てていますが、あなたはどう思いますか? FSF FAQ から明らかだと思います。社内で使用することで、私が好きなことはほとんど何でもできるので、組織の外部にソースを配布する必要がありません。私の唯一の本当の懸念は、次にitext libを呼び出すWebアプリを作成することです。この場合、何をする必要がありますか? itextコードをダウンロードするには、リンクまたは場所を指定するだけでよいと思います。別のオプションとして、小さな独立したスタンドアロンプログラムを作成し、Webサイトで標準の「実行」メカニズムを介して呼び出した場合はどうなりますか?既存のWebサイトの残りの部分は、たとえテキスト抽出部分がそうであっても、突然AGPLに該当する必要はないはずです。
GPLとAGPLの唯一の重要な違いは、AGPLが配布の概念を拡張して、「プログラムのWebインターフェースをインターネットに接続している顧客に提供する」ことを含むことです。
本当に回避策が必要な場合は、AGPLライブラリを実行可能ファイルでラップし、コマンドラインから呼び出すことで回避策を実行できます。 FSFはこれを「武器間通信」と呼んでいます。これは、AGPLライブラリが、事前バインディングまたは遅延バインディングのプログラミング言語メカニズムを介して実行可能ファイルと「リンク」されていないことを意味します。
here を参照してください:
多くの場合、GPLで保護されたソフトウェアを独自のシステムと一緒に配布できます。これを有効に行うには、フリープログラムと非フリープログラムが十分な長さで通信し、それらが効果的に単一のプログラムになるような方法で組み合わされていないことを確認する必要があります。
これとGPLでカバーされたソフトウェアの「組み込み」の違いは、部分的には実質の問題であり、部分的には形式です。実質的な部分は次のとおりです。2つのプログラムが結合されて1つのプログラムの2つの部分になる場合、それらを2つの別個のプログラムとして扱うことはできません。したがって、GPLはすべてをカバーする必要があります。
コンパイラとカーネルのように、またはエディタとシェルのように、2つのプログラムが適切に分離されている場合、それらを2つの別個のプログラムとして扱うことができますが、適切に行う必要があります。問題は単に形式の1つです。つまり、自分が何をしているかをどのように説明するかです。
つまり、AGPLライブラリはスタンドアロンプログラムである必要があり、アプリケーションはそれなしで機能できる必要があります。
いつものように、本当の法的懸念がある場合は、この種のことを専門とする本物の弁護士に相談してください。
私の理解は(私は弁護士ではありません)、それを変更しなければ、プライベートサーバー上のパブリックWebアプリケーションで自由に使用できます。たとえば、 https://opensource.stackexchange.com/questions/4691/Java-and-agpl-3-how-far-does-license-extend-into-web-app を参照してください