小林慎治氏の OpenOcean に対する誹謗中傷・印象操作

2018 年頃にわれわれがソースコードを公開、実行可能ばクライアントバイナリを配布していた OpenDolphin 由来の OpenOcean という電子カルテがある。

商用版よりもバグがなく、簡易ながらカルテ記載内容のバックアップ機能を搭載していたせいか、かなり好評で、おかげさまでかなりダウンロードされた。

以前に厚労省の標準型電子カルテの班会議

今となってはいにしえのオーパーツみたいなものですが、オープンドルフィンという経産省が旗振りをしたオープンソースの電子カルテがありました。あれは、商用化は、LSCというところがある程度やっていましたが、結局売れなくて、現在はメドレーが引き取ったような形になっています。オープンドルフィンは自力運用している施設が多くて、多分その次ぐらいに私がカスタマイズしたバージョンが普及していたようですが、私は対価は一銭ももらっていませんし、サポートもできる限り無料で答えていました。

と言っていたのは、こういったことを指す。なお、会議録で PHAZOR とあるのは私の発言です。
当方としては

・バグのありか・直し方を実践的に示したい

・バックアップ機能を一般ユーザーがどのように評価するか知りたい

という意図があり、だから、クライアントバイナリの配布も 2018 年のみとしていた。
その後は、HorliX のメンテや PHORLIX Lite のリリースなどがあり、正直、Ocean のことは忘れていた。

ところで、その当時、OpenOcean に関して小林慎治氏が書いた怪文書(この呼び方が適当かどうかわからないが、客観性を持った内容とはとても思えずここではそのように呼ぶ)があり、その存在は知っていたのだが、元記事自体が非公開になったりで、その怪文書の存在自体もすっかり忘れていた。

それですんでいればよかったのだが、この文書がまとめサイトのようなところに長期に渡って転載されていたのが最近になって判明した。
拡散されることはまずないと思うが、困るのは(出来の悪い) AI などによるまとめで、ニッチな分野の場合、その分野に関する文書があるだけでそれを無条件に正しいとみなしてしまうようだ。

ああ、これは反論しておかないとまずいと思い、いくつかの記事にまとめた。
背景事情や経緯なども盛り込んでしまったから、中には読みにくい記事もあったと思う。
本稿では、反論に関してはなるべく整理して書く。


皆川和史氏による LICENSE 文書の改竄

怪文書の主張は「OpenOcean が GPL 違反をしている」というなんとも物騒なものだが、主な根拠は

1. LICENSE の (C) 表記が dolphin-dev の Kazushi Minagawa から air-h-128k-il に変更なっている

2. LICENSE(GPLv2) と README(GPLv3) とで GPL のバージョンが一致していない

の2点だ。
どちらにも LICENSE が出てきていることに注意してほしい。怪文書全体も LICENSE 文書が正しいという前提に立って書かれている。

ところで、実際の LICENSE 文書は、以下のようなものだ。

文書は修正履歴がわかるようにこちらのコミット履歴から取ってきた。
一見してわかるように( ver2.7.0b のリポジトリであるにも関わらず)

・著作権表記を会社名義から「皆川和史」名義に変更
(ログイン画面などでは (C) OpenDolphin Lab と (C) Life Sciences Cmputing が併記され、一致していない)
・GPL version を 3 から 2 に変更
(これも他の箇所では 3 で統一)
・ソフト自体の version を 2.4 から 2.2 に変更
(2018 年時点でリポジトリは ver 2.7.0b )

と不適切な表記になっている。
ここだけ取り出すと、単なる ver2.4 からの更新忘れに見えなくもないが、問題なのは、このコミットが、mbot-dev(皆川和史氏のアカウント)によって 2015/8/8 になされたものだということだ。ver2.5.12 が公開されたのが 2015/1/15 のことだから、この修正は、ver2.5.1 の公開後に行われたもので、明らかに意図的な改竄だ。

