カテゴリー: OpenDolphin

見当はずれのコメントしかできないようなレベルのスキルしか持ち合わせていないにも関わらず、増田茂の尊大な態度に何か違和感を覚えるという人が多いようだ。

最近になって「増田茂の態度が尊大なのは、2.7m のベースは自身の 2.3m が元になっていると勘違いしていたから」ということが言われるようになった。

これはありうる話で、この説を採用すると 2.7m 登場以前は win 限定の傍流プロダクツに過ぎなかった通称『増田ファクト』が、2.7m つまり

・win, linux はおろか Mac で動作する
・データ構造は当時の最新バージョン 2.7 と完全互換（=本家直系）
・コメント系のバグが完全に解消されている

というプロダクツのフォーク元と主張できるようになるからだ。
しかも本人は何の努力もしないで。
（もちろん、この認識は完全に間違っているのだが）

怪文書にもそれを窺わせる記載がある。

「ソースコードの不正利用」、「私が提供した資料とソースコードをもとに」あたりの表現は、かなりあやしい。
2.7 系のインストール方法は、高東ソフトウェアさんが突破口を開き、air-h-128k-il（この時点ではほぼ猪股弘明氏）が完成させ、さらに ANN2b 氏が Mac に拡張した、というのが経緯だ。
2.3 系の windows インストール特化の古い導入書が参考になることはない。

I 氏とあるのが 2.7m の開発者の猪股弘明氏のことだ。
直接フォークでも何でもない増田ファクトの著作権表記を別系統のプロダクツに要求したのは、彼がフォーク順を誤認していた、という理屈だ。
また、（後で主張を修正したようだが）2.3m の m は masuda の m だとも当時は主張していた。

これに関するコメントをいくつか。

「ありえない。2.7m のソースコードは公開されている。
ソースが公開されていて検証できるのに間違うのは、彼が自分が開発したと称するプログラムを把握していない証拠。自分でコーディングしてはいないのではないか？」

「『2.3m の m は masuda の m』は自己顕示欲がえぐい。
ここまで言いながら、その後に起こった変化への対応、すなわち

・Java のアップデート対応
・安全性ガイドライン対応
・医療Dx 対応

のどれもできていない。つまりまともにメンテナンスすらできていない。
にも関わらず、名称に関して自分に優先権があると主張するのはマナーの問題としてどうなんだろう」

「そもそも、LSC の経営陣が刷新されて以降、アウトプットは出せていないので、それまでの成果にしても LSC からの技術情報を元に自分の手柄として発表していただけではないか？
プログラミングの成果にしても OpenDolphin に関係するものしかなく、独立したアプリはひとつもない。
やったことといえば、2010年以降の数年間、すでにある程度完成されたソフトのカスタマイズをしたのみ。
これで俺はすごい開発者なんだアピールされても、自己評価がなんかおかしいとしかいえない」

「誤認云々は置いておいても自分のプロダクツが全ての OpenDolphin に影響を与えていると言わんばかりの主張は奇異で誇大的すぎる」

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

最後のコメントは推測を含みますが、説得力ありますね。
ここら辺はややこしいところなのですが、興味深い説なので一応解説しておきます。
プログラムであっても保護の対象になっているのであれば、著作権人格権が発生し、これは譲渡不能です。
が、メドレーが言うには、このような権利に当てはまりそうなものは一切なかったということなので、そもそも増田茂は著作権法で規定されているような保護すべき著作権人格権を保持していなかったのではないか、という仮説です。
ありうる話です。
というか推測を交えていいなら、状況を説明する上で一番無理のない自然な考え方のように思います。

 

 

ややこしい背景説明は終わったので、次の怪文書。

なんで彼（増田茂医師）がこの箇所を切り取ったのか考えられる背景理由もあったりするのだが、メンドくさいので割愛（知りたい人はこの記事でも）。

説明的な文章もメンドくさいので、反応を五月雨式に書いていく。

「コード上では 0/1 しか返り値はないが、拡張すれば他の整数値を返した方がいいので int にしておく方が自然」

「そもそも expired() というメソッドは、air-h-128k-il 氏が付加したものなので、それにあれこれ言うのは失礼」

「コメントは、このソフトがこの後どのように動作するかを簡潔に示したもので、どちらかといえば後で読む人のことを考えて付け加えた教育的・説明的なもの。
ここでコーディングの技量を推し量るというのが、意味わからん」

ちなみにコメントというのは以下の箇所のコメントのこと。

