投稿日:

WebORCA お試しサーバと OpenOceanMini

ORCA 公式で案内されている WebORCA お試しサーバは、ORCA API が生きていて通信できた。
URL: https://weborca-trial.orca.med.or.jp/
Authentication: BASIC user: trial password: weborcatrial

OpenOceanMini

ちょっと嬉しくなって、お試しサーバと API 経由でお話しできる MacOS 専用の OceanMini というアプリを公開した。

OveanMini download

現時点で使う人がいるとも思えないが、一応説明しておく。

ダウンロードした OceanMini.zip を解凍。ダブルクリックで起動。
公証とっているのでここら辺はスムーズに行くと思う。

タブパネルで ORCA の方を選ぶ。

この状態で Start ボタンを押すとお試しサーバと通信してくれます。（現在は 5 秒毎に受付情報を取得）
具体的には
/api/api01rv2/acceptlstv2?class=03 に


<data>
     <acceptlstreq type="record">
         <Acceptance_Date type="string">today(yyyy-MM-dd)</Acceptance_Date>\
         <Department_Code type="string"></Department_Code>
         <Physician_Code type="string"></Physician_Code>
         <Medical_Information type="string"></Medical_Information>
         <Display_Order_Sort type="string">True</Display_Order_Sort>
       </acceptlstreq>
</data>

を POST。
返ってきたレスポンスを適当にパースして表示させています。
（この API の詳しいフォーマットは公式ページに書いてあります）

CLAIM 廃止

ORCA 連動型のユーティリティを作成する際、現時点ではここいらの通信機能の実装から入るのが適当だと思う。
というのは今まで ORCA と「お話し」するためには CLAIM という接続方式を採用する必要があったのだが、この接続方式は 2026/4 月からは原則廃止になる。
代わりになるのが ORCA API というやつで、上の例でもわかるようにリクエストやレスポンスは xml 形式になっている。（JSON も使えるが）
この部分は新規に実装する必要がある。

Java では JAXB、C/C++ では？

その一方で最近のシステム開発言語のほとんどがオブジェクト指向で、xml 表現をそのまま取り扱うのが苦手だ。
だから、今後 ORCA を使うのであれば、なんらかの形で

クラス ↔︎ XML

ができるような仕組みを用意しておく必要がある。

XML は汎用的な書式なので、大抵の言語系ではそのためのライブラリなどが用意されている。
Java では（正確には JakartaEE の仕様だが） JAXB という仕様が決まっている。ちなみに内輪で使っている dolphin-2.7m 系では、この仕様に従って EzOrcaApi というライブラリを作成した。
例外は C/C++ 系で、具体的にこうやれという仕様のようなものは何もない。ここら辺は文化の違いというものだろうか。その代わり XML Parser のようなものは各種用意されている。実装するなら、それらを使ってお好きなように、ということなのだろう。

MacOS アプリでサーバー機能を提供する

ORCA に限らずウェブ系全般に言えることだと思うが、実務的に Java や JavaScript あたりのフレームワークでさらっと実現できるものにわざわざ C/C++ を持ち出す必要はない。

ただ、ここにも例外があって、それは Mac でサーバー機能を提供したいというような場合だ。
MacOS 上で Java 系のフレームワークやアプリケーションサーバを走らせるという選択肢はあるのだが（実際、dolphin ではそうしている）、アプリ感覚でボタン一発でサーバ機能を提供したいというような場合、これといったソリューションはこれまでなかったように思う。

前々から、小規模医療機関の LAN 内でお手軽に使えるような電子カルテ（もどき？）はあってもいいかなと思っていて、今回、ようやくという感じではあるが、OpenOceanMini としてチャレンジしているという次第だ。

Ver 1.0.1

C/C++ では、標準的なウェブサーバーすらないので、サーバーはもちろん、認証機構も独自実装する必要がある。

Ver 1.0.0 では、ドキュメントルートに出来合の dashboard.html というファイルを設置してログインしたユーザーにそこに遷移するようなテストコードを書いていた。
いかにもテストコードなので、ここを修正。
Welcome というページを動的に生成しログインが成功したユーザーはここに飛んでくるように変更した。

