Dolphin プロジェクトと皆川和史

以前にこの記事OpenDolphin に関して「向う(注:LSC の一部などのこと)も困っているのか人を介して元プロダクトマネージャーの方から、オープンソース版のとりまとめ役になってくれないかという依頼もあった」ということを述べたが、一部の人から「そんなことはない!」みたいな反応があったようである。

どうもこの手の人たちは「人を介して」の部分を読み飛ばして「とりまとめ役になってくれないか」だけに(なぜか)憤りを覚えていたようだ。

「LSC から(直接)とりまとめ役を頼まれた」と書いているのではないのだが?

その「人」が少々話を盛っているかもしれないので、私だって真に受けてはいない。だが、そういう話をふられたことは事実だ。

具体的には、twitter(X) の DM でこんなやり取りが行われていた。
その一部を抜粋する。

air_h_128k_ill 版というのは OpenOcean のことで、処方箋打ち出し機能などを備えていたが、本質的には OpenDolphin-2.7m と同じだ。
LSC が提供していたDcoker 版のドルフィンサーバーと通信し、目立ったバグはなく、ファイルバックアップ機能を有していたことから、当時、かなり人気があったのだ。

ここだけだと「とりまとめ役」というニュアンスは薄いが、会話相手が言うには皆川(和史)氏の希望としては「OpenOcean をベースに増田バージョン(増田ファクト)をマージし、オープンソースとしてメンテしていってほしい」というようなことだったらしい。

会話相手が盛大に話を盛ったかもしれないので、私もこれを額面通りには受け取っていないが、少なくとも「向うも困っているのか人を介して元プロダクトマネージャーの方から、オープンソース版のとりまとめ役になってくれないかという依頼もあった」という表現はそれほど間違っていないと思う。わざわざ「人を介して」と入れているのだから、その程度の文意は汲み取ってほしい。

ところで、今、読み返してみると、当時の混乱ぶりが窺い知れる。

例えば「OpenOcean は元々は増田ファクト」というトンデモな解釈。これは「一部」の人たちの間では、さも真実であるかのように扱われた。

これは完全な間違いで、Fork 順は

LSC Dolphin → OpenDolphin-2.7m → OpenOcean

というのが正しい。増田ファクトは入っていない。
そうでなければ、LSC のドルフィンサーバーと何の齟齬もなく通信できるわけがない。
(ソースコードから検証した内容を『ソースコード嫁』として記事にしました。オープンソース界隈の方からかなり好評のようです)

なぜ、そういったことを言ったのかは、現在なら、ある程度推測はつくが、その詳細を述べるのは、長くなりそうなので、ここでは触れない。が、相当焦っていたのは事実だろう。ドルフィンの担当役員を外され、LSC 自体の経営陣が刷新され、公的にはドルフィンと関われなくなりつつあったのだから。


この話はこれでおしまいなのだが、一応、付け加えておくと、この後、経営陣が刷新され新たに LSC に加わった担当者が直接当方まで会いにきてくれて、「本家リポジトリのメンテナになってくれないか」という依頼があったのは事実です。
OpenDolphin-2.7m は、LSC Dolphin の直系なので、悪い話ではなかったが、HorliX の開発でいっぱいいっぱいでお断りせざるを得なかった。

また、2020 のメドレー譲渡の際にメドレー担当者(マッチョな人、と言えばわかるでしょうか)から、やはりメンテナ就任の打診は(電話でですが)ありました。


これは、私の全くの想像だが、経営陣が刷新された時点で「基本的にはドルフィンはオープンソースをやめる」というのが決まっていたんではないかと思う(実際、2.7 以降、本家のリポジトリ更新はない)。
オープンソースであるが故にとにかく売れていなかった。
私は、かなり詳細なインストール記事を書いていたし、SOSO さんは本家ドルフィンにさらに機能追加した GlassDolphin をリリースしていた(その後、MIA も参入)。
この状況下では、あえて LSC Dolphin を選ぶ理由がない。


しかし、おかしなこと言わなきゃいいのに。。。

HorliX にコメントしてくれるのは嬉しいが、見当はずれとわかったら訂正して欲しいものだ。
実際、上二つのツィートは作成者が勘違いに気がついたかなにかして削除してあるのだから。
誰でもうっかりミスはある。それだけで咎めることは現実世界でもそう多くないと思うし、私も咎めない。
だが、ミスを認められず放置となると話は別だ。
不健全な自己顕示欲は、拗らせると碌なことにはならない。

 

 

