近況 Twitter

2011年01月26日(水)

LGPLAndroid


続編書きましたhttp://d.hatena.ne.jp/pekeq/20110201/p1


問題なのは、LGPLライブラリの.jarを、Androidの.apkに組み込んで配布したらそのソフトのライセンスはどうなるのか、ということ。

結論があるわけではないのだが、メモ程度で。

Wikipediaから

Wikipedia日本語版にはLGPLについてこうある。

LGPLライセンスで配布されたライブラリAについて、

GNU Lesser General Public License - Wikipedia

FSF見解

問題は.apkに.jarを組み込むのが「静的リンク」にあたるのか?ということだが、.jarを使うことについてはLGPLの英語記事からFSFサイトリンクがあった。FSFの公式見解がこれっぽいな。

FSF's position has remained constant throughout: the LGPL works as intended with all known programming languages, including Java. Applications which link to LGPL libraries need not be released under the LGPL. Applications need only follow the requirements in section 6 of the LGPL: allow new versions of the library to be linked with the application; and allow reverse engineering to debug this.

FSFの考えは一環していて、JavaでもLGPLは通る。アプリLGPLのsection6に従う必要がある「ライブラリの新バージョンとのリンクを許可する。そのデバッグのため解析を許可する」

The typical arrangement for Java is that each library an application uses is distributed as a separate JAR (Java Archive) file. Applications use Java's “import” functionality to access classes from these libraries. When the application is compiled, function signatures are checked against the library, creating a link. The application is then generally a derivative work of the library. So, the copyright holder for the library must authorize distribution of the work. The LGPL permits this distribution.

普通JavaJARファイルを別で持ってimportして使う。アプリコンパイルされる際にリンクされる。アプリライブラリ派生物となる。これは許可された行為。

If you distribute a Java application that imports LGPL libraries, it's easy to comply with the LGPL. Your application's license needs to allow users to modify the library, and reverse engineer your code to debug these modifications. This doesn't mean you need to provide source code or any details about the internals of your application. Of course, some changes the users may make to the library may break the interface, rendering the library unable to work with your application. You don't need to worry about that―people who modify the library are responsible for making it work.

LGPLライブラリをimportするJavaアプリを配布する際は、ライセンスにおいてライブラリの変更と、その変更をデバッグするための解析を許可すること。ソースコードや内部情報を配布する必要はない。ユーザライブラリを変えてアプリが動かなくなったとしてもアンタが気に病んでやる必要はない。

When you distribute the library with your application (or on its own), you need to include source code for the library. But if your application instead requires users to obtain the library on their own, you don't need to provide source code for the library.

ライブラリアプリに含めて配布する場合、ソースを含めること。ユーザに別途取ってこいと言うのならば、ライブラリソースを入れる必要はない。

The only difference between Java and C from the LGPL's perspective is that Java is an object-oriented language, supporting inheritance. The LGPL contains no special provisions for inheritance, because none are needed. Inheritance creates derivative works in the same way as traditional linking, and the LGPL permits this type of derivative work in the same way as it permits ordinary function calls.

LGPLの点からJavaとCの違いは、JavaOOP継承を使えること。LGPL継承を特別扱いしていない。継承は一般的なリンク同様派生物を作ることになる。LGPLは一般的な関数呼び出しによる派生物と同じように扱う。

The LGPL and Java- GNU Project - Free Software Foundation

これを読んでも.apkに.jarを含めること自体の解釈は載ってない(この記事が書かれた当時はAndroidなんてなかったんだからあたりまえ)。

上記FSFの記事については、ほかにも日本語解釈されている方がいた。

派生物とは?

調べていて「派生物」というものの扱いが気になったのだが、GPLLGPLでは「派生物」の扱いが違うようだ。

iPhoneはどうか

電車の中で、手元のiPhoneライセンスを眺めてみたのだが、iPhoneにもLGPLライブラリが入っていた。(iOS4, libiconv)

iOSの中身はBSD UNIXだから、文字通りdynamic linkしているわけで、jarとは事情が違うだろうが、参考として。


Android問題

Android固有の問題として、jar類も全部.apkにまとめるわけだが、こうすることでリンクとなるのか?という疑問がある。FSFの記事を読む限りそうじゃない(リンクが解決されるのは.apkにパッケージする際ではなく、実行時にJVM内でimportが実行されるときだからいやこの考えは違うなあ。やっぱり時間を取って別途考えるべきか)と思うが明確にはならん。

あと、自分の中で論点を整理できたとしても、いざソフトを公開したあとで、GPL crazyな人が「わあGPLGPLだあ。ソース公開しないと騒いじゃうぞお」となったときの風評はどんなもんだろうか。


追記: 2011/1/31

Androidの場合、コンパイル後のクラスや利用しているライブラリ等が、全てclasses.dexにまとめられるわけだが、これは静的リンクになるのだろうか?だとすると静的リンクと同じ扱いになる気がする。


追記

続編書きましたhttp://d.hatena.ne.jp/pekeq/20110201/p1

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


画像認証

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