PHAZOR-JP BLOG

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

最近になって「増田茂の態度が尊大なのは、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 のインスタンスを取得する必要がある。
その手間や拡張性を考えたら、書式情報を最後まで保持できてなおかつ動作実績のあるこの書き方でいいと考えたわけだ。

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

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

（その２に続く）