近況 Twitter

2011年02月01日(火)

LGPLAndroid その2

先日のLGPLとAndroidを書いて以来、悶々としている。要するにプロプライエタリアプリAndEngineを使いたいのだが、かのライブラリLGPLなのだ。AndEngine作者のNicolasさんはblogソース公開はしなくていいと表明しているが、このエントリコメントにもあるように、作者の表明とライセンス意味するところは別ではあるので、白黒つけた確証が欲しかった。

で、先日からさらに調べて、現時点での素人解釈としては、LGPLライブラリプロプライエタリAndroidアプリリンクするのは「クロ」だ。なぜクロかと言えば、Androidの.apkファイルの仕組み上、LGPLの求める条件を満たすことができないから。とはいえ、私はGPL解釈は素人なので、誰か詳しい人のご意見お待ちしております。


Androidビルドのしくみ

つまり、.apkに含まれるclasses.dexファイルは、かなり静的リンクに近い性質を持っている。前回のエントリにあるように、LGPLライブラリをimportするJavaアプリを配布する際は、ライセンスにおいてLGPLライブラリ部分の改変を許可する必要があるが、このビルドの仕組みだと、ライブラリ差し替えはかなり困難だ。


強引な解釈として、以下のような考え方もあると思うのだが、これを受託案件で強弁できるかと言えば、できんわな。


ようやくLGPLを読んでみた

ここまできてようやくLGPL 2.1を読んでみた(読んでなかったんか!!)。と、6-(b)にこんな言葉があるではないか。

6. b)『ライブラリ』とのリンクに適切な共有ライブラリ機構を用いる。適切な機構とは (1) ライブラリ関数を実行形式にコピーするのではなく、実行時にすでにユーザコンピュータシステム上 に存在するライブラリコピーを利用し、そして (2) ユーザライブラリの修正版をインストールした場合でも、そのような修正版が著作物が作られた版とインターフェース的に互換である限り、修正版のライブラリで も適切に動作するようになっているものである。

GNU 劣等一般公衆利用許諾契約書 - GNU プロジェクト - フリーソフトウェア財団 (FSF)

つまり、先日私が読んでいた、The LGPL and Javaは、前提として、「ファイルシステム上の.jarを使う」という条件があり、その上でライブラリ差し替えを認めなさいね、ということだったのだ。上述の通り、Androidの場合はライブラリをバラバラにした上で、独自の実行形式に変換後、classes.dexの中にコピーしているわけで、たとえ差し替え技術的に可能だとしても、LGPLの条件を満たしているわけではなかった。

というわけで、AndroidアプリLGPLライブラリを使った場合、アプリ本体もGPLの影響を免れない、という結論になりました。


どうしてもLGPL/GPLライブラリを使いたかったらどうするか

どうしてもLGPL/GPLライブラリを使いたい場合は、LGPL/GPL部分を別アプリとして分割し、使いたい機能をインテントとして実装しておけばいいと思う。こうすれば公開すべき範囲はLGPL/GPLを含むアプリ側だけに限定できる。昔のNetscape Navigatorが、Emacsのmovemail.cを使っていたときの方法と同じことですね。

ただ、AndEngineみたいにアプリと密結合して動くライブラリの場合、インテントとして実装するというのは現実的な解ではないなあ… というわけでAndEngineよ、さようならライセンスが変わったら是非使いたいです。受託の宿命ながら、惜しいなあ…


追記

AndEngineのライセンスについては、AndEngineのフォーラムでも話題が出ている。

Source Code released! - AndEngine Forums

ggamanggaman 2013/08/02 17:18 こんにちは。

ずいぶん前に私もAndroidでLGPLのライブラリを使用してもか悩みました。
も同様の結論に達した。
(当然法的な問題を知らない素人的な解釈です。)

dex file formatは、classを一つのdexで作られるため、
互いに独立したライブラリに存在することができません。

特に、proguardのような最適化を通じるようになると、
私が作ったclassの結果にLGPLライブラリのclass結果と混在させることができ、また、問題が発生します。

解決策は、LGPLのclassファイルをまとめて一つのdexファイルを作成します。
そして、このdexをDexClassLoaderを使用してloadingする方法があるでしょう。

(アマチュア的な解釈によれば)
これにより、独立したlibraryを維持することができますので、LGPLの問題を解決することができると考えられます。

以前から気になっていた部分について探してみたところ、
この記事を発見して返信を書きます。

"他の場所でもこのような悩みをするんだ。"という考えに返信を配置します。

インターネットのGoogle Translator(Google翻訳)を使用しました。

次は韓国語で書いたものです。
=======================
안녕하세요.

오래전에 저도 Android에서 LGPL 라이브러리를 사용해도 되는지 고민하였습니다.
역시 마찬가지로 같은 결론에 도달했습니다.
( 당연히 법적인 문제를 모르는 아마추어적인 해석입니다. )

dex file format은 class들을 하나의 dex로 만들게 되므로,
서로 독립된 라이브러리로 존재 할 수 없습니다.

특히 proguard와 같은 최적화를 통하게 되면,
내가 만든 class의 결과물에 LGPL 라이브러리의 class 결과물과 섞일 수 있어서 또 문제가 발생합니다.

해결책은 LGPL의 class 파일들을 묶어서 하나의 dex 파일을 만듭니다.
그리고 이 dex를 DexClassLoader를 이용하여 loading 하는 방법이 있을겁니다.

(아마추어적인 해석에 의하면)
이렇게 하면 독립적인 library를 유지 할 수 있으므로 LGPL 문제를 해결 할 수 있으리라 생각됩니다.

예전부터 궁금하던 부분에 대해서 찾아 보던 중,
이 글을 발견하여 답글을 씁니다.

"다른곳에서도 이러한 고민을 하는구나." 라는 생각에 답글을 남깁니다.

인터넷에서 Google Translator(구글 번역기)를 이용하였습니다.

fu7mu4fu7mu4 2016/08/01 16:56 AndEngine は LGPLから Apache License v2に変更されたようですが、どのバージョンからライセンスが変わったのかはわかりません。2013年頃?

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/pekeq/20110201/p1
Connection: close