OpenOcean/Dolphin licensed by GPL

ワイもよくわかってなかった OpenOcean/Dolphin のライセンスの話。

OpenDolphin というのは、GPL でライセンスされたオープンソースの電子カルテ。OSS ゆえ fork が行われてその中で最も有名なバージョンが猪股弘明先生(現役精神科医)の OpenDolphin-2.7m。商用 dolphin が次々にオープンソースの旗を下ろしていくなか、現在でも「オープンソース」として開発が継続されている(最新版は OpenDolphin-2.7.3m)。
実際に普及したのは、2.7m からさらに fork した OpenOcean(air-h-128k-il 名義)。

普及したゆえの妬みなのか小林慎治という人が「OpenOcean は GPL に違反している」という記事(内容が内容ゆえ「怪文書」などと呼称されている)を 2018 に公開。
一時期、皆川や増田が同調したようなのだが、彼らがほぼ自滅(開発失敗)したため、現在(2026)誰もこの考えを支持している人はいないっていう状況になっている。
正直、支持する云々以前に、怪文書の存在自体、dolphin との付き合いが長い人以外は、誰も知らないと思う。(ワイも知らなかった)

で、怪文書のいう違反の根拠は LICENSE 文書の (C) 2001-2011 Kazushi Minagawa, Digital Globe という一行のみ。
2011 までの著作権がなんで 2018 にも有効なのかわからないが、小林は (C) Kazushi Minagawa だけ切り取って怪文書内で根拠としていた。
ただ、確かに LICENSE だけ、(C) 2001-2011 Kazushi Minagawa, Digital Globe という表記になっているのは、不自然ではあった。
(この箇所以外は (C) LSC という妥当な表記)

最近になって、結局、皆川和史が元の (C)Life Sciences Computing という表記を (C)Kazushi Minagawa, Digital Globe と自分に都合よく改ざんしていた事実が発覚。
皆川の能力を疑問視していた人は多く、大方の反応は

あー、やっぱり(笑)。

だった。
これで、この件の顛末は腑に落ちたと。

ただ、いい機会なので Dolphin/Ocean について思ったことをまとめる。

皆川和史による LICENSE 文書の改ざん

まずは、皆川和史が行なった改竄の確認。

こういうものの確認には GitHub のコミット履歴が便利だ。
上の図は、https://github.com/dolphin-dev/OpenDolphin/commit/ba93b8aaa76175376c1119bcdc4c975ae12cf2de から取ってきている。行頭の – が削除された文言、+ が挿入された文言です。
一見してわかるとおり、OpenDolphin Lab, Life Sciences Computing という当時は適切と思われる表記を Kazushi Minagawa, Digital Globe などと自分に都合よく書き換えている。
更新日が 2015/8/8 というのにも驚かされる。この時点での運営元は Life Sciences Computing で Digital Globe という会社は存在していない。自分が管理していた時代の v2.2 にバージョンを変えているのもいやらしい。これは、これより後にアップデートされた dolphin であっても、自身が開発に関係した v2.2 の直系だと言い募るための布石でしょう。
事実関係を言えば dolphin が普及し始めたのは LSC に運営が移ってからの v2.4 以降だから、むしろ皆川の影響が薄れていってからの方が普及している。

このアプリの他の著作権表記は全て (C) LSC などとなっているため、GitHub の編集権を持っていた皆川の LSC への抵抗と解釈できるでしょう。(皆川の Digital Globe 社は 2012 年末に LSC に吸収合併)

でも改竄は改竄。

小林は怪文書の中で「Kazushi Minagawa を air-h-128k-il にしたから GPL 違反」と主張しているが、その Kazushi Minagawa 表記自体が改竄されているのだから、根拠の前提が根こそぎ崩れているわけです。
これが小林怪文書が「怪文書」と呼ばれる所以です。

ここまで書いたので、dolphin の胡散臭さについて語りましょうか。

増田茂(医師)という虚構

2012 年頃から dolphin は「現役医師がつくった」と宣伝されるようになったが、その時に脚光を浴びたのが和歌山増田内科(当時)の増田茂医師です。

しかし、現在(2026)増田医師の X アカウントとされていた @masudanaika は、自分が医師だとは名乗っていません。
アイコンは烏賊ですし、表記も masudana_ika と医師のパロディを装っています。

もはや、自分でも「現役医師がつくった電子カルテ」という物語の役割を担うことを放棄しているわけです。
しかし、下手したら医師法違反で訴えられかねない広報戦略をよく取ったなと思いますね。広報内容自体も虚偽広告や誇大広告に該当しそうだし。
小林怪文書ではなんの疑いもなく「現役医師」として紹介されているので、こういうところも小林の主張が信用されていない理由の一つでしょう。

