GPL v2 および GPL v3 ライセンスのソフトウェアを商用生産環境で使用することに懸念があります。HaProxy を負荷分散ソリューションとして使用したいと考えています。コピーレフトに対して安全ですか? ソース コードからは何も変更しません。また、システムのアーキテクチャにはロード バランサーを使用する必要があります。
これは、より大きな分散システムに組み込まれます。したがって、私たちが販売するのはシステム全体です。別のサイトでは、ロード バランサーを再度インストールする必要があり、他のサイトと混在する可能性があります。私を混乱させているのは「配布」という用語だと思います。
出荷する製品と一緒に（変更されていない）バイナリを配布する場合は、それらと一緒にソースを配布するか、人々がソースを要求する方法を提供する必要があります。これはGPLを無視できる状況ではありませんが、実際の問題にはなりません。GPLは、リンクしない限り、プロプライエタリソフトウェアに感染することはありません。
この意味での配布とは、顧客に提供（または販売）することを意味します。社内で分散（マルチノード）システムを使用しているだけの場合は、yanが言うように完全に明確です。
ちなみに、GPLv2（ここではv3）は非弁護士が読むように書かれています。ぜひご覧になることをお勧めします。英語が母国語でない場合、翻訳は多くの言語で利用できます。
Haproxy は GPLv2 であるため、ソースを取得して再構築する場所についてエンド ユーザーに十分な情報を提供すれば、バイナリ形式で再配布できます。また、ビルド オプションや環境についても知らせる必要があります。それらがないと、同じ機能を利用できない可能性があるからです。
これらの点に疑問がある場合は、GPL の目標は、あなたが姿を消した場合に、修正できないバグのあるソフトウェアが顧客に残されないようにすることであることを覚えておいてください。したがって、可用性に依存しないことを意味するものを提供する必要があります。それを念頭に置いておくと、正しい選択をするのがずっと簡単になります。そして、これを可能にしようとしても、すべてを考えていないために失敗した場合、常に誠実さが重要です。
また、ソフトウェアの配布を開始するときはいつでも、一部の顧客は、ニーズをより適切に満たすために特定の変更を要求することに注意してください。最初は拒否しますが、まったく同じ小さな機能を望んでいる数人の顧客を失った後、受け入れるようになります。その後、コードにパッチを当ててしまい、コードを取得するために元のサイトに顧客を誘導できなくなるため、当惑することになります。
これには 2 つのアプローチがあります: - パッチは一般的に使用され、維持したくない場合。メインストリームに含めるために提出するだけです。承認された場合は、バージョンを更新でき、パッチを維持する必要がなくなります。- パッチが顧客固有のものであり、受け入れられる可能性が低い場合、顧客が公式リリースを取得してパッチを適用し、ビルドできるように、ビルド手順とともに顧客が利用できるようにする必要があります。
考えられる典型的なパッチの 1 つは、ドキュメント内のいくつかの名前/URL/バージョンなどを削除して、よりクリーンでソリューションとの統合性を高めることです。これらの情報を削除するパッチを提供する場合、これらの情報を削除することは正しいことです。そうすれば難読化はなく、変更は透過的です。
いずれにせよ、バグを見つけて修正したと思われる場合は、原因ではなく結果を修正するのが一般的であるため、レビューのために送信することを強くお勧めします.
「商用環境で GPL ソフトウェア バイナリを使用できますか?」という質問のタイトルについてのもう 1 つのポイントは、次のとおりです。: はい、できます。そうすることをお勧めします。商用環境で使用できるフリー ソフトウェアが増えるほど、本番環境で問題を修正する必要が少なくなります。
ソースを変更せずにバイナリを使用している場合は、完全に明確にする必要があります。