松村哲理(元町皮ふ科)の件

小山哲央の件が出たので、ついでで松村哲理(医師。元町皮膚科院長 札幌)の件も。

この人も(なぜか小山ツィートと同じ 2019/3/19 に)おかしなツィートをしていた。

前後のツィートを切ってこれだけ取り出すとわかりにくいかもしれないが、彼が言いたいのは「ソースコード上の @author 表示を当方開発陣が本来の author から自分たちの名前に勝手に書き換えた。つまり

@author Junzo SATO を @author air-h-128k-il (例えばね)

に書き換えた」ということなのだと思う。

なんで、こういうこと言うかなあ。

もちろん、そんなことは一切していない。

OpenDolphin-2.7m にしても HorliX にしてもソースコードは GitHub 上に全公開している。
そんなに疑うなら、自分で調べればいいだけの話だ。

OpenDolphin に関しては、今まで README などにクレジットすらされていない author を当方が発見してその都度ブログや SNS などで情報発信すらしている。

中でも Junzo SATO (佐藤純三)氏に関しては、プロジェクト初期にはクレジットされているのにもかかわらず(下図参照。オリジナル魚拓はここ)、途中から、なぜか脱落していたため、ソースコード・機能の両面からその貢献度を調べ、かなり正確に(再)評価していると思う。

他にも funabashi 氏,  Kushiro 氏, miura 氏などのコーダーの名前をソースコード上で発見・適宜報告している。

こういった方々の存在を隠蔽していたのは、むしろ、皆川和史増田茂松村哲理・・・といった面々だったのではないか?

確かにある時期までは(プログラムに関する著作権法的な意味で)何らかの著作権は有していたのかもしれないが、メドレー譲渡以降は保持していないのだから、今となっては、少なくとも「自分たちのみですべてを開発した」といった主張は訂正した方がいいのではないかと思う。


ところで、彼の OpenDolphin に関するブログを見るといまだに以下のような表現をしている。

オープンドルフィンラボが物理的には LSC 社内に置かれていたとしても、名義的にはメドレーが保有しているわけだから、いい加減、訂正したらどうかと思う。

頑ななまでにメドレーへの譲渡を認めないのは不自然すぎる。


また、彼はこういったツィートもしている。

HorliX のリポジトリを探査したが(horlix 固有のオリジナルな)コードがないと言いたいんだと思うが、これは当たり前の話で、彼が参照している先は horos ブランチ。14件のコミットは Fork 元の horos 由来のマージだ。

horlixhoros から分離独立するときに、ある程度の連携を両者で保つために、horlix のリポジトリのブランチの一つを horos と同じにすることを「オープン」に取り決めている。horlix ではこれが horos ブランチになっている。

https://github.com/horosproject/horos/issues/342 より

この構成は、horos-horlix だけということはなく、Fork 元を上流ブランチとして設定するときにはかなり一般的に行われていることだ。

これが理解できていないということは

・Git ホスティングサイトを使った開発の経験がない
(Fork 元のない単独プロジェクトであってもプロジェクト内でブランチを切ることはしばしば行われるのだが?
今までどうやって開発してたんだろう?)

・この分野で慣例的に使われる英語が読めない

ことを強く示唆するもので、彼が書いたと称するコードの質と釣り合いが取れない。
以前から関係者の間では「松村哲理が開発したと称するコードの大半は他の業者の手によるものだ(業者開発コードを自分名義で発表している)」ということは噂話のレベルでは言われていた。
松村氏自身はそれほど開発者アピールをする人ではなかったので、私はこの手の話は耳にしても聞き流していた。だが、この手のツィートがあると、どうしてもこの噂話は本当だったと考えざるを得なくなってしまう。
現在の開発元のメドレーも松村氏の(著作権的な意味での)関与を認めていない以上、当方も今後はそのように取り扱うしかないであろう。

参考

・総合的な解説は『OpenDolphin -wikipedia風解説-』が詳しい。

・『ソースコード嫁』から類推するに、小林慎治皆川和史増田茂・・といった人たちは Java のソースコードをほとんど読めていないことがわかる。

・Twitter(X) アカウント @masudanaika は、実在の増田茂医師ではなく、関係の深い業者が管理していたのではないか?という推測が『@masudanaika による個人情報流出ツィート』でなされている。

 

 

小山哲央(アーク情報システム)の件

