前々から、Mac でお手軽に使える電子カルテはないと思っていて、少々不便に感じていた。
OpenDolphin は、Mac でも動くが、Java を用意して、アプリケーションサーバをインストして・・・とやっていくと「お手軽」とはほど遠い。また、設計に古くさいところがあり、カルテデータを AI 使って解析するなんてことはやりにくい。
そこで、DolphORCA のフロントエンドサーバーを MacOS 向けに書き直して Mac アプリにしてみることにした。
最初の関門は、アプリ内に組み込んだウェブサーバがまともに動作するかということだったのだが、やってみるとこれが速い速い。
C 系で低レイヤーから組むとこんなにきびきび動くものなんだなと感心した。
サーバが十分なパフォーマンスを得られそうだったので、この上に認証機構やエディタなどをどんどん組み込んでいった。
現在は、AI（ローカル LLM）による文書作成機能を追加して Ver 1.0.6 になっている。
ご興味のある方はこちらのページからダンロードしてください。
以前に『ソースコード嫁』という記事で
2018 以前の LSC と繋がりの深かった人々からおかしな非難をされていた。（略）彼らがいうには、Fork 順は
LSC Dolphin（いわゆる本家） → 2.3m（いわゆる増田ファクト）→ 2.7m （ワイのバージョン）
なんだそうだ。
正しくは LSC Dolphin(Ver 2.7) → 2.7m なんだが、それはソースコードを読めばわかる。
と書いた。要するにわれわれが公開していた OpenOcean というソフトの Fork 順が間違って紹介されてますよという指摘だ。
間違いの出所の一つは、小林慎治という人が 2018 年11月26日に書いた記事だ。
フォーク順以外にも事実誤認が多く、指摘しようかと思っていたのだが、記事自体が公開になったり非公開になったり、そうこうしているうちに内容が陳腐化し、そこまでする必要もないと思い放置していた。
が、「いるか怪文書」と同様、いかがわしめなサイトに転載されていたのを確認したので、反論「めいた」記事を書く。
「めいた」というのは、完全で網羅的な反論は手間暇の関係でできそうもないから。
彼は「事実」と「主観的評価」を混交して推論し間違った結論に至ることが多い。
正式な反論ならば、その一つ一つを吟味、つまり、その思考プロセスを素過程にバラして逐次訂正を入れていくのが好ましいのだろうが、それは作業量の関係でできそうもない。
例えば、上記の Fork 順をなぜ間違ったのか今まで不明だったのだが、（後で示すが） GitHub リポジトリに記録されたコミットの解釈を間違えていたからと今回判明した。
この思考プロセスは、私の馴染みのある分野でいうと「結論への飛躍（jumping to conclusion）」にあたる。Jumping To Conclusion、少ない証拠で結論に飛びつくこと。あれに近い。
この分析を文書全体にやるのは、とてつもない労力がかかる。
これは、裁判の精神鑑定ではないのだから、そこまではやらないし、やる必要もないだろう。反論「めいた」、というのはそういう意味だ。
ところで、その小林記事をなんと呼ぶのが適当なのかわからないが、「いるか怪文書」にならって、ここでは「OpenOcean 怪文書」や「怪文書」としておこう。
なお、air-h-128k-il というのは、私がその頃、頻用していたハンドルです。
OpenDolphin-2.7m のときは、ほとんどの作業を私一人がやったので Hiroaki-Inomata 名義で発表、OpenOcean では協力者がちょっぴり増えたので（例えば、OpenDolphin 関連本の担当ライターさん）、共同作業というニュアンスを出すために名義は air-h-128k-il となっています。
（注）以下、少々長いです。ポイントだけ知りたい場合は『OpenOcean 騒動』や『OpenOcean 騒動 #27』をお読みください。
まず、その記事、全般的に「OpenDolphin は GPL でライセンスされたオープンソースソフトウェア」という前提で書かれているが、これは完全には同意できない。
実務的には、運営主体はメドレーに移ってからは、メドレー自身がかなりはっきりとオープンソースではないと言っている。
OpenDolphin は、2020 年に LSC からメドレーへの法人間での事業譲渡がなされたが、もし、個人に保護すべき著作権が残っていたとしたら、権利を含めた完全な事業譲渡はできにくい。権利を含めた譲渡が行われ、その上でメドレーはオープンソースをやめてしまったと解釈するのが普通だろう。（ちなみに、メドレードルフィンサポートページの表記は Copyright Medley, Inc. All rights reserved.）
色々いう人はいるようだが、結局のところ、権利的には「e-Dolphin 時代の成果 + 開発法人による職務著作」と考えていいと思う。
では、2018 年はどうだったか？といきたいところだが、2025 年現在の状況から話を始める。
2025
現在（2025年）からみれば、OpenDolphin のオープンソースっぽさはほとんどない。オープンソースの最大の特徴は「ソースコードが公開されていること」だと思うが、いくつかの個人や有志が、今でもソースコードを一般公開しているものの、商用プロダクツに関してはソースコードを一般公開しているところは一つもない。
一般公開しなくてもユーザーがなんらかの形でソースを入手できればよいという立場もあるのかもしれないが、ドルフィンの場合には特殊事情があってこれではまずいと思う。
というのは、GPL では author を publish する必要があるが、2025年現在でも表記すべき author は完全には見つかっていないから。
ある程度知られている事例は Junzo SATO さんで、彼の名前はソースコード上でかなり見つかる。
Panel2.java(client プロジェクト)
/**
*
* @author Junzo SATO
*/
public class Panel2 extends JPanel implements Printable {
private String patientName;
private boolean printName;
private int height;
/** Creates a new instance of Panel2 */
public Panel2() {
}例えば、上の箇所なぞ、クライアントをデバッグしていると必ずと言っていいほどお世話になる箇所で、基本設計も担っていたのでは？と推測されていたが、dolphin-dev のリポジトリでは全く言及されておらず、その正体は長らく謎のままだった。
その後の調べで（例えば、学会口演要旨。下図参照） e-Dolphin プロジェクトに参加していた佐藤純三さんであることが判明した。
ドルフィンプロジェクト初期の公式資料でもコーダーとして言及されている。
こういう事例が一つでも見つかると後は速い。funabashi, Kushiro,miura… などの author が次々に見つかった。が、これは主にデバッグ途上で見つけたに過ぎず、完全に網羅的なものではない（ただし、デバッグ途上で見つけたということは、ある程度の機能は担っており、使われてないクラスやメソッドのコード上の単なる署名ではない）。
「2025年現在でも表記すべき author は完全には見つかっていない」と前に書いたのはこういった事情による。
完全には見つかっていないのだから、GPL 的な要請からソースコードを一般に全公開しておいた方がいいと私たちは考えた。
こうしておけば、まだ見つかってない author がいたとしても、それを誰かが見つけてくれるかもしれないからだ。
その観点からすると 2025 年現在でも、ドルフィン派生プロジェクトでソースが一般公開されていないものはオープンソースとは言いにくいと思う。
「ドルフィンの場合には特殊事情があってこれではまずい」と書いたのはそういった理由による。
ドルフィンを GPL ライセンスによるオープンソースプロジェクトとして捉えても、完全に条件を満たしているか疑わしいのだ。少なくとも理想的なものとは言えないだろう。
では、2018 年に戻ろう。
各種ドルフィンが、ソースの一般公開をやめてしまった発端は、2018 年の LSC （Life Sciences Computing）のポリシー変更にある。
われわれは OpenOcean を公開するにあたって、何回か LSC に問い合わせている。
最初は特に理由も教えられることもなく「許可する」という主旨の回答で、変にあっさりしているなと不思議に思っていたのだが、リアルで担当者に会った時に「経営陣が変更になったので、OpenDolphin の取り扱いを変える。LSC としてはGPL の旗を下ろす。派生プロジェクトには GPL 的な決まり事はできれば守ってほしいが、LSC がやめてしまった以上、厳密には従わなくていい。任せます。皆川・増田が言っていることは気にしないでください」という主旨のことを言われた。後で知ったことだが、GlassDolphin の中の人にも同様のアナウンスをしていたということだ。
経営陣が変わるとこうも変わるものかと驚いていたが、その後、LSC の GitHub リポジトリや GlassDolphin のそれの更新がプッツリと途絶えたことを考えると、かなり明確な意志・決断であったと思う。
何が言いたいかと言えば、2018 年にはフォーク元自体が GPL 的な取り扱いを実質的にはやめてしまっていたし、派生プロジェクトにも GPL 的な縛りを強要はしていなかったということだ。
怪文書が書かれたのは 2018 年末のことだが、2018 年にこういったことが水面下であり、そのことを小林氏は知らない。（か、知っていてとぼけている）
ところで、Junzo SATO 氏の 2018 年時点での評価だが、彼が遺したコードの重要性は認識されつつあったが、この時点では彼の素性は全くわかっていなかった。
ただし、この人の（再）発見によって、従来言われていたように「特定の人のみが開発に関与した」という皆川らの主張は、実際に改変にあたっている技術寄りの人たちからはかなり疑問視され始めていた。
ざっくり言えば、この時点でも「OpenDolphin は GPL でライセンスされた完全無欠のオープンソースソフトウェア」とはみなされていなかったと思う。
長々と書いてきたが、彼が採用した前提は、2018 年時点でも厳密には成立していなかったと思うのだ。
これまで漠然と author という単語を用いてきたが、この定義が難しい。GPL には author の明確な定義がないからだ。
日本の場合、著作権法的な制約があるので、概ね「法（著作権法）及び GPL の要請で保護すべき著作権的人格権（著作者人格権）を保有している開発者・コーダー」ということになるだろうか。
ところで、何を基準に表記すべき author とするかは見解の分かれるところだとは思う。
例えば、小林慎治氏は佐藤純三さんの仕事を重視はしていないようだ。
佐藤さんを揶揄嘲笑する上のような X の投稿がみられた。
@masudanaika の中の人も同様の発言をしていたと思うが、考え方・評価を変えたのか自分の投稿を削除している。
コーダーと評論家の感覚の違いと言ったらいいだろうか。
ここら辺は見解の相違だろう。
長々と書いてきたが、あとは、目についた順で反証などを挙げていく。
怪文書の表記がオリジナルと違うかもしれないが、それは転載されたサイトからとってきているから。
散々言われていると思うが、ネット社会では拡散された情報への対処の方が重要で、われわれが稿をおこしたのもそれが理由だ。
2018年6月7日air-h-128k-il氏が[Open DolphinのGitHub repository]:https://github.com/dolphin-dev/OpenDolphin からfork(正確にはforkのforkのfork)してOpenOceanと名前を変えたプロジェクトを立ち上げた。
正確には fork（2.7.0b → 2.7m） の fork（2.7m → OpenOcean） 。詳しくは『ソースコード嫁』を読んでください。
ここでの議論の大筋には関係ないから問題視しないが、これを信じた勢力が一部にいた。その点では非常に迷惑だった。
問題なのは根拠のあげ方。
根拠として挙げているのがこのコミット履歴なんだが、これはコミットツリーで表示すると一番の最初のコミット（first commit）。
それまで存在していたファイルにどういう改変を加えたかはわかるが、フォーク順まではわからない。ファイル内容とリポジトリに記録された Fork 元の情報から、一つ前の Fork 元まではわかるが、わかるのはそれだけで、それから先は原則わからない。
Fork の連鎖を辿っていけば Fork 順はわかるのでは？と思う人もいるかもしれないが、OpenOcean の場合はわからない。なぜなら、2.7m は GitHub 上で LSC 2.7 から直接 fork したのではなく、いったんローカルに置いた LSC 2.7 に改変を加えた 2.7m を GitHub にあげたから。
おそらくある種の先入観を元に Fork 順を脳内補完したのだと思うが、この思考過程ってなんなんだろうね。この表現が適当かわからないが、ある種の患者さんが示す思考プロセス Jumping To Conclusion に似ている。
他にも引っかかっているところはあるのだが、多分、彼が強調したかったのはここだろう。
OpenDolphinの原著作者は皆川和史氏であり、戸村(王)勝偉氏が共同著作権者として挙げられています。更に下記の著作権者が協力者としとREADMEに記載されています。
・札幌市元町皮ふ科の松村先生
・和歌山市増田内科の増田先生
・新宿ヒロクリニック
・日本RedHat Takayoshi KimuraさんのJBoss as7 へのポーティング
GPL3の ” appropriate copyright notice” は形式までは具体的に定めていないので、様々な表示形式が見られております。いろいろなやり方があると思いますが、上記はすべて著作権者であり、OpenOceanはOpenDolphinのソースコードの大部分を利用している以上、GPL-HowToに記載されているように上記著作権者をすべて適切に表示する必要があります
彼が認定している author は、上記の人々であり、それらは README に記載すべきだ、というのが彼の考えなのだろう。
われわれはそうは思っていなかったし、今でもそう思っていない。
README は、リポジトリのフロントページであり、多分に広報的要素が強く、リポジトリを訪れた閲覧者に知ってほしい特徴などを記載する場所だと思っている。
それは dophin-dev の README を書いた人も同様だと思う。
例えば「日本RedHat Takayoshi KimuraさんのJBoss as7 へのポーティング」は、このバージョンのドルフィンにはその痕跡は留めていない。そもそも 2.7 系では、JBoss as 7 自体使ってないので、これは過去のバージョンでお世話になった人への謝辞とみるべきだと思う。
author を正確に規定している場所ではない。
そして、前章で述べたように、README で記載されていないソースコード提供者の中に author と呼ぶに値する人物がいるとわれわれは認識していたので、小林氏の主張する書き方の流儀は採用できない。
一般的に、ソースコード管理が甘くなったプロジェクトでは、フォーク元のプロジェクトの主張をそのまま信用するのは不適当だ。
では、どういう方式が好ましいのかという話になる。
潜在的なプロジェクト参加者の努力に期待するしかないのだが、ソースコードを一般公開しておき、新規の author が見つかり次第、その旨をどこかで報告・記載していくのが適当だろうか。
われわれは、author 候補が見つかり次第、プロジェクト関連ブログで、その名前と提供されたソースコードの説明をつけ報告してきた。結果的に、Junzo SATO, funabashi, Kushiro, miura… といった author 候補を発見報告している。
見方によっては GPL が要請する著作権表示以上のことをやっているように思う。われわれはそれなりに努力してきたつもりだが、さてどうだろう？
ところで、彼は GPL3 の section 4（4条）、つまり
4. Conveying Verbatim Copies.
を根拠に自説を組み立てているようだが、これは「ソースコードを受け取った時の（そのソースコードの）伝搬時の取り扱い」を述べている部分であり、2.7m は 2.7 の modified version なのだから、根拠とすべきは、その次の section 5、つまり
5. Conveying Modified Source Versions.
の箇所だ。
そして section 5 では
This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
本ライセンスは、これ以外のやり方には作品をライセンスする許可を与えないが、あなたが本ライセンスとは別に許可を得ていた場合には、そのような許可を無効とするものではない。
と、フォーク先の許可を得ていれば、その許可は無効にならないことを述べている。
われわれは配布形態などに関してフォーク先から許可を得ているのだから、その許可の範囲内では「違反」になどなるわけもない。
後で、加筆するかもしれないが、これはこの記事の「補足」や『OpenOcean は GPL 違反？』を読んでください。
簡潔に言えば、当時は「複数のドルフィンのバイナリ及びソースの開発主体・運営主体を区別するために (C) を使っていた」ということです。
まあ、職務著作と考えれば当たり前の話なんですが。
FSF も GPL FAQ で以下のように述べている。
The GPL requires the maker of a version to place his or her name on it, to distinguish it from other versions and to protect the reputations of other maintainers.
GPL は、別バージョンの作成者の名前を、他のバージョンと区別するために、かつ、他のメンテナの評判を保護するために、そのバージョンで表記することを要請する。（猪股訳）
このやり方は、2.7 系 dolphin の起源になった dolphin-dev のドルフィンでも採用されている。
ログイン画面は以下のようになっている。
(C) OpenDolphin Lab と (C) Life Sciences Computing Corp の両方を記載。
前者はひょっとすると著作権人格権の意味かもしれないが、後者は明らかに管理主体でしょう。どちらにせよ個人名ではなく組織名になっていて (C) Kazushi Minagawa にはなっていないことに注意。
一方、ソースコードの LISENCE では以下のように (C) 2001-2011 Kazushi Minagawa という表記になっている。
だが、16 行目に OpenDolphin version 2.2 とある。
これは皆川和史（GitHub 上でのアカウントは mbot-dev）が、ver 2.6 時代になぜか修正した内容で ver 2.7 の LICENSE ファイルとしては相応しくないものだ。 （詳しくは、この issue 参照）
ver 2.7 に有効な LICENSE ファイルは「ない」と考える方が自然だろう。
確かに README では、皆川和史が OpenDolphin の特徴などを述べているが、怪文書が言うように「原著作者」を示すようなことは実は他のどこにも書かれてはいない。所属する組織を代表して記載にあたる者と開発者・著作権者・author というのは、概念からして違う。
おそらくはフォーク元運営会社的には OpenDolphin は職務著作という扱いで、それを裏付けるように LSC からの指示は「運営主体がわかるように表示してくれ」というものだった。
後述するように OpenOcean はフォーク元から独立した派生ソフトと認められ、上の形式を踏襲した (C) 表示の許可を取っている。われわれはその指示に従ったに過ぎない。にも関わらず、GPL 違反や著作権法違反だと彼は主張する。
経緯を知りうる立場にない第三者にしては、行きすぎた行為に思える。
ところで、怪文書を読んでいて気になったのは、以下の箇所。
百歩譲ってair-h-128k-il氏の主張が正しいと仮定したとしても、OpenDolphinはどこからどう見ても、 皆川氏の思想 を反映したものであり、それが認められないようでしたらair-h-128k-il氏が書かれた数十行程度のOpenOceanのコードも同様に著作権が認められることはないでしょう。
「air-h-128k-il氏が書かれた数十行程度のOpenOceanのコード」というのは、たぶん、私（猪股弘明）が OpenDolphin-2.7m で実装したファイルバックアップシステムのことだと思う。
この箇所は OpenOcean を試用した開業医の人たちからは評判がよく、あれはどうやってやったんですか？という問い合わせが多かったので、後で『OpenDolphin-2.7m コード解説 -FileBackUpSystem と電子カルテのデータ構造-』という記事を書いたほどだ。
保護するような著作権があるかどうかは置いておくとして、現在の電子カルテではこの機能に該当するような機能がないと安全性のガイドラインを満たせないはずだ。
いわゆる『安全性のガイドライン』は、 Ver5.2 から、システム停止時の見読性確保のためのカルテ閲覧システムの具備を要請している。
ファイルバックアップシステムでは、カルテ記載内容をユーザーホームの専用ディレクトリにプレーンテキストで強制的に書き出すため、これらを何処かに集めておけば、たとえ dolphin server が止まったとしても、直近の処置や処方内容はそこを閲覧すれば確認できる。
確かに 2.7 にも増田氏が実装したとされる PDF 出力機能があるのだが、残念ながら、Mac では文字化けする。
理工系に代々伝わる「UNIX という考え方」が無意識にあったせいか、こういう時にはシンプルで軽いプレーンテキストファイルがいいと直感的に思って、とにかく「軽く」動かすことを意識してそのようにした。
凝ったデータ管理は『移行ツール』（のちの HTML/PDF Viewer）でやればいいと考えていたのだ。
著作権云々は置いておくとして、ほんの数年後にガイドラインで義務化される機能の評価がいくらなんでも低すぎる。
経営陣が刷新された LSC の評価は、小林氏のものとは違っていて、こちらが認めてほしいと思っていた機能を高く評価してくれた。そもそも、電子カルテの３原則を満たしていないと、電子カルテとは呼べないのだから、ある意味当然だ。だから、2.7m や Ocean をオリジナル 2.7 とは異なる独立したプロジェクトと認めたのだ。
また、この箇所の言い回し自体がわかりにくく、ロジックが読み取れない。
・皆川氏の思想を認めるか認めないか
・ファイルバックアップの機能が意味のあるものかどうか
の二つは、ほとんど独立な事象で、なんでこれらの事象が連結しているのか理解できない。おそらくは、先に結論があったが、そこまで展開できず、ロジック自体が破綻したと思われる。
怪文書は、全般的にフォーク元の主張を無批判に認める傾向が強く、適切な批判とは言い難いものになっている。
いくつかの点をまとめる。
1 author 相当の人物は、皆川・増田・松村・木村… といった人のみで、それは README に書いてあるから、というのが彼の主張なのだが、これは以下の理由で適切とは言えない。
・ソースコード・文献・プロジェクト初期の公的資料などから、Junzo SATO 氏のような author 相当の人物が見つかるが、README では見つからない
（歴史的経緯から、author をソースコード上で探索するなどの工夫が必要だが、こういった作業を一切していない）
・README は、慣例的には当該プロジェクトの特徴などを広報する場所であり、この場所のみが author を表記する場所と考えるのは妥当性に乏しい
憶測になるが、素直に考えるなら、皆川和史が、佐藤氏をはじめとする e-Dolphin 時代〜初期 OpenDolphin プロジェクトの author を自分の名前で置き換え、README でそれを伏せて主張した、と考えるのが自然でしょう。
2 LICENSE 冒頭の (C) name が GPL 的な意味での author であると主張するが、ドルフィン（派生）プロジェクトにおいては、以下の理由で認めにくい。
・(C) は、著作権管理主体を表す場合があり、フォーク元のプロジェクト自体、
(C) Life Sciences Computing Corp や (C) Kazushi Minagawa
とこの表記方式を採用している。
・フォーク元がこの方式の許可を OpenOcean に与えているのだから、この方式に従った事実を持って「OpenOcean は GPL 違反」とするのはおかしく、もしそのような指摘をするのであれば、フォーク元の GPL 違反（違反というのがきつければ、ログイン画面と LICENSE 文書での表記の不一致）も合わせて指摘しないといけない（が、していない）
3 自らの言説を「コミュニティによる是正勧告」と位置付けるのだが、電子カルテのような限定的なソフトの場合、そのソフトの開発者コミュニティとユーザーコミュニティとが「コミュニティ」の基本単位と考えるのが適当だ。だが、氏は
・開発者コミュニティには加わっておらず、勧告を行うのに必要な情報が得られていない
のだから、怪文書が状況を適切に整理するという意味での適切な是正勧告とはとても言えない。
などなど。
また、全般的に悪意のある表現が目につく。
例えば、彼が指摘するGPLv2 と GPLv3 の不一致は、元の dolphin-dev がそうなっているのだから、こちらとしてはどちらかに統一してみようもない。
前章で見たように、論理展開が破綻している箇所が多く、おそらくこれは「OpenOcean は GPL 違反」と言いたいがために後付けで論理を構成したものと思われる。
LICENCE の (C) Kazushi Minagawa という表記だけを真として独自に解釈、それ以外の整合性のつかない事象は全て無視、その解釈に合致しない OpenOcean の表記スタイルは違反だとやるわけだ。
だが、彼が奨励する記載方法は当の LSC ですら採用していない。
怪文書が指摘する GPL3 の第4条の「違反」にしても、私たちがやったことは「フォーク元の勧めやドルフィンプロジェクトの慣例に従って、著作権管理主体の表示を置き換えて、従来とは異なるやり方で author を同定していった」ということで十分に GPL の要請を満たすものだ。怪文書が主張するような「従来の著作権管理主体の名前を削除だけして、他のクレジットすべき著作権者の名前を隠蔽した」わけではない。
憶測になるが、むしろ LSC 2.7 の方が e-Dolphin 時代〜プロジェクト初期の author の名前のかなりの部分をソースコード上で削除、その存在を隠蔽していた可能性がある。
文章の目的からみても、2025 年現在では、明確に成立しているとは思えない「フォーク元の GitHub README での主張」を無批判に受け入れており、書かれた時期を考慮しても怪文書が「是正勧告」として有効とは思えない。
さらに、医療オープンソースソフトウェア協議会が構成員ほぼ一人からなる任意団体であり、実質的な関与が限定的であることを考慮すると、同組織がドルフィンコミュニティの何らかの代弁者的な役割を果たしているとは思えない。
要求の実現の交渉手法という観点からも、怪文書をいきなり公開するのはおかしい。アプリログイン画面で (C) Life Sciences Computing と著作権の管理主体が明確に示され、皆川もそこに在籍しているのだから、どこかの段階で LSC に連絡を入れ、LSC から当方に連絡を入れるよう促すのがより良い解決経路だったと思われる。
が、この手続きをなぜかしていない。
穿った見方をすれば、皆川はそもそも保護すべき著作権人格権は保有しておらず GPL 的な意味での author ではなかった可能性がある。OpenOcean 騒動を介して皆川と小林が共謀してその権利を獲得しようと試みたのであれば、かなり悪質な行為といえるだろう。
時系列でみれば、メドレー譲渡後もドルフィンはメンテナンス程度の開発は継続されている。しかし、そのソースコードは一般公開されておらず、皆川らが開発者であると特別に強調されてもいない。
もし、皆川らが、本当に個人に属する著作権人格権を有していたのならば、運営元が変わろうともその権利は保持されるはずだが、実際にはそのように取り扱われてはいない。
この事実は、怪文書の「皆川らは GPL 的な意味で author であり、法的にも保護すべき著作権人格権を有している」という主な主張と矛盾する。
現在から見たドルフィンプロジェクトとしては、私も以下のコメントに概ね同意する。
「オープンソース時代に彼らが保有した権利は、著作権人格権とは無関係な『著作権者と名乗っていい権利』だけだったのではないか？
実際に開発して保護の対象になっているのであれば、プログラムであっても著作権表示権は保持できるはずだが、実際にはそうはなっていない。
LSC からメドレーへの譲渡がスムーズにいったのも、そもそも彼らが保持できるような著作権表示権を持っていなかった、つまり実際には開発には関与していなかったからだと思う。
2.3 系までの契約上の権利しか持っていなかったので、その権利を保持するために 2.7m は 2.3m の派生だと主張する必要があったのではないか？」『いるかの怪文書 ３』より
「オープンソースの物語」と言ってもいいようなシナリオができており、それに従って物事が動いていた印象を受ける。
どの分野でもそうかもしれないが、作為的すぎるシナリオは、参加者の自然で自発的な意欲を削いでしまい、目立った成果をあげられない場合が多い。未知の力を呼び込み、それが自ずから発展していくような何か特別の仕組みがないと、豊かな成果を生み出すということはできにくいように思うのだ。
（適宜加筆修正予定）
猪股弘明
OpenDolphin-2.7m 開発者
精神保健指定医
かなり以前に OpenOcean という OpenDolphin 2.7 系完全互換のアプリを配布・公開していたことがあった。
その際に小林慎治という人が（ちなみに面識はいっさいない）「OpenOcean は GPL 違反」ということを主張していた。
所属組織から注意を受けてその主張を引っ込めたと思っていたのだが、一時的なものだったらしく、いまだに主張しているらしい。
えーと、手短にいうと、当時の著作権管理をしていた LSC から、許可もらってやってますのであり得ないですね。
あり得ないというか、第三者がそこら辺の事情を知りようがないと思うんですが？
商用開発元は、遅くとも 2018 年以降は GPL 云々の適用をやめていて、MIA・SOSO などにも同様のアナウンスしています。
両者ともソースコードの公開とかフォーク元の著作権表記とか厳密に守ってないでしょ。
例えば、SOSO さんの GlassDolphin だが、ログイン画面はこのようになっている。
一見してわかる通り、著作権表示の類はなし。製品案内サイトを介して GitHub ページに飛べるようにはなっているが、挙げられているソースコードはここ数年全く更新されていない 2.6 と 2.7 だけ。GlassDolphin 最新 Ver4.0 のコードはどこにも見当たらない。ちなみに、他の方法でのソースの開示もしていない。
ソースコードの開示なし、（GPL 的な意味での）autohr の表示なしと小林氏の主張からしたら、GlassDolphin も GPL 違反や著作権法違反になるのだろうが、現実にはトラブルに至ってないのは、メドレーがこの配布方法を許可しているから。
私らの場合なんて、法人-有志の約束事に過ぎないが、SOSO-メドレーの場合には、法人間の契約と考えてよく、それに関して知りうる立場にいない第三者が著作権違反だのというのは名誉毀損や侮辱にあたるのではないかと思う。
私らなんか、かなり GPL を意識していて、ソースコードを一般に全公開するなど可能な限りその精神を尊重してたんですけどね。
この件は、そのとき現場にいた人間からすると、そんなにおかしくもないのだが、一般の人からはそうは見えないだろうし、ケチのつけられ方に前々から違和感を持っていたので思ったことを（まとまらないかもしれないが）もう少し書き留めておく。
小林氏が持論を展開した時点では、原著作権者（この言い方は曖昧すぎて法律的な問題を扱う時は不適切だが）とされていた皆川氏は LSC 社に在籍していて、だからわれわれは筋を通すためにわざわざ一席もうけて LSC にご意見伺いを立てたわけだ。
その場に出てこないで、後で文句を言うのは筋違いではないか？
交渉時に「こういう表記にしてくれ」と言われたらわれわれは従ったと思う。
そのときに勘違いか何かあったとしても、後でメールかなにかで指摘してくれれば、それでも従ったと思う。
著作権や各種契約を管理していた法人（しかも本人が所属している）を通してでは何も主張できないのだから、それ以外のルートで非公式にとやかく言われてもこちらとしては社会人のマナーとしてなんの対応もできない。
これは小林氏に対しても同様で、そんなに確信があるなら、LSC に問い合わせればよかったのではないかと思う。
もちろん、そうはできない事情もある程度は察していたわけだから、もう少しやり方を工夫して欲しかった。
事情、というのは、LSC 版と goody 版で同一ファイルであっても author 表記が食い違うとか、基本設計に近い部分で Junzo SATO（佐藤純三）氏の貢献が確認できるとか・・に起因するある種の広報と実体との矛盾のことだ。
2010 年台中頃から、LSC のドルフィンは不具合は頻発し更新も滞りがちで、LSC の主張を額面通りには受け取れないという雰囲気はあった。
それでも、フォークした開発者連中は、「ソースコードが公開されている電子カルテ」などそれまでなかったのだから、違和感を持ちながらも商用開発元の喧伝する「オープンソース」の物語には付き合っていこうという態度であったと思う。
だから、ことをおさめるためにもうちょっとうまいやり方をとって欲しかった。
例えば、Junzo SATO・funabashi・miura… といったソースコード提供者の貢献を再評価し、適切にクレジットする、といったやり方だ。
e-Dolphin 時代からの業績を考えれば、Junzo SATO 氏などはもっとフィーチャーされていいはずだ。
が、「歯医者さんが考えた歯ブラシ」的な商業的なプロバガンダのせいか、実際はそうはならなかった。
代わりにフォーカスされたのは、増田茂と松村哲理だ。
松村氏は、当時からそれほど開発者アピールはしていなかったし、今でもソースコードの開示はして開発は継続しているので、現在でもそれほど違和感なく受容されていると思うが、増田氏の現状は一体どうしたものだろう？
増田氏の X(twitter) アカウントは @masudanaika というものだが、現在（2025.9 月）では、プロフを見る限り、OpenDolphin に関与していたとも医師だとも名乗っていない。
この現状で「増田内科の増田茂医師が開発に関与している」というかつての主張とどう辻褄をつける気なのか？
増田氏の名前が出たついでで言ってしまえば、皆川和史に至っては事情はもっとおかしく、調べたら X のアカウント自体が消えてしまっていた。
著作権云々の観点からみてもおかしなことで、本当に保護すべき著作権人格権を有しているのであれば、むしろ所属を離れた時の方がその権利を主張しやすい。
財産権としての著作権は法人所有であっても構わないが、職務著作が成立している場合を除いて著作権人格権（表記権含）は法人には委譲不可能だからだ。
組織のしがらみでその時は自分の権利を主張できないことがあるというのは理解しているつもりだ。
何かおかしい。
小林氏の怪文書が公開されたのが 2018 年11月26日ということだが、実は、小林さん、それに先立つ 同年11月5日に OpenOcean にプルリクエスト（PR）を送っている。
詳しくは『オープンソースの世界 〜残酷な自由さ〜』を読んでほしい。
結局、この PR はマージされなかったわけだが。
PR 送った時点では、OpenOcean が GPL 違反だとは一言も主張しておらず、PR を断ってから、突如として「違反だ、違反だ。皆川・増田をクレジットしないのは違反だ」と騒ぎ立てている。
これも何かおかしい。
最初の方で「まとまらないかもしれないが」と書いたが、なんとなくまとまってきた。
彼らが騒ぎ立てていたのは、OpenOcean 騒動の 2018 から始まって、メドレーへの譲渡が決まった 2020 までの期間にほぼ限られる。
経営陣が変わった LSC は、2018 には多分に経営的な観点から「GPL はやめる。活動実体が把握しにくい皆川・増田の位置付けも変える」ということを仄めかしていた。
この決定に関して、皆川は知っていたはずで、「開発者」の立場が風前の灯だということもわかっていたはずだ。
結果的には、メドレーへの事業譲渡という形で、この狙いは強制的に果たされるわけだが、「開発者」たちは、こうなる前に自分の author としての名前をプロジェクトに刻みつけておきたかったのではないかと推測する。
「オープンソース時代に彼らが保有した権利は、著作権人格権とは無関係な『著作権者と名乗っていい権利』だけだったのではないか？
実際に開発して保護の対象になっているのであれば、プログラムであっても著作権表示権は保持できるはずだが、実際にはそうはなっていない。
LSC からメドレーへの譲渡がスムーズにいったのも、そもそも彼らが保持できるような著作権表示権を持っていなかった、つまり実際には開発には関与していなかったからだと思う。
2.3 系までの契約上の権利しか持っていなかったので、その権利を保持するために 2.7m は 2.3m の派生だと主張する必要があったのではないか？」
『いるかの怪文書３』より
それまでの主張と整合性を取るために、無理とわかっていても主張を変えられない、引っ込みがつかないというのは、わかる気もするが、一時的とはいえ世間の耳目を集めたプロジェクトの着地点としては適当なものとは言い難かった気がする。
見当はずれのコメントしかできないようなレベルのスキルしか持ち合わせていないにも関わらず、増田茂の尊大な態度に何か違和感を覚えるという人が多いようだ。
最近になって「増田茂の態度が尊大なのは、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 と繋がりの深かった人々からおかしな非難をされていた。人々、といっても、皆川和史・増田茂・松村哲理・小林慎治・杉原利彦くらいなものだが。
どういうものだったかは
『保健医療科学院 小林慎治が国家公務員法違反疑いで厳重注意を受けた件について』
『小林慎治氏の OpenOcean に関する事実誤認』
『小山哲央（アーク情報システム）の件』
あたりを参照してください。
彼らがいうには、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 順に関して間違えるとは思えない。
メドレーも、皆川氏と同様に増田茂氏を開発者とは認めていない。
やはり、別の人が設計・コーディングしたと考えざるをえない。
ところで、オープンソースの世界は一般には不親切で（商用を前提にしていないので当然だ）、よくわかってない人間に対してメンテナが言う言葉は大抵の場合
ソースコード嫁
である。