ネットで昔関わっていた仕事を調べていたときたまたま見つけたのが、これ。
慣例？にならってここでも「開いたイルカ」としておきましょう。なんか変に絡んでくる人いそうだし。
昔、某自治体絡みでこれ関係の仕事をしたことがあるのだが、今、こんな事態になっていたわけですね。
これは電子カルテのプロジェクトなのだが、オープンソースになったときなんて、けっこうインパクトあったように思う。
その当時は（笑）。
だが、本邦のソフト開発者が「設計図共有サイト」github などでの開発に慣れてくると、とりわけ、海外有名プロジェクトのオープンソースソフト開発のやり方に慣れてくると、このプロジェクトがけっこう不自然なものに見えてくる。
開発者を限定する、というのはあってもいいのだが（ニッチな分野では不特定多数の開発者をアテにはできないことがしばしばある）、そうだとしてもプルリクやマージは普通に行われる。ところが、「イルカ」ではこのプロセスがつい最近まで一切なかった。ちょうど下請けや孫請けにつくらせたコードをそのままボンッとリポジトリに送りこむかのように突如としてバージョンアップ版が出現していた。
また、開発元がログ出力の対応ができなかった、データ移行ツールがなかったなんて話を聞くと、何だろうこれはと思ってしまう。
慣例？にならってここでも「開いたイルカ」としておきましょう。なんか変に絡んでくる人いそうだし。
昔、某自治体絡みでこれ関係の仕事をしたことがあるのだが、今、こんな事態になっていたわけですね。
これは電子カルテのプロジェクトなのだが、オープンソースになったときなんて、けっこうインパクトあったように思う。
その当時は（笑）。
だが、本邦のソフト開発者が「設計図共有サイト」github などでの開発に慣れてくると、とりわけ、海外有名プロジェクトのオープンソースソフト開発のやり方に慣れてくると、このプロジェクトがけっこう不自然なものに見えてくる。
開発者を限定する、というのはあってもいいのだが（ニッチな分野では不特定多数の開発者をアテにはできないことがしばしばある）、そうだとしてもプルリクやマージは普通に行われる。ところが、「イルカ」ではこのプロセスがつい最近まで一切なかった。ちょうど下請けや孫請けにつくらせたコードをそのままボンッとリポジトリに送りこむかのように突如としてバージョンアップ版が出現していた。
また、開発元がログ出力の対応ができなかった、データ移行ツールがなかったなんて話を聞くと、何だろうこれはと思ってしまう。
そのほか、おかしな点はいくつかあるのですが（あくまで今から思えばという話です。当時は画期的だったんですよ）、上記記事をお読みください。
”MacOSでの使用についての注意・・動作保証は出来ません。Java環境に対するOS のポリシーの変更により使用出来なくなる可能性があります。アプリの一部の機能や操作が有効ではない場合があります。 同状態に遭遇しましても修正や稼働をお約束することは出来ません。”
ここらへんは 2.7(m)系の発展形態と比較するとわかりやすいと思う。
例えば、増田ファクトでも、サーバーに関して言えば、頑張れば Mac でも動作したと思うのだが、検証したものはいない。これは、ソースコードを一般公開しない弊害で、こうしてしまうと、外部からの貢献が全く期待できず、プロダクツのクオリティは良くも悪くも運営の能力によってしまう。
これに関してもある程度合点がいくことはあるのだが、これも手が空いたときにでも。
逆にこれで正当に評価されるようになったのは、OpenDolphin-2.7m の猪股先生ではないだろうか。
・機能の追加より bug fix を優先（どうもこれが現在の商用版にも使われているような・・・）
・データコンバーターツールの開発
なお、ファイルバックアップシステムとデータ移行ツールを混同している人もいるようだがこれは全然別物。
LSC版はもちろんだが、猪股先生版・glassdolphin 版がネット上では関心度が高いようだ。
これらは、データ構造をすべて LSC 版に準拠しており、導入方法も
GlassDolphin
その後もちらちらチェックしていたのだが、かなりおかしな、だが（見方によっては）健全な方向に向かいつつあるようだ。
まず、現在の開発元 LSC は、初期のコミッターによるバージョンを「正規版」みたいな位置付けにしていたのだが、この制限が開発元自体によって撤廃された。
商用版としては、LSC 版以外に glassdolphin というものがあるのだが、どちらかといえば、こちらの方がアクティブに開発が進んでいるようだ。
ガラス細工の「イルカ」が透明感あって美しい。
（付け足し）2020/4/6 に glassdolphin ver 3.0.1 がリリースされたということで早速インストールしてみた。
導入方法はこちらで。
クライアントバイナリが配布されている。jar 版か zip 版（windows ではこちらも選べる）をダウンロードして起動。
デフォルトでは横長のログインパネルだが、適宜サイズは変えられる。
指定のサーバに、所定のユーザ・パスワードでログインするとシステムに入れる。
Mac では下のような画面になる。
windows 版は手が空いたら試してみたい。
まず、現在の開発元 LSC は、初期のコミッターによるバージョンを「正規版」みたいな位置付けにしていたのだが、この制限が開発元自体によって撤廃された。
商用版としては、LSC 版以外に glassdolphin というものがあるのだが、どちらかといえば、こちらの方がアクティブに開発が進んでいるようだ。
ガラス細工の「イルカ」が透明感あって美しい。
（付け足し）2020/4/6 に glassdolphin ver 3.0.1 がリリースされたということで早速インストールしてみた。
導入方法はこちらで。
クライアントバイナリが配布されている。jar 版か zip 版（windows ではこちらも選べる）をダウンロードして起動。
デフォルトでは横長のログインパネルだが、適宜サイズは変えられる。
指定のサーバに、所定のユーザ・パスワードでログインするとシステムに入れる。
Mac では下のような画面になる。
windows 版は手が空いたら試してみたい。
（付け足し）MacOS 版は以下のように動作保証外になってた。
一般に MacOS の Java デスクトップアプリではメニューが windows と違うので、修正が必要なんですが、できなかったのかもしれませんね。
そもそも Java17 になったら、windows 版も動くかあやしいと思ってますが。
慣例的な GPL の著作権表記
ちなみに一部の人が主張している著作権表示云々だが、glassdolphin では (C)マークは「全く使ってない」。ヘルプメニューから glassdolphin サイトに飛ぶという仕様にはなっている。
細かな理由は挙げないが、これはこれでいいのではと思う。
細かな理由は挙げないが、これはこれでいいのではと思う。
何らかの形で
・リリースした団体・個人は誰か（著作権法的にはリリース主体として(C) マークを使うのが普通）
・フォーク元がどこか（GPL 的配慮。これはどこかに表示できていればいい）
・ソースコード提供者のクレジット（これもGPL的配慮。たぶん、一番簡単な実現方法はコーディングした人の署名がされているソースコードを「一般」公開しておくこと）
となっていて、上記の慣例に忠実であることがわかる。
・リリースした団体・個人は誰か（著作権法的にはリリース主体として(C) マークを使うのが普通）
・フォーク元がどこか（GPL 的配慮。これはどこかに表示できていればいい）
・ソースコード提供者のクレジット（これもGPL的配慮。たぶん、一番簡単な実現方法はコーディングした人の署名がされているソースコードを「一般」公開しておくこと）
がわかるようになっていれば、OKではないかと思う（確か判例もあったと思う）。
これをなんで小林慎治が「違反ダー」みたいにいったのか理解できない。（その後の経緯から、小林は 2.7m のフォーク元を 2.3m と誤認していた可能性が高い。後述する）
大体において開発元のLSC・メドレーが「むしろ著作権表記を変えてください」と言っている以上、無関係の小林慎治が首を突っ込む話ではない。
実際、某所でこの話題が出たときは主に情報系の方々から「小林の解釈は聞いたことがない」「いつものアレ」みたいな形で散々批判されていた。
「いつものアレ」というのは以前にも知財権のおかしな解釈を垂れ流して批判されていたから。こことか参照。コメントにもあるが「明細書の読み方勉強した方がいい」レベルですよ、これ。明細書書いたことある人からしたら絶対しないようなミス。
「いつものアレ」というのは以前にも知財権のおかしな解釈を垂れ流して批判されていたから。こことか参照。コメントにもあるが「明細書の読み方勉強した方がいい」レベルですよ、これ。明細書書いたことある人からしたら絶対しないようなミス。
ところで、小林慎治さんが所属している保健医療科学院というところから、「不愉快な思いをさせてしまい、大変申し訳ありません」という主旨の謝罪のメールをいただきました。細かい経緯はよくわからないのですが、他のオープンソースのプロジェクトで行動規範を逸脱する言動があったようです。
『OpenDolphin 2.7(m)を WIN10 にインストールしてみた』より
ああ、やっぱり。。。
さらに、これは素人目に見てもダメなのはわかるんではないでしょうか。
air-h-128k-il 氏にまったく違反をしているという認識がないところが問題点です。
などと彼はいっているようだが、その当人が著作権法違反が疑われるような行為をしているようでは、無視されても仕方ないでしょう。
フォーク元を誤認していただけ？
一部の人々が大騒ぎした著作権表示云々だが、その理由はそう主張した人々が「2.7m のフォーク元を 2.3m（増田ファクト）と勘違いしていた」だけだったとする説がある。
つまり、2.7m のフォーク元は増田ファクトなのだから増田茂の名前をクレジットしないのはおかしいという理屈だ。
まあ、それなら論旨だけは理解できるか。
事実関係を言えば 2.7m のフォーク元は LSC 2.7 であって増田ファクトではないけどな。
事実関係を言えば 2.7m のフォーク元は LSC 2.7 であって増田ファクトではないけどな。
ただ、誤認した理由というのが、かなりおかしい。
「2.7m の開発者の（精神科医の方の）猪股先生が、2.3m（増田ファクト） のユーザーであったから、2.7m は 2.3m のフォークだ」
「2.7m の開発者の（精神科医の方の）猪股先生が、2.3m（増田ファクト） のユーザーであったから、2.7m は 2.3m のフォークだ」
というもの。
色々な意味でありえないと思う。
色々な意味でありえないと思う。
猪股先生はソースコードを GitHub に公開しただけでなくそのインストール・デプロイ方法もネット上で公開している。
Java8 時代に代表的なインストール記事として挙げられていた『OpenDolphin 2.7(m) の Win10 へのインストール及びカルテデータの２次利用について等』がそれだ。
何度かの改訂で現在では初期の頃よりかなり記載内容が変わったのだが、一貫して言われているのはビルド対象のソースコードは LSC 2.7 または 2.7m と指定している点だ。
記事の指示通り作業すれば、2.7 かつ/または 2.7m ができる。
実際に自分で手を動かせば、それらが 2.3m とは違うものだと認識できるはずだ。
記事の指示通り作業すれば、2.7 かつ/または 2.7m ができる。
実際に自分で手を動かせば、それらが 2.3m とは違うものだと認識できるはずだ。
また、サーバープログラムをデプロイしたときにデータベースにテーブルを作成するのだが、増田ファクト特有の msd_ 系は作成されない。
データベースをチェックしてもいいし、hibernate に慣れた人なら、デプロイせずともソースコード上で確認できるはずだ。
データベースをチェックしてもいいし、hibernate に慣れた人なら、デプロイせずともソースコード上で確認できるはずだ。
他には、増田氏が実装したとされるカルテ内検索機能も 2.7(m) には実装されていない。
この事実に至っては、ビルドせずとも公開・配布されていたバイナリを動かせばわかる。
この事実に至っては、ビルドせずとも公開・配布されていたバイナリを動かせばわかる。
技術把握能力の低い皆川和史や小林慎治が誤認するのは理解できなくもないが、2.3m を開発したと自称していた増田茂がこういった間違え方をするとは思えない。
このことから、増田ファクトは増田茂が作成したのではなく、技術方面に明るい別の誰かが作成し、増田茂はそれを自分名義で発表していただけだったのではないかということが強く疑われるようになった。
猪股先生自身も『ソースコード嫁』でこれに近い考え方を表明している。
だから、増田ファクトの真の作者は、こういった状況を理解していながら、無理を承知で意図的に「2.7m = 2.3m フォーク説」を流布しようとしたのではないかと思っている。
増田ファクトの過大評価
そもそも増田ファクトは LSC dolphin の windows 特化バージョンといった趣で、動作実績は windows しかない。正直なところ、windows 特化の傍流プロダクトという感が拭えない。
LSC dolphin のソースコードを見ても masuda というクレジットがあるのは、そのほとんどがクライアントで、サーバー部にはあっても調整用のコードが大半だ。
グライアントの、特に GUI を変えれば、一般的なユーザーからの好意的な評価は得られやすい。このこと自体は、悪いことではないのだが、サーバー部のメンテを怠ると、Java 自体のアップデートについていけなくなり、アプリ自体が正常に動作しない、いきなり sudden death ということがありうる。
Java17, JakartaEE 時代以降、増田ファクトの評判をまるっきり聞かないのはこういった事情もあるのではないかと思う。
この意味では、一時期の増田ファクトは過大評価であったのではないかと思う。
Java17, JakartaEE 時代以降、増田ファクトの評判をまるっきり聞かないのはこういった事情もあるのではないかと思う。
この意味では、一時期の増田ファクトは過大評価であったのではないかと思う。
ここらへんは 2.7(m)系の発展形態と比較するとわかりやすいと思う。
なにしろ、2.7 と 2.7m では、データ構造・クライアント外観とも全く同一だ。
派手さは全くない。
にもかかわらず、2.7m が登場以来、根強い人気があったのは、現場医療職ユーザーは、増田ファクトで謳われていた「先進的拡張」など求めておらず、2.7m で実現していた特徴、つまり、安定した動作・オープンな雰囲気のコミュニティ・豊富なドキュメント・データの取り扱いに対する配慮・・を支持したからであろう。
にもかかわらず、2.7m が登場以来、根強い人気があったのは、現場医療職ユーザーは、増田ファクトで謳われていた「先進的拡張」など求めておらず、2.7m で実現していた特徴、つまり、安定した動作・オープンな雰囲気のコミュニティ・豊富なドキュメント・データの取り扱いに対する配慮・・を支持したからであろう。
運営方針もまずかったのではなかろうか。
例えば、増田ファクトでも、サーバーに関して言えば、頑張れば Mac でも動作したと思うのだが、検証したものはいない。これは、ソースコードを一般公開しない弊害で、こうしてしまうと、外部からの貢献が全く期待できず、プロダクツのクオリティは良くも悪くも運営の能力によってしまう。
2.7m も元々は windows でしか動作実績はなかった。（正確には、Mac でも動作はしていたが、まとまったビルド・デプロイ方法が公開されていなかった）
が、公開している効果は徐々にあらわれ、いつの間にやら Mac でのビルド・デプロイ方法のかなりまとまった記事が公開されるにいたった。
が、公開している効果は徐々にあらわれ、いつの間にやら Mac でのビルド・デプロイ方法のかなりまとまった記事が公開されるにいたった。
増田ファクトは運営面も含めて、何かうまくやれていなかった印象を受ける。
結局、増田ファクトはオワコン
以前から増田ファクトは電子カルテの３原則のうち真正性を満たしてないと言う指摘はあったのだが、正直、他の商用電子カルテにも実装されていないものがあり、以前はこのアラが見えにくくなっていた。
が、2020 年頃よりほぼ全ての電子カルテで真正性がクリアされるようになり、増田ファクトの対応の悪さ（増田氏が「ノーマル PDF 書き出し機能のみで十分」と主張していたらしい。論外。そんなものは後でいくらでもでっち上げられる）が目立つようになってきた。
他には、安全性ガイドラインで推奨されている本システム停止時の閲覧システムの提供なし。医療Dx諸機能（オンライン資格確認情報の取得、電子処方箋）も対応予定なしと・・・以前の個人開発のペースかそれ以下のペースに戻ったようだ。
今では、電子カルテは組織的に開発されることが多くなったから、個人開発体制では現行の水準についていくことすら難しい。
まとめると
① 真正性を満たしていない
今では、電子カルテは組織的に開発されることが多くなったから、個人開発体制では現行の水準についていくことすら難しい。
まとめると
① 真正性を満たしていない
② 本システム停止時の閲覧システムの提供なし
③ 医療Dx諸機能未対応
これでは、実務的には使えません。
③ 医療Dx諸機能未対応
これでは、実務的には使えません。
GlassDolphin に話を戻して・・
ただ、GitHub リポジトリには、Ver3.0.1 のソースコードは上がってはいないようだ。これに関してもある程度合点がいくことはあるのだが、これも手が空いたときにでも。
手が空いてときにでも、と書いていたが、少し時間ができたので述べておくと、「商用開発元はもはや GPL を守る気がほとんどないから」というのがその理由。
関係者に聞くと「一応は GPL でライセンスされているから、配慮はするが、実態は・・・」みたいな感じで、口を濁す。
関係者に聞くと「一応は GPL でライセンスされているから、配慮はするが、実態は・・・」みたいな感じで、口を濁す。
これには理由があって、猪股先生が以前に「GPL違反だ」とケチつけられた時、さっさと FSF の中の人に相談し、FSFのライセンス担当者も「あのプロジェクトを GPL とみなすのは難しい」と評価をくだしたからだ。また、その中でもこれはもう「裁判管轄」だと言っているが、法曹関係者が「あれはOK」と言っている以上、もう話はおしまいではないかと思う。
「プロジェクト自体が（今ではクレジットすらされていない）関係者の共同著作物的意味合いが強いのだが、それをオープンソース化するにあたって特定の者に copy right/left を集約させ GPL を適用している。現在は FSF (Free Software Foundation)も GPL の位置づけを微妙に変えてきている節もあり、微妙なところではあるのだが、そもそも GPL を適用すること自体が、けっこう無理筋なプロジェクトだったように思う」
とかなり以前からこの点を指摘していた。
実際、開発プロセスが不透明すぎて「開発した」と自称している人たちの主張を額面通り受け取れない。「Junzo SATO さんの謎」は今でも謎のままだし（→どうやら、佐藤純三氏のようです。）また、現在のリポジトリにも oracle あたりのサンプルコードがそのままの形で含まれている。今では、このような事実はけっこうな人が認識している。
実際、開発プロセスが不透明すぎて「開発した」と自称している人たちの主張を額面通り受け取れない。「Junzo SATO さんの謎」は
Junzo SATO 氏の件。ここから転載。eDolphin プロジェクトのコードをそのまま流用していたようです。演題やコードの機能から考えて、画像表示に関する基本設計は eDolphin 時代のものでしょう。
運営権・商標権など実務的な権利を「金で買った」人たちを完全に信用するつもりはないが、ここらへんもうちょっと上手くやれなかったか？とは思う。
→結局、メドレー、「運営などの権利はもつが積極的には普及させないという方針」を取ったようですね。（『OpenDolphin と電子カルテの３要件とメドレー』より）
→結局、メドレー、「運営などの権利はもつが積極的には普及させないという方針」を取ったようですね。（『OpenDolphin と電子カルテの３要件とメドレー』より）
逆にこれで正当に評価されるようになったのは、OpenDolphin-2.7m の猪股先生ではないだろうか。
実際、LSC やメドレーあたりの担当者からも声がかかっているようです。
そのうちクラウド版に移行させたい実利的な背景はあるんでしょうけど（余計な機能を追加されたり、データベースレベルで変更があったりするとクラウド移行にとって邪魔でしかない）。
・機能の追加より bug fix を優先（どうもこれが現在の商用版にも使われているような・・・）
・データコンバーターツールの開発
などどちらかといえば、「縁の下の力持ち」的貢献だったと思うが、今後の展開を考えるとこういった貢献の方が有難いわけですね。
なお、ファイルバックアップシステムとデータ移行ツールを混同している人もいるようだがこれは全然別物。
ファイルバックアップシステムはクライアントに組み込まれてドルフィン動作中にその機能を発揮する。
データ移行ツールは、ドルフィンのクライアントでもサーバーでもなく、これらとは別に独立して動くプログラム。直接データベースを探索し、欲しい情報を外部に取り出す。
開発よりの側に立つと有難いのはデータ移行ツールだろう。
データ移行ツールは、OpenDolphin HTML/PDF Viewer に進化し、さらに DolphORCA プロジェクトのベースとなった。
普及の実際
公式発表によれば、LSC 版の導入数は 500 という話だが、私が見聞きした範囲では、開業医さんを中心にこれ以上ありそう。メディコムやダイナミクス（これは開発形態を考えるとよく健闘していると思う）が多いが、「イルカ」もちらほら見かける。おそらくはソースコードからビルド・デプロイして自力運用していると思われる。LSC版はもちろんだが、猪股先生版・glassdolphin 版がネット上では関心度が高いようだ。
これらは、データ構造をすべて LSC 版に準拠しており、導入方法も
などで公開されている。
こちらの方がオープンソースのプロジェクトとしては、健全な進化を遂げているように私には思える。
こちらの方がオープンソースのプロジェクトとしては、健全な進化を遂げているように私には思える。
結局、GPL は事実上廃止
私に限らず、このプロジェクトの運営面でのおかしさは、いろんな人が指摘していたと思うが、結局、メドレーさんの鶴の一声？で実質的にGPLライセンスは廃止。
いろんな意味で良かったんじゃないでしょうか。
コメント
コメントを投稿