クローズドソースでのLGPLライブラリの使用Androidソフトウェア
クローズドソースでLGPLネイティブライブラリを使用することの法的問題を調査していますAndroidソフトウェア。
今のところ、このテーマに関する私の調査では、クローズドソースソフトウェアでLGPLライブラリを使用することは可能であり、要件はそれほど高くないことが示されています。
通常のアプリケーション（たとえば、Cのクローズドソースアプリケーション）では、ライブラリを動的にリンクし、アプリケーションのバイナリをライブラリとともに適切に参照して配布し、このライブラリをユーザーのバージョンで置き換える方法を説明しますしたいと思う。 （私はここでいくつかのものを忘れているかもしれませんが、これは私の質問のポイントではありません）。
私の質問は、AndroidソフトウェアとJNIを参照しています。Android JNIを使用するソフトウェアを構築していると仮定すると、
My Java source Aを含むJNIフォルダ：
- アプリケーションのコンパイル用のAndroid.mkファイル
- ライブラリのソースコード
- 。cpp /。hソースコードとJNIをリンクするファイル
アプリケーションをコンパイルするには、2つのステップが必要です。
- NDKを使用して* .soファイルを生成するライブラリのコンパイル
- Androidアプリケーションのコンパイル。JavaコードにはSystem.loadlibrary（ "nameOfTheLibrary"）が含まれています）
私が直面している問題は、ライブラリのソースコードが最初に* .soファイルにコンパイルされることです。これは二次的著作物と見なすことができます、そうですか？
法的問題を回避するために、ネイティブLGPLライブラリを含め、適切な方法で配布するにはどうすればよいですか
コードは.soにコンパイルされます。ただし、これには、ソースと静的にリンクされたライブラリのみが含まれます（つまり、.aとして）。 .soに個別にコンパイルされたライブラリは個別です。
したがって、LGPLパーツから別の.soファイルを生成し、コードから別の.soを生成する必要があります。これは、他の.sosにリンクされます（これは、LGPLがそれ以上適用されないようにするダイナミックリンクです） ）。これらすべての.soファイルは.apkにパックする必要があり（ビルドシステムは自動的に正しいディレクトリに配置する必要があります）、ユーザーはそれらを置き換えて.apk（および自分のキーで署名する必要がありますが、有効なキーで十分なので、問題ありません）
ビルドシステムは、共有ライブラリモジュールをいくつでも定義できる必要があります（詳細は覚えていません。Android CMakeでライブラリをコンパイルしているので、ドキュメントを参照してください）。 LGPLライブラリの構築方法を記述したmakefileも、LGPLによってソースと見なされます。
LGPL libを再構築する必要がありますが、これは、それにリンクするアプリが二次的作業の定義に該当することを意味するのではなく、再構築における作業のみです。
そのため、Androidで実行できるようにするコードをリリースする（プロジェクトに貢献するなど）限り、問題はありません。