最近言われているのは、こういった宣伝目的以外にも彼の存在は「皆川 dolphin の延命目的だったのではないか?」という説です。

というのは、いわゆる増田ファクトが(Digital Globe 時代の)v2.2 fork だから。
こちらのバージョンが普及すれば、法人のプロダクトとは無関係に自分の権利が保持されるという理屈です。

実際には、Java8 で実質開発が終了していますが。

彼らから見た 2.7m

「皆川和史の dolphin の私物化」という切り口で見ると、彼らがなぜ執拗なまでに「2.7m は 2.3m fork だ」と主張していたのかもクリアカットになります。
仮に fork 順が

2.2(Digital Globe 時代に開発) → 2.3m → 2.7m

だとすると、皆川の著作権はこの順で継続され、保持されます。

もちろんこれは妄想レベルの捏造で、実際は 2.7 → 2.7m。
ソースコード嫁』という記事で徹底的に批判されています。

逆に「皆川・小林・増田らはソースコードが読めない」という彼らのスキルの低さが明るみに出される結果となっています。余計なこと言わなきゃいいのに。

GPL 違反を指摘した側が返り討ちを喰らったケース

結局のところ、怪文書騒動は、コミュニティの名目で「GPL 違反」を主張していた側が、開発側の詳細な反論にあい、返り討ちを喰らったケースでしょう。

「GPL 違反」というのは人目につきやすいタイトルだが、著作権者ではない第三者がその主張を維持していくのは難しい。ocean 開発陣から詳細な反論が公開された後、その反証は全くなされていない。理屈の上では、違反を指摘した側が違反の証拠を提示していく必要があるから、これはもう決着がついた問題として取り扱うの適当だ。

汎用性の高いライブラリでは監視者も多くこういうことはおこりにくいが、ニッチなアプリでは似たような事例は起こりそうです。

オープンソースに関する活動は善意に基づくボランティア行為と受け止められがちだが、商用にも供され、企業活動と連動しているような場合、犯罪性を帯びることも十分ありうる。また、参加するのに特別な資格がいらないという特性ゆえ「コミュニティ」の名の下、関与の薄い第三者が、GPL などの OSS ライセンスを独自解釈して関係者に違法行為を教唆し、不当な利益を享受する道も開かれている。
これらの点には十分な注意が必要だろう。

OpenOcean 怪文書 -GPL 誤用による違法行為教唆- 

その通り。

参考

OpenOcean 怪文書 -GPL 誤用による違法行為教唆- 
数ある反論系の記事の中ではナンバーワンでしょう。

OpenDolphin と職務著作と GPL
小林が根拠にした (C) Kazushi Minagawa, Digital Globe という表記を著作権法に従って素直に解釈するなら、Digital Globe 社の職務著作でしょう。
なんで、この表記から「dolphin は、皆川の個人著作」になるのか意味がわからない。
しかも、それは改竄されたものだったってオチだし。恥の上塗り。

goody 版 opendolphin
Ocean 開発陣がネットから発掘してきたもう一つの dolphin。e-dolphin という同一起源を持つ goody 版 opendolphin。MIT ライセンス。
・LSC dolphin と似通ったコードがあるが、こちらの author 署名はほぼ「ない」。
・更新がかなり早い段階で止まっており、そのため e-dolphin 時代のコードをかなり強く保存していると考えられる。
これらのことから、Digital Globe や LSC の dolphin のソースコード上での author 署名は e-dolphin 時代のコードに author Kazushi Minagawa という表記を追記したものだということが推測されている。

 

【無料】OceanMini とソースコードの2次利用【電子カルテ】

私もちょっとお手伝いしてきた OpenOcean 系列の最新プロジェクト OceanMini だが、先日(2025/11/14)、パイロット版とでもいうべき、Ver 1.0.0 が公開された。

ここから機能が爆速で追加され、2025/12/13 現在では Ver1.0.7 になっている。

あ、まだ一月経ってないんだ。。。すげ。

OceanMini 自体は電子カルテとして使えるのだが、私がすぐに使うものではない。

興味あるのは、ウェブフレームワークとしての使い勝手の良さ。

関係者も驚いていたが、ウェブサーバーってこんなに簡単に扱えるものなんですか(笑)

ありがたいことにコンソーシアム開発方式の良さが出て、私は、このソースコードにアクセスできる。