public static void main(String[] args) {
        //Dolphin.getInstance().start(args.length==1 ? args[0] : "i18n");
        Dolphin.getInstance().start(args.length==1 ? args[0] : "dolphin");
        //? 式１:式２は三項演算子。なお、args.length は配列の要素数。
        //引数の要素が１だった場合は args[0] でスタート。そうでなければ i18n でスタート。
        //windows環境ではダブルクリックして使いたいので i18n を pro に変更。
        //pro? dolphin? どっち？
    }

三項演算子は、プロの間でも「読みにくい」・「直感に反する」と取捨選択が取り沙汰されるほどなんだが？
（『三項演算子は仕事で使うべきではない』など）
2.7m 開発時に猪股弘明氏がドルフィンクライアントの「起動モード」の役割について明らかにしてくれたおかげで、当時最新の 2.7 系がストレスなく使えるようになったんだが？
（改変前のままビルドして起動すると、クライアントは評価モードで立ち上がり、すぐにログインできない。正直、使えない）

この成果は増田茂も「バックポートした」と称する彼のドルフィンで使っている。

にもかかわらず、彼は「プロの仕事ではない」と頓珍漢なコメントをしている。
おまけに Junzo SATO 氏に対する言及は一切なし。
あり得ないと思う。

（３に続く）

怪文書騒動

先日、X の dolphorca 界隈がさる怪文書でプチ盛り上がりをみせた。
こんな感じ。

怪文書だけ取り出すとこうなる。

これが何か関係者以外正確にはわからなかったと思うが、簡単に説明すると増田茂という医師が自身の運営するクリニックホームページ（HP）に掲載したページのスクリーンショットだ。
なんでプログラミングに関係すると思われる文書がクリニックHPにアップされていたのか不思議に思う人もいると思う。
が、安心して欲しい。
われわれがこれを見つけたときもまるっきり同様の感想を持った（笑）。

背景事情に関しては、こちらの記事などを参考にしてほしい。
以前にも「増田茂は医療広告規制ガイドラインで厚労省から行政指導を受けており・・」などと言っていたのはこのページのことだ。
保険診療所は、ネット上での広報活動に関してガイドラインが決められており、原則、診療とは無関係なものは掲載できない。
もちろん、このページはガイドラインの規定を大きく逸脱しており、発見したときは、当局に報告し、当局経由で速やかに削除してもらった。

だから、この怪文書を再び見せられるまで、存在自体忘れていた。
それですんでいれば、この話は終わっていた・・・と思うのだが、実際にはそうでなかったらしく、いかがわしげなサイトにその痕跡がかなりはっきり記録されていたという次第だ。

反論

ページが複製されて残っている以上、閲覧した人におかしな解釈されても困るので内容に関して触れておこう。

内容はその当時ソースコードを公開していた OpenOcean という電子カルテに対する彼からの批判のようなものだ。

OpenDolphin-2.7 → OpenDolphin-2.7m → OpenOcean

の順でフォークされている。
彼は彼で、「増田ファクト」と言われていた OpenDolphin-2.3 のカスタマイズバージョンを配布していた。彼が OpenOcean に執着した理由は、彼が OpenOcean を自分のバージョンのフォークだと認識していたからだと思われるが、このフォーク順の認識は間違っている（『ソースコード嫁』参照）。

ファイルバックアップシステム

まず、われわれが実装したファイルバックアップシステムというものを彼は気に入らないらしい。
ファイルバックアップシステムというのは、カルテの記載を確定したときに使用端末の適当なフォルダにその内容をプレーンテキストファイルの形で書き出すという機能だ。

彼が切り取った実際のコードはこうだ。

KarteStyledDocument soadoc = (KarteStyledDocument)soaPane.getTextPane().getDocument();
int nleft = soadoc.getLength();
Segment stext = new Segment();
int offs = 0;
stext.setPartialReturn(true);
StringBuilder sb = new StringBuilder();
String Separator=System.getProperty("line.separator");
sb.append(""+ Separator);
while (nleft > 0) {
soadoc.getText(offs, nleft, stext);
sb.append(stext.toString()); sb.append(Separator);
  nleft -= stext.count;
  offs += stext.count;
}

彼はこの部分に関して「JTextPane からテキストだけを抽出するなら getText() で可能だ」という指摘をするのだが、これがなんと言っていいやら・・・。

「JTextPane からテキストだけを抽出するなら getText() で可能」というのは、これだけを取ると正しいのだが、そもそもここで目指していたのはそういうことではない。

というのは、このコードは、データ移行ツールと呼んでいたものからの流用だからだ。
データ移行ツールは、dolphin/ocean とは独立したアプリで以下のような動作をする。

