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

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

この人も(なぜか小山ツィートと同じ 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 先の法人自体が「以前に著作権を主張していた人にはもう関与させていないし、今後も関与させるつもりはない。まずは、実務的な要求を満たす改修を優先したい。可能であれば協力してほしい」という方針を打ち出していた。
小山のツィートはこういった努力に水を指す行為だ。


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

 

MOSS というのは反社組織かなにかなのか???

最近、更新サボり気味なので、身の回りで起こったことなど。

OpenDolphin に関連して前々からおかしな情報(ほとんど誹謗中傷と言っていい)を垂れ流している小林慎治とかいう男がいるんだが、最近、こいつが書いた間違いだらけのブログ記事が見つけたので所属先に連絡して削除してもらった。

元のタイトルは『openoceanによるgpl違反事例について』というかなり物騒なもの。

論旨はいつものアレ。

OpenDolphin は GPL で、かれこれという著作権者がいる、にもかかわらず、air-h-128k-il (当時、もっぱら私が使っていたネット上でのハンドルネーム)は、 そういった権利関係を根こそぎ無視して自分の著作として公開しているから GPL 違反だ、というもの。

記事が書かれたのは 2018 らしく、この時点でよくもまあこれだけ、出鱈目なことをかけたものだと思う。

まず、大前提としてこれが書かれた時点では、OpenOcean に関しては LSC と連絡を取っていて、この形態で公開して OK という許可をもらっている。小林はこの事実関係を知りようがないわけだから、書かれている内容は推測の域を出ず、事実としても間違っている。内容に関してもほとんど妄想レベルの作話です。

私もけっこう記憶が曖昧になっているが、この時期、LSC は経営陣に変化があって、OpenDolphin に関してそれまで広報されていた内容と実態とが大きく食い違っていたため、LSC 自体が内部から開発や広報の方針などを大きく変えていた時期だ。

まず、OpenDolphin は医師が協力して・・・という宣伝文句だが、これは文字通りほとんど宣伝用のアナウンス。

文献的な調査からも明らかになりつつあるが、基本設計は e-Dolphin 時代のもの。

また、開発フローも

e-Dolphin 時代のコード→LSCによる新機能の企画・実装→下請けに発注

が基本という話で、このフローに README に記載されている医師の関与は「ほとんどない」そうだ。

特に増田茂に関しては「データ互換性のない同一名称プロダクツをあたかも互換性のあるかのように広報している」ということで、メドレーからは作者扱いはされておらず、むしろ監視・注意の対象となっていたほどだ。

要するに小林は、LSCが一時期(多分に宣伝目的のために発表した)広報内容をなんの検証もなく「これが事実だ事実だ」と盲目的に言い募っていただけなのだ。LSC自体が訂正入れているにもかかわらず、自分の主張の方が正しいって言い張る神経がよくわからない。

なお、タイトルに「反社」といれたのは、当方管理下のブログに小林から訴訟を仄めかす内容の投稿があったからだ。

 

(追記)MOSS(医療オープンソースソフトウェア協議会) というのは、法人格も何もない任意団体のようっすね。
厚労省本省の方も言っていたが、こんなしょうもない主張をわざわざそれっぽい団体名で権威づけしてまで発表しなければいいのにと思う。その時はいいかもしれないが、収束させるのに手間がかかることこの上ない。

(追記2)あまりにも出鱈目な内容が多いせいなのか、twitter に関しては鍵垢になったようですね。
アイコンのピカチュウは(おそらく)利用許可とってないでしょうから、相変わらず、著作権違反しまくってますね。

(追記3)まあ、国立保健医療科学院という組織自体、業者との癒着の温床になっているようですが。

(続く)

 

次世代型 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 でもこれらのフォーマットが扱えないかが気になるところ。

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

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

 

(続く)