vyamaの日記： 組込み機器+LGPL part2 2
法務との協議2回め。(以下ソフトウェア=S/W LGPLed S/W=LGPLが適用されたソフトウェア)問題になっているのは組込みシステムでLGPLed S/W+プロプラアプリの場合。OSはLinux。
3つの意見が出された。
- LGPLed S/Wを動的リンクすれば、組込みS/Wでも5節の条件に合致する(S/WはLGPL派生を含まない)から、自社IP部分はどんなライセンスでもよい。
- LGPLed S/Wをどんな形でもリンクして実行形式を作れば、全体がLGPLed S/Wの派生物になると前文に書いてある。だから6節の条件に合致するようにしなければいけない。共有ライブラリ機構を用いればプロプラアプリはリバースエンジニアリングを許可するだけで、LGPL 6(b)に従って配布出来る。
- 組込みで共有ライブラリ機構を利用するといっても、ROMに分かち難い形でリンクされている。後からユーザがROMにプログラムを追加する事など事実上不可能だから、それを「共有ライブラリ機構」を使っているとは認められない。LGPL 6(a)に従って、オブジェクトコードを公開しなければならない。
で、3.は、私が出した見解だが、さすがにちょっと極端かなと思う。FSFもそこまで要求していないだろう。理由は
- デスクトップ分野で、LGPLedなglibcを使うプロプラなS/Wをインストールしたプレインストールモデルを出荷した企業をFSFが訴える気がない様子であること。
- Linuxを使う場合、デスクトップ分野では共有ライブラリはHDDにある。一方組込み分野ではROM/RAMにあるが、実現しているFile Systemが違うからといって、同じI/Fを使っているなら、同じライセンス条件が適用されるのが妥当だと考えられること。
よって、6節(a)まではやらなくていい。で、残りは5節と6節(b)のどちらを適用出来るか。5節を適用出来ると解釈するのは結構法的リスクがあるぞ、と法務担当者に説明。で、直近の製品ではOSを含め、プログラムがHDDに入っていることもあって、リバースエンジニアリングをやらせないってことが非現実的ということがあった。「LGPLの制限内でやってもいい」と試用許諾に付け加えるのは問題ないとの事。これで1つ壁を越えられたかな。
まとめると「組込みLinuxシステムで、LGPLライブラリを使う場合、ld.soを使う仕組み、具体的には/lib、/usr/lib、/usr/local/libなどにlibxxx.so.xxxという形式で共有ライブラリが配置されていて、使用者がdebugのためにリバースエンジニアリングを許可する条項が使用許諾にあればよろしい。」となる。
ただ、「LGPLed S/Wをどんな形でもリンクして実行形式を作れば、全体がLGPLed S/Wの派生物になる」ってのは、個人的に違和感があるんだよね。デスクトップアプリケーションで、hogehoge.exe単独で配布した場合でもLGPLed S/Wが入っていると解釈するのは行きすぎだと思う。だって、そいつが動的リンクしないで、実行される可能性だってあるんだもん。ライブラリを全然使ってないのに、動的リンクされる可能性があるからといって、全部派生物だって主張は無理があるような気がする。でもだからって、動作状態で適用されるライセンスが違うってもの変。
反論を期待します。
なんとなく (スコア:1)
Windows上にて、APIフックですべてのプログラムにフックするLGPLedなライブラリが(共有で)含まれるフックプログラム。
これを噛ますようになるだけで、All-LGPLedとは考えにくいし。
# ソフト屋的にはDynamicでリロケータブルでリエントラントなライブラリとか、はっきりいってソフト用デーモンですしねぇ。
# 疎結合だよなぁ、と。
FSF的には *あえて* 見解がないんでしょうかね。
# 利用してOpenか、利用しないか。
# という、Matrixのアメのごとく、理由を説明しないことが縛りのような。
M-FalconSky (暑いか寒い)
Re:なんとなく (スコア:1)
ご意見ありがとうございます。
私もGPL/LGPLの心ってのは疎結合かどうかで判断したいってことだと思ってます。ただ、その疎結合かどうかってのは定量化しにくい。だとするあのようなライセンス条項になるのも分かるような気がします。
LGPL/GPL3にその「現実」と「心」の乖離が解消されているのかは、現在GPL3をぼちぼち読み進めている段階なので、なんともいえません。
vyama 「バグ取れワンワン」