左が dolphin クライアントのカルテ画面、右はそのカルテ情報を移行ツールを使ってデータベースから直接復号して画像とテキストに分離して表示したものだ。
見ればわかるように、画像を埋め込んだ位置に <Image: schemaHolder 0> というタグを表示させている。
だから、上で掲げたコードもちょっとした修正を加えれば、このタグを表示する程度のことはできる。
ファイルバックアップシステムでは、凝った表示をさせるよりは最低限のプレーンテキストを書き出すことを目標としたが、画像が含まれていたかどうか？含まれていたとすればどこに表示されていたのか？くらいの情報を盛り込むのはあってもいいと思い、将来的な拡張を視野に入れてこういう書き方になっている。

また、コードを見ればわかり通り、getText(int, int, int) を作用させたのは KarteStyledDocument という独自クラスのインスタンス soadoc であって、JTextPane もしくはその継承クラスではない。
仮にもしここで getText() を使うのであれば（ちなみに getText() と getText(int, int, int) は似ているが全くの別物）、JTextPane のインスタンスを取得する必要がある。
その手間や拡張性を考えたら、書式情報を最後まで保持できてなおかつ動作実績のあるこの書き方でいいと考えたわけだ。

ある機能を実装するのにどのような書き方をするかは書いた人（たち）の自由ではないか？と思う人もいるかと思う。
私たちもそう思う。

このとき彼はネット上でたびたび出現する「正義の人」になっていたのだろう。
迷惑な話だ。

（その２に続く）

 

私がカスタマイズした OpenDolphin-2.7m （という電子カルテ。本家 LSC Dolphin の直接 Fork）は、以前に前期LSC一家と言ったらいいんだろうか、ともかく 2018 以前の LSC と繋がりの深かった人々からおかしな非難をされていた。人々、といっても、皆川和史・増田茂・松村哲理・小林慎治・杉原利彦・・・くらいなものだが。

どういうものだったかは
『保健医療科学院 小林慎治が国家公務員法違反疑いで厳重注意を受けた件について』
『小山哲央（アーク情報システム）の件』
あたりを参照してください。

彼らがいうには、Fork 順は

　LSC Dolphin（いわゆる本家） → 2.3m（いわゆる増田ファクト）→ 2.7m （ワイのバージョン）

なんだそうだ。

正しくは LSC Dolphin(Ver 2.7) → 2.7m なんだが、それはソースコードを読めばわかる。

例えば、ModuleModel.java というファイルの冒頭をみてみよう。

2.7 と 2.7m では一字一句いっしょ。

この箇所は 2.3m ではこうなっている。

赤枠の部分が追加されたコードで、検索（hibernate search）のためのアノテーション（＠から始まるコード）が付加されていることがわかる。

私がわざわざカスタマイズしたのは、

・2.7 にあったバグ（通院精神療法のコメントが正しく表示されない）を修正したい
・簡易なファイルバックアップシステムを実装したい

というのが主な動機で、データの互換性は完全に保ちたかったから、データ構造周りには一切手をつけていないし、上記の機能に関係しない部分も同様に手を加えていない。

だから、2.3m → 2.7m という Fork 順はありえない。
いちいち、付加されたコードを削ぎ落として作業すんの？
ありえんでしょ。

なお、ModuleModel.class というのは、Dolphin サーバーがカルテ記載内容をデータベースに永続化する際に最も基本となる単位で、SOA 欄文字列・図などのグラフィック要素・P欄文字列をそれぞれ一つのモジュールとしている。
シンプルだが、当時のデータベースが CLOB をうまく扱えなかった関係上、図も文字情報も全てバイナリ化してBLOB として格納されている。
カルテに復号する時は、モジュールを拾い集めた後、内容毎に処理を変える必要があるというなかなか地獄のような仕様になっている。

さらにおかしいのは皆川和史氏が設計したことにはなっている点だ。
しかし、

・LSC の経営陣が変わった際に彼は担当役員を外されている
・この程度の基本的なデータ構造を把握していない
（自分が設計したデータ構造を他のものと取り違えるということがあるだろうか？）
・メドレーに至っては開発者認定していない

といった事実があり、個人的には別の人が設計したのではないかと思っている。

増田茂医師に関しては言わずがなだろう。
hibernate search を用いた検索機能はアイディアとして素晴らしいし、付加されたコードも申し分のないものだ。だが、こんな完璧な修正を行える人が、データ構造を把握しておらず、Fork 順に関して間違えるとは思えない。
メドレーも、皆川氏と同様に増田茂氏を開発者とは認めていない。
やはり、別の人が設計・コーディングしたと考えざるをえない。

ところで、オープンソースの世界は一般には不親切で（商用を前提にしていないので当然だ）、よくわかってない人間に対してメンテナが言う言葉は大抵の場合

　ソースコード嫁

である。