どうしてこういうことをしたのかは推測するしかないのだが、おそらくは「Kazushi Minagawa, Digital Globe」の表記をどこかに刻んでおきたかったからなのではないかと思う。
というのは Digital Globe(DG) は、2012年に Life Sciences Computing(LSC) と合併しており、その際に OpenDolphin の取り扱いもいわゆる「職務著作」になっている。

この場合、著作権表記はログイン画面やアバウトボックスなどが示すように
(C) OpenDolphin Lab や (C) Life Sciences Cmputing Corp
と表示するのが適切で、逆に個人名を出すのは不適切だ。

悪意のある切り取り

怪文書に話を戻す。

改竄された文書を正しいとみなしている時点で、主張の前提が崩れており、批判にもなっていないと思うのだが、改竄の事実に気がついていなくとも (C) 2001-2011 Kazushi Minagawa から (C) Kazushi Minagawa だけを取り出すのは不自然だ。文書全体を見れば (R) OpenDolphin version 2.2 とあるので、この LICENSE を version 2.7.0b のものとみなすのには無理があるからだ。
悪意のある切り取りで、誹謗中傷と言っていい。

なお、OpenOcean の表記を (C) air-h-128k-il としたのは、「ここを (C) LSC としてしまうとユーザーが混乱してしまうから、配布元がわかるようにしてください」というLSC からの要請です。
著作権の管理主体として (C) を使うのは、著作権法的にみて適当ですし、ドルフィンプロジェクトでは各々の慣例的にこのように表記されていたので、それらに従ってこの表記になっています。

・・・と、ここまでで怪文書に対する反論としては十分な気もするが、補足事項なども書いておこう。

オープンソースの物語

怪文書は、他にも事実誤認があり、以前から指摘していたのは fork 順の誤認だ。
彼が言おうとしているのは

2.2 → 2.3m(増田内科増田医師のカスタマイズ)→ 2.7m

なのだが、これは全く正しくなく、2.7 → 2.7m だ。
この点は『ソースコード嫁』という記事に実際のソースコードをあげて詳しめに解説した。2.3m の開発者であり医師だと自称していた増田茂医師(X のアカウントは @masudanaika)の主張があまりに強かったため、ここだけで一つの記事にしたのだ。

mbot-dev が、わざわざ 2.4 → 2.2 としたのは、おそらくは

2.2
→ 2.3m(いわゆる増田ファクト)

とすることで「彼自身の個人的著作を起源とするオープンソースプロジェクト」としての継続性を確立したかったからだと推測する。

怪文書の主張は 2.3m → 2.7m だから、この系譜の継続性や影響度を補強したかったのだろうという意図は感じるが、事実はまったく異なる。

e-Dolphin 時代の成果の隠蔽

では、仮に 2.2 時代への巻き戻しが成功したとしても、彼らが言うような「理想的なオープンソースプロジェクトしての OpenDolphin」は成立するのだろうか?
そこまでいかなくても彼らが周囲に信じさせようとした「皆川和史の個人的著作を起源とするオープンソースプロジェクト」という物語は成立するだろうか?

「しない」というのが、最新の見解だ。
2018 年時点でも「技術的なドキュメントが少なすぎる」・「開発者を自称する人たちの説明がおかしい」というようなことは言われていた。
なかでも Junzo SATO さんは、ソースコード上でも署名がなされ、機能的にも意味のあるコードを提供しているのに、当時のアナウンスでは一切言及されておらず、その存在が謎とされていた。

その後の調べで(例えば、学会講演要旨。下図参照) e-Dolphin プロジェクトに参加していた佐藤純三さんであることが判明した。

ドルフィンプロジェクト初期の公式資料でもコーダーとして言及されている。

この事実だけでも「README に言及されている人物のみが開発者」という主張は崩れる。

なんでこんなことが起こったかといえば、おそらくは e-Dolphin のソースコードが事業主体に著作権付きで提供されたから。
同じ e-Dolphin の成果を基に開発された goody 版 OpenDolphin では、著作権表記

(C) 2016 Open☆Star

となっている。しかもライセンスは MIT である。

ソースコード上での @author 表記は残されているのだから、なんらかの形で著作権表記に関する配慮は必要なはずだが、皆川和史はこれを意図的にしていないし、小林慎治もこの方針を支持している。