以前に小山哲央という人が OpenDolphin や OpenOcean ひいては開発陣へ誹謗中傷のツィートをしたことがあったのだが(ちなみに当方がこのツィートを発見したのは 2022年末)、諸々あってツィート削除などしてもらった。

しかし、待てど暮らせど正式な謝罪がない。

気乗りしないことだが、先日、かなり強硬な態度で「社会人ならちゃんとしなさい!」的な連絡をさせてもらった。ニュアンス、わかりますよね?

これに関しては、謝罪・訂正らしきものはあった。(アイキャッチ参照)

しかし、その文言はどうだろう?

>2019年3月14日にポストしたGPLライセンスのポストについて、
>ポストの削除をいたしました。
>コミュニティの是正勧告について第3者がコメントをすることは
>不適切な行為でした。
>お詫びすると同時に、今後はこのようなことがないように注意いたします。

確かに「お詫びする」とは言っているけど、じゃあ、元ツィートの「故意に」「違反」しただのといった一方的な攻撃的な表現や「一読をおすすめします」といった自分をさもオープンソースの権威かのように自認した上から目線の表現は何だったの?という話になる。
そこらへんの説明が一切ないから、この内容だと、(私の印象では)法的な意味で「名誉毀損」や「侮辱」に対処したことになってない。

詳しい知識はないが、「事実の真偽に関係なく社会的評価を低下させる」内容であれば「名誉毀損」にあたるはずですよね?

世代的な問題もあるのかそれとも他の理由があるのかわかりようがないが、必要最低限のことしかやろうとしない。

そこらへん、意識してやってるのか、無意識でやってるのか不明だが、やり取りを側から見ている関係者は徐々に呆れていってます。

主だった意見をまとめておくと・・・


法的な問題は置いておいても「第3者がコメントをする」といった表現も、責任逃れのような印象を受ける。
内容はオープンソースに関わる。
オープンソースは、その言葉が示す通り、ソフトウェアのソースコードは公開されている。この場合も Fork 元・Fork 先ともソースコードは全て一般公開されている。
両者の比較からリンク先の記事の論証は極めて甘いことはわかるし、小山自身が事実確認や検証を行うことは可能だ
しかし、この作業を怠っている
オープンソースの分野で何ごとかの判断を行いたいなら、まずはオープンソースの流儀に従って自分で検証するのが筋だろう。


実務的な意味でまずいのは、このオープンソースのプロジェクトが電子カルテだったという点だ。
電子カルテというのは、単純に動けばいいというものではない。種々のガイドラインで定められた基準を満たす必要のある極めて実用性の高いソフトだ。
そして、小山がツィートした 2019 頃には、Fork 先のプロダクツは改修が滞り気味で実務的な要求に応えられなくなってきた時期だ。
だから Fork 先の法人自体が「以前に著作権を主張していた人にはもう関与させていないし、今後も関与させるつもりはない。まずは、実務的な要求を満たす改修を優先したい。可能であれば協力してほしい」という方針を打ち出していた。
小山のツィートはこういった努力に水を指す行為だ。


「オープンソースの開発者や開発方式には敬意を払うが、オープンソース『信者』は嫌いだ」という人は多いが、その理由が今回の一件で分かったような気がする。

(追記)ところで小山が拡散に努めた小林慎治元記事だが、しばらく非公開になっていたのだが、どういうわけか再び公開されていた(2025 年 9 月確認)。
ほぼないと思うが拡散される可能性もある。
対策として、結局、反論記事を作成・公開することになった。
小林慎治氏の OpenOcean に関する事実誤認
OpenOcean が GPL 違反?
をご覧ください。

次世代型 HorliX

現行の HorliX を Mac AppStore からリリースしたのは、2018 年のことだから、かれこれ 5 年前のことになる。

売れ行きも評判も上々で気を良くしていたんだが、すぐに今も続く懸案事項が持ち上がる。

それは当時のアップルが打ち出した

OpenGL の廃止・Metal への移行

という方針だった。

HorliX に限らず、画像系のアプリはほとんど OpenGL に依存していたから、それなりの騒ぎになったことは覚えている。

幸い?すぐに廃止ということにはならなかったが(ちなみに、今でも OpenGL は使えている)、Metal が普及するにつれ、そのパフォーマンスの良さに「移行はやむなし」という雰囲気に変わってきたように思う。

私も、この方針が打ち出された直後、次期バージョンのことを思い浮かべた。

