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

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

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

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

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

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

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

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

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

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

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

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


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


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


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

(追記)ところで小山が拡散に努めた小林慎治元記事(通称、怪文書)だが、しばらく非公開になっていたのだが、どういうわけか再び公開されていた(2025 年 9 月確認)。
ほぼないと思うが拡散される可能性もある。
対策として、結局、反論記事を作成・公開することになった。
小林慎治氏の OpenOcean に関する事実誤認
OpenOcean が GPL 違反?
をご覧ください。

(追記2)人手による拡散はないのだが、AI がおかしなまとめを作ることがある。
対策として、最近は、そもそも小林が根拠とした LICENSE 自体が改ざんされたものだということを強調して説明するようにしている。

 

オープンソースと 生成 AI

タイトルはおっきめにつけたが、ネタは東大松尾研が生成 AI のプレスリリースで「オープンソース」というワードを使ったことに関するあれこれ。

実際に適用されたライセンスは CC BY NC 4.0 で、オープンであるが「商用利用不可」というもの。

これは「商用利用不可」という制限があるので OSI がいうところの「オープンソース」ではない。

そういったわけで、プレスリリースされた直後から、その点を指摘する声が多数あがった。

いつもの話と言われればそうなんだが、今回は世間的に注目を集めている研究室の生成 AI に絡んでいるという点で従来の諍いみたいなものと違っていたように思うので、その点を意識してあれこれ書く。

なお、顛末を先に書いておくと、松尾研がプレスリリースに訂正を入れるということで騒動は決着ついた。ただし、訂正後はデータ公開云々みたいな話はどこにも記載されておらず、この点も興味深かった。

今回の件がこれまでの論争と違っていたのは、「細かいこと(OSI の定義に従っているかどうか)にこだわる必要があるのか?」という正面切った反論が出てきたこと。

この件は宗教論争的側面が多いのでここではスルー。

興味深かったのは、これに伴ってよく出てくる「オープンソースという言葉は、オープンソースな人々が初めて使った言葉なので、OSI に従うべきだ」みたいな都市伝説的な言い分が完全に論破されたこと。

いかにも SNS 。例えば、このスレあたり参照。

元の記事にもあるように open source という言葉は、オープンソース教祖が特別な意味を付与する以前から普通に使われていた。

また、「オープンソースは商標が成立しているので、この言葉を使うときは OSI の定義に従うべきだ」というよくあるアレも完全に論破されている。

これなんぞ参照。

むしろ事実は逆で「オープンもソースも一般的なワードなので、ソフトウェアの分野で商標は成立し得ない」というのが正しいのだが、皮肉なことにこの著作権的な常識が強調された結果になったようだ。

まあ、今までがおかしかったんだけどね。

オープンソースはよく宗教や政治的信条(共産党とかさ)に喩えられるが、今回の騒動でその党派的で胡散臭い側面が白日の元に晒され、完全に否定されたようだ。
この点が従来の小競り合いとは違っていたように思う。

 

猪股弘明

爆縮

初出は facebook の某グループです。
突如、iPS の話題が出てくるのは、並行して人気のスレだったから。
深い意味はないです。


潜水艦タイタン号の破壊メカニズムは「爆縮」と推測されてますが、構造物が外圧で部分的に壊れていく「圧壊」とは物理プロセスが違います。

物理畑の人が「爆縮」で想起するのはプルトニウム型原子爆弾の起爆装置の原理となった「爆縮レンズ」でしょうか。

アナログな爆薬と電子制御で爆弾中心に設置されたプルトニウム塊に「高爆圧を」「周囲から同時に」「瞬間的に」かけるのがキモです。(こうしないと臨界状態にならない)

原子爆弾というとアインシュタインの E=mc^2 が有名ですが、これは単に基礎的な原理を表しているに過ぎず、実際にプロダクツ?をリリースするにはプルトニウムやウランの精製や起爆装置などの周辺技術も整備しないといけません。

爆縮レンズの担当はフォンノイマンだったらしく、彼の超人的な仕事ぶりが wiki あたりにも載っています。
https://ja.wikipedia.org/wiki/%E7%88%86%E7%B8%AE%E3%83%AC%E3%83%B3%E3%82%BA
(GIF も同ページより転載)

