松村哲理(元町皮ふ科)の件

小山哲央の件が出たので、ついでで松村哲理(医師。元町皮膚科院長 札幌)の件も。

この人も(なぜか小山ツィートと同じ 2019/3/19 に)おかしなツィートをしていた。

前後のツィートを切ってこれだけ取り出すとわかりにくいかもしれないが、彼が言いたいのは「ソースコード上の @author 表示を当方開発陣が本来の author から自分たちの名前に勝手に書き換えた。つまり

@author Junzo SATO を @author air-h-128k-il (例えばね)

に書き換えた」ということなのだと思う。

なんで、こういうこと言うかなあ。

もちろん、そんなことは一切していない。

OpenDolphin-2.7m にしても HorliX にしてもソースコードは GitHub 上に全公開している。
そんなに疑うなら、自分で調べればいいだけの話だ。

OpenDolphin に関しては、今まで README などにクレジットすらされていない author を当方が発見してその都度ブログや SNS などで情報発信すらしている。

中でも Junzo SATO (佐藤純三)氏に関しては、プロジェクト初期にはクレジットされているのにもかかわらず(下図参照。オリジナル魚拓はここ)、途中から、なぜか脱落していたため、ソースコード・機能の両面からその貢献度を調べ、かなり正確に(再)評価していると思う。

他にも funabashi 氏,  Kushiro 氏, miura 氏などのコーダーの名前をソースコード上で発見・適宜報告している。

こういった方々の存在を隠蔽していたのは、むしろ、皆川和史増田茂松村哲理・・・といった面々だったのではないか?

確かにある時期までは(プログラムに関する著作権法的な意味で)何らかの著作権は有していたのかもしれないが、メドレー譲渡以降は保持していないのだから、今となっては、少なくとも「自分たちのみですべてを開発した」といった主張は訂正した方がいいのではないかと思う。


ところで、彼の OpenDolphin に関するブログを見るといまだに以下のような表現をしている。

オープンドルフィンラボが物理的には LSC 社内に置かれていたとしても、名義的にはメドレーが保有しているわけだから、いい加減、訂正したらどうかと思う。

頑ななまでにメドレーへの譲渡を認めないのは不自然すぎる。


また、彼はこういったツィートもしている。

HorliX のリポジトリを探査したが(horlix 固有のオリジナルな)コードがないと言いたいんだと思うが、これは当たり前の話で、彼が参照している先は horos ブランチ。14件のコミットは Fork 元の horos 由来のマージだ。

horlixhoros から分離独立するときに、ある程度の連携を両者で保つために、horlix のリポジトリのブランチの一つを horos と同じにすることを「オープン」に取り決めている。horlix ではこれが horos ブランチになっている。

https://github.com/horosproject/horos/issues/342 より

この構成は、horos-horlix だけということはなく、Fork 元を上流ブランチとして設定するときにはかなり一般的に行われていることだ。

これが理解できていないということは

・Git ホスティングサイトを使った開発の経験がない
(Fork 元のない単独プロジェクトであってもプロジェクト内でブランチを切ることはしばしば行われるのだが?
今までどうやって開発してたんだろう?)

・この分野で慣例的に使われる英語が読めない

ことを強く示唆するもので、彼が書いたと称するコードの質と釣り合いが取れない。
以前から関係者の間では「松村哲理が開発したと称するコードの大半は他の業者の手によるものだ(業者開発コードを自分名義で発表している)」ということは噂話のレベルでは言われていた。
松村氏自身はそれほど開発者アピールをする人ではなかったので、私はこの手の話は耳にしても聞き流していた。だが、この手のツィートがあると、どうしてもこの噂話は本当だったと考えざるを得なくなってしまう。
現在の開発元のメドレーも松村氏の(著作権的な意味での)関与を認めていない以上、当方も今後はそのように取り扱うしかないであろう。

参考

・総合的な解説は『OpenDolphin -wikipedia風解説-』が詳しい。

・『ソースコード嫁』から類推するに、小林慎治皆川和史増田茂・・といった人たちは Java のソースコードをほとんど読めていないことがわかる。

・Twitter(X) アカウント @masudanaika は、実在の増田茂医師ではなく、関係の深い業者が管理していたのではないか?という推測が『@masudanaika による個人情報流出ツィート』でなされている。

 

 

小山哲央(アーク情報システム)の件

以前に小山哲央という人が OpenDolphin や OpenOcean ひいては開発陣へ誹謗中傷のツィートをしたことがあったのだが(ちなみに当方がこのツィートを発見したのは 2022年末)、諸々あってツィート削除などしてもらった。

しかし、待てど暮らせど正式な謝罪がない。

気乗りしないことだが、先日、かなり強硬な態度で「社会人ならちゃんとしなさい!」的な連絡をさせてもらった。ニュアンス、わかりますよね?

これに関しては、謝罪・訂正らしきものはあった。(アイキャッチ参照)

しかし、その文言はどうだろう?

>2019年3月14日にポストしたGPLライセンスのポストについて、
>ポストの削除をいたしました。
>コミュニティの是正勧告について第3者がコメントをすることは
>不適切な行為でした。
>お詫びすると同時に、今後はこのようなことがないように注意いたします。

確かに「お詫びする」とは言っているけど、じゃあ、元ツィートの「故意に」「違反」しただのといった一方的な攻撃的な表現や「一読をおすすめします」といった自分をさもオープンソースの権威かのように自認した上から目線の表現は何だったの?という話になる。
そこらへんの説明が一切ないから、この内容だと、(私の印象では)法的な意味で「名誉毀損」や「侮辱」に対処したことになってない。

詳しい知識はないが、「事実の真偽に関係なく社会的評価を低下させる」内容であれば「名誉毀損」にあたるはずですよね?