この項目の冒頭で、「仮に 2.2 時代への巻き戻しが成功したとしても、彼らが言うような「理想的なオープンソースプロジェクトしての OpenDolphin」は成立するのだろうか?」と書いたが、これだけあからさまな開発者の隠蔽工作が行われているのだから、「成立しない」と考えるのが妥当だろう。
少なくとも「皆川和史の個人的著作を起源とするオープンソースプロジェクト」というのは全く成立していない。

ブロバガンダとしての README

怪文書は皆川和史を「原著作権者」としているが、実は、そんなことは LICENSE 以外にはどこにも書かれていない。役割的には README を記載しているにすぎない。
リポジトリの編集権限を持っているということとアプリを開発したことは概念からして違う。

後期LSC やその後のメドレーの主張は一貫していて、OpenDolphin は、あくまで「法人としての職務著作」である。

だから、README の記載は多分に広報的要素の強いブロバガンダ的なものだ。
実際の記載も以下のように控え目だ。

OpenDolphinのライセンスは GNU GPL3 です。
OpenDolphinは下記先生方の開発されたソースコードを含んでいます。
・札幌市元町皮ふ科の松村先生
・和歌山市増田内科の増田先生
・新宿ヒロクリニック
・日本RedHat Takayoshi KimuraさんのJBoss as7 へのポーティング
これらの部分の著作権はそれぞれの先生に帰属します。またOpenDolphinにはコミッターが存在しません。フォークされた場合はそれぞれ独立した開発者になっていただき、 GitHub 等でソースの共有をお願いしています。 

ソースコードを含んでいる・著作権はある、と漠然と言っているだけで、それらが保護すべき著作権だとも表記しなくてはいけないものだ、とも書かれていない。
実際、アプリレベルでは、上に挙がった人たちの名前は記載されていない。

「歯医者さんが考えた歯ブラシ」ではないが「お医者さんが考えた電子カルテ」という表現は消費者に強い訴求力があり、実際、2015 年頃まではこの広報は成功していたのだから、個人的には、そこまで厳密な追求(開発者・著作権者としての立場の承認など)をしなければ良かったのではないかと思う。

わかりやすいのは、増田内科増田茂医師の X 上でのアカウントとされていた @masudanaika で、2025 年現在では、アイコンも烏賊に変わっているし、プロフィールには医師とも書かれていない。
日本の医師法では、医師以外の者が医師と名乗ることはできないので、そのための配慮だろうか。

特に、メドレーに事業譲渡がなされた 2020 年以降は、2.3m の開発自体もほぼ停止している状況で、これでこの中の人が「独自の先進的な拡張を施した開業医兼開発者」と言われても、とても信じることはできない。

最後に

怪文書に対する反論としては最初に2項目程度で十分という気もするが、それだけではうまく内容が伝わらないと思い、経緯や当時の状況に関しても述べた。
率直な感想としては、「このプロジェクトは、収まりが悪い」というもの。
オープンソースとしての特徴や使われている技術内容からして、(特に登場時など)注目に値するものだったと思う。
だが、一部のリーダーや関与者の利己的な振る舞いで、それがうまく展開できなかったのではないかという疑念を持つ。
適当な着地点を見つけることができれば良いのだがと今でも思う。

(適宜修正更新予定)

 

猪股弘明
OpenDolphin-2.7m 開発者
精神保健指定医

 

オープンソースに関わられている方には一読をおすすめします

関係者の怒り方が半端なかったため、やむなく投下。

小山哲夫(当時アーク情報システム所属)の誹謗中傷 tweet について

まあ、ちゃんとソースコードにあたって検証していれば、間違えないところですからね。

にもかかわらず、あたかも自分がオープンソースの代表者のように振る舞うのはどうなんだろう?

オープンソースに関わられている方には一読をおすすめします。

 

Protected Mode への入り方【HorliX/Horos/OsiriX?】

HorliX のユーザーさんで Protected Mode に入れないという方がいたので、動画で解説してみました。

