beroの日記: IMフレームワークとライセンス矛盾
Anthyライブラリとのリンクを必要とするのは、uimやscimなどのIMプログラムだけ。scimやuimは、ximやimmoduleのインターフェースを通じてキーイベントを受け取り、変換結果を返す、という構造。なので、プロプラなソフトでAnthyは使えないという理解自体がおかしい(そもそもリンク自体が不要)。
IMフレームワークがXIMのようなクライアント/サーバ方式の場合はそういう理解でも良かった。しかし
多くの入力メソッドフレームワークはクライアント/サーバーシステムとして実装されます。しかし、uimはライブラリです。
また変換エンジンがクライアント/サーバ方式の場合、クライアントライセンスさえ満たせば(あるいは互換クライアント作れば)変換サーバのライセンスは干渉しないだろう。しかしAnthyやSKK(C版)のようなライブラリ方式の場合もある。
IMフレームワークと変換エンジンの双方がライブラリ方式の場合、同時リンクによるライセンス矛盾が生じる可能性がある。
コンパイル時に(明示的な)リンクが不要だからといってリンクしてない証明にはならない。
例えばライブラリが別のライブラリをリンクしている場合がある。
ならlddで調べればいいのかというと、dlopen等で動的リンクしてるのを見逃す。
straceを使ったデバッグ
ではstraceを使う手法が紹介されてるが、失敗も含め全部出るのでウザイ。
共有ライブラリは一般にメモリマップドファイルとして実装されているので、
cat /proc/<PID>/maps
でマップ状態を見れば実際にロードされた共有ライブラリがわかる。(Linuxの場合)
てことで調査すると
凡例
-- リンク
== プロセス間通信
firefox-bin -- gtk+ -- immodule -- im-uim -- libuim -- libuim-anthy -- libanthy -- libanthydic -- anthy.dic
依存順は想像。
ちなみに昔は
app -- xlib ==(XIMプロトコル)== XIMサーバ(kinput2) -- 変換クライアントライブラリ ==(独自プロトコル)== 変換サーバ(wnn)
SCIMはクライアント/サーバ方式らしく
app -- gtk+ -- immodule -- im-scim -- libscim -- IMEngine/socket.so ==
scim-launcher -- libscim -- IMEngine/anthy.so -- libanthy -- (略)
または
app -- gtk+ -- immodule -- im-scim-bridge ==
scim-bridge -- libscim -- IMEngine/anthy.so -- libanthy -- (略)
scim-bridgeのはさまり方は違うかもしれん。
im-scimのメモリマップ見てるとlibscimからIMEngine/socket.soを経由せずに直接IMEngine/anthy.soをロード(つまりクラサバ方式ではなくライブラリ方式で使う)できるような気もする。
IMフレームワークとライセンス矛盾 More ログイン