ソースコードの2次利用に関しては、訊いてみたら「勝手にオープンにするとか、そのまんまの形で使うのでなければ、好きに使ってもらってけっこう」だそうだ。ありがたい限り。
だから、サーバー部だけ切り出して、他のアプリに転用するとかは全然OK。

すぐに思いつくのはブログとかだろう。

全然、いける(笑)

私がパッと思いつく応用例は、andoroid スマフォ→ Mac 間のファイル転送用のサーバかなあ。
あれは適当なアプリがなく、いつも困る。

参考

Mac でウェブフレームワークというと Vapor というプロジェクトが有名なようだ。
入門・解説記事もそれなりに豊富。(これとかこれとか)
ただし、こちらは Swift ベースで、Objective-C に慣れている身からすると手を出しにくい。
流石に Vapor に触れておかないと片手落ちだと思うので言及しました。

ただし、OceanMini は Objective-c で書かれていると言っても、pure C/C++ を強く意識した実装になっている。
実際、移植はされていて(公開はされていませんが)Ubuntu 版や win 版もあります。

電子カルテとしての OceanMini

とってつけたようで申し訳ないが(笑)、電子カルテとしては ORCA 連動型というやつで WebORCA というレセコンと連動して動作する。
Vector でも無料で公開されているので、興味ある人は使ってみては?と思う。
軽量スタンドアローンアプリと思いきや、外来・訪問診療・入院機能まで提供されているので「どうせ、無料ソフトだから・・」と舐めてかかっている人はカルチャーショックを受けると思う。

 

J2ObjC は使えるか?

Java プログラムを Objective-C プログラムに変換してくれる天下のグーグル謹製プロジェクト J2ObjC 。

興味を持ったので試してみた。

何はともあれビルド。

ビルド

公式のページに従う。

注意点としては・・・。

PROTOBUF_ROOT_DIR=/usr/local

を .zprofile あたりに追記。この時に

PROTOBUF_ROOT_DIR='/usr/local'

とやってしまうと文字列と判定されてしまうので、ビルド途上でおこられます。

並列ビルドも失敗しやすいようなので、まず

make -j4 dist

と最低限のコンパイルを片付けてしまい、必要に応じて

make frameworks
make all_frameworks

とするといいと思う。

Hello World

ビルドはとんでもなく時間がかかるので、すぐにできる j2objc, j2objcc を使ってハロワしてみよう。

公式ページにある Hello.java

public class Hello {
  public static void main(String[] args) {
    System.out.println("hello, world");
  }
}

j2objc Hello.java

すると同名の .m ファイル(Hello.m)ができる。


#define J2OBJC_IMPORTED_BY_JAVA_IMPLEMENTATION 1




#include "Hello.h"
#include "IOSObjectArray.h"
#include "J2ObjC_source.h"
#include "java/io/PrintStream.h"
#include "java/lang/System.h"



#if __has_feature(objc_arc)
#error "Hello must not be compiled with ARC (-fobjc-arc)"
#endif

#pragma clang diagnostic error "-Wreturn-type"
#pragma clang diagnostic ignored "-Wswitch"


@implementation Hello

J2OBJC_IGNORE_DESIGNATED_BEGIN
- (instancetype)init {
  Hello_init(self);
  return self;
}
J2OBJC_IGNORE_DESIGNATED_END

+ (void)mainWithNSStringArray:(IOSObjectArray *)args {
  Hello_mainWithNSStringArray_(args);
}

+ (const J2ObjcClassInfo *)__metadata {
  static J2ObjcMethodInfo methods[] = {
    { NULL, NULL, 0x1, -1, -1, -1, -1, -1, -1 },
    { NULL, "V", 0x9, 0, 1, -1, -1, -1, -1 },
  };
  #pragma clang diagnostic push
  #pragma clang diagnostic ignored "-Wobjc-multiple-method-names"
  #pragma clang diagnostic ignored "-Wundeclared-selector"
  methods[0].selector = @selector(init);
  methods[1].selector = @selector(mainWithNSStringArray:);
  #pragma clang diagnostic pop
  static const void *ptrTable[] = { "main", "[LNSString;" };
  static const J2ObjcClassInfo _Hello = { "Hello", NULL, ptrTable, methods, NULL, 7, 0x1, 2, 0, -1, -1, -1, -1, -1 };
  return &_Hello;
}

@end

void Hello_init(Hello *self) {
  NSObject_init(self);
}

Hello *new_Hello_init() {
  J2OBJC_NEW_IMPL(Hello, init)
}

Hello *create_Hello_init() {
  J2OBJC_CREATE_IMPL(Hello, init)
}