世代的な問題もあるのかそれとも他の理由があるのかわかりようがないが、必要最低限のことしかやろうとしない。

そこらへん、意識してやってるのか、無意識でやってるのか不明だが、やり取りを側から見ている関係者は徐々に呆れていってます。

主だった意見をまとめておくと・・・


法的な問題は置いておいても「第3者がコメントをする」といった表現も、責任逃れのような印象を受ける。
内容はオープンソースに関わる。
オープンソースは、その言葉が示す通り、ソフトウェアのソースコードは公開されている。この場合も Fork 元・Fork 先ともソースコードは全て一般公開されている。
両者の比較からリンク先の記事の論証は極めて甘いことはわかるし、小山自身が事実確認や検証を行うことは可能だ
しかし、この作業を怠っている
オープンソースの分野で何ごとかの判断を行いたいなら、まずはオープンソースの流儀に従って自分で検証するのが筋だろう。


実務的な意味でまずいのは、このオープンソースのプロジェクトが電子カルテだったという点だ。
電子カルテというのは、単純に動けばいいというものではない。種々のガイドラインで定められた基準を満たす必要のある極めて実用性の高いソフトだ。
そして、小山がツィートした 2019 頃には、Fork 先のプロダクツは改修が滞り気味で実務的な要求に応えられなくなってきた時期だ。
だから Fork 先の法人自体が「以前に著作権を主張していた人にはもう関与させていないし、今後も関与させるつもりはない。まずは、実務的な要求を満たす改修を優先したい。可能であれば協力してほしい」という方針を打ち出していた。
小山のツィートはこういった努力に水を指す行為だ。


「オープンソースの開発者や開発方式には敬意を払うが、オープンソース『信者』は嫌いだ」という人は多いが、その理由が今回の一件で分かったような気がする。

 

OpenDolphin Ver 6

ちょっと手が空いたので、OpenDolphin-2.7m を JakartaEE 9.1, java17 環境に移行した。

軽くまとめ。

 以下の記事内でも書いてますが Ver6.3 & 6.4 は例外的に Ver2.7m 系列の単純な JDK アップデートバージョンです。
だから、データ構造なども 2.7m と同一。それゆえ使いにくい側面もあったりするのですが(この記事参照)、カスタマイズする場合、こちらをベースにした方がいいでしょう。

主な変更点

主な変更点は二つ。

・画像の取り扱いの変更

・ウェブレイヤーの追加

まず、画像に関して。

これまで、画像の取り扱いが jpeg/png に限定されていたのだが、この制約を取り払った。

ただし、従来のデータベースとの互換性を保つため、jpegByte あたりのコードには直接変更を加えず、新規に画像保管用のカラムを加えた。

これまで、データ構造は LSC 時代の 2.7 と全く同一にしていたのだが、この変更でこの原則は崩れた。

ただし、API にはある種の追加はしたが、これまでのものを削除することはしなかったので、以前のバージョンのデスクトップアプリを使えば、使用感は変わらないと思う。

一種の上位互換。

API の追加は、まだ進行中。煮詰まってない。

画像のフォーマットは山ほどある。どこまでサポートするかは現時点では決められない。

次に、ウェブレイヤーの追加に関して。

以前から、「クライアントは Java デスクトップアプリである必要はない」ということは言われていたのだが、ではどう構成するのか?という具体的な議論はなかった。

個人的には、3層クラサバ化がいいのではないかと思っていたので、今回、OpenDolphin HTML・PDF Viewer をウェブサーバー化して、フロントエンドサーバーとした。

諸々の機能は実装中。

サーバーサイド

フロントエンドサーバーを加えたので、単に「サーバー」と言った場合、従来のサーバーと混同してしまう。

そこで、従来のサーバーを BackendServer と名称変更した。

クライアントサイド

前述のように、クライアントは従来のデスクトップアプリと新規に作成したフロントエンドサーバー(ブラウザタイプ)に別れた。

デスクトップアプリ

今回のアップデートが最後でしょうか。

フロントエンドサーバー(ブラウザ)

以前に dolphorca と呼んでいたものがこれにあたる。

名称

これまでにも、ノーマル 2.7-m ベースのいくつかのカスタマイズバージョンがあった。

例えば、以前に書いたように(『聴診音クラファンからの・・・OpenDolphin』など参照)、研究支援用のプロトタイプバージョンなど。

ところで OpenDolphin のアプリケーションサーバーといえば、WildFly がデフォルトである。
が、若干修正することで GlassFish でもデプロイ程度はできる(正常動作はしないが)。
こういったバージョンも存在した。

このように非公開のいくつかのバージョンがあって、バージョン番号はいささか混乱していた。

そういった経緯で今回移行したプロジェクト群を総称して(数字的には 2.7 から一気に飛ぶが) Ver 6 とした。

Ver6.3

諸々の事情で Ver6.3 のみ単純な実行環境のアップデート版とした。
(だから、データベースは 2.7m と完全互換。その代わり、クライアント起動時に JVM に特別なオプションを渡す必要がある)
Java17, JakartaEE 9.1 環境で動作する。

バイナリは関係者のみに配布。

ソースコードは github: https://github.com/Hiroaki-Inomata/OpenDolphin-6.3 で開示。

(追記)バイナリを配布したバージョンは 6.3.1 とした。
元が GPL だったとはいえ、このソースコードを一般公開するのは、実務的にはかなり難しい。
公開する準備はしているが。
https://github.com/Hiroaki-Inomata/OpenDolphin-6.3.1
現在著作権は、メドレーが保有しているからだ。
迂闊に公開してしまうと著作権侵害ともとられかねない。
ドルフィンの権利関係はスッキリとはしておらず、こういった場合には「オープンソースのライセンスがあれば、なんだって許される」といった幼稚な考え方は捨てるべきだ。