当初は、まずプラットフォームを Qt に移そうかと考えていた。
Qt はかなり早い段階から、Metal 対応を進めていたので、構想としては悪くなかったと思う。実際、試験的にプロトタイプも作成したりした。

ただ、どうしても本気になれなかったのは、HorliX を構成する膨大なライブラリ群もまとめて Qt で面倒をみなくてはならなくなることだった。

何か本質的でない気がした。

Metal への移行が思っていたより緩やかなことがわかってくると、アプリの Metal 対応は次第に考えなくなっていった。

ここ数年はそんな感じだった。

ところが、別件で画像処理関係で Metal を触ってみると、意外に扱いやすいことがわかってきて、HorliX 云々は別にしていくつか試験的なコードを書いてみた。

例えば、2D ビューア。

3D ビューア。

機能を豊富に盛っているわけではないが、最低限のラインはできているんじゃないかと思う。

当初は何かに使うという予定はなかったが、Metal による 2D や 3D 画像の取り扱いに慣れてくると、「これらを使って、次期 HorliX (PHORLIX と呼んでいる)できるのでは?」と思うようになった。

ここからの話は長くなりそうなので、いったん切ります。

 

DCMTK Ver 3.6.7

ちょっと前に twitter でも触れたのだが、DICOM 解析用のライブラリ DCMTK が Ver 3.6.7 にアップグレードされた。

このバージョンでは、ネイティブで arm Mac にも対応したので、早速、 M1 MacBookPro でビルド。

HorliX に組み込む

一部の機能を HorliX に搭載した。

ところで従来の HorliX のビルドシステムはお世辞にも洗練されているとはいえず、これを機会にかなり手を入れた。

ユニバーサルバイナリ(一つのバイナリファイルで Intel Mac と arm Mac で動作可能なファイルをこういう)まで一回のビルドでできれば申し分ないのだが、各種設定が面倒なため、当面は arm アーキテクチャにしぼって対応を進めていく予定だ。

(追記)やはり、ユニバーサルバイナリは、アーキテクチャ毎にビルドして、lipo コマンドで、それらを一つのファイルに落とし込む、というのが基本のよう。

デスクトップアプリ単体なら、一度に生成する、というのもなんとかなるかもしれないが、horlix のようにソースコードの大半がライブラリという場合は、やめておいた方がいいでしょう。

ライブラリとして使ってみる

知り合いの先生が、dcmtk を純粋にライブラリとして使ってみた例を提示している。(『DCMTK を Mac で使う』)

私も試してみたが、コマンドラインツールでは紹介されている方法でうまくいく。が、cocoa アプリでは(ビルド自体はできるが)実行させたときに、落ちるようだ。

最初、???だったのだが、どうやら、タグ解析時に使う dicom.dic がサンドボックスのせいで cocoa アプリから読み込めないのが原因のようだ。

解決方法は色々あると思うが、最も簡単なのはビルトインの辞書を使う方法だろう。

外部フォルダに置かれた辞書ではなくビルトインの辞書を使うためには CMake でライブラリを構築する際に ↓ のように

DCMTK_DEFAULT_DICT を builtin に設定する。

というわけで問題なく cocoa アプリから dcmtk が使えるようになった。
試しに実際のダイコムファイルから特定のタグ情報を抜いて、画像を表示させた。

コントラストがおかしいが、白黒反転すると正しくなりそう。

おそらく、US (Unsigned Short) の値を特に工夫せずにそのまま使うとこのようになる。

臨床的にはかなりまずいのだが、dcmtk 自体はうまく動いていると考えてよいのでまずは一安心。

クラスの階層構造

ところで、dcmtk は(多くのオブジェクト指向で書かれたライブラリがそうであるように)各クラスは階層構造を取っている。

上のサンプルでは、タグ情報を抜いてくるのに DcmDataset というクラスのメソッドを使ったが、このクラスの階層は以下の通り。

DcmDirectoryRecord は使ったことがないなあ。

まずは、興味の持てそうなクラスの主要なメソッドを試しに使ってみると次第に使い「慣れ」ていくようになると思う。

動画系は扱えるか

ここまで書いたついでで、動画系 dicom の話題。

dicom の転送構文(transfer syntax などという。訳語がいまいちピンとこないが)には、mpeg などの動画フォーマットも定義されている。

当然、dcmtk でもこれらのフォーマットが扱えないかが気になるところ。

海外でも同様の疑問は上がっているようだ。

現状だと「扱えなくはないが、安定性に欠ける」といったところでしょうか。

 

(続く)