以前に『ソースコード嫁』という記事で
2018 以前の LSC と繋がりの深かった人々からおかしな非難をされていた。（略）彼らがいうには、Fork 順は
LSC Dolphin（いわゆる本家） → 2.3m（いわゆる増田ファクト）→ 2.7m （ワイのバージョン）
なんだそうだ。
正しくは LSC Dolphin(Ver 2.7) → 2.7m なんだが、それはソースコードを読めばわかる。
と書いた。要するにわれわれが公開していた OpenOcean というソフトの Fork 順が間違って紹介されてますよという指摘だ。
間違いの出所の一つは、小林慎治という人が 2018 年11月26日に書いた記事だ。
フォーク順以外にも事実誤認が多く、指摘しようかと思っていたのだが、記事自体が公開になったり非公開になったり、そうこうしているうちに内容が陳腐化し、そこまでする必要もないと思い放置していた。
が、「いるか怪文書」と同様、いかがわしめなサイトに転載されていたのを確認したので、反論「めいた」記事を書く。
「めいた」というのは、完全で網羅的な反論は手間暇の関係でできそうもないから。
彼は「事実」と「主観的評価」を混交して推論し間違った結論に至ることが多い。
正式な反論ならば、その一つ一つを吟味、つまり、その思考プロセスを素過程にバラして逐次訂正を入れていくのが好ましいのだろうが、それは作業量の関係でできそうもない。
例えば、上記の Fork 順をなぜ間違ったのか今まで不明だったのだが、（後で示すが） GitHub リポジトリに記録されたコミットの解釈を間違えていたからと今回判明した。
この思考プロセスは、私の馴染みのある分野でいうと「結論への飛躍（jumping to conclusion）」にあたる。Jumping To Conclusion、少ない証拠で結論に飛びつくこと。あれに近い。
この分析を文書全体にやるのは、とてつもない労力がかかる。
これは、裁判の精神鑑定ではないのだから、そこまではやらないし、やる必要もないだろう。反論「めいた」、というのはそういう意味だ。
ところで、その小林記事をなんと呼ぶのが適当なのかわからないが、「いるか怪文書」にならって、ここでは「OpenOcean 怪文書」や「怪文書」としておこう。
なお、air-h-128k-il というのは、私がその頃、頻用していたハンドルです。
OpenDolphin-2.7m のときは、ほとんどの作業を私一人がやったので Hiroaki-Inomata 名義で発表、OpenOcean では協力者がちょっぴり増えたので（例えば、OpenDolphin 関連本の担当ライターさん）、共同作業というニュアンスを出すために名義は air-h-128k-il となっています。
（注）以下、少々長いです。ポイントだけ知りたい場合は『OpenOcean 騒動』や『OpenOcean 騒動 #27』をお読みください。
1 OpenDolphin は GPL？
まず、その記事、全般的に「OpenDolphin は GPL でライセンスされたオープンソースソフトウェア」という前提で書かれているが、これは完全には同意できない。
実務的には、運営主体はメドレーに移ってからは、メドレー自身がかなりはっきりとオープンソースではないと言っている。
OpenDolphin は、2020 年に LSC からメドレーへの法人間での事業譲渡がなされたが、もし、個人に保護すべき著作権が残っていたとしたら、権利を含めた完全な事業譲渡はできにくい。権利を含めた譲渡が行われ、その上でメドレーはオープンソースをやめてしまったと解釈するのが普通だろう。（ちなみに、メドレードルフィンサポートページの表記は Copyright Medley, Inc. All rights reserved.）
色々いう人はいるようだが、結局のところ、権利的には「e-Dolphin 時代の成果 + 開発法人による職務著作」と考えていいと思う。
では、2018 年はどうだったか？といきたいところだが、2025 年現在の状況から話を始める。
2025
現在（2025年）からみれば、OpenDolphin のオープンソースっぽさはほとんどない。オープンソースの最大の特徴は「ソースコードが公開されていること」だと思うが、いくつかの個人や有志が、今でもソースコードを一般公開しているものの、商用プロダクツに関してはソースコードを一般公開しているところは一つもない。
一般公開しなくてもユーザーがなんらかの形でソースを入手できればよいという立場もあるのかもしれないが、ドルフィンの場合には特殊事情があってこれではまずいと思う。
というのは、GPL では author を publish する必要があるが、2025年現在でも表記すべき author は完全には見つかっていないから。
ある程度知られている事例は Junzo SATO さんで、彼の名前はソースコード上でかなり見つかる。
Panel2.java(client プロジェクト)
/**
*
* @author Junzo SATO
*/
public class Panel2 extends JPanel implements Printable {
private String patientName;
private boolean printName;
private int height;
/** Creates a new instance of Panel2 */
public Panel2() {
}例えば、上の箇所なぞ、クライアントをデバッグしていると必ずと言っていいほどお世話になる箇所で、基本設計も担っていたのでは？と推測されていたが、dolphin-dev のリポジトリでは全く言及されておらず、その正体は長らく謎のままだった。
その後の調べで（例えば、学会口演要旨。下図参照） e-Dolphin プロジェクトに参加していた佐藤純三さんであることが判明した。
ドルフィンプロジェクト初期の公式資料でもコーダーとして言及されている。
こういう事例が一つでも見つかると後は速い。funabashi, Kushiro,miura… などの author が次々に見つかった。が、これは主にデバッグ途上で見つけたに過ぎず、完全に網羅的なものではない（ただし、デバッグ途上で見つけたということは、ある程度の機能は担っており、使われてないクラスやメソッドのコード上の単なる署名ではない）。
「2025年現在でも表記すべき author は完全には見つかっていない」と前に書いたのはこういった事情による。
完全には見つかっていないのだから、GPL 的な要請からソースコードを一般に全公開しておいた方がいいと私たちは考えた。
こうしておけば、まだ見つかってない author がいたとしても、それを誰かが見つけてくれるかもしれないからだ。
その観点からすると 2025 年現在でも、ドルフィン派生プロジェクトでソースが一般公開されていないものはオープンソースとは言いにくいと思う。
「ドルフィンの場合には特殊事情があってこれではまずい」と書いたのはそういった理由による。
ドルフィンを GPL ライセンスによるオープンソースプロジェクトとして捉えても、完全に条件を満たしているか疑わしいのだ。少なくとも理想的なものとは言えないだろう。
2018
では、2018 年に戻ろう。
各種ドルフィンが、ソースの一般公開をやめてしまった発端は、2018 年の LSC （Life Sciences Computing）のポリシー変更にある。
われわれは OpenOcean を公開するにあたって、何回か LSC に問い合わせている。
最初は特に理由も教えられることもなく「許可する」という主旨の回答で、変にあっさりしているなと不思議に思っていたのだが、リアルで担当者に会った時に「経営陣が変更になったので、OpenDolphin の取り扱いを変える。LSC としてはGPL の旗を下ろす。派生プロジェクトには GPL 的な決まり事はできれば守ってほしいが、LSC がやめてしまった以上、厳密には従わなくていい。任せます。皆川・増田が言っていることは気にしないでください」という主旨のことを言われた。後で知ったことだが、GlassDolphin の中の人にも同様のアナウンスをしていたということだ。
経営陣が変わるとこうも変わるものかと驚いていたが、その後、LSC の GitHub リポジトリや GlassDolphin のそれの更新がプッツリと途絶えたことを考えると、かなり明確な意志・決断であったと思う。
何が言いたいかと言えば、2018 年にはフォーク元自体が GPL 的な取り扱いを実質的にはやめてしまっていたし、派生プロジェクトにも GPL 的な縛りを強要はしていなかったということだ。
怪文書が書かれたのは 2018 年末のことだが、2018 年にこういったことが水面下であり、そのことを小林氏は知らない。（か、知っていてとぼけている）
ところで、Junzo SATO 氏の 2018 年時点での評価だが、彼が遺したコードの重要性は認識されつつあったが、この時点では彼の素性は全くわかっていなかった。
ただし、この人の（再）発見によって、従来言われていたように「特定の人のみが開発に関与した」という皆川らの主張は、実際に改変にあたっている技術寄りの人たちからはかなり疑問視され始めていた。
ざっくり言えば、この時点でも「OpenDolphin は GPL でライセンスされた完全無欠のオープンソースソフトウェア」とはみなされていなかったと思う。
長々と書いてきたが、彼が採用した前提は、2018 年時点でも厳密には成立していなかったと思うのだ。
author
これまで漠然と author という単語を用いてきたが、この定義が難しい。GPL には author の明確な定義がないからだ。
日本の場合、著作権法的な制約があるので、概ね「法（著作権法）及び GPL の要請で保護すべき著作権的人格権を保有している開発者・コーダー」ということになるだろうか。
ところで、何を基準に表記すべき author とするかは見解の分かれるところだとは思う。
例えば、小林慎治氏は佐藤純三さんの仕事を重視はしていないようだ。
佐藤さんを揶揄嘲笑する上のような X の投稿がみられた。
@masudanaika の中の人も同様の発言をしていたと思うが、考え方・評価を変えたのか自分の投稿を削除している。
コーダーと評論家の感覚の違いと言ったらいいだろうか。
ここら辺は見解の相違だろう。
2 いくつかの反証
長々と書いてきたが、あとは、目についた順で反証などを挙げていく。
怪文書の表記がオリジナルと違うかもしれないが、それは転載されたサイトからとってきているから。
散々言われていると思うが、ネット社会では拡散された情報への対処の方が重要で、われわれが稿をおこしたのもそれが理由だ。
フォーク順の誤認
2018年6月7日air-h-128k-il氏が[Open DolphinのGitHub repository]:https://github.com/dolphin-dev/OpenDolphin からfork(正確にはforkのforkのfork)してOpenOceanと名前を変えたプロジェクトを立ち上げた。
正確には fork（2.7.0b → 2.7m） の fork（2.7m → OpenOcean） 。詳しくは『ソースコード嫁』を読んでください。
ここでの議論の大筋には関係ないから問題視しないが、これを信じた勢力が一部にいた。その点では非常に迷惑だった。
問題なのは根拠のあげ方。
根拠として挙げているのがこのコミット履歴なんだが、これはコミットツリーで表示すると一番の最初のコミット（first commit）。
それまで存在していたファイルにどういう改変を加えたかはわかるが、フォーク順まではわからない。ファイル内容とリポジトリに記録された Fork 元の情報から、一つ前の Fork 元まではわかるが、わかるのはそれだけで、それから先は原則わからない。
Fork の連鎖を辿っていけば Fork 順はわかるのでは？と思う人もいるかもしれないが、OpenOcean の場合はわからない。なぜなら、2.7m は GitHub 上で LSC 2.7 から直接 fork したのではなく、いったんローカルに置いた LSC 2.7 に改変を加えた 2.7m を GitHub にあげたから。
おそらくある種の先入観を元に Fork 順を脳内補完したのだと思うが、この思考過程ってなんなんだろうね。この表現が適当かわからないが、ある種の患者さんが示す思考プロセス Jumping To Conclusion に似ている。
著作権者 author の選定基準とその表記（場所）
他にも引っかかっているところはあるのだが、多分、彼が強調したかったのはここだろう。
OpenDolphinの原著作者は皆川和史氏であり、戸村(王)勝偉氏が共同著作権者として挙げられています。更に下記の著作権者が協力者としとREADMEに記載されています。
・札幌市元町皮ふ科の松村先生
・和歌山市増田内科の増田先生
・新宿ヒロクリニック
・日本RedHat Takayoshi KimuraさんのJBoss as7 へのポーティング
GPL3の ” appropriate copyright notice” は形式までは具体的に定めていないので、様々な表示形式が見られております。いろいろなやり方があると思いますが、上記はすべて著作権者であり、OpenOceanはOpenDolphinのソースコードの大部分を利用している以上、GPL-HowToに記載されているように上記著作権者をすべて適切に表示する必要があります
彼が認定している author は、上記の人々であり、それらは README に記載すべきだ、というのが彼の考えなのだろう。
われわれはそうは思っていなかったし、今でもそう思っていない。
README は、リポジトリのフロントページであり、多分に広報的要素が強く、リポジトリを訪れた閲覧者に知ってほしい特徴などを記載する場所だと思っている。
それは dophin-dev の README を書いた人も同様だと思う。
例えば「日本RedHat Takayoshi KimuraさんのJBoss as7 へのポーティング」は、このバージョンのドルフィンにはその痕跡は留めていない。そもそも 2.7 系では、JBoss as 7 自体使ってないので、これは過去のバージョンでお世話になった人への謝辞とみるべきだと思う。
author を正確に規定している場所ではない。
そして、前章で述べたように、README で記載されていないソースコード提供者の中に author と呼ぶに値する人物がいるとわれわれは認識していたので、小林氏の主張する書き方の流儀は採用できない。
一般的に、ソースコード管理が甘くなったプロジェクトでは、フォーク元のプロジェクトの主張をそのまま信用するのは不適当だ。
では、どういう方式が好ましいのかという話になる。
潜在的なプロジェクト参加者の努力に期待するしかないのだが、ソースコードを一般公開しておき、新規の author が見つかり次第、その旨をどこかで報告・記載していくのが適当だろうか。
われわれは、author 候補が見つかり次第、プロジェクト関連ブログで、その名前と提供されたソースコードの説明をつけ報告してきた。結果的に、Junzo SATO, funabashi, Kushiro, miura… といった author 候補を発見報告している。
見方によっては GPL が要請する著作権表示以上のことをやっているように思う。われわれはそれなりに努力してきたつもりだが、さてどうだろう？
適用条項の取り違え
ところで、彼は GPL3 の section 4（4条）、つまり
4. Conveying Verbatim Copies.
を根拠に自説を組み立てているようだが、これは「ソースコードを受け取った時の（そのソースコードの）伝搬時の取り扱い」を述べている部分であり、2.7m は 2.7 の modified version なのだから、根拠とすべきは、その次の section 5、つまり
5. Conveying Modified Source Versions.
の箇所だ。
そして section 5 では
This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
本ライセンスは、これ以外のやり方には作品をライセンスする許可を与えないが、あなたが本ライセンスとは別に許可を得ていた場合には、そのような許可を無効とするものではない。
と、フォーク先の許可を得ていれば、その許可は無効にならないことを述べている。
われわれは配布形態などに関してフォーク先から許可を得ているのだから、その許可の範囲内では「違反」になどなるわけもない。
(C) は著作権管理主体を表示するときにも使う
後で、加筆するかもしれないが、これはこの記事の「補足」や『OpenOcean は GPL 違反？』を読んでください。
簡潔に言えば、当時は「複数のドルフィンのバイナリ及びソースの開発主体・運営主体を区別するために (C) を使っていた」ということです。
まあ、職務著作と考えれば当たり前の話なんですが。
FSF も GPL FAQ で以下のように述べている。
The GPL requires the maker of a version to place his or her name on it, to distinguish it from other versions and to protect the reputations of other maintainers.
GPL は、別バージョンの作成者の名前を、他のバージョンと区別するために、かつ、他のメンテナの評判を保護するために、そのバージョンで表記することを要請する。（猪股訳）
このやり方は、2.7 系 dolphin の起源になった dolphin-dev のドルフィンでも採用されている。
ログイン画面は以下のようになっている。
(C) OpenDolphin Lab と (C) Life Sciences Computing Corp の両方を記載。
前者はひょっとすると著作権人格権の意味かもしれないが、後者は明らかに管理主体でしょう。どちらにせよ個人名ではなく組織名になっていて (C) Kazushi Minagawa にはなっていないことに注意。
一方、ソースコードの LISENCE では以下のように (C) 2001-2011 Kazushi Minagawa という表記になっている。
だが、16 行目に OpenDolphin version 2.2 とある。
これは皆川和史（GitHub 上でのアカウントは mbot-dev）が、ver 2.6 時代になぜか修正した内容で ver 2.7 の LICENSE ファイルとしては相応しくないものだ。 （詳しくは、この issue 参照）
ver 2.7 に有効な LICENSE ファイルは「ない」と考える方が自然だろう。
確かに README では、皆川和史が OpenDolphin の特徴などを述べているが、怪文書が言うように「原著作者」を示すようなことは実は他のどこにも書かれてはいない。所属する組織を代表して記載にあたる者と開発者・著作権者・author というのは、概念からして違う。
おそらくはフォーク元運営会社的には OpenDolphin は職務著作という扱いで、それを裏付けるように LSC からの指示は「運営主体がわかるように表示してくれ」というものだった。
後述するように OpenOcean はフォーク元から独立した派生ソフトと認められ、上の形式を踏襲した (C) 表示の許可を取っている。われわれはその指示に従ったに過ぎない。にも関わらず、GPL 違反や著作権法違反だと彼は主張する。
経緯を知りうる立場にない第三者にしては、行きすぎた行為に思える。
ガイドラインの軽視
ところで、怪文書を読んでいて気になったのは、以下の箇所。
百歩譲ってair-h-128k-il氏の主張が正しいと仮定したとしても、OpenDolphinはどこからどう見ても、 皆川氏の思想 を反映したものであり、それが認められないようでしたらair-h-128k-il氏が書かれた数十行程度のOpenOceanのコードも同様に著作権が認められることはないでしょう。
「air-h-128k-il氏が書かれた数十行程度のOpenOceanのコード」というのは、たぶん、私（猪股弘明）が OpenDolphin-2.7m で実装したファイルバックアップシステムのことだと思う。
この箇所は OpenOcean を試用した開業医の人たちからは評判がよく、あれはどうやってやったんですか？という問い合わせが多かったので、後で『OpenDolphin-2.7m コード解説 -FileBackUpSystem と電子カルテのデータ構造-』という記事を書いたほどだ。
保護するような著作権があるかどうかは置いておくとして、現在の電子カルテではこの機能に該当するような機能がないと安全性のガイドラインを満たせないはずだ。
いわゆる『安全性のガイドライン』は、 Ver5.2 から、システム停止時の見読性確保のためのカルテ閲覧システムの具備を要請している。
ファイルバックアップシステムでは、カルテ記載内容をユーザーホームの専用ディレクトリにプレーンテキストで強制的に書き出すため、これらを何処かに集めておけば、たとえ dolphin server が止まったとしても、直近の処置や処方内容はそこを閲覧すれば確認できる。
確かに 2.7 にも増田氏が実装したとされる PDF 出力機能があるのだが、残念ながら、Mac では文字化けする。
理工系に代々伝わる「UNIX という考え方」が無意識にあったせいか、こういう時にはシンプルで軽いプレーンテキストファイルがいいと直感的に思って、とにかく「軽く」動かすことを意識してそのようにした。
凝ったデータ管理は『移行ツール』（のちの HTML/PDF Viewer）でやればいいと考えていたのだ。
著作権云々は置いておくとして、ほんの数年後にガイドラインで義務化される機能の評価がいくらなんでも低すぎる。
経営陣が刷新された LSC の評価は、小林氏のものとは違っていて、こちらが認めてほしいと思っていた機能を高く評価してくれた。そもそも、電子カルテの３原則を満たしていないと、電子カルテとは呼べないのだから、ある意味当然だ。だから、2.7m や Ocean をオリジナル 2.7 とは異なる独立したプロジェクトと認めたのだ。
また、この箇所の言い回し自体がわかりにくく、ロジックが読み取れない。
・皆川氏の思想を認めるか認めないか
・ファイルバックアップの機能が意味のあるものかどうか
の二つは、ほとんど独立な事象で、なんでこれらの事象が連結しているのか理解できない。おそらくは、先に結論があったが、そこまで展開できず、ロジック自体が破綻したと思われる。
3 批判的検討
怪文書は、全般的にフォーク元の主張を無批判に認める傾向が強く、適切な批判とは言い難いものになっている。
いくつかの点をまとめる。
1 author 相当の人物は、皆川・増田・松村・木村… といった人のみで、それは README に書いてあるから、というのが彼の主張なのだが、これは以下の理由で適切とは言えない。
・ソースコード・文献・プロジェクト初期の公的資料などから、Junzo SATO 氏のような author 相当の人物が見つかるが、README では見つからない
（歴史的経緯から、author をソースコード上で探索するなどの工夫が必要だが、こういった作業を一切していない）
・README は、慣例的には当該プロジェクトの特徴などを広報する場所であり、この場所のみが author を表記する場所と考えるのは妥当性に乏しい
憶測になるが、素直に考えるなら、皆川和史が、佐藤氏をはじめとする e-Dolphin 時代〜初期 OpenDolphin プロジェクトの author を自分の名前で置き換え、README でそれを伏せて主張した、と考えるのが自然でしょう。
2 LICENSE 冒頭の (C) name が GPL 的な意味での author であると主張するが、ドルフィン（派生）プロジェクトにおいては、以下の理由で認めにくい。
・(C) は、著作権管理主体を表す場合があり、フォーク元のプロジェクト自体、
(C) Life Sciences Computing Corp や (C) Kazushi Minagawa
とこの表記方式を採用している。
・フォーク元がこの方式の許可を OpenOcean に与えているのだから、この方式に従った事実を持って「OpenOcean は GPL 違反」とするのはおかしく、もしそのような指摘をするのであれば、フォーク元の GPL 違反（違反というのがきつければ、ログイン画面と LICENSE 文書での表記の不一致）も合わせて指摘しないといけない（が、していない）
3 自らの言説を「コミュニティによる是正勧告」と位置付けるのだが、電子カルテのような限定的なソフトの場合、そのソフトの開発者コミュニティとユーザーコミュニティとが「コミュニティ」の基本単位と考えるのが適当だ。だが、氏は
・開発者コミュニティには加わっておらず、勧告を行うのに必要な情報が得られていない
のだから、怪文書が状況を適切に整理するという意味での適切な是正勧告とはとても言えない。
などなど。
また、全般的に悪意のある表現が目につく。
例えば、彼が指摘するGPLv2 と GPLv3 の不一致は、元の dolphin-dev がそうなっているのだから、こちらとしてはどちらかに統一してみようもない。
4 結論
前章で見たように、論理展開が破綻している箇所が多く、おそらくこれは「OpenOcean は GPL 違反」と言いたいがために後付けで論理を構成したものと思われる。
LICENCE の (C) Kazushi Minagawa という表記だけを真として独自に解釈、それ以外の整合性のつかない事象は全て無視、その解釈に合致しない OpenOcean の表記スタイルは違反だとやるわけだ。
だが、彼が奨励する記載方法は当の LSC ですら採用していない。
怪文書が指摘する GPL3 の第4条の「違反」にしても、私たちがやったことは「フォーク元の勧めやドルフィンプロジェクトの慣例に従って、著作権管理主体の表示を置き換えて、従来とは異なるやり方で author を同定していった」ということで十分に GPL の要請を満たすものだ。怪文書が主張するような「従来の著作権管理主体の名前を削除だけして、他のクレジットすべき著作権者の名前を隠蔽した」わけではない。
憶測になるが、むしろ LSC 2.7 の方が e-Dolphin 時代〜プロジェクト初期の author の名前のかなりの部分をソースコード上で削除、その存在を隠蔽していた可能性がある。
文章の目的からみても、2025 年現在では、明確に成立しているとは思えない「フォーク元の GitHub README での主張」を無批判に受け入れており、書かれた時期を考慮しても怪文書が「是正勧告」として有効とは思えない。
さらに、医療オープンソースソフトウェア協議会が構成員ほぼ一人からなる任意団体であり、実質的な関与が限定的であることを考慮すると、同組織がドルフィンコミュニティの何らかの代弁者的な役割を果たしているとは思えない。
要求の実現の交渉手法という観点からも、怪文書をいきなり公開するのはおかしい。アプリログイン画面で (C) Life Sciences Computing と著作権の管理主体が明確に示され、皆川もそこに在籍しているのだから、どこかの段階で LSC に連絡を入れ、LSC から当方に連絡を入れるよう促すのがより良い解決経路だったと思われる。
が、この手続きをなぜかしていない。
穿った見方をすれば、皆川はそもそも保護すべき著作権人格権は保有しておらず GPL 的な意味での author ではなかった可能性がある。OpenOcean 騒動を介して皆川と小林が共謀してその権利を獲得しようと試みたのであれば、かなり悪質な行為といえるだろう。
時系列でみれば、メドレー譲渡後もドルフィンはメンテナンス程度の開発は継続されている。しかし、そのソースコードは一般公開されておらず、皆川らが開発者であると特別に強調されてもいない。
もし、皆川らが、本当に個人に属する著作権人格権を有していたのならば、運営元が変わろうともその権利は保持されるはずだが、実際にはそのように取り扱われてはいない。
この事実は、怪文書の「皆川らは GPL 的な意味で author であり、法的にも保護すべき著作権人格権を有している」という主な主張と矛盾する。
5 感想など
現在から見たドルフィンプロジェクトとしては、私も以下のコメントに概ね同意する。
「オープンソース時代に彼らが保有した権利は、著作権人格権とは無関係な『著作権者と名乗っていい権利』だけだったのではないか？
実際に開発して保護の対象になっているのであれば、プログラムであっても著作権表示権は保持できるはずだが、実際にはそうはなっていない。
LSC からメドレーへの譲渡がスムーズにいったのも、そもそも彼らが保持できるような著作権表示権を持っていなかった、つまり実際には開発には関与していなかったからだと思う。
2.3 系までの契約上の権利しか持っていなかったので、その権利を保持するために 2.7m は 2.3m の派生だと主張する必要があったのではないか？」『いるかの怪文書 ３』より
「オープンソースの物語」と言ってもいいようなシナリオができており、それに従って物事が動いていた印象を受ける。
どの分野でもそうかもしれないが、作為的すぎるシナリオは、参加者の自然で自発的な意欲を削いでしまい、目立った成果をあげられない場合が多い。未知の力を呼び込み、それが自ずから発展していくような何か特別の仕組みがないと、豊かな成果を生み出すということはできにくいように思うのだ。
（適宜加筆修正予定）
猪股弘明
OpenDolphin-2.7m 開発者
精神保健指定医
