GPLv2ライセンスのライブラリを会社の内部イントラネットアプリケーションで使用できますか？

契約している会社の内部アプリケーションを作成しています。このアプリケーションでは、GPLv2ライセンスライブラリを使用します。いくつかのポイント

1. このアプリケーションは、会社の範囲内で使用されるものであり、一般に使用されることはありません。これは社内でのみ使用されます。
2. それは決して販売されることはありません!! 。そのため、コードの販売から直接金をmadeけることはありません。製品ではありません。
3. アプリケーションの使用には2つの形式があります
   • コンソールベースのexe（GPLライブラリを使用）であるネイティブ形式。そして
   • 実行可能ファイルを呼び出すWebインターフェイスを介した使用。
4. ソースコードはクローズドソースのままであり（会社での使用のみ）、適切である

私はこれについて多くの質問をしました（1つはトピックとして閉じられ、もう1つはプログラマからマークされていません）が、ライセンスの解釈が正しいかどうかを理解するのに苦労しました。

これまでの私の理解に基づいて、私はこのライブラリを問題なく使用することを許可されています。ソースコードを変更したり、アプリケーションを配布したり、アプリケーションを公開したりすることはありません。アプリケーションは販売されず、社外に配布されることもありません（ただし、当社のオフサイトDR施設で入手できます）。リリースされたバージョンのバイナリを使用する可能性が非常に高く、ソースから再コンパイルすることはできません。

GNU FAQからの次の質問は私の考えを裏付けているようです。

GPLでは、変更されたバージョンのソースコードを一般に公開する必要がありますか？

GPLでは、変更されたバージョンまたはその一部をリリースする必要はありません。変更をリリースすることなく、自由に変更してプライベートに使用できます。これは組織（企業を含む）にも適用されます。組織は変更されたバージョンを作成し、組織外にリリースすることなく内部で使用できます。

ただし、何らかの方法で修正版を一般に公開する場合、GPLでは、修正されたソースコードをGPLの下でプログラムのユーザーが利用できるようにする必要があります。

したがって、GPLは変更されたプログラムを特定の方法でリリースする許可を与えますが、他の方法では許可しません。しかし、それをリリースするかどうかの決定はあなた次第です。

GPLv2ライセンスのライブラリを会社の内部イントラネットアプリケーションで使用できますか？

GPLは、そのすべてのバリエーションにおいて、再配布ライセンスです。コードを再配布しないと、まったく適用されません。将来、アプリケーションから製品を作成することに決めた場合、将来的には適用される可能性がありますが、現在は適用されません。

あなたは答えを引用したと思うので、あなたはそれを持っています。

GPLについての私の知識は、あなたが何をしたいのかについては問題ないということです。

ここでの答えは分配の法的定義にかかっています。

従業員に実行するプログラムを提供することがプログラムの配布である場合、GPL要件が適用され、プログラムを受け取る従業員にもソースを提供する必要があります。

従業員にプログラムのコピーを配布するのが配布ではない場合、配布していないので要件はありません。

引用したFAQは、コードを公開する必要がないことを示しています。（つまり、路上でランダムな人に。）

GPLv2では、Webサービスが配布と見なされないことは明らかです。紛らわしいのはコンソールアプリケーションだけです。

会社の弁護士から法的助言を受けることをお勧めします。

はい。ただし、下請業者、パートナー企業などとの協力を考慮することができます。これは、「社内向け」が「パートナー間で共有」になり、「販売用製品」になったため、多くの管理者を苦しめました。その後、GPLパーツを最初から書き直すか、ソースをイントラネットにリリースする必要があります。

LGPLバージョン2では、ソースとバイナリを再配布できます。

あなたもそれを売ることができます。

唯一の実際の制限は次のとおりです。

ライブラリを変更して配布する場合は、ライブラリに加えた変更を公開する必要があります。LGPLのポイント2を読んでください。

変更しなければ、実際には問題はありません。

私はそれが問題になるとは思わない。GPLコードを使用しているがソースコード形式でユーザーが利用できないWebアプリケーションは、GPLv3がGPLv2と比較して変更された問題の1つであり、その「抜け穴」を閉じています。これはほぼ同じ質問のようです。

ライブラリの目的に応じて、問題全体を回避するもう1つの明白な方法は、ライブラリの周りに非常に単純なラッパーを作成することです。ライブラリがGPLである場合、ラッパーは最終的にGPLである必要がありますが、インターフェイスが明確に分離されている場合、ラッパーコードのライセンスはそうすべきではありません開業医）は、メインアプリケーションのライセンス要件に影響を与えます。

この「プログラマーツープログラマー」のアドバイスのすべてにおいて、それは法律顧問ではないということを覚えておくことは重要です。このスレッドが明らかにするように、GPLで解釈する余地があります。

GPLに違反した場合と、適切で健全な法的意見を得る場合に、組織を法的措置にさらすコストを比較検討する必要があります。このスレッドには良いアイデアがありますが、この入力だけで決定を下すつもりはありません。

-

たとえば、次のようなしわがあります。GPLコードがJavaScriptの場合はどうでしょうか。

ユーザーがGPLのJavaScriptコードを使用してWebサイトにアクセスすると、技術的には「ソースコード」（この場合はJSファイル）がエンドユーザーに「配布」されます。それはあなたのウェブサイト全体がGPLされる必要があることを意味しますか？それについても議論があります。

私は次の勤勉な人ほど弁護士にお金を払うことを嫌いますが、リスクを考えると、これは一般的にインターネットのアドバイスに依存しないほうが良い分野です（もちろん、このアドバイスを除く）。

以前のポスターで述べたように、GPLライセンスは、アプリケーションをリリースする場合にのみ適用され、内部使用のみに残っている場合、問題はありません。ただし、これが変化する場合に関係なく、影響を考慮する価値があります。

ライセンスに関する私の基本的な理解は、ソースコードを変更し、必要に応じて結果のアプリケーションを販売できることですが、ソースコードを変更することを含め、尋ねる人が利用できるようにすることです。

コンパイルされたライブラリの場合、GPLされたコードはメインコードベースから分離されているため、コードライブラリの残りではなく、コンパイルされたライブラリのソースコードのみをリリースする必要があります。

ライブラリがコンパイルされていない場所-つまり、PHPアプリケーションでは、分離はまだ存在していると思います。たとえば、アプリケーションでPDFを生成するためにオープンソースライブラリを使用するとします。PDF生成コードへの変更はすべてライセンスでカバーされ、すべての拡張機能をリリースする必要がありますが、このライブラリを使用するアプリケーション内のコードはリリースする必要はありません。

これはGPL v3で変更されるため、オープンソースライブラリにリンクする場合はコードをオープンソースにする必要があることに注意してください...

アプリケーション自体もGPLであるため、従業員がそのアプリケーションを再配布することを禁止してもよいかどうかはわかりません。そのため、「内部アプリケーション」と思われるものは、ソースコードとともに（合法的に）リークされる可能性があります。