http://localhost/Welcome となっているが、もちろん Welcome.html という静的なページはない。上のページのようにログインしたユーザー（ocean という施設の ocean さん）の情報を入れ込んでページを生成し、サーバから出力。ブラウザに表示させる、という仕組みだ。

この改変をもって Ver 1.0.1 とした。
1.0.0 から大した機能が加わっているわけではないが、ルーティングとページの動的生成がうまくいくかどうかは未知数だったので、その成功記念のようなものだ。

また、これを機会に対象 OS バージョンを Montery まで引き下げた。
今のところ arm64 特有の機能は使ってないので Intel & Arm の両対応になっている。

 

（続く）

 

投稿日:

OpenDolphin と職務著作と GPL

OpenOcean 怪文書の論旨展開などを見るに小林慎治という人は「職務著作」の概念を知らなかったのではないかと思う。

われわれが「著作権」で思い浮かべるのは、音楽作品や文芸作品のそれだ。が、そこまで創作性の必要とされない工業製品のマニュアルなども立派な著作物だから、それらの著作権の保有者を決める必要がある。

これらの権利関係は、著作権法15条で規定されている。

第十五条　法人その他使用者（以下この条において「法人等」という。）の発意に基づきその法人等の業務に従事する者が職務上作成する著作物（プログラムの著作物を除く。）で、その法人等が自己の著作の名義の下に公表するものの著作者は、その作成の時における契約、勤務規則その他に別段の定めがない限り、その法人等とする。
２　法人等の発意に基づきその法人等の業務に従事する者が職務上作成するプログラムの著作物の著作者は、その作成の時における契約、勤務規則その他に別段の定めがない限り、その法人等とする。

日本の場合、プログラムの法的位置付けは、既存の著作権法の枠組みに後から押し込むような格好で規定されたので、条文でも 2 として別に取り扱われている。

社内やフリーのプログラマが、特定のプロジェクトにジョイン・・・（笑）、いや参加する場合、よほど特別な場合を除き、権利関係はデフォルトではこの条文が適用されている。
いわゆる職務著作というもので、この場合の著作者財産権は文句なしにそのプロジェクトを企図した法人だ。
問題は著作者人格権だが、職務著作が成立した時点で著作者人格権も法人が所有するという解釈も存在する。実務的には、参加するコーダーに事前に「著作者人格権を行使しない」旨の契約を取り交わしておくことで法人所有にしておくプロジェクトが大半ではなかろうか。（ここら辺の情報は検索するとたくさん出てきます。事前取り決めが曖昧だと外注業者などがソースコードを勝手に公開しても咎められない、というたまに世間を賑わす事態になる）

で、OpenDolphin/OpenOcean の文脈に話を戻すと e-Dolphin の時代から、このプロジェクトは職務著作的な取り扱われ方をしていたと思う。
例外は、参加者が後で学会発表などで使いたいというような場合で、コーダーがそのコードを書いた瞬間から著作権が法人に移ると考えると、公表権を行使してそれを主題に学会などの公的な場で広報することができなくなるという不都合が生じる。これを避けるために（内的な「別段の取り決め」などで）その箇所だけコーダーの著作者人格権を残しておくということはある。
思うに Junzo SATO さんの件はこれだったのではないかと思う。

だから、OpenDolphin は、「職務著作に GPL を適用したプロジェクト」とみなすと実態に近く、また興味深いとも思うのだが、怪文書には残念ながらこの視点は全くない。

怪文書に限らず、法曹資格を持たない「オープンソース評論家」が取り扱う OSS ライセンス論は、法的な側面を軽視したものが多い。
が、これはかなりおかしい。
現在、ほとんどの近代国家は法治主義であり、日々の生活の営みの国レベルでの基本的な秩序を定めているのは法だ。つまり、書いたり、歌ったり、プログラミングしたり・・・の権利関係を定めているのは、日本の場合は、著作権法や締結された条約ということになる。
が、プログラミングに関係する領域で著作権法を尊重し過ぎてしまうと、ソースコードの２次利用がしにくい、などの不都合が生じる。そこで考え出されたのがコピーレフトという概念で、文書としてある程度体系的にまとめられたものが OSS ライセンスだ。だから、OSS ライセンスは著作権法下での「使用許諾」（最近は 「使用許諾」+「契約」）と考えると理解しやすい、と大半の初学者向けのテキストには書かれている。
しかし、細かな議論になると、なぜか、この基本事項を忘れてしまう「評論家」が多い。

 