Horos も同じ手順で入れると思います。

現行 OsiriX は、持ってないのでわかりませんが、以前のバージョンなら、これで入れると思います。

ビューアがダイコムファイルを読み込む時、タグ情報などをデータベースに保存、画像は適当なフォルダに入れておくと思います。
が、おかしなダイコム(異常ダイコム)の場合、タグ情報や画像をうまく展開できず、ファイル(スタディ)としては登録されているのに、画像表示できない時があります(ひどい時は、以降、起動不能)。
そこで、画像を表示させない状態でアプリ自体を立ち上げるモードが Protected Mode というものです。
このモードで立ち上げて、異常ダイコムを取り除く、という操作をすると、次回以降は、データベースは元の状態に戻り、起動可能となる場合もあります。

ただし、’INCOMING.noindex’ フォルダの方におかしなファイルが引っかかっている場合は、そもそも Protected Mode 自体に入れないので、これが絶対ということはありません。

 

猪股弘明
HorliX メイン開発者

 

接触確認アプリ cocoa とオープンソース

某所でコメントしたことの転載。


cocoa はバグが枯れてきた印象はあるんですが、今後も継続的に適切な保守開発が行われるかというと若干疑問もあります。
契約の詳細まではわかりませんが、実際に保守開発を行っているであろうデザイアードには405万の費用しか渡っていないからです。
https://www.tokyo-np.co.jp/article/87051/

エンジニアを一人 40 万/月でアサインして 10 ヶ月保守したら、予算尽きてしまいます。
今後どういう運営をするつもりなのかの説明がまったくないのでこのままでは信用できません。

そして、このプロジェクトが興味深い点は、元はオープンソースで、献身的なエンジニアがバグなどをボランティア的に見つけ、その改善策を提案しているところです。
今回の修正もおそらくそれらを参考になされたものだと思いますが、その点をいっさい伏せて、さも「自分たちで修正しました」というのは、ちょっとどうかと個人的には思います。

そして、これが一番ダメなんじゃないかと思うのは、プルリクエスト(コードの修正依頼)に対して、厚労省側のレビューが全くない点です。
これされると(=オープンソース性の喪失)今後バグが出てもその責任箇所を指摘できないし、どう修正していいかといった提案も当然できません。
これやって失敗したプロジェクトはけっこうあります。

最後に、ボランティアで参加したエンジニアの方の意見を一つあげておきます。

Issueとは直接関係ないのでコメントとして記載します。

現在のCOCOAの状況を大変、憂慮しています。

このIssueを見ている関係者の方は居られないのかもしれません。しかし、もし居られるならば、今一度、オープンソースのやり方でCOCOAを継続的に改善する方向へ舵を切ることを何卒ご検討ください。

もしそうなったならば、ぼくはAndroidアプリ開発に携わるソフトウェア開発者の一人として、お力になれるものと確信しています。

https://github.com/cocoa-mhlw/cocoa/issues/21?#issuecomment-780502093

 

猪股弘明
医師:精神科

 

オープンソースの世界 〜残酷な自由さ〜

オープンソース開発方式は理想の開発形態の一つとして語られることも多いが、現場寄りの人はかなりリアルな見解を持っている。

開発者目線では…

例えば、以前評判になったこの記事。

筆者の megamouth さんによれば、contributor(ソースコードを提供した者)にも序列があるという。


OSSへのコントリビューターにもカーストがあって、ついでに書いておくと

カーネルメンテナ>言語メンテナ>カーネルコミッター>言語コミッター>有名ライブラリメンテナ>色々>ユーザーグループ主催者>ブログでアプリへの文句だけ書奴~

みたいな序列である。

ある程度名の通ったプロジェクトの contributor になるだけでもけっこう苦労するよ、という挿話が語られている。

曰く、


アホみたいな量のコードを読み下し、コーディングスタイルを真似し、単体テストケースを書き、開発者とコミュニケーションをとってまで、自分のコードをマージしてもらう。

