GPLライセンスのソフトウエア(C言語のもの)をライブラリ化して、JNIを使って
Javaのコードからライブラリを呼ぶAndroidアプリを作っています。
GNU GPLのFAQ
http://www.gnu.org/licenses/gpl-faq.ja.html#DistributeWithSourceOnInternet
を読むと、GPLがAndroidアプリ全体に波及して、Javaで書いているソースコードも
公開の義務が生じるのではと思うのですが、このことは正しいですか?
ご存知の方、よろしくお願いします。
すみません、リンクの訂正です。
http://www.gnu.org/licenses/gpl-faq.ja.html#DistributeWithSourceOnInternet
でなく、
http://www.gnu.org/licenses/gpl-faq.ja.html
です。
よろしくお願いします。
2010年10月15日21:52 yukihiro yanai <yana...@gmail.com>:
こちらに「JNIと呼ぶJavaクラスは動的にリンクされている」とあり、
http://www.gnu.org/licenses/gpl-faq.ja.html#IfInterpreterIsGPL
こちらに「動的にリンクされている場合は単一のプログラム」とあるので、
http://www.gnu.org/licenses/gpl-faq.ja.html#GPLPluginsInNF
JNIを使うJavaアプリ側も対象になるんではないかな、と思いました。
--
//ueno
2010年10月16日11:18 hirokuma ueno <ueno...@gmail.com>:
> こんにちは。
> 詳しくはないのですが・・・
>
> こちらに「JNIと呼ぶJavaクラスは動的にリンクされている」とあり、
> http://www.gnu.org/licenses/gpl-faq.ja.html#IfInterpreterIsGPL
>
> こちらに「動的にリンクされている場合は単一のプログラム」とあるので、
> http://www.gnu.org/licenses/gpl-faq.ja.html#GPLPluginsInNF
>
> JNIを使うJavaアプリ側も対象になるんではないかな、と思いました。
Free Software FoundationのGPLのFAQでは、動的ライブラリにリンクした
プログラムはGPLライセンスになると書かれていますね。
しかし、いろいろ、ググったのですが、wikipediaにGPLライブラリの
動的リンクの取扱いについての記事がありました。urlは
です。この内容は法律用語が含まれているため、私には難解なんですが、
動的リンクした場合の二次的著作物の扱いの解釈がグレーな印象を受けます。
wikipediaには誤りもあるという話ですが、厳密にはどういう解釈なん
でしょうか。
Android marketにはJNIでGPLのソフトウエアを利用しているアプリが
出回っていると思うのですが、今まで問題があると聞いたことがないのは
開発者が問題点に触れないようにしているのでしょうかね。
ちなみに、JNI+GPLでググると、約 738,000 件のうちで私の最初の投稿記事が
一番に挙がりますね。
> 動的リンクした場合の二次的著作物の扱いの解釈がグレーな印象を受けます。
実際に、かなりグレーなところだと思います。
私が7年前くらいにLinuxでやってたときは、動的リンクなら大丈夫、という
意識が強かったのですが、近頃のことはよくわかりません。
このあたりは技術的なところよりも、状況によるものが大きいのではないかと
個人的には思います。
(技術が変わったとか、一般的になったとか。)
弁理士の方や、実際に裁判になった方が詳しいと思います。
訴えられない限り、いいのかどうかわからないことが多いと思ってます。。。
-------- Original Message --------
Subject: Re: [android-group-japan: 7096] Re: JNIを使った場合のGPLライセンスの影響
From: yukihiro yanai <yana...@gmail.com>
Date: 2010/10/16 22:18
--
//ueno
2010年10月16日22:18 yukihiro yanai <yana...@gmail.com>:
動的リンクの扱いが微妙なのは、自分のプログラムAと、リンク先のライブラリBが
別々に配布されるケースがある上に、実際の「リンクする」という行為をユーザが行うためです。
この場合、ライブラリBがGPLであって、別のBSDLな互換ライブラリCを利用すれば
GPLなライブラリにリンクしていないのですから当然GPLには感染しません。
また、ユーザはGPLに同意しなくてもGPLなソフトウェアを使用することができるので、
配布者はプログラムAとライブラリCをセットで配布している場合に、
ユーザがBと入れ替えて実行してもやはりGPLには抵触しません。
などと、動的リンクの場合は明確に回避可能なパターンが存在する一方で、
プログラムAとライブラリBをセットで配布した場合には雲行きが怪しくなってきます。
単なる集積物だと言うのは難しくなってくるんじゃないですかね。
http://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation
で、戻ってAndroind marketにおけるJNIでGPLなライブラリを利用した場合、
個人的にはアウトだろうなぁと思っています。
つまり、ご自分で配布するならばソースコードを請求される覚悟をしておくべきですし、
ライバルがやっているならソースコードを請求してみるとおもしろいんじゃないですかね。
なお、確実なところはuenoさんの仰るとおり訴訟してみるしかないと思います。
--
NARUSE, Yui
nar...@airemix.jp
>動的リンクの扱いが微妙なのは、自分のプログラムAと、リンク先のライブラリBが
>別々に配布されるケースがある上に、実際の「リンクする」という行為をユーザが行うためです。
と、いうことは、GPLなプログラムを利用するActivityなりServiceなりを別のAPKファイルにして、
そのAPKはフリー&オープンソースにしてやれば、
そのActivityなりServiceなりをIntentで呼び出すアプリの方は、有償アプリでも構わない、と言うことですかね?
そういった、「GPLを使用した要素のみ別にしたAPK」を作るプロジェクトとか、皆さんで作りませんか?
例えば「ffmpegが動くServiceが含まれたAPK」とかをオープンソースで公開しておけば、
色んなソフトからIntentで動画エンコードが利用できるよ・・・とか。ライセンス的には可能ということですよね?
2010年10月17日7:59 kazu <kazum...@gmail.com>:
> --
> このメールは Google グループのグループ「日本Androidの会」の登録者に送られています。
> このグループに投稿するには、android-g...@googlegroups.com にメールを送信してください。
> このグループから退会するには、android-group-j...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/android-group-japan?hl=ja からこのグループにアクセスしてください。
>
>
2010年10月17日9:26 sakamoto toshiyuki <sakamo...@gmail.com>:
>>動的リンクの扱いが微妙なのは、自分のプログラムAと、リンク先のライブラリBが
>>別々に配布されるケースがある上に、実際の「リンクする」という行為をユーザが行うためです。
>
> と、いうことは、GPLなプログラムを利用するActivityなりServiceなりを別のAPKファイルにして、
> そのAPKはフリー&オープンソースにしてやれば、
> そのActivityなりServiceなりをIntentで呼び出すアプリの方は、有償アプリでも構わない、と言うことですかね?
>
> そういった、「GPLを使用した要素のみ別にしたAPK」を作るプロジェクトとか、皆さんで作りませんか?
> 例えば「ffmpegが動くServiceが含まれたAPK」とかをオープンソースで公開しておけば、
> 色んなソフトからIntentで動画エンコードが利用できるよ・・・とか。ライセンス的には可能ということですよね?
Intent による連携は、「パイプやソケット、コマンドライン引数」のように、
「二つの分離したプログラ ムの間で使われるコミュニケーションメカニズム」にあたると思います。
つまり、「別々のプログラム」といえるでしょう。
「この場合、プログラムの一つがGPLで保護されていても、他のプログラムには 何の影響もありません。」
http://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation
なので、そのようなアプリならばソースコードを公開する必要はありません。
なお、GPLのアプリでも有償で販売することは可能ですよ。
売った相手がソースコード公開を請求してきたときに応じないといけないだけで。
--
NARUSE, Yui
nar...@airemix.jp
DalvikはApache Licence2.0です。
もともと、元のメールでは
「JNIという仕組みに対して、ネイティブライブラリがGPLの場合に、呼び出し側のライセンスはGPLにする必要がありますか?」
という質問であって、Java自体のライセンスとかDalvik自体のライセンスとは全然関係無いと思っていますが。
間違ってたら指摘願います。
付け加えるならば、JNI自体は初期のJavaからあったもの(openjdkができる前)だし、
Dalvikのライセンスなんかはここで聞いて答えを待つよりもご自分で調べた方が速いと思います。
#Dalvikという単語を知っているくらいなら。
2010年10月17日18:12 Tatsuo Nagamatsu <naga...@gmail.com>:
> IANAL,
>>「JNIという仕組みに対して、ネイティブライブラリがGPLの場合に、呼び出し側のライセンスはGPLにする必要がありますか?」
>
> 呼び出し側は Dalvikであり、Apache v2ライセンスですよね。
呼び出し側というか、GPL を混ぜるその「プログラム全体」に感染するという話ですね。
で、Dalvik はここでいう「プログラム全体」には入りません。
なぜなら、GPL には「システムライブラリ条項」による適用除外があり、それにDalvikは該当すると思われるからです。
http://www.gnu.org/licenses/gpl-faq.ja.html#WritingFSWithNFLibs
この条項がないと、例えば Windows で GPL なプログラムをネイティブで動かせなくなってしまいます。
> GNU Classpathでライセンスが遮断されるのであれば、VMが GPLであっ
> ても JNIを自由にできる
GNU Classpath はリンクに関する例外によってプログラムまで感染しないように明示しています。
> VMが proprietaryであっても同じ JNIが読み込
> める場合には JNIが GPLであってもよいと理解しています。
VM が proprietary の場合は若干ケースバイケースな部分が入ってきます。
GPL と互換性があるようになんとかするか、システムライブラリ条項を使えるようにするか、ですかね。
> では、Dalvikはどうなっていますか?
> Googleは Dalvikを APLv2で公開する事により、端末製造者の proprietaryな
> コードを公開する事無く利用する事が出来るような仕組みを作りました。
> しかし、GPLの JNIコードを読み込む事まで考えていたのでしょうか?
> どうもそこまで考えていなかったような気がします。
前述の通り、通常はシステムライブラリ条項を使えると思うので、あまり VM のライセンスは関係ないと思いますが、
さておき、使えなかった場合に VM のライセンスはどのような条件を満たす必要があるか考えてみましょう。
JNI を使った場合は「プログラム全体」が GPL になるのですから、プログラムの構成要素それぞれが GPL として扱える必要があります。
で、Apache License 2.0 は GPLv3 とは互換性があるので問題ありません。
つまり、Dalvik 上で動くプログラムは JNI を介して GPLv3 なライブラリをリンクすることができます。
ここで GPLv3 と明示しているのが注意点で、GPLv2 は Apache License 2.0 と互換性がないので、
「1つのプログラム」で共存することができません。
つまり、システムライブラリ条項を用いることのできる場合でないとリンクができません。
--
NARUSE, Yui
nar...@airemix.jp
2010年10月17日18:41 sahd <stopathome...@gmail.com>:
> Androidカーネルが元々Linuxで、GPLv2になりますが、Linusのポリシーとしては
> 低いレイヤー(kernel直叩き)までGPLを適用するものではない
> というのを見た記憶があるので、普通にプログラミングするレベルならGPL汚染されることはないんじゃないでしょうか。
Linux は例外付GPLv2ですね。
で、その例外がご指摘の通り、 system call を呼んでいる限りはプログラム側には感染しないというものです。
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=blob_plain;f=COPYING;hb=master
--
NARUSE, Yui
nar...@airemix.jp
2010年10月16日23:25 NARUSE, Yui <nar...@airemix.jp>:
> 成瀬です。
>
>
> 動的リンクの扱いが微妙なのは、自分のプログラムAと、リンク先のライブラリBが
> 別々に配布されるケースがある上に、実際の「リンクする」という行為をユーザが行うためです。
>
> この場合、ライブラリBがGPLであって、別のBSDLな互換ライブラリCを利用すれば
> GPLなライブラリにリンクしていないのですから当然GPLには感染しません。
> また、ユーザはGPLに同意しなくてもGPLなソフトウェアを使用することができるので、
> 配布者はプログラムAとライブラリCをセットで配布している場合に、
> ユーザがBと入れ替えて実行してもやはりGPLには抵触しません。
>
> などと、動的リンクの場合は明確に回避可能なパターンが存在する一方で、
> プログラムAとライブラリBをセットで配布した場合には雲行きが怪しくなってきます。
> 単なる集積物だと言うのは難しくなってくるんじゃないですかね。
> http://www.gnu.org/licenses/gpl-faq.ja.html#MereAggregation
>
> で、戻ってAndroind marketにおけるJNIでGPLなライブラリを利用した場合、
> 個人的にはアウトだろうなぁと思っています。
> つまり、ご自分で配布するならばソースコードを請求される覚悟をしておくべきですし、
> ライバルがやっているならソースコードを請求してみるとおもしろいんじゃないですかね。
>
> なお、確実なところはuenoさんの仰るとおり訴訟してみるしかないと思います。
Androidアプリでは、apkパッケージで配布されるため、動的にライブラリと
リンクする場合でも、ライブラリ自体と、それにリンクするアプリ本体が同時
に一つで配布されるため、別々配布という回避手段はとれそうもありませんね。
JNIでGPLライブラリを使用するのを諦めライブラリが提供していた
機能をJavaで実装するか、他の方が指摘しているように、JNIで
GPLライブラリを利用するアプリと本体アプリを別々に作り、インテント
を利用するかしたいと思います。
# Javaだと性能が出ないかな。。。