OpenOcean 感想戦 -オープンソースと犯罪幇助・教唆-

まさか 2025 年にもなって OpenOcean の話をするとは思わなんだ・・・。

OpenOcean というのは、われわれが 2018 年に公開していた OpenDolphin 由来の電子カルテだ。
「OpenOcean は GPL 違反をしている」という主旨の記事がネット上で(再)発見されたため、反論の意味を込めて当方も記事を書く必要があったのだ。
反論系の記事はいくつか書いたが『小林慎治氏の OpenOcean に関する事実誤認』が一番まとまっているでしょうか。

「LICENSE 文書の (C) 表記が Kazushi Minagawa から air-h-128k-il になっている」というのが GPL 違反の根拠なのだが、当方が精査した結果、その LICENSE 文書の (C) 表記自体が Life Sciences Computing Corp という本来の著作権保有主体から Kazushi Minagawa に当の Kazushi Minagawa 自身の手によって改竄されていた、ということが判明した。(GitHub 関連 issue はこちら

図式的に書けば

彼らの主張:Kazushi Minagawa → air-h-128k-il

実際:Life Sciences Computing Corp → Kazushi Minagawa(改竄後) → air-h-128k-il

ということになる。

それほど声高に主張する気はないが、小林慎治のやったことは、私的文書偽造(改竄)の共犯みたいな位置付けになるはずで、どうするんでしょうね、これ。
われわれにしても彼らの要求を呑んでたら、業務上横領とかの犯罪の片棒担がされてた可能性もあるわけで(後述します)、今になってけっこう戦慄している。

それはともかく、この手の誹謗中傷に対する反論というのは、けっこう気を使う。相手の主張に対して過不足なく反論のロジックを組み立てていかないとそもそも反論にならないし、根拠も客観性が欲しい、主観的表現はなるべく使わない・・などなど。気にしなければならないことは多いのだ。

だから、そういった反論には書き切れないことがある。
感想や改善策といったことだ。

鬱憤も溜まっているので、ここではそういったことなど。
ああ、だから、推測なども含みますので、誤解なきよう。念の為。


オープンソースを隠れ蓑にした犯罪幇助・教唆

感想としてまず思ったのは、怪文書の主張の内容が poor で拍子抜けしたこと。

GPL やら著作権法やらを持ち出しててきているので、大層、物々しいロジックでそういう結論に達したかと思っていたのだが、よくよく読んでみると単なる (C) 表記だけの話。

これがなんといって良いやら・・。

フォーク元のクライアントログイン画面は図のようになっている。

ある程度わかっている人たちだったら、一見して「このアプリは LSC が著作権管理をしている職務著作によるものですね」になると思う。著作権法的にも GPL 的にも形式的にはまるっきり正しい表記法だ。

私だったら

職務著作に GPL を適用したら、個人としての著作権や GPL 的な author としての権利はどうなるのか?

みたいなオープンソース的な話にするかなあ。
怪文書にしても
「経営のためやむなく皆川は著作権を譲り渡したが、設計や実装では、XX をやったので、GPL 的な意味では author として認められるべきだ」
みたいな筋書きだったら、まともに検討したと思う。
われわれが後に Junzo SATO さんでやったことはまさしくそういうことなのだから。

有効性の疑わしい LICENSE の (C) マークを根拠に全ての権利は皆川のものだって犯罪者の論理でしょ。ジャイアンの理論といおうか。業務上横領を容認せよとかそういう話に聞こえてくる。犯罪の共謀の幇助の強要? 無理ですね。

実際、(C) Kazushi Minagawa は改竄でしたって盛大なオチもついているわけだし。

ところで、この話で思い出したのだが、リアルで LSC の人に会った時に、皆川さん、かなり否定的な評価のされ方をしていたこと。何もそこまでと訝しんでいたが、その答え合わせをさせてもらった気分ではある。
GitHub リポジトリの編集権を盾に会社のものを自分名義で発表されたら、そりゃ新しい会社経営陣は怒るよね。

自分たちで独自のプロジェクト起こせば?

けっこうよくあった感想は「なんで、皆川和史や小林慎治は、自分たちで独自プロジェクトを起こさなかったのか?」というもの。

単純にそこまでする能力がないってことなのか?と深く考えずにいたが、犯罪の構成要件みたいなことに思いが至ると話はガラッと変わってくる。

所属先の保有する財産を自分の手で配布したとなるとわかりやすい業務上横領になるが、オープンソースの著作物ということで、第三者が配布してしまうと彼らは手を汚さないで済む。

考えすぎだとは思うが、そうなる可能性もあっただけに怖い。

 

(続く)

OpeOcaen プロジェクトを代表して
air-h-128k-il

 

OpenOcean の怪文書

増田茂が書いたとされる OpenDolphin 関係の怪文書が某所で見つかり、反論の意味も兼ねて『いるかの怪文書』などが公開された。

関係者に聞いたら「小林慎治が書いた OpenOcaen 関係の怪文書もある」とのことだったので、読ませてもらった。

「いるか怪文書」とは違ってロジックがあそこまで支離滅裂ということはなかったが、主張内容がなんと言おうか・・・やはり、怪文書かな?


私がパッと感じた違和感は・・

・OpenDolphin は GPL である、というのが前提になっているが、その後の経緯を見ればわかるように、ほとんどのプロジェクトが 2018 年を境にオープンソースっぽさを失っていく。
この時期のいるか界隈のことは、私は詳しくないので、関係者からの情報発信を待ちたい。→『OpenOcean は GPL 違反?』、『小林慎治氏の OpenOcean に関する事実誤認』公開。

・README の主張を信用しすぎ。
Junzo SATO さん担当部分が再評価されてきて、ソースコード提供者が思っている以上にいることが判明しつつあった時期。著作権の問題をひとまず置くと、GPL でいうところの author は、README 記載の人物以外にもいることは明らか。 README を重視するのは不自然。

・同じ理屈で、ソースコードは全公開しておく方が適当。
まだ見つかっていない author がいる可能性があるわけだから、クローズドな形で publish しても意味がない。Junzo SATO さんの名前を出してない時点で「適切な著作権表示」とは言えない。
この観点からすると増田ファクトは GPL 違反。


これ GPL という枠組み取っ払うと「e-Dolphin の成果 + 職務著作」という内容。

職務著作の場合、個人名が著作権表記になることはほぼない。
問題になっている (C) Kazushi Minagawa は、職務著作とするとその表記はかなりおかしく、経営陣が変わった時に咎められた、と見る方がすっきりする。

(続く)

 

 

Save the DolphinS -OpenDolphin データ抽出ツール・プロジェクト-

久しぶりに電子カルテ OpenDolphin-2.7m(実質的には OpenOcean 0.0.1 と一緒)を臨床現場に投入するかもしれないということで、データ抽出ツールも数年ぶりにテスト稼働させる。
開発言語である Java のバージョンも上がっているし、まるっきり動かないかと思っていたら、そうでもなかった。

細かいところではもちろん不具合はあるのだが、データベース(PostgreSQL)に永続化されているカルテ記載内容を OpenDolphin を経由せずに取り出してくれた。
ちょっとほっとした。

なんで、こういうものが必要なのかは一般の人にはわかりにくいと思うが、電子カルテには縛りがあるためだ。具体的に気にかけておくべきは

・カルテ自体に保管義務がある
・電子カルテには3要件(真正性・見読性・保存性)が求められている
・3要件自体はガイドラインで罰則はないが、e-文書法(電子文書法)が適用される場合には罰則の対象になる可能性がある

の三つくらいだろうか。

ここらへんの解説は『OpenDolphin と電子カルテの3要件とメドレー』あたりを読んでみてください。

3要件のうち面倒なのは「真正性」というやつで、

電子カルテのデータを例えばデータベースに保存する場合、「誰が」書いたのか、その後「いつ、誰が」改変(あるいは消去)したのか、わかるような特別の仕組みをつくりこんでおかなければならない

とちょっとややこしい。
たいていの場合、ユーザーにシステム上の記録の「消す」作業に制限をかけることでこの条件をクリアしていると思う。こうしておくと、電子カルテ画面上である表現を削除したとしても、削除する前のバージョンは残っているので、データベース上にはこの一連の経過が残ることになる。
システムレベルで「上書き保存」ではなく「別名で保存」を採用しているといえば伝わるでしょうか。

だが、こういう作り込みをしてようやく「真正性」をクリアしたとしても、問題はまだ終わりではない。

何か問題がおこって、例えばカルテ開示を求められたような場合、そのカルテの(日付上は)最新の日時のバージョンを提示してもそれだけでは厳密にはカルテ開示したことにはならない。
想像つくかと思うが、医療者側に都合よくカルテ記載内容が書き換えられているかもしれないからだ。
この場合は、正しくは、通常使用では見えない状態になっている「消された表現」の部分も提示する必要がある。

実際、上の例でもこの患者さんのカルテは3件だが、途中経過版を含めると11件になっている。

MML 出力(という外部出力機能。ただし MML 規格はほとんど普及しなかった)を引き受けるサーバがない状態での OpenDolphin は、果たして電子カルテの3要件を満たしているのか?という疑問は実際よくあがっていた。

最近(2021 あたりからか?)では、保健所の個別指導あたりでもこの程度の開示は求められることがあるので、もはやこういった機能(途中経過版の抜き出し・修正履歴の出力など)の実装は必須だろう。

ローカルで稼働する OpenDolphin は、商用での開発が止まったため、自力運用する場合には、ここらへんの配慮をする必要があるのだ。

 

air-h-128k-il

(追記)データ移行ツールですが、出力形式を html・PDF にも対応させました。

ですが、これは保管・閲覧向きだと思うので、移行ツールから独立させ、OpenDolphin HTML/PDF Viewer という別のソフトとしました。
開発状況などは『OpenDolphin HTML/PDF Viewer プロジェクト』をご参照ください。

(追記2)Save the DolphinS としているから、一部ユーザーから全ての opendolphin 派生プロダクツを対象としていると思われていたようだ。
そんなことはない。
2.7 系列は基本上のアプリでうまくいくと思うが、それ以外はうまく動くかどうかはあやしい。
当たり前だが、データベースの構造自体が異なり、そのソースコードも明らかにされていないようなバージョンでうまくデータの抽出ができる保証はないからだ。
例えば、いわゆる増田ファクトは、動作保証外。
そもそもテストすらできないし、開発者とされていた増田茂自身がこの手のソフトは不要、と言い切っていたので、積極的に対象とする必然性もないでしょう。