（適宜加筆修正）

 

air-h-128k-il

投稿日:

OpenOcean 怪文書

もう終わったことだろうと思っていた OpenOcean 騒動だが、小林慎治の書いた怪文書がどこぞに転載されているようだ。

今となっては、彼のいうことを真に受ける人はいないと思うが、さすがにこれは反論しておいた方がいいと思ったので、そのための記事をいくつか公開している。

『OpenOcean 騒動』

『小林慎治氏の OpenOcean に関する事実誤認』

『OpenOcean が GPL 違反？』

あたりをご参照ください。

怪文書ではおかしな論理を振りかざしているが、根拠となるようなものはひとつしかない。
LICENSE の

(C) 2001-2011 Kazushi Minagawa

という表記だけだ。
この主張自体、ログイン画面の (C) 表記（(C) Life Sciences Computing Corp など）と一致していない、という意味でまるっきり整合性が取れていない。

おそらく会社（LSC）的な著作権の取り扱いはログイン画面の著作権表記が示すように「業務著作」に過ぎず、（具体的な形式までは決めていなかったが）この表記を「運営元がわかるように換えてくれ」というのが OpenOcean を公開するにあたっての LSC からの注文だった。
ひょっとすると、当時、LSC がドルフィンを皆川和史から取り上げたかったという事情があるかもしれないが、それはわれわれの知りうることではなく、7 年前の著作権表記を盾にわれわれを思うように扱っていいということにはならない。
dolphin-dev の GPLv2 と GPLv3 の不一致に関しても同様で、これもわれわれの知りうることではなく、そんなに知りたければ、まずは（当時の）LSC に確認してくれとしか言いようがない。

個人的に気に入らないのは、「評論家」とか「コミュニティ」とかの胡散臭さ。
最近では、法曹資格を持ちながら IT にも明るいという人材が増えてはきている。こういう人がコミュニティにいて、動向を窺いながら開発陣に助言をしてくれる、というなら理想的だが、小林慎治はこういったタイプではない。
ドルフィンに限らず、オープンソースでは各種情報が公開されているため、何事かは主張しやすい。だが、間違った解釈に従って利己的に自説を述べ立てるだけの人はいらないのだ。
われわれと後期 LSC との関係は、（メドレーに移行する前までだが）うまくいきかけていただけに極めて残念だ。

 

air-h-128k-il

 

投稿日:

著作権法違反が疑われるコメントの掲載はできかねます

当サイトに限らず、いくつかのHPを管理している身としては、記事へのコメントなどの投稿は歓迎していますが、内容に関わらず社会常識的に不適切なものは公開できません。

一般に twitter など SNS でアニメや漫画のキャラをアイコン・アバターにしているケースは散見されますが、著作権者からの許可を得ていない場合の使用は厳密には著作権侵害にあたります。
（一般向けのわかりやすい解説がこちらにあります）

HPを管理している側からすると、投稿者が著作物の使用許可を管理団体などから受けているかどうかのチェックをすべて行うのは現実的には不可能です。
このような投稿は内容に関わらず公開はしません。

また、公的機関に所属している方の場合、その機関が保有するインフラを介しての投稿も避けてください。

所属組織の公的な見解なのか個人的な意見なのか、コメントだけからでは判断してみようがないからです。

例えば、以前に以下のようなコメントが京都大所属（当時。保健医療科学院をへて現在は岐阜大）の小林慎治という人からありました。
「公共に益する」といった表現などからさも所属組織の公式見解のような印象を受けます。

ですから、このような場合には、
・京都大の IP アドレスから送信されているため、これが京都大の公的見解なのか
・その上で京都大がこのアイコンの使用許可を得ているのか
調べる必要があります。
この作業には、それなりの労力がかかりました。
内容的に吟味する前に、形式的に違法性がないか確認するだけでこれだけの手間がかかるわけです。