プルリクエスト(Pull Request PR, 自分の改変したコードを取り込んでもらう修正依頼のこと)送るだけでも大変なのだ。

さらに、新機能の提案などになると・・・

新機能にしても、同じようなことは過去の誰かが考えているものだ。それらの機能が今存在しないのは、何らかの経緯で却下されたか無視されたことによることがほとんどである。
もし彼が「ぼくのかんがえたすごいしんきのう」を拙いCコードで表現することに成功したとしても、Google翻訳を駆使して、なんとか英語圏の人間に読めるプルリクを送れたとしても、忙しいメンテナが一瞥して言うことは「過去ログ嫁」である。

単に PR 送るより大変なのがわかる。

きっかけは個人的な欲求から始まる

ところで、私がオープンソースの世界に足を踏み入れ始めたのは、2018 年の春頃からだ。
きっかけは horos という医療用画像ビューアのプロジェクトの存在を知ったとき。
医療画像ビューアは一般に高額で、レントゲンや CT の画像を「ちょっと」確認する程度であれば、オープンソースのプロジェクトの公開されているソースコードを自力でビルドして使った方が金銭的な節約になる。
おまけに自分で改変もできる。ちょっと使いにくいというところがあれば、そこを自分で改変したっていいのだ。
私の場合、改変したいくつかの機能は、horos の本プロジェクトにも PR を送り、マージしてもらった。


そういう意味では、私は「医療用の OSS」 というニッチな分野では contributor なのだが、上で述べられたようにすごく苦労したかといえば、そんなことはない。
OSS のカースト的にみれば「アプリケーション」レベルだし、何よりも「医療」と名が付くと開発寄りの参加者は極端に減る傾向がある
慢性的な人手不足なのだ。この分野では一定水準のプログラミングスキルを持った人なら、新機能の提案・実装は、(カーネルなどへ contribution するのに比べたら)かなり楽だ。

ある程度慣れたきた段階で、自分でもプロジェクトを持つようになった。

だから、けっこう短期間の割には PR を送る側の経験も受け取る側の経験も両方したことになる。

ところで、ネットを見ていると「どうやったら PR をマージしてもらえるか?」みたいな記事は見つかるのだが、逆に「これやっちゃあかん!」というような記事はあまりない。
参考になるかどうかわからないが、一つ例示したいと思う。

マージされなかった Pull Request の例

以下は、私たちが OpenOcean という OpenDolphin 由来の電子カルテのプロジェクトで、クライアントバイナリを配布してきた時にもらった PR 。
公開するのもはばかれるような内容な気もするが、当人たちは open にしろしろと主張しているのでここで取り上げても問題ないでしょう。


一目でわかる通り、単純に特定行を delete したのみ(文頭の – は削除した印)。
この場合で言えば、public static int expired( ) という関数が関与する部分を削除しましたってだけの内容。

一般にコード書きが何かを実装する場合、たいてい、狙った機能というものがある。
上記のコードでは特定時刻と現在の時刻を比較し、現在時刻が特定時刻より先に進んでいた場合、そのプログラム自体を終了せよというのが狙った機能だ。
要するにこのアプリの使用期限を設定している。(この時点で元のプロジェクトにはれっきとした商用版が存在しており、こちらはちょっとした機能の提案をしたかっただけ。気合い入れて継続的に開発していく意思がなかったというのがその理由)

だから、これは bug (バグ)ではない。

確かに、プログラムが複雑になってくると、深刻なバグがあるにもかかわらずそれがどこにあるかわからないといった場合はよくある。このような場合、それを特定するだけでも貴重な情報になる。
だが、これはそういった類のものではない。

だから、この PR はマージできない。

逆に、「残り XX 日で使用不能になります」といったアラートダイアログなどを表示させるようなコードの場合、おそらくコードの書き方が少々稚拙であってもこちらで手直ししてマージしたのではないかと思う(例え、この噂が本当であったとしても、だ)。

つまり、相手(レビュアーやメンテナー:PR を評価しリポジトリを管理する人たち)の意図を汲み取ってプロジェクトにとってプラスの価値を与えるようなプルリクには大概のメンテナーは寛容でありマージもされやすいが、単に自分の願望を押し付けるだけでは考慮もされないのだ。実際このときもそれが主な理由でマージはしなかった。

