OpenDolphin と「商業」GPL
オープンソースの定義の一つに、オープンソース・イニシアティブ（OSI）が決めた「オープンソースの定義」に従っているソフトウェア、というものがある。
具体的にはGPL・Apache・BSD... などのライセンスが OSI からお墨付きを得ている。
だから、ソースコードを公開する際に形式的に GPL （でもなんでもいいんだが）のライセンス文書をソースコード群の中に忍ばせておいて、GitHub あたりに「公開」しておけば、そのプロジェクトは立派な「オープンソース」ソフトウエアと名乗ることができる。
それに何か不都合があるのか？と言われそうだが、OpenDolphin （という電子カルテ用ソフト）の一連のゴタゴタを見ていた身としては、これだけではちょっと無理があるんじゃないかと思わなくもない。
もうすんでしまったことだから、細かい話はしないが、もはや開発元自体がこのプロジェクトは「GPL」のライセンスを守った「オープンソース」のソフトだとは主張しなくなってしまった。
「オープンソース」という名前が欲しくて形式的にGPLに従っているだけ（でもその実態は「オープンソース」の理念から大きくかけ離れている）のようなソフトは「商業」GPLとでも、つい、言いたくなってしまう。
最近では PACS サーバの Orthanc が、どんどん「商業」GPL っぽくなっている。
開発者のセバスチャンがメーリングリスト上で「この修正には、XXXX万円かかる」などと述べていた。
おそらく、主要な部分は彼が書いているだろうが、それ以外の部分は仕様を決めて外注などしていると思われる。
プロジェクトの理念に賛同した心あるプログラマーが無償でコードを提供してプロジェクト自体を発展させていく、というのは理想論だが、なかなか難しいものがある。
（追記）なお、現在（2022）、数ある OpenDolphin 派生バージョンのうちオープンソースらしさを最も残しているのは OpenDolphin-2.7m 系列だろう。
GitHub で公開されているソースコードは更新されておらず、 Java 1.8 にしか対応していないのだが、関係者向けに限定公開されているリポジトリでは、Java 17, Jakarta EE 9.1 に対応したバージョン（OpenDolphin Ver 6）が公開されている。
なお、現在（2022/11〜）は WildFly 27 のリリースに合わせて、JakartaEE 10 への対応を検討している。というのは、WildFly 27 は、JakartaEE 10 にしか対応していないから。逆を言えば、WildFly 26 までは、JavaEE 8 対応の少々古くさいウェブアプリであっても、ほとんど問題なく動いた。
限定公開になっているのは「一般公開しても構わないのだが、メドレー自体がこれまでの経緯でそうはしてないし、（今となっては）セキュリティなどで問題を抱えているバージョンをこのままの形で公開する意義は少ない」という漠然とした判断からだ。
セキュリティの問題をいくつか挙げておくと
1. サーバ-クライアントの通信には REST API を用いているが、この時の URL(URI) がオープンソースであるがゆえに特定可能であり、サイバー攻撃の格好の対象になる
2. ログイン認証の仕組みも特定されており、これもセキュリティ的にみて脆弱
3. データ構造も（一部の人によって）解析されており、改ざんの可能性につながる
などである。
1. はあまり言われてない事だと思うが、（おそらく）この脆弱性ゆえ商用のクラウドタイプはサーバーの URL を一般に公開していない。
メドレー、SOSO(GlassDolphin)、MIA どこもそうでしょ？
2. は言わずもがなでしょう。
3. に関してはこれまでにも「オープンソースはセキュリティに見て安全なのか？」という（素朴だがある意味確信をついた）疑問は上がっていた。OpenDolphin-2.7m のメイン開発者の猪股（弘明）先生が、実に巧妙にその具体例を提示してくれた。
あまり一般ウケする記事ではないと思うが、先生の書かれた
『OpenDolphin は「真正性」すら満たしていないかもしれない』
の一読を勧める。
要するに「（OpenDolphin は記録の保存には hibernate を使って blob を操作しているが、hibernate を使っている限り）データベースの blob 保存領域を直接操作してデータを書き換えると、OpenDolphin のシステム自体はデータ操作（改竄）されたことに気がつかない（＝検知することすらできない）」（『2022/07 モヤっとしたことなど』を一部改変）という理屈です。
先生自体は、例の半田病院事件に触発されて書いたんだそうだが、そういった具体的な事例を超えてかなり一般化された考察のように思える。
少なくとも、「PDF で出力できるから、真正性を満たしている」という小理屈はもう成立しなくなったように思える。
なお、この関係者のみでソースコードを共有する仕組みは、一般のオープンソース開発方式よりうまくいっているようで、ここから『OpenDolphin HTML/PDF Viewer』や『WebDolphORCA』などの派生プロジェクトが生まれている。
（追記２）なお、上で言っていた「関係者のみでソースコードを共有する仕組み」はコンソーシアム開発方式と言われるようになった。（『オープンソースの世界』）
議論も活発で、なかなか盛況ですね。
（追記３）ところで、たまに「なぜ、java のアップデートに対応させる必要があるのか？ 日常業務に不具合がないなら、そのまま使い続けてもいいのではないか？」といった質問を受ける。
色々な理由が考えられるが、「java の開発環境にサポート期間が設定されているから」というのが、もっとも基本となる理由でしょうか。
例えば、orcale の場合、以下のようなサポートがある。
・Premier Support リリースから５年間のメンテナンスとサポート
・Extended Support 追加料金で Premier Support の期間延長
Java 1.8(Java 8) の場合、Premier Support は 2022/3 で切れてしまっているから、このバージョンの Java で開発されたアプリに開発環境（JDK）由来のバグが出たとしても基本的には修正できない。
Extended Support は、ありがたいことに 2030/12 まで延長されたが、そもそもオープンソースのプロジェクトで開発環境にサポート料金を払っているところは多くないので、この恩恵はなかなか享受できない。
「Prmier Support の終了＝開発環境のサポート終了」と考えてもらっていいと思う。
（詳しく知りたい人は、このページなど参照）
結構な人が移行したと思われる AdoptOpenJDK は、Java8 に関しては 2026 まで使えそうですが、そんなことをするくらいなら、java11（可能ならば java17）に移行した方がいいでしょう。
OpenDolphin に関して言えば、一般公開されているソースコードは java1.8(java8) にしか対応していないため、このバージョンで開発を継続するのは（セキュリティの観点などから）その行為自体がリスクになります。
（追記４）ところで Java のアップデートは舐めてかかるとハマるときがある。
1.7 → 1.8 の移行くらいだったら、修正はそれほどでもないが、Java9 あたりから新規の文法が導入され Java17 あたりでは、それがより厳しく適用されるようになってきた。
以前どこかでいくつかの OpenDolphin プロダクツは移行で苦労するのではないかと書いたが、当たっていたようだ。
サーバーログが、これ（↓）だと、んー。
選択式コメントは必ず特定の診療行為に紐づいているため、ORCA データベースのコメント格納テーブルに診療行為との関係性を記録するカラムがあれば、その値を検索することで所定のコメントを取り出すことができる。
上図では、「通院精神療法（３０分以上）（精神保健指定医による場合）」を選んだ際、この診療行為に対応する選択式コメント「３０分以上４０分未満」・・・が正しく表示されている。
なお、従来のドルフィンでは、これに対応しようとするとかなりコストのかかる改修が必要になる。
というのは、診療行為もコメントも tbl_tensu からしか検索できないからだ。（選択式コメントはそんなところにはない）
何らかの改修をして、正しくコメント群を引っ張ってこれたとしても、クライアントに表示させるには UI の変更も必要になってくる。
猪股先生が、Ver6 以降、デスクトップアプリをメンテの対象外にしたのは、この辺を予想してのことだったと思われる。
クライアントがブラウザの場合、上図が示すようにそこまで難しくはない。
（おそらく、松村バージョン・増田バージョンは未対応）
（追記６）電子処方箋対応もクライアントがデスクトップアプリの場合は、かなりの改修コストがかかる。
特に arm Mac の場合、HPKI のカードドライバは公式には提供されていないため、ここから作成する必要がある。
猪股先生は、あっさり arm Mac 対応のカードドライバを作成、こちらのページで配布している。
コメント
コメントを投稿