OpenOcean が GPL 違反?

かなり以前に OpenOcean という OpenDolphin 2.7 系完全互換のアプリを配布・公開していたことがあった。
その際に小林慎治という人が(ちなみに面識はいっさいない)「OpenOcean は GPL 違反」ということを主張していた。
所属組織から注意を受けてその主張を引っ込めたと思っていたのだが、一時的なものだったらしく、いまだに主張しているらしい。

えーと、手短にいうと、当時の著作権管理をしていた LSC から、許可もらってやってますのであり得ないですね。
あり得ないというか、第三者がそこら辺の事情を知りようがないと思うんですが?

商用開発元は、遅くとも 2018 年以降は GPL 云々の適用をやめていて、MIA・SOSO などにも同様のアナウンスしています。
両者ともソースコードの公開とかフォーク元の著作権表記とか厳密に守ってないでしょ。

例えば、SOSO さんの GlassDolphin だが、ログイン画面はこのようになっている。

一見してわかる通り、著作権表示の類はなし。製品案内サイトを介して GitHub ページに飛べるようにはなっているが、挙げられているソースコードはここ数年全く更新されていない 2.6 と 2.7 だけ。GlassDolphin 最新 Ver4.0 のコードはどこにも見当たらない。ちなみに、他の方法でのソースの開示もしていない。
ソースコードの開示なし、(GPL 的な意味での)autohr の表示なしと小林氏の主張からしたら、GlassDolphin も GPL 違反や著作権法違反になるのだろうが、現実にはトラブルに至ってないのは、メドレーがこの配布方法を許可しているから。
私らの場合なんて、法人-有志の約束事に過ぎないが、SOSO-メドレーの場合には、法人間の契約と考えてよく、それに関して知りうる立場にいない第三者が著作権違反だのというのは名誉毀損や侮辱にあたるのではないかと思う。

私らなんか、かなり GPL を意識していて、ソースコードを一般に全公開するなど可能な限りその精神を尊重してたんですけどね。


この件は、そのとき現場にいた人間からすると、そんなにおかしくもないのだが、一般の人からはそうは見えないだろうし、ケチのつけられ方に前々から違和感を持っていたので思ったことを(まとまらないかもしれないが)もう少し書き留めておく。

皆川和史の立ち位置がわかりにくい

小林氏が持論を展開した時点では、原著作権者(この言い方は曖昧すぎて法律的な問題を扱う時は不適切だが)とされていた皆川氏は LSC 社に在籍していて、だからわれわれは筋を通すためにわざわざ一席もうけて LSC にご意見伺いを立てたわけだ。
その場に出てこないで、後で文句を言うのは筋違いではないか?
交渉時に「こういう表記にしてくれ」と言われたらわれわれは従ったと思う。
そのときに勘違いか何かあったとしても、後でメールかなにかで指摘してくれれば、それでも従ったと思う。
著作権や各種契約を管理していた法人(しかも本人が所属している)を通してでは何も主張できないのだから、それ以外のルートで非公式にとやかく言われてもこちらとしては社会人のマナーとしてなんの対応もできない。
これは小林氏に対しても同様で、そんなに確信があるなら、LSC に問い合わせればよかったのではないかと思う。

もちろん、そうはできない事情もある程度は察していたわけだから、もう少しやり方を工夫して欲しかった。
事情、というのは、LSC 版と goody 版で同一ファイルであっても author 表記が食い違うとか、基本設計に近い部分で Junzo SATO(佐藤純三)氏の貢献が確認できるとか・・に起因するある種の広報と実体との矛盾のことだ。
2010 年台中頃から、LSC のドルフィンは不具合は頻発し更新も滞りがちで、LSC の主張を額面通りには受け取れないという雰囲気はあった。
それでも、フォークした開発者連中は、「ソースコードが公開されている電子カルテ」などそれまでなかったのだから、違和感を持ちながらも商用開発元の喧伝する「オープンソース」の物語には付き合っていこうという態度であったと思う。
だから、ことをおさめるためにもうちょっとうまいやり方をとって欲しかった。
例えば、Junzo SATO・funabashi・miura… といったソースコード提供者の貢献を再評価し、適切にクレジットする、といったやり方だ。

@masudanaika の変節

e-Dolphin 時代からの業績を考えれば、Junzo SATO 氏などはもっとフィーチャーされていいはずだ。

が、「歯医者さんが考えた歯ブラシ」的な商業的なプロバガンダのせいか、実際はそうはならなかった。
代わりにフォーカスされたのは、増田茂と松村哲理だ。
松村氏は、当時からそれほど開発者アピールはしていなかったし、今でもソースコードの開示はして開発は継続しているので、現在でもそれほど違和感なく受容されていると思うが、増田氏の現状は一体どうしたものだろう?
増田氏の X(twitter) アカウントは @masudanaika というものだが、現在(2025.9 月)では、プロフを見る限り、OpenDolphin に関与していたとも医師だとも名乗っていない。

この現状で「増田内科の増田茂医師が開発に関与している」というかつての主張とどう辻褄をつける気なのか?

皆川和史の消失

増田氏の名前が出たついでで言ってしまえば、皆川和史に至っては事情はもっとおかしく、調べたら X のアカウント自体が消えてしまっていた。
著作権云々の観点からみてもおかしなことで、本当に保護すべき著作権人格権を有しているのであれば、むしろ所属を離れた時の方がその権利を主張しやすい。
財産権としての著作権は法人所有であっても構わないが、職務著作が成立している場合を除いて著作権人格権(表記権含)は法人には委譲不可能だからだ。
組織のしがらみでその時は自分の権利を主張できないことがあるというのは理解しているつもりだ。
何かおかしい。

