私はアプリケーションを持っています、それはlibmysqlclient.soを使用します私はlibmysqlclientがGPLであるためにこのアプリケーションでGPLライセンスが必要かどうか、またはクローズドソースでプログラムを続行できるかどうか疑問に思います
編集：このサイトによると、私はクローズドソースソフトウェアでlibmysqlclientを使用することができます。
なぜGPLがコードに「感染」するのか理解できません...
EDIT2： ライブラリが（LGPLではなく）GPLの下でリリースされている場合、それを使用するプログラムはGPLまたはGPL互換ライセンスの下にある必要があるということですか？
この問題に関しては、常に多くの混乱とFUDがありました。
まず、libmysqlclientはLGPLではなくGPL 2です（これは、ライブラリであることにもっと一致していると言えます）。ただし、実際にはいわゆるFLOSS例外があり、GPLライセンスを採用しなくても、無料のオープンソースプロジェクトでlibmysqlclientを使用および配布できます。
あなたの場合、アプリケーションがGPLであるか、別のオープンソースライセンス（FLOSS例外による）を使用している場合にのみ、libmysqlclientにリンク（および/または配布）できると思います。
これには例外がありますが、GPLでは通常、プロジェクトもオープンソース化し、GPLと互換性のあるオープンソースライセンスを使用する必要があります。GPLはその面で驚くほど制限的ですx_x
libmysqlclient、JDBCコネクタ、およびMySQLとのインターフェースに使用するその他のライブラリはGPL（GPLv2）です。ライセンスを厳密に読むと、GPLの下でソースコードを配布する必要があることがわかります。
FLOSS免除があり、オープンソースライセンスにlibmysqlclientを含めることができますが、これは適用されません。
Sun / Oracleは、コネクタライブラリとサーバーコンポーネントのライセンスを積極的に取得しており、私の経験ではかなり高価です。クエリプロキシサーバーなど、使用できるトリックがいくつかあります。子プロセスを起動するだけで、独自のSQLコマンドをlibmysqlclientに変換できます。プロキシのソースを出荷する必要がありますが、それは自己完結型のピースです。
このサイトによると、クローズドソースソフトウェアでlibmysqlclientを使用できます。
なぜGPLがコードに「感染」するのか理解できません...
libmysqlclientは確かにGPLv2であり、このライブラリを呼び出すコードをGPLするか、Oracleから商用ライセンスを購入する必要があります。
ただし、代わりにODBCを使用する場合は、GPLではないODBCAPIにアプリケーションを書き込むことができます。その後、顧客はMySQLODBCドライバーまたはその他のドライバーのインストールを選択できます。