void Hello_mainWithNSStringArray_(IOSObjectArray *args) {
  Hello_initialize();
  [((JavaIoPrintStream *) nil_chk(JreLoadStatic(JavaLangSystem, out))) printlnWithNSString:@"hello, world"];
}

J2OBJC_CLASS_TYPE_LITERAL_SOURCE(Hello)

おお、Objective-C じゃん!

次に

j2objcc -c Hello.m
j2objcc -o hello Hello.o

として実行バイナリ hello をつくる。

% ./hello Hello
hello, world

おおお。

Java リバーシアプリを iPhone アプリに

そうこうするうちに dist フォルダに生成物ができていたので、これを利用して Xcode プロジェクトのサンプルを試してみた。
公式が Java reversi プログラムを Xcode 上でビルドするサンプルを紹介していたので、これにトライする。

ほぼそのままで動きました。

JRE.framework を JRE.xcframework にするくらいの変更でOK牧場。

すげ。

 

 

(続く)

 

曖昧な日本のユーザー

私の所属する会社(休眠がちだが)は、集まったメンバー(学生バイト含む)の仲がよく、とてもよくまとまっていると思う。
この点に関してはなんの不満もないのだが、リリースしたソフトのユーザーについては、なんの不満もないかと言われるとちょっと微妙。

お行儀の良いユーザーたち

ユーザーに関しては、一般的な水準で見れば良質だとは思う。なにしろクレーマーのようなユーザーは一人もいなかった。みんな、お行儀よい。おとなしいと言っていいかもしれない。
無い物ねだりかもしれないが、おとなしすぎて物足りない感じは正直ある。

例えば、OpenDolphin-2.7m 系列(ただし、これは代表のまったくの個人制作)に関しては、最近のユーザーの関心はもっぱらデータ移行だろう。
具体的にどことは言わないが基本設計自体がもはや古臭く、新規の導入は勧めていないし、私たちの興味も「標準型電子カルテ」を意識した新規のシステムに向かっていて、実際、2.7m シリーズはメンテ程度しかやっていない。
だから、データ移行の必要が生じた際には「◯ヶ月程度を目処に、XXという電子カルテ向けにデータコンバートしてほしい」と明快に意思表示してもらわないと動きようがないのだ。準備にもそれなりの時間がかかるのだから。
どうも見ていると、OpenDolphin HTML/PDF Viewer あたりをばら撒いてくれることを期待しているようなのだ。
あちこちで「できない」とはっきりと言っていると思うんだけど?

Q4 データ移行ツールのバイナリ・ソースコードなどは配布・公開しないのか?

A4 これ、過去に商用開発元の方から似たような要望を受けたことがあります。 一瞬、私もそうしようかと思いました。が、

OpenDolphin のカルテを途中経過版も含めて一括書き出し

→途中経過版の一部を削除など加工

→加工したデータを再度、OpenDolphin などの電子カルテデータベースに戻す

という使い方をしてしまうと立派な「改竄」ツールになってしまうので、思い直してやめました。”

OpenDolphin-2.7m(系列)FAQ』より

これはおそらく
・以前に実行可能なファイルバックアップシステム付き OpenDolphin-2.7m クライアント
(いわゆる OpenOcean クライアント)を無料で配布した
・オープンソースプロダクツに「無料」というニュアンスを強く感じている
から、「どうせ、そのうち無料で配布してくれるんだろう」と安心しちゃっているからなのかなあと思う。

大事なことなので2回言いますが、ないですよ。

あとメンズ陣がたまに言うには「全然、勉強してないし、その痕跡も見せない。作業現場に来て暗い感じで、突っ立っているようなものなので、何も言葉がかけられない」んだそうだ。
ここら辺は、彼らはシビアだ。

与えられることに慣れすぎていると・・・

私たちのグループに専業従事者は一人もいない。

だから、ユーザーが反応してくれない箇所などは最悪放置すらあり得る。

日本のユーザーは、成熟したメーカーのそれなりによくできた製品(尖った部分はないが全体として80点みたいな製品)を使うことに慣れている。サポートも手厚い。
私の個人的な印象かもしれないが、アメリカはここら辺はかなり違う。
名もなきベンチャーのピーキーな製品がしれっと販売され、一般市民もそれにチャレンジする。いかにダメな部分があろうが、魅力的な機能があれば、その製品のファンになってくれる。

このような消費行動の差が、日本のユーザーの一種の甘えにつながっているのかもしれない。

人生の多くの場面で当てはまることかもしれないが、「与えられることに慣れすぎている」と何かを失うのかもしれない。

 

AXIA