小林慎治の不審なプルリクエスト

小林氏の怪文書が公開されたのが 2018 年11月26日ということだが、実は、小林さん、それに先立つ 同年11月5日に OpenOcean にプルリクエスト(PR)を送っている。
詳しくは『オープンソースの世界 〜残酷な自由さ〜』を読んでほしい。
結局、この PR はマージされなかったわけだが。
PR 送った時点では、OpenOcean が GPL 違反だとは一言も主張しておらず、PR を断ってから、突如として「違反だ、違反だ。皆川・増田をクレジットしないのは違反だ」と騒ぎ立てている。
これも何かおかしい。

類推を含む結論

最初の方で「まとまらないかもしれないが」と書いたが、なんとなくまとまってきた。
彼らが騒ぎ立てていたのは、OpenOcean 騒動の 2018 から始まって、メドレーへの譲渡が決まった 2020 までの期間にほぼ限られる。
経営陣が変わった LSC は、2018 には多分に経営的な観点から「GPL はやめる。活動実体が把握しにくい皆川・増田の位置付けも変える」ということを仄めかしていた。
この決定に関して、皆川は知っていたはずで、「開発者」の立場が風前の灯だということもわかっていたはずだ。
結果的には、メドレーへの事業譲渡という形で、この狙いは強制的に果たされるわけだが、「開発者」たちは、こうなる前に自分の author としての名前をプロジェクトに刻みつけておきたかったのではないかと推測する。

「オープンソース時代に彼らが保有した権利は、著作権人格権とは無関係な『著作権者と名乗っていい権利』だけだったのではないか?
 実際に開発して保護の対象になっているのであれば、プログラムであっても著作権表示権は保持できるはずだが、実際にはそうはなっていない。
 LSC からメドレーへの譲渡がスムーズにいったのも、そもそも彼らが保持できるような著作権表示権を持っていなかった、つまり実際には開発には関与していなかったからだと思う。
 2.3 系までの契約上の権利しか持っていなかったので、その権利を保持するために 2.7m は 2.3m の派生だと主張する必要があったのではないか?」

いるかの怪文書3』より

それまでの主張と整合性を取るために、無理とわかっていても主張を変えられない、引っ込みがつかないというのは、わかる気もするが、一時的とはいえ世間の耳目を集めたプロジェクトの着地点としては適当なものとは言い難かった気がする。

 

 

air-h-128k-il

この air-h-128k-il というアカウント、以前は

理工系院中退。メーカー勤務などを経て現在はフリーのエンジニア。 地味に医療+ITが盛りあがってきたような。でも、本来の専門は実計測なんだな、これが。

のようなプロフィールくっつけてましたが、中の人があまりに活用しないので、今後しばらくは、複数人で共同運用します。はい。

 

VTK と Vulkan

以前に VTK のことを取り上げた。
これまで、VTK は MacOS 向けの画像ライブラリに OpenGL を用いていたが、ご存じの通り、将来的には OpenGL は廃止になる。VTK は各 OS 向けに window を提供しているが、MacOS で使う vtkCocoaRenderWindow は、クラスの継承関係としては以下のようになっている。

vtkObjectBase

vtkObject

vtkWindow

vtkRenderWindow

vtkOpenGLRenderWindow

vtkCocoaRenderWindow

このうち vtkOpenGLRenderWindow が OpenGL に依存しているのため、これを継承している vtkCocoaRenderWindow は OpenGL が廃止になったら、使えなくなってしまう。

当然、VTK は、こういった構成も含めて、再検討しなければならない。

順当にいくなら、アップル公式推奨の Matal を使うことになるのだろうが、Metal は windows や linux 上では動かず、マルチプラットフォームが売りの VTK の基本設計と甚だ相性がよろしくない。

どうするか気になっていたのだが、結局、Vulkan を採用するようだ。

GitLab のリポジトリには、(完全ではないが)ある程度のコードが既に上がっている。
開発者からのメッセージも読むことができる。

 

ただ、ここのところ更新は滞っており、どうなることやら。

 

VTK のサワリ

VTK といいうのは Visualization Tool Kit の頭文字の略で、容易に想像がつくようにデータの可視化ツールだ。

技術的には標準的な C++ で書かれており(一部、OS 依存の部分はもちろんあるが)、cmake というツールを使って各々の OS 向けにライブラリとしてビルドする。

医療系のソフトだと、まず OsiriX に3D構築のツールとして組み込まれて知名度が高まった。(だから、当然、Horos や HorliX にも使われている)

今でもアクティブに開発は続けられているが、新しい MacOS 向けの修正(M1 や Metal 対応)がやや遅れている。

VTK がどんなものかは見てもらった方がわかりやすいでしょう。

これは、サンプルコードを cmake のみで Mac アプリまで作成した例。

では、こちらはどうでしょう。

表示されている内容は最初のものといっしょですが、動作のさせ方が違いますね。いったん、空の window が表示され、メニューからこの画像を呼び出しています。
これは、VTK のライブラリを MacOS のアプリに組み込んで使っているのでこうなっています。

実際のソフトは特定の OS 上で動き、UI などのパーツはその OS が提供するものを用いるので、実務的には後者の使い方が多くなります。