また、彼の意図を汲み取るならば、それは「最終産物のアプリの使用期限を取り払ってほしい」ということだ。issues あたりに掲げておけばいい要望であって、わざわざ PR にするほどのものでもない。

(付記)その他の理由 -著作権に対する配慮-

上で「主な理由」と書いたが、他にも気になった点はあった。
というのは、このとき PR 送ってきた相手の GitHub アカウントのアバターが、全世界でかなりの人気を誇るアニメのキャラだったから。漫画・アニメなどで人気のあるキャラの2次利用は、たいていの場合制限されている。
実際、このキャラクターは基本的には2次利用を許していない。
もしかすると、この人と著作権管理団体などで使用許諾の契約がなされているのかもしれないが、基本的には第三者にはそんなことはわからない。
そして、PR を送ってきた相手はまったく知らない人だ。信用できる人なのかどうかもわからない。
一応、名前や所属などは確認したが(京都大の小林慎治という人。現在は、保健医療科学院を経て岐阜大学に所属)、ここらへんの権利関係に関してはまったく気にしていないようだった。
私が気になったのはこの点だ。
OpenOcean プロジェクトに関しては特に行動規範(CODE of CONDUCT)のようなものは定めてはいなかったが、やはり「知的財産権に関して一定の配慮ができる」というのが最低限の暗黙の前提になる。この件にしてもそうだが、知財権に関して無頓着すぎるように思える。
どんなオープンソースのプロジェクトでもそうだが、ネット接続環境を持っていて、アカウントさえあれば、議論に参加するくらいのことはできる。有意義な議論になることもあれば、まったく不毛な質の低いものになることもある。ネットで不特定多数を相手にするというのはそういうことなのだ。そして、意味のある議論ができるかどうかは実社会のステータスとは相関しない場合が多い。主張している内容や実際に書いたコードでその人の能力を推し量るしかないのだ。(蛇足かもしれないが、それはオープンソースの可能性でもあるだろう。全く無名の人でも活躍できることに繋がるのだから。)
だから、何かをしたい・信用を勝ち得たいというならば、その資質を実践で示す必要がある。それ以外の基本的な部分でレビュアーやメンテナに不信感を持たせては、まず PR は拒否されるし、以降はまともには相手にしてもらえないだろう。

(追記)小林慎治氏、この後、何を思ったか「OpenOcean は GPL 違反だ」という傍迷惑な主張を展開するようになった。自分が PR 送ったプロジェクトを誹謗中傷して何が面白いのか?と訝しんでいた。単純に逆ギレしたからというだけではなく、(メドレー移行に伴い、その後、開発者としての立場が否定されることになる)皆川和史や増田茂などの名前を OpenDolphin プロジェクトに刻みつけておきたかったからという理由もあるのかもしれない。
しかし、この主張は無理がある。(『ソースコード嫁』参照)

Fork の効用・意味

また、付け加えておくと、アプリケーションレベルのOSSでは、「エンドユーザーに近い」という特性ゆえ、異なるバージョンの開発が並行して進められるということはよくある(当たり前だがユーザーには「好み」があるから)。
特に、電子カルテのように施設毎でのカスタマイズが前提になる場合はその傾向が顕著になる。実際、元になったプロジェクト自体、施設毎での独自カスタマイズを奨励していた。自分で既存のプロジェクトにはない機能を付加したいというなら、元プロジェクトを fork して独自プロジェクトをおこせばいいだけだ。

まとめ? 残酷でもあるが自由でもある

既存のプロジェクトに自分の提案を受け入れて欲しいというなら、相手の意図にはある程度意識的になる必要がある。もし、それが叶わないというのなら、自分で独立してプロジェクトおこせ、ということになる。
タイトルに「残酷」と入れたが、ある意味、それはオープンソースの世界の自由さとも言える。

 

他にも面白い話もあるので、また続き書きます。

 

猪股弘明