Just another PHAZOR Blog
macOS 向けにアプリを公開している関係上、Mac の一台は開発者向けの macOS を載せている。
今だと、GoldenGate のパブリックベータが稼働している。
PHORLIX や PHORLIX Lite は全く問題なく動く。
ついで、という感じで Horos (v4.0.1) を起動させたところ、起動自体はできるのですが、クラッシュしますね。
思い当たることがあったので Miele-LXIV も試しましたが、やはり同じような形でクラッシュします。
Golden Gate のリリースが 9/20 頃の予定ですから、これは正式リリースまでには間に合わない感じでしょうか。
HorliX v1.1.1 も同様にクラッシュしましたが、Golden Gate 向けにビルドし直してクラッシュを回避してます。
（v1.1.2 としてこちらのページで案内してます）
久々に Horos さんの issues に出没してきた。
評判いいのはこの投稿。
As a matter of fact, the source code for Phorlix was initially made public—though it didn’t use OSI-approved licenses like GPL, MIT, or Apache.The source code was eventually closed off because the pool of contributors was limited.
We are still interested in sharing source code, but we are not entirely convinced by OSI-style licenses.
It feels like OSI licenses are somewhat out of step with the times.
訳すとすると
実際、Phorlixのソースコードは当初公開されていました。GPL、MIT、ApacheといったOSI承認ライセンスは使用していませんでしたけどね。最終的にソースコードは非公開となりましたが、これは貢献者の数が限られていたためです。
私たちは今でもソースコードの共有には関心がありますが、OSIスタイルのライセンスには完全に納得しているわけではありません。
OSIライセンスはいささか時代遅れになっているように感じます。
と言った感じだろうか。
けっこうあちこちで言われているが、AI ブースト当たり前の現代にあって OSI ライセンスはその本来の意味や効果が薄れてきているように思う。コードを公開すれば、AI を使って書き直されてしまう時代にあって、従来のやり方でソースコード全体を公開し続けていくことはメリットばかりとは言えないのだ。
どちらかといえば「ソースコードの共有方法」に関して OSI ライセンスとは異なる別のアイディアが必要とされているように思う。
HorliX のユーザーさんで Protected Mode に入れないという方がいたので、動画で解説してみました。
Horos も同じ手順で入れると思います。
現行 OsiriX は、持ってないのでわかりませんが、以前のバージョンなら、これで入れると思います。
ビューアがダイコムファイルを読み込む時、タグ情報などをデータベースに保存、画像は適当なフォルダに入れておくと思います。
が、おかしなダイコム（異常ダイコム）の場合、タグ情報や画像をうまく展開できず、ファイル（スタディ）としては登録されているのに、画像表示できない時があります（ひどい時は、以降、起動不能）。
そこで、画像を表示させない状態でアプリ自体を立ち上げるモードが Protected Mode というものです。
このモードで立ち上げて、異常ダイコムを取り除く、という操作をすると、次回以降は、データベースは元の状態に戻り、起動可能となる場合もあります。
ただし、’INCOMING.noindex’ フォルダの方におかしなファイルが引っかかっている場合は、そもそも Protected Mode 自体に入れないので、これが絶対ということはありません。
猪股弘明
HorliX メイン開発者
ORCA ユーザーのメーリングリストで、大阪の八木高秀先生の
ORCAと連動した電子カルテをご使用中の方がおられましたら、
ご使用感を教えていただけないでしょうか。
という投稿をきっかけに医療用ソフトの議論が突如として活発化。
多少「あれ？」と思うようなところもありますが、現場で使っている先生方はこの手の問題に熱心ですね。熱意が伝わってきます。
OpenDolphin の話題も出ていたので、私もイントロ的な概要と現在注意しておいた方がいい点などをコメントしてきました。
カルテ記載内容のデータベースの永続化方法に関しては、ほぼほぼ解析できてまして、クライアントからではなく、別のツールを使って抽出もすることもできました。
『Save the DolphinS -OpenDolphin データ抽出ツール・プロジェクト-』
https://allnightnihon2b.net/blog-jp/?p=816
で案内しています。データベースに直接アクセスして復号しているため、最終確定版だけでなく途中経過版も抜いてこれます。カルテに貼り付けた図版も別に画像ファイルとして抽出できます。
なんで、こんなものを作成したかといえば、opendolphin から他電子カルテへの乗り換えを考えた場合、途中経過版も含めて電子化して取り出さないと実質的にはデータ移行しにくいと考えたからです。
「データ移行」に関しては関心が高かったようですね。
また、ORCA に関しても気になっている点を挙げさせてもらいました。
ただ、現行の OpenDolphin を大幅に機能強化させるようなことは考えてません。以前は、手が空いたら着手しようかと考えていたのですが、某筋から「ORCA の技術的側面に関して調べてみては？」と提案されて、調べたところ、設計の古さが目についたからです。
この件に関しては以前このMLにも投稿しましたね。
例えば
『ptid のデータベース上での定義について』
https://ml.orca.med.or.jp/orca-users/msg14679.html
などの一連のやり取りをご覧ください。今すぐということはないでしょうが、ORCA は将来的には再設計される可能性もあるわけで、その状況では、ORCA「だけ」に依存する上物には手を出しにくいかなあと思っています。
などなど。
ただ、取り扱いが微妙な問題も孕んでいるので、あくまであっさりとした解説です。
「取り扱いが微妙な問題」というのは（ここで細かい話をしてもしょうがないと思うので）
『保健医療科学院 小林慎治が国家公務員法違反疑いで厳重注意を受けた件について』
『HorliX -wikipedia 風解説- にまつわるあれこれ』
あたりをご参照ください。
ところで、この手の話をするときに、クライアントに実装した「いわゆる」ファイルバックアップシステムをまず取り上げ、次にデータ抽出ツールの説明をするようにしている。
そちらの方がわかりやすいと思いそうしているのだが、実は、実際の開発順序は違う。
時系列的には、まず、データ抽出ツールを作成し、その次に（ツールの副産物として）ファイルバックアップシステムに関するコードをクライアントに付け加えたというのが本当のところです。
これはコード上にも反映されている。
OpenDolphin のカルテインスペクタの文字情報だけを取り出すのなら、gettext という関数を使えばすむのだが、これだとカルテ上の右半分（処方や処置などを記載する欄）もベタな文字情報のままになってしまう。
過去の直近の処方内容をチェックする程度であれば、（処置区分なしの）文字情報だけでもかまわないと思うのだが、もう一歩踏み込んで処置内容毎に区分して処理したいというような場合、これだと後処理が必要になってしまう。
ところがデータベース上では各処置（スタンプ）には、それがどの区分に属するかの情報も含まれている。
これを活用しない手はないと思い、区分を読み取って条件分岐させてから、文字情報を抜く、というロジックにした。
最終的なアウトプットは単純に文字情報だけを抜いたときと変わらないのだが、ちょっと凝った統計処理をしたいというような場合、コードの修正がしやすいと思いそのような実装にした。
ファイルバックアップシステムに関わるコードは１００行にも満たないが、コードを書くときはこんな風にあれこれ考えながらやるものなんですよ。
ちょっとマニアックな話ですが、何かの参考になればと思い補足説明してみました。
OsiriX や Horos の話題も出ていたので、年末の隙間時間をついて HorliX に関しても投稿してきました。
https://ml.orca.med.or.jp/orca-users/msg14953.html
当たり前のことを言ってもしょうがないので、気持ち開発寄りに振ってます。
例えば、Horos でROIを使うとき、使う毎にその描画色がくるくると変化すると
思いますが、その元になったコードは私が送ってます。
いわゆる ROI-color-rotation-UI というやつです。
このときの改変のやり取りは今でも残ってますね。
https://github.com/horosproject/horos/issues/342ここら辺までは、Horos と協調していたんですが、当時（2018年）課題に
なっていた 64bit 対応がもたもたしていたことや彼らが若干「やりすぎ」て
しまうところが気になって、結局、独立してしまいました。「やりすぎ」というのは、具体的には、ROI-color-rotation-UI でいうと
彼らは記録時のファーマットまで改変してしまってます。
ROI を XXXX.roi のようなファイルを書き出したとき、色情報まで入れ込んじゃっているので、互換性が崩れちゃってるんですよ。
上であげた github issues 上での議論を見てもらえればわかると思いますが、
元々は「ROI の描画色が単色だと視認性が良くないので、マルチカラーを扱える
ようにしたい」というかなりシンプルで（おそらく有用な）ユーザーさんからの
指摘から始まってます。
私も色が変わるのは便利だなと思いますが、記録するほどのことでもないと
思い、Horosの改変は取り込みませんでした。
「やりすぎ」と感じるのは、こういった点です。
ここら辺、そんなに説明したことはないので、興味を持ってもらえたらいいなあという気持ちがちょっとはいっています。
猪股弘明（ご連絡は twitter の DM や facebook の友達申請などでお願いします）
OpenDolphin-2.7m 開発者
オープンソース開発方式は理想の開発形態の一つとして語られることも多いが、現場寄りの人はかなりリアルな見解を持っている。
例えば、以前評判になったこの記事。
筆者の megamouth さんによれば、contributor（ソースコードを提供した者）にも序列があるという。
OSSへのコントリビューターにもカーストがあって、ついでに書いておくとカーネルメンテナ＞言語メンテナ＞カーネルコミッター＞言語コミッター＞有名ライブラリメンテナ＞色々＞ユーザーグループ主催者＞ブログでアプリへの文句だけ書奴～
みたいな序列である。
ある程度名の通ったプロジェクトの contributor になるだけでもけっこう苦労するよ、という挿話が語られている。
曰く、
アホみたいな量のコードを読み下し、コーディングスタイルを真似し、単体テストケースを書き、開発者とコミュニケーションをとってまで、自分のコードをマージしてもらう。
プルリクエスト（Pull Request PR, 自分の改変したコードを取り込んでもらう修正依頼のこと）送るだけでも大変なのだ。
さらに、新機能の提案などになると・・・
新機能にしても、同じようなことは過去の誰かが考えているものだ。それらの機能が今存在しないのは、何らかの経緯で却下されたか無視されたことによることがほとんどである。
もし彼が「ぼくのかんがえたすごいしんきのう」を拙いCコードで表現することに成功したとしても、Google翻訳を駆使して、なんとか英語圏の人間に読めるプルリクを送れたとしても、忙しいメンテナが一瞥して言うことは「過去ログ嫁」である。
単に PR 送るより大変なのがわかる。
ところで、私がオープンソースの世界に足を踏み入れ始めたのは、2018 年の春頃からだ。
きっかけは horos という医療用画像ビューアのプロジェクトの存在を知ったとき。
医療画像ビューアは一般に高額で、レントゲンや CT の画像を「ちょっと」確認する程度であれば、オープンソースのプロジェクトの公開されているソースコードを自力でビルドして使った方が金銭的な節約になる。
おまけに自分で改変もできる。ちょっと使いにくいというところがあれば、そこを自分で改変したっていいのだ。
私の場合、改変したいくつかの機能は、horos の本プロジェクトにも PR を送り、マージしてもらった。
そういう意味では、私は「医療用の OSS」 というニッチな分野では contributor なのだが、上で述べられたようにすごく苦労したかといえば、そんなことはない。
OSS のカースト的にみれば「アプリケーション」レベルだし、何よりも「医療」と名が付くと開発寄りの参加者は極端に減る傾向がある。
慢性的な人手不足なのだ。この分野では一定水準のプログラミングスキルを持った人なら、新機能の提案・実装は、（カーネルなどへ contribution するのに比べたら）かなり楽だ。
ある程度慣れたきた段階で、自分でもプロジェクトを持つようになった。
だから、けっこう短期間の割には PR を送る側の経験も受け取る側の経験も両方したことになる。
ところで、ネットを見ていると「どうやったら PR をマージしてもらえるか？」みたいな記事は見つかるのだが、逆に「これやっちゃあかん！」というような記事はあまりない。
参考になるかどうかわからないが、一つ例示したいと思う。
以下は、私たちが OpenOcean という OpenDolphin 由来の電子カルテのプロジェクトで、クライアントバイナリを配布してきた時にもらった PR 。
公開するのもはばかれるような内容な気もするが、当人たちは open にしろしろと主張しているのでここで取り上げても問題ないでしょう。
一目でわかる通り、単純に特定行を delete したのみ（文頭の – は削除した印）。
この場合で言えば、public static int expired( ) という関数が関与する部分を削除しましたってだけの内容。
一般にコード書きが何かを実装する場合、たいてい、狙った機能というものがある。
上記のコードでは特定時刻と現在の時刻を比較し、現在時刻が特定時刻より先に進んでいた場合、そのプログラム自体を終了せよというのが狙った機能だ。
要するにこのアプリの使用期限を設定している。（この時点で元のプロジェクトにはれっきとした商用版が存在しており、こちらはちょっとした機能の提案をしたかっただけ。気合い入れて継続的に開発していく意思がなかったというのがその理由）
だから、これは bug （バグ）ではない。
確かに、プログラムが複雑になってくると、深刻なバグがあるにもかかわらずそれがどこにあるかわからないといった場合はよくある。このような場合、それを特定するだけでも貴重な情報になる。
だが、これはそういった類のものではない。
だから、この PR はマージできない。
逆に、「残り XX 日で使用不能になります」といったアラートダイアログなどを表示させるようなコードの場合、おそらくコードの書き方が少々稚拙であってもこちらで手直ししてマージしたのではないかと思う（例え、この噂が本当であったとしても、だ）。
つまり、相手（レビュアーやメンテナー：PR を評価しリポジトリを管理する人たち）の意図を汲み取ってプロジェクトにとってプラスの価値を与えるようなプルリクには大概のメンテナーは寛容でありマージもされやすいが、単に自分の願望を押し付けるだけでは考慮もされないのだ。実際このときもそれが主な理由でマージはしなかった。
また、彼の意図を汲み取るならば、それは「最終産物のアプリの使用期限を取り払ってほしい」ということだ。issues あたりに掲げておけばいい要望であって、わざわざ PR にするほどのものでもない。
上で「主な理由」と書いたが、他にも気になった点はあった。
というのは、このとき PR 送ってきた相手の GitHub アカウントのアバターが、全世界でかなりの人気を誇るアニメのキャラだったから。漫画・アニメなどで人気のあるキャラの２次利用は、たいていの場合制限されている。
実際、このキャラクターは基本的には２次利用を許していない。
もしかすると、この人と著作権管理団体などで使用許諾の契約がなされているのかもしれないが、基本的には第三者にはそんなことはわからない。
そして、PR を送ってきた相手はまったく知らない人だ。信用できる人なのかどうかもわからない。
一応、名前や所属などは確認したが（京都大の小林慎治という人。現在は、保健医療科学院を経て岐阜大学に所属）、ここらへんの権利関係に関してはまったく気にしていないようだった。
私が気になったのはこの点だ。
OpenOcean プロジェクトに関しては特に行動規範（CODE of CONDUCT）のようなものは定めてはいなかったが、やはり「知的財産権に関して一定の配慮ができる」というのが最低限の暗黙の前提になる。この件にしてもそうだが、知財権に関して無頓着すぎるように思える。
どんなオープンソースのプロジェクトでもそうだが、ネット接続環境を持っていて、アカウントさえあれば、議論に参加するくらいのことはできる。有意義な議論になることもあれば、まったく不毛な質の低いものになることもある。ネットで不特定多数を相手にするというのはそういうことなのだ。そして、意味のある議論ができるかどうかは実社会のステータスとは相関しない場合が多い。主張している内容や実際に書いたコードでその人の能力を推し量るしかないのだ。（蛇足かもしれないが、それはオープンソースの可能性でもあるだろう。全く無名の人でも活躍できることに繋がるのだから。）
だから、何かをしたい・信用を勝ち得たいというならば、その資質を実践で示す必要がある。それ以外の基本的な部分でレビュアーやメンテナに不信感を持たせては、まず PR は拒否されるし、以降はまともには相手にしてもらえないだろう。
（追記）小林慎治氏、この後、何を思ったか「OpenOcean は GPL 違反だ」という傍迷惑な主張を展開するようになった。自分が PR 送ったプロジェクトを誹謗中傷して何が面白いのか？と訝しんでいた。単純に逆ギレしたからというだけではなく、（メドレー移行に伴い、その後、開発者としての立場が否定されることになる）皆川和史や増田茂などの名前を OpenDolphin プロジェクトに刻みつけておきたかったからという理由もあるのかもしれない。
しかし、この主張は無理がある。（『ソースコード嫁』参照）
また、付け加えておくと、アプリケーションレベルのOSSでは、「エンドユーザーに近い」という特性ゆえ、異なるバージョンの開発が並行して進められるということはよくある（当たり前だがユーザーには「好み」があるから）。
特に、電子カルテのように施設毎でのカスタマイズが前提になる場合はその傾向が顕著になる。実際、元になったプロジェクト自体、施設毎での独自カスタマイズを奨励していた。自分で既存のプロジェクトにはない機能を付加したいというなら、元プロジェクトを fork して独自プロジェクトをおこせばいいだけだ。
既存のプロジェクトに自分の提案を受け入れて欲しいというなら、相手の意図にはある程度意識的になる必要がある。もし、それが叶わないというのなら、自分で独立してプロジェクトおこせ、ということになる。
タイトルに「残酷」と入れたが、ある意味、それはオープンソースの世界の自由さとも言える。
他にも面白い話もあるので、また続き書きます。