内容に関してはここでは細かい話はしませんが、一般に知的財産権（著作権も含まれます）と言われる事柄に関することです。コメントの「公開」を要望されても、そのコメント関連情報が著作権法的に違法が疑われる場合は、当然ですが掲載・公開はできません。

以上、よろしくお願いします。

 

air-h-128k-il

 

その他、『OpenOcean 騒動』などもご覧ください。参考になると思います。

投稿日:

GitHub から GitLab へ

git のホスティングサービスは GitHub だけではない。
GitLab というサイトもそれなりの趣きがあるという話だったので、試しに OpenDolphin-2.7m を
GitHub: https://github.com/Hiroaki-Inomata/OpenDolphin-2.7m
から
GitLab: https://gitlab.com/Hiroaki-Inomata/OpenDolphin-2-7m
に移動させた。
GitHub のアカウントを持っていれば比較的簡単にできるので、ちょっと触ってみたいという方は試してみてはいかがだろう。

なお、DolphORCA は、一時期、github でソースを公開していたのだが、現在はバイナリのみ公開している。
https://github.com/Hiroaki-Inomata/DolphORCA-back-binary

 

猪股弘明　医師

投稿日:

ORCA Plus から OpenOcean へ

ORCA Plus というレセコン ORCA のユーティリティソフトをつくっているついでに、電子カルテっぽい画面をつくってみたら、意外に好評だった。
いや、まだ、ビュー（ブラウザ画面）しかつくってないんですが (^^;)

 

ブラウザ上で動く WYSIWYG のエディタを実装するのが若干面倒だが、参考になるコードはネット上ではよく見つかる。それほど難しくはない。これにしてもボタンを押したらパーンとポップアップで出現する、みたいな演出入れないとダメかと思ったが、こんなものでも許されるようだ。

さらに日本だとフロンエンドをやれる人は多いと思うので、私が何も細部まで凝る必要もなかろう。

こういった画面がサーバに繋がり、適宜データベースと連係して一つのまとまったシステムになるように持っていくのが私の次の目標かな。

（追記）結局、WYSWYG のエディタは自前で実装。

OpenOcean は DolphORCA プロジェクトに統合されそうです。

 

 

 

猪股弘明（医師：精神科、精神保健指定医）
HorliX, OpenDolphin-2.7m 開発者

 

投稿日:

Java の現在

Red Hat replaces Oracle as OpenJDK 8, OpenJDK 11 steward

OpenJDK に関する記事。北米の業界の方々のコメントが色々載ってます。

Java ちょっと前は好きだったんだけど、なんか微妙な感じになってるようですね。なお、Java は
初期は SUN が旗振り
→が、オラクルが買収、有償化の方針を打ち出す
→Red Hat がオープンソースとしてサポートを意思表明（←いまここ）
という経緯をたどってます。

悲観的なコメントで〆られているあたりがなんとも。

steward はオタ的には「執事」でしょうが、この場合は「世話人」・「監督係」的な意味合いでしょう。


（追記）元記事が少々おかしいのではないかと何人かの方からご指摘を受けました。（コメント欄を参照してください）確かに replace は言い過ぎなようですね。
現時点（2019/04/23）での、各ベンダーから出ているディストリビューション・有償/無償モデルに関して @u-tanic さんがまとめています（↓）。

JDKの長期商用サポート(LTS)の提供ベンダー比較（無償利用についても言及あり）

参考にしてください。

（追記２）と、正統派の方々は上のように言ってましたが、SE 環境に関しては各ディストリビューションによってけっこうバラつきが出てきました。
EE 環境に関しても実装のクセがあって、例えば、アプリケーションサーバー上での挙動が微妙に異なってたりします。
もちろん、Java の仕様からの大きな逸脱はないんですが、元々の開発元の手を離れれば、こうなること（配布元によって機能の差が出てくること）はある程度は予想できたことで、それを個人の願望で否定するというのは、ちょっとどうしたものなんでしょう？
しかも図々しくは、上に挙げた方は自説を記事トップに配置するように示唆していました。
そんなに自説を強調したいなら、自分のブログなりなんなりでやればいいだけの話です。
単なる個人の願望を他人に強要するのはおかしいですね。