独自のCベースのアプリケーションでBluezBluetooth（GPL）ライブラリを使用したい。GPLを使用するための回避策が必要です。
私の計画は：
Bluezライブラリ（GPL）にリンクするLGPLラッパーライブラリを作成します。Bluezライブラリヘッダー（これもGPLです）も含まれます。したがって、ラッパーはLGPLになります（私は正しいですか？）。
LGPLラッパーライブラリをプロプライエタリアプリケーションにリンクします。
これで、私のプロプライエタリアプリケーションはGPL汚染から安全ですか？
そうでない場合、ここでの正しい回避策は何ですか？
前もって感謝します
いいえ、これは不可能です。GPLでは、アプリケーション全体をGPLの下で配布する必要があります。それを回避するためのラッパーを作成するための規定はなく、GPLがLGPLに「崩壊」する規定も確かにありません。（多分あなたは別の方向を考えています-LGPLはあなたがGPLとして再ライセンスすることを可能にします。）あなたがしようとしているのはGPLされたアプリケーションに対する古典的な侵害であり、それはほぼ確実に追求されます（あなたが捕まえられたと仮定して） 。
適切な回避策は、独自のBluetooth実装を作成するか、GPLの下でアプリケーションを配布することです。
最後に、標準の免責事項が適用されます。私は弁護士ではありません。GPLを自分で読んで、私が今言ったことを判断できない場合は、GPLコードに触れる前に、弁護士を雇ってそれを解釈してもらう必要があります。
それはそれほど簡単ではありません:-)GPLの制約を取り除くことはできません。
私の会社でも同様のケースがありました。私たちが選んだ解決策は、GPLベースのライブラリ（私の場合はlibiw）の使用を必要とする機能を分離し、GPLベースのスタンドアロンアプリケーションを作成することでした（したがって、開くコードはできるだけ少なくします）。次に、メインアプリケーションから（たとえば、fork / execl関数によって）「小さなプログラム」を起動し、シグナル、パイプ、またはRPCなどによって通信します。あなたのアプリケーションが何をするのかわからないので、それがあなたの状況に当てはまるかどうかはわかりませんが、それは私たちが選んだ回避策です。
そのような回避策はGPLの精神に反するものであり、FSFがIsを点在させ、Tsを超えた場合、それらは存在しないはずです。
あなたの唯一の法的選択肢は（IANAL）です：
専門家のアドバイスについては弁護士に連絡してください。