しかし、今から見てもマンハッタン計画はすごいですね。
リーダーをオッペンハイマー、理論や実験の実務をフェルミ、数値解析はフォンノイマン、派生的なテーマをファインマンあたりがやっていたという贅沢すぎる豪華人材の投入っぷり。

比較するのも可哀想な気もしますが、iPS は(原理は私もすごいと思いますが)すり寄ってきた人たちがダメすぎた気がします。

なお、なんでこのスレを立てたかと言えば、どこかで「乗員はどうなったんでしょうか?」というような投稿を見かけたから。
まず、探索時に衝撃音を観測したという報告があったので、「圧壊」ではなく「爆縮」であった可能性が高くなりました。
破壊メカニズムのあたりがつくと、理論を使って何が起こっているかの大雑把な見積もりができるようになります。
爆縮は瞬間的に起こりますが、これはミリ秒オーダーでおこったらしいです(ネット上で計算した人がいた)。ミリ秒オーダーだと、外界と熱交換している時間はほぼないため、断熱圧縮という現象がおこります。
この効果で乗員の体表温度は数千度に一気に上昇(おそらく黒ごけ)、ただし、生体の熱伝搬はそれほど早くないため、内部臓器はおそらく「レア」。続けて(現実のタイムスケールではほぼ同時に)圧力波と潜水艦構造物が乗員を襲います。身体各部位の損壊は相当激しかったと思われます。
このシナリオだとすると、恐怖を感じることなくほぼ即死でしょう。

 

次世代型 HorliX

現行の HorliX を Mac AppStore からリリースしたのは、2018 年のことだから、かれこれ 5 年前のことになる。

売れ行きも評判も上々で気を良くしていたんだが、すぐに今も続く懸案事項が持ち上がる。

それは当時のアップルが打ち出した

OpenGL の廃止・Metal への移行

という方針だった。

HorliX に限らず、画像系のアプリはほとんど OpenGL に依存していたから、それなりの騒ぎになったことは覚えている。

幸い?すぐに廃止ということにはならなかったが(ちなみに、今でも OpenGL は使えている)、Metal が普及するにつれ、そのパフォーマンスの良さに「移行はやむなし」という雰囲気に変わってきたように思う。

私も、この方針が打ち出された直後、次期バージョンのことを思い浮かべた。

当初は、まずプラットフォームを Qt に移そうかと考えていた。
Qt はかなり早い段階から、Metal 対応を進めていたので、構想としては悪くなかったと思う。実際、試験的にプロトタイプも作成したりした。

ただ、どうしても本気になれなかったのは、HorliX を構成する膨大なライブラリ群もまとめて Qt で面倒をみなくてはならなくなることだった。

何か本質的でない気がした。

Metal への移行が思っていたより緩やかなことがわかってくると、アプリの Metal 対応は次第に考えなくなっていった。

ここ数年はそんな感じだった。

ところが、別件で画像処理関係で Metal を触ってみると、意外に扱いやすいことがわかってきて、HorliX 云々は別にしていくつか試験的なコードを書いてみた。

例えば、2D ビューア。

3D ビューア。

機能を豊富に盛っているわけではないが、最低限のラインはできているんじゃないかと思う。

当初は何かに使うという予定はなかったが、Metal による 2D や 3D 画像の取り扱いに慣れてくると、「これらを使って、次期 HorliX (PHORLIX と呼んでいる)できるのでは?」と思うようになった。

ここからの話は長くなりそうなので、いったん切ります。

 

Metal 関係覚書

たまにしか使わないので基本概念が抜けがち。

シェーダー

具体的には ***.metal ファイルがそれ。
頂点データと色の処理を決めているファイル。これだけだと有り難みがピンとこないが、実際にはこれが(並列処理可能な) GPU で処理される、というのがミソ。
このおかげで、頂点が増えれば増えるほど、効率的な処理ができるようになる。

なお、この時、使用される言語が MSL (Matal Shading Language)。

Metal は OpenGL とは違い、***.metal ファイルはビルド時にプリコンパイルされれる(.metallib というファイルが生成される)。OpenGL では実行時にコンパイルされるので、この点も高速化に貢献してそう。