反オープンソース評論家

常々、「IT 評論家」のような人が嫌いだった。

特にオープンソース評論家のような人は、その主張が激しく界隈ではある種の「武闘派」や反社組織とみなされていると思う。

その点で、いわゆる OpenOcean 騒動はチェックしていた。
OpenOcean 騒動というのは、air-h-128k-il さんたちが OpenDolphin という GPL でライセンスされた電子カルテの独自カスタマイズバージョン OpenOcean をソース・バイナリともに公開・配布した際に、小林慎治(医師、現岐阜大医学部特任講師)というオープンソース評論家のような人が、「OpenOcean は GPL に違反している!」と難癖つけた事件のことだ。

この難癖というのがなんと言っていいやら・・・。

まあ、トンデモの類。

最近になって、当時の開発陣からかなりまとまった反論が提出されている。
(例えば『小林慎治氏の OpenOcean に関する事実誤認』、『OpenOcean 騒動』、『OpenOcean 騒動 #27』)

ここで注目したいのは、オープンソースの責任性について。

彼は怪文書の中で言っている。

OpenOceanのWebには2018年12月までの試用期間であると記載とされています。ユーザーはこの指示に従うべきものとも考えられますが、このままだと使用期限が近づいてもクライアントに何の警告も表示されずに2019年1月以降起動しなくなってしまいます。GUIなインタラクティブメニューを持つソフトウェアであれば、1ヶ月以上前から警告を表示しておくのが親切ではないでしょうか。
Webに記載される試用期間を見落とすほうが悪いのかもしれませんが、使用期限を過ぎて起動しないソフトウェアに対してどのように対処すべきかも書かれていませんので、ユーザーである医師には対応できずに医療事故につながる危険性があります。

ここだけ取り出すと提案の一つとしてあってもいいかなと思えなくもないが、実際に彼の取った行動は理解不能。

なんと、使用期限に関するコードを削除したものをプルリクエスト(PR)として OpenOcean リポジトリに送ってしまったのだった。「残り X 日です」とアラートウインドウを出すような実務的なコードではなくて。
その PR は今もリポジトリに記録されている。こういうものだ。

expired() というメソッドで使用期限を設定しているわけだが、この機能に関するコードを削除しただけ。

すごいでしょ。

issue あたりで改善要望出しておけばいいだけだし、そんなに使用期限がいやなら使用期限のないバージョンを自分でビルドしてユーザーに提供すればいいだけ。後者は、ほぼパクリとも言える行為だが、air さんたちだったら許していたと思う。

その一方で怪文書は、

第三者にその製品を提供することは著作権法が定める頒布権の侵害であり、公衆の場であるGitHubにソースコードを置くことは著作権法が定める公衆送信権侵害です。

とソースコードの公開停止を主張している。
PR 送ったのが 2018/11/4 で、怪文書が公開されたのが 2018/11/26 のことだ。
俗っぽい言い方をするならば「PR がマージされなかったので、逆ギレして公開停止を主張した」ということになる。

ところで、そもそもオープンソースは、ビルド産物に関しては責任は限定的だし無保証だ。
この点に関してある人が面白いことを言っていた。


OpenOceanの試用期限表示とオープンソースの責任について

1. OpenOceanの試用期限表示について

OpenOcean配布サイトには「使用期限は、2018/12/31 までです。」と明記されているので、「警告なく起動しなくなる仕様」という批判は不当であると言えます。情報が公開されていた以上、利用者はその条件を理解した上で使用を開始する責任があります。

2. オープンソースにおける開発者の責任について

多くのオープンソースソフトウェア(OSS)のライセンスには、開発者による保証の放棄(無保証)と責任の限定が明確に記載されています。

無保証の原則: OSSは一般的に「あるがまま(as-is)」で提供され、品質保証や機能保証は行われません。利用者は自己責任においてソフトウェアの品質や安全性を確認し、利用する必要があります。

責任の限定: ほとんどのOSSライセンスは、開発者がソフトウェアの利用によって生じた損害に対して責任を負わない旨を規定しています。これは、オープンソース活動がボランティアベースで行われることが多く、開発者に過度な負担をかけないための措置でもあります。

新機能の搭載: 開発者が責任に限定的である立場にあるからこそ、新機能や実験的な仕様を導入しやすいという側面があります。


実際、OpenOcean には、ファイルバックアップ機能などそれまでのドルフィンになかった新機能が搭載されていた。

どれが正しいのだかもわかりにくい著作権表記だのでワーワー騒いで、OpenOcean 開発陣からユーザーによる新機能の評価を得る機会を奪ってしまった。

「小林慎治はオープンソースの足を引っ張っているだけ」という批判がなされている一つの根拠になっている。

おそらくこの人のスキルからしてオープンソースといった開発現場に近い位置での論評は無理がある。
それを自覚したのか、小林氏、最近では初学者向けに「医療Dx」に関して語ることが多く、一時の「オープンソース」偏重とは異なる態度をとっている。
言い方を変えれば、実務家が彼を「オープンソース」領域から追っ払ったとも言えるわけで、反「オープンソース評論家」のささやかな勝利といえるだろう。

 

(追記)本稿では、責任性について触れたが、私がのけぞったのは、そもそも怪文書の根拠となっていた著作権表記が改竄されたものであったという事実。
そして怪文書の「是正勧告」とやらに従った場合、まるでミステリのような犯罪が成立していたという指摘。
OpenOcean 怪文書 -GPL 誤用による違法行為教唆-』に詳しく書かれていますので、興味のある方はそちらをご覧ください。
OSS は無保証・限定責任ですが、OSS に関して語ったことは語った人の責任です。
どう責任取るつもりなんでしょうか?
でも、この人のことだから、言いっ放しで終わりそう。

(追記2)X の TL みてたら、佐渡秀治という人が引っかかってきたようだ。

「流れは知らんけど」って。追補されているのだから、流れは重要だろう。
これ、反撃されるとみた。
→案の定、『OpenOcean 怪文書 – 適切な GPL 使用のために-』で追記されてた。
ところで、ネットで検索してたら、この人のことを評した情報はほとんどない。
あの言動では当然そうなるよなあというのが感想。

なお、X の佐渡秀治アカウントをブロックすることを佐渡島の気候的なブロック効果になぞらえて「佐渡ブロック」というそうです(笑)。
個人的にはツボった。

集客が微妙?
著作権法の基本概念が身に付いているかどうかもあやしい評論家の上から目線の講演を聞きたい人はそんなに多くないだろう。

(追記3)小林慎治氏、電子カルテの標準仕様に関するパブリックコメントでも盛大にやらかしてます
猪股先生は、「この人は物事の判断をする際に jumping to conclusion 的傾向がある」と示唆していたけれど、ああ、なるほどと思わされた。「個人著作/職務著作」でもそうだが、批判的吟味をするのに必要な知識の整理が不十分なまま結論を急ごうとする。
「準備不足」かと思っていたが、二度三度と重なるとそれだけでは片付けられない。能力の問題があるように思う。
思うに、医学部ではこういう人が多いように思う。
ある時期に集中的に論理的思考のトレーニングを積まないと、ある種の能力は身につかないと思うのだ。

 

造船大

限定公開記事だが、以前にFラン大のことを書いた。

で、X で監視している垢があると言っていたが、無論、今でも続けている。

そのうちの一人を「造船大」と呼んでいる。

2025 年になっても、フォロワー約100、インプレションも二桁と絶好調である。

 

 

オープンソース考

「オープンソースの素晴らしさ」みたいな記事はどこにでも落ちていると思うので、ここでは書かない。
そうではなくてあの業界の性善説的な寛大さにつけこんでよからむことを考えている連中がいるので、それに関して述べる。

よく遊んでくれるお姉さんが書いた記事が印象に残っているので、まずは再録。(許可取ってます)


OPENSAUCE/OPENSOURCE

X(twitter)の投稿はそんなに頻繁にしておらず、だから、バズるみたいな現象とは無縁なのだが、例外的にこのポストにはちらほら反応があった。

要するに
「OPENSAUCE 社が公開レシピのプラットフォームとして OPENSAUCE を商標登録しようとしたが、OPENSOURCE が既に登録されていたため、拒絶された。
が、OPENSOURCE の使用実態がなかったため、不使用取消審判を請求した。
しかし、この件を OPENSOURCE 商標を保持している OSDN 社及び同社代表佐渡秀治が、誤解を招くようにアナウンスしている」
というものだ。
詳しく知りたい方は、リンク先の OPENSAUCE 社のこのページからどうぞ。

これを見つけた時の私の第一感は、(ポストにもそのニュアンスは出しているが)「うわぁ、またやっているよ」というもの。

以下、ちょっとした感想。

松尾研究室オープンソースAI事件とその副産物

また、というのは、ちょっと前に(時系列的には、これより後なんだが)生成AIで有名な松尾研究室が、同研究室開発のソフトを「オープンソース」と広報したときに、オープンソースな方々が「Creative Commons ライセンスは OSI 基準のオープンソースライセンスに当てはまらないので、この AI はオープンソースではない」と騒ぎを起こしたことがあったから。

ちなみにこの騒ぎは松尾研究室が「オープンソース」の旗を下ろすことで幕が降りた。

個人的には、(この手の論争はよく起こることなので一定の結論を出すという意味で)もっとやり合って欲しかったのだが、そこまでには至らず、松尾研究室が大人の対応をすることでこの件はクローズとなってしまったのだった。

だが、論争相手が現在勢いのある松尾研究室であったため、いくつかの副産物が生まれた。
X(twitter)を漁ればわかると思うが、かなり優秀な人々がこの件に関してコメントしている。この点はいつもの「オープンソース」論争とは一味違っていたのだ

副産物の一つは、「open source という単語は、OSI などオープンソース関連団体が特別な意味を付与する以前から、『ソースコードが公開されている』程度の意味合いで普通に使われていた」という事実が発覚したことだ。

open も source もごく一般的な名詞にすぎない。
「ソースコードが公開されている」程度の意味で「open source」という一般単語組み合わせワードを使うことは、商標が成立する以前から使われていたわけだから、仮に商標があったとしても、禁じることはできない、というように解釈するのが普通だろう。

もう一つの大きな副産物は
「そもそも、プログラム領域では商標自体が成立していなかった
というかなり身も蓋もないもの。
拒絶された理由も、わかりやすく書けば
「open も source も一般的に使われている。それらを組み合わせた open source は特別な知識なしでも「ソースコードが公開されている」という意味に解釈できるよね。なんでそんなものに特別な権利を与えなきゃならんの?」
とかなり明快だ。

佐渡秀治氏の立ち回りが政治的すぎて生理的に受け付けない

松尾事件勃発直後の末端オープンソース信者のおおよその反応は
「オープンソースTM の商標は我らが教祖様が保有しているのだから、松尾研究室のネーミングは法的にも許されない」
というような感じだった。

しかし、これは色んな意味で間違えている。
教祖様はプログラム領域では商標は保持していない。

私が佐渡氏に生理的な嫌悪感を持つのは、こういうときに「それは誤解であって、私は、プログラム領域では、商標保有者ではないんだよ」と直接信者には語らないから。
実際、そのことに触れた書き物は公開されていたりもするのだが、佐渡氏はこの存在にほとんど言及しない。

ある程度の誠実さがあるのなら、「商標的には成立していないが、ライセンス限定という意味でなら、オープンソースライセンスはその定義が広く普及しているのだから、その観点から松尾研のネーミングを検討してみてほしい」と言えばいいだけではないか?

それをしていないのは、彼や彼の取り巻きにとっては、信者に意図的に誤解させたままにしておくほうが都合がいいからなのだろう。

私は、こういった立ち回りを生理的に受け付けない。

なお、見出しは「佐渡、キモっ」という意味ではないので、念の為。


フォントなどは適宜改変した。

何でこの記事が興味深かったかというと、オープンソースの思想みたいなものに触れず、その周囲に生息している人たちのやり方に焦点を当て、その本質的な反社会性のようなものにフォーカスしているから。

考えてみれば日本でバリバリにオープンソースプロジェクトに貢献している人はそれほどおらず、どちらかといえば「オープンソースは素晴らしい。そのような崇高な活動に深くコミットしている私も素晴らしい」みたいなナルシスト活動家が多いのが実情だろう。

ナルシスティックに自分に酔っている程度なら実害は少ないのだがオープンソース利権までなっていたプロジェクトがあるので紹介したいのだが、これはまたの機会に。

・・・などと言っていたのだが、その後も同じ調子でデジタル庁の資料を攻撃していた。

ただ、SNS 時代に彼のやり方はあってないフシがある。
IT 界隈の実務的なリーダー層を中心に「文意を汲み取れば、デジタル庁の説明はおかしくない。デジタル庁がこの言葉を使った本来の目的は『各省庁が保有するソースコード資産の共有範囲を拡大するのか?するとすればどのようなやり方を取るのか?』という問題提起やその手法の検討のためだ。佐渡秀治の横槍は従来の言葉の定義に必要以上にこだわっており、議論の邪魔をしているだけではないか」というような指摘をする人が結構いた。

政治とマスコミの関係を見るまでもなく、多くの監視の目がある SNS の世界では、幼稚で単純なスローガンを声高に叫ぶだけでは通用しにくくなっている。

 

秋葉

参考

OpenOcean 怪文書 -適切な GPL 使用のために-
オープンソースと共産主義の類似性を指摘する声は昔からある。
そのせいなのかやはり「活動家」の方々の言動が左翼的になるようだ。だが、現実のプロジェクトは理想通りにはいかない。上記の記事に詳しめに書いてあるが、dolphin プロジェクトでは author の改ざんも実際にあった。
それでも OpenOcean 開発チームは「オープンソースプロジェクト」としての体面を保つためにドキュメントなどにも事の経緯をかなり詳細に記述している。
だが、佐渡秀治はドキュメントのロジックが読み取れないのか、雑に「OpenOcean = GPL 違反」説を支持。
正直、アホかと思った。
関係者が散々言っていると思うが、それすると犯罪(業務上横領罪)になる可能性が高い。
まるで

理念のためなら犯罪を犯しても正当化される

と言わんばかりの物言いだ。
author とされていた人物が自分自身の手で LICENSE 文書の改竄を行った、というのが OpenOcean における現実的な問題なのだが、彼はその点に関して触れようともしない。
個人的にはこの言動でワイはこの人を見限った。
おそらくは能力不足で現実の非典型的な問題を扱えないのだが、プレザンスをアピールしたいがためにこの問題に言及したのだ。
実社会では、現実的な問題に柔軟に対応できるかどうかでその人の能力を推しはかることが多いと思うが、この人の対応は予想以上に酷かったし、今でもそのように評価している。
この人の経歴から言って今後も表現形式を変えるようには思えないが、どうか現実で動いているプロジェクトの邪魔はしないでくれと思う。

 

 

 

NSUserDefaults

サンプル

AppDelegate.m
@implementation AppDelegate

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {
    // Insert code here to initialize your application
    NSUserDefaults *ud = [NSUserDefaults standardUserDefaults]; // 取得
    [ud setObject:@"hoge" forKey:@"KEY_S"];
    [ud synchronize];
}

 

参考:https://glassonion.hatenablog.com/entry/20110920/1316473990

保存場所

Non SandBox: /Users/ユーザ名/Library/Preferences

SandBox: /Users/ユーザ名/Library/Containers/アプリ名/Data/Library/Preferences/

なのだそうだが、デバッグ時にそれらしいファイルはなかったな???

→registerDefaults メソッドはファイルに書き出しません!

しかし、standard と shared の違いがわからんなあ。

→shared は文字どおり「共有」ということらしい。
何と共有するかは、この記事によれば、同じグループ間で、ということらしいのだが、使ったことはない。

 

Objective-C 諸々

objective-c や cocoa の割と独自仕様っぽいところ。

delegate

見かける割にいまいち理解できていなかったデリゲート。

「MTKView のデリゲートがレンダラー」と気がつき、ああそういうことかと納得。

大抵の場合、ViewController が MTKView を呼び出す前に

_view.delegate = _renderer;

などとしているはずだ。

メタルの表示用ビューとして MTKView は存在しているが、各アプリでのこのビューの使い方は様々だろうから、そこら辺は自分で DrawInMTKView を実装してね、プロトコルは準備しておくから・・・ということなんだと思う。

わかりにくくなるのは、プロトコルが明示されているわけではないので、その仕組みに気が付きにくいからじゃないでしょうか。

本来であれば以下のような記述が必要なようだ。

委譲する側(のヘッダ)

@protocol HogeDelegate

@property (weak, nonatomic) id delegate;

@protpcol HogeDelegate <NSObject>
-(void)FugaMethod;
@end

以下のように明示的にぶん投げるときもある。

委譲する側(の .m ファイル)

[self.delegate FugaMethod] //こうやって使うようだ

ぶん投げられる側はプロトコル準拠を明示しておく。

委譲される側(のヘッダ)

@interface Fuga: NSObject <HogeDelegate>

ところで、これが面白いのは、ある種の情報の通知として利用できる点。
上の例なら、Hoge の情報を Fuga で受けられる。
ViewerController に受け持たせてしまい、あるオブジェクトでの情報をビューに反映させるといった使い方ができる。

参考:https://dev.classmethod.jp/articles/ios-delegate/

マルチスレッド処理

NSTread を使う方法、dispatch_async – queue の系を使う方法などいくつかあるようだ。

(続く)

KVO

https://qiita.com/mitsu9/items/e738c41a8d87cc71ec3e

KVOとはキー値監視(Key-Value Observing)のことを指します。
アプリ開発をかじったことのある人ならMVCという言葉を聞いたことがあると思いますが、KVOはModelの変更をControllerやViewに通知し、反映させるための仕組みです。
他の通知システムとしてはdelegateやNSNotificationを利用した方法などがあります。

なるほど。

サンプルとして MCV を意識したメモアプリあり。

インスタンス変数の宣言

Objective-Cでは、インスタンス変数をどこに宣言するのが正しいのか? 』が興味深かった。

やはり、みなさん疑問に思っていたんですね。

参考

phorlix100 の github issues
いやー、大変参考になりました!