元々の久米氏の講演に関して 「日本発オープンソースソフトウェアなんて捉え方に意味はない」 という発言を散見するような気がする。 たとえば、八田さんの「日本発のオープンソース」という幻想における
という発言などがこの種のものの典型だろう。
確かに国際協調があたりまえのオープンソースソフトウェアで 日本という国籍をうんぬんするのは意味がないという主張は正しい。
しかし、私は久米氏が「日本発」という表現を使った時の意図は少々違うのではないかと考えている。 ここでは私の勝手な推測を述べておいて、 私の考えが正しいかどうかは今月25日に本人に直接お会いした時にうかがうとしよう。
まず、最初に注目すべきだと私が考えるのは「経済産業省、商務情報局情報処理振興課・課長補佐」という 久米氏の肩書きである。 要するに彼は官僚であり、 日本国が行政としていかなる見識を持ち、 いかなる行動を取るべきかというのがその視点の基礎となるのではないか。
「政策」という文脈においては「日本」というポジションは絶対不可欠である。 国民の税金を用いる以上、最終的には国民に利益が還元される行動が要求される。
そういう制約の下で「(国の)支援の対象になりえるオープンソースソフトウェア」という観点で 「日本発オープンソースソフトウェア」を捉えていて、 それがまだまだ少ないと感じていた、ということではないだろうか。
ここでは「まだ少ない」と彼が感じたということだけに注目し、 「42件」という数字とか、リストの妥当性についてはおくこととする。
では、残る疑問はふたつだ。日本政府の行動として
「政府は放っておいてくれ」という意見も聞こえるが、別に支援の押売りをしようというわけではない。 問題は支援を受ける側ではなく、支援する側にある。 つまり、「国がオープンソースプロジェクトを支援することが正当化できるか」ということだ。
単純化して、投入した金額以上の経済的効果が見込めるかと言い換えてもよい。 そうでなければ、税金の無駄づかいと非難されるだろう。
オープンソースソフトウェアが進展することによって、期待できる経済効果としては、
ソフトウェア輸入超過の軽減
商用ソフトウェアの多くは海外製でソフトウェアの分野では大幅な輸入超過が続いている。 オープンソースソフトウェアは輸出にはならないが、少なくとも資金流出にはならない。
ソフトウェア産業構造の変化の促進
海外製ソフトウェアを中心にサービスを構築していくだけでは、 国内にノウハウは残らず、将来の産業空洞化が懸念される。 オープンソースソフトウェアにより重要なノウハウが公開される。 そのノウハウ(というかソースコード)を用いて、より高度なテクノロジーが実現される
(国内の)IT化促進
十分な機能・性能を持ったオープンソースソフトウェアにより、 システム構築の費用が低減されれば、資金をより高度なIT化に向けることができ、 国内産業の競争力が増加する。
などが考えられるだろう。私は経済は素人以下なので、どれも「かもしれない」を付けて読んでほしい。 投資以上の経済効果がありそうだ、と感じていただければ十分だ。検証は専門家がするだろう。
いち開発者としては、正当であれば国からの支援であろうが、企業からの支援だろうが受けたいと思っている。 また事実、私は国からも企業からも支援を受けたことがある。
開発者の視点からは、八田さんの言う通り「日本発」に意味はない。 プロジェクトを開始した時点の開発者が日本人であるかどうかとか、 意思決定者の過半数が日本人とかいうような適当な規準を定めても、 「だからなんなの？」という結末になるのは目に見えている。
しかし、「経済省が(おそらくはIPAや産総研を通じて)オープンソースソフトウェアを支援する」という文脈では、 おそらく支援を受けるオープンソースソフトウェアの多くは 「日本発」とか「国産」という言葉で表現されてもおかしくないようなものになるだろう。
日本の事情
日本特有の事情や問題に対応するソフトウェアや機能は、 日本の事情に精通した開発者によって行われなければならないだろう。 オープンソースソフトウェアが日本において最大の効果を発揮するために これらの事情に対応するソフトウェアの開発を支援することには意味がある。
事実、久米氏も言及していた「オープンソフトウェア活用基盤整備事業」はそのような趣旨であった(なんで「オープンソフトウェア」だったんだろう？ きっと理由があるに違いない)。
国内技術の育成
今のままOSなど基盤となるソフトウェアを海外から輸入するままでは、 ソフトウェア・インフラストラクチャに関する実践的な技術がブラックボックス化し、海外に握られてしまう懸念がある。 そうならないためにも日本人のソフトウェア技術者育成に貢献することに意味がある。
資金の還流
投下した資金は日本国内で使っていただけるのがありがたいわけで、 支援を受ける人が日本人(または国内に住む人)というのはそれなりに意味がある。
要するに「国産オープンソースソフトウェア」を支援するのではなく、 「日本のオープンソース開発者」を支援するということか。
話はこの後「ではいかなる形の支援が適切か」という方向に進むはずだが、 実はまだそこまでは考察できていないのだった。
まただ。
なんて言わないでくれよ。彼にとっては「マイクロソフトシェアードソース」もオープンソースなんだろうか。
「オープンソースの俺定義をしている文書のリスト」でも作って、 晒す必要があるのだろうか。
あと、すくなくとも私にとっては
は、「感謝の表現」でもなんでもありません。それはアナタの「仕事」です。 相互運用性が重要なソフトウェアでもフィードバックがなければ感謝にはならないでしょう。
そのような活動をしてくださるのはご自由ですし、むしろお勧めしますが、 それと「感謝」を混同しない方が嬉しいです。
「オープンソース」も「フリーソフトウェア」も別に感謝なんか要求してないんですから、 エセ感謝を表明して自己満足されるよりも、 「実際には感謝を示してなんかいないんですけどね」 とかいう態度の方が正直で好感が持てます。
ついでに「いつか貢献できたら」という気持ちが見えると好感度アップです。
いやんなっちゃう、またコンパイルできないコードをコミットしちゃった。
発生手順は以下の通り。
あ〜あ。皆さんは真似しないでくださいね。
サイバーノーガード戦法についてツッコミが来た。
実はどうして私にその質問が来るのかやや疑問ではあるが、 たぶん5月29日のエントリに法的措置について書いたので、 そのことに関してであろう。 普段なら笑い飛ばすところだが、 「冗談を真面目に考察する」のもこの「にっき」の持ち味のひとつではないかと 感じているので、後ればせながら改めて考えてみたい。
まず、サイバーノーガード戦法とはなにか、というところからまとめたい。
サイバーノーガード戦法という単語の オリジナルと思われる文章では、以下のように解説されている。
その１ セキュリティへのコストを切り詰めて、脆弱性あってもいいやで安価に開発。サーバ管理者もセキュリティまでわかる人は単価高いので、安いサーバモンキー程度ですませる。予算があったら保険に入っておく。
その２ 冒頭の文章＝このサイトがメソッドＡで運用されていることを掲示する。
その３ 脆弱性の指摘があったら「うちはノーガード戦法だから、余計なことをいうな。」とつっぱねる。
その４ 脆弱性をついた攻撃あるいは脆弱性の情報公開があったら、相手を不正アクセス法と威力業務妨害で告訴する。今回の事件でわかるように、脆弱性を放置し個人情報を漏洩させても運営者は全くおとがめなしで安全である。これは運営者からすると、訴えたもん勝ちといえる。警察のお墨付きというわけである。
その５ もし、本当に被害が発生したら、迅速にお詫びのメールを被害者に送付する。世間がうるさかったら、商品券でも送る。商品券のコストがセキュリティ投資のコストを上回る可能性はまずないので、これでも損ではない。
なお、タイトルにある「安全」というのは、運営者が安全という意味で利用者はきわめて危険な状態におかれる。
さて、この戦法にはいくつかの問題がある。
ということで、真面目に考察した結果、サイバーノーガード戦法は、 有効な局面が極めて限られるので採用できない、というのが結論だ。 そもそも我々は個人情報なんてほとんど持ってないし。
そういう観点からは、ACCSをはじめとする「サイバーノーガード派(なんてくくってよいのか？)」に対応は残念だ。
そういう観点からはサイバーノーガード戦法には賛成できない。
真に対抗すべき悪意ある存在に対しては無力で、 さほど悪意がない「警告者」を恫喝する結果を招くだけだから。
さて、この言葉の発端となったoffice氏の行為については、 その行為に問題があったとは私も思うが、 問題の所在はイベント会場で個人情報を漏洩してしまったことにあって(それがどのような罪に該当するのかは知らない)、ACCSから情報を入手できてしまったことではないと思う。 ACCSの脆弱性は、情報の入手に成功してしまって、 はじめて脆弱性の存在が分かるようなタイプである以上、 彼の行為の問題はそこにはない(はず)。 「被害者」としてのACCSの怒りは想像できるが、 だからといって自分の落ち度を棚に上げて、 一方的にofficeに責任を押しつけてよいわけではない。
今回のruby-lang.orgのクラックについてだが、 たとえばhelium(ホスト名)のCVS脆弱性を突いて、 本来保護されている領域に侵入して、ファイルシステムを「改竄」した行為は 不正アクセス以外の何者でもないと思う。 よって議論の余地はないはずだ。 もし、侵入者が特定できたならば(残念なことにかなり可能性は低いが)、 彼はそれを償う必要がある。 特定できなくても彼が犯罪者であることには変わりはない。 すくなくとも日本の法律の下では。
我々にも落ち度があるのは認めざるをえないが、 だからといって犯罪者が免責されるわけではない。 実際、この一連のコストは我々が(特に前田くんが)負担しているのだ。
では、思考実験として、CVS脆弱性を利用してheliumに侵入し、 それを悪用せずに、我々に 「heliumにはCVS脆弱性がありますよ」と警告してきたケースを考えてみよう。
我々は「警告者」が本当に警告だけだったのか、 実際に侵入し、踏み台としての仕掛けを行っている「ほんとは悪いやつ」なのか 区別がつけられない以上、結局は今回行ったのと同じような ホストの再構築を行う必要に迫られたであろう。
が、「警告者」がCVS脆弱性を利用したとしても、 本当に警告のためにしか用いていなかったならば、 我々はその警告者を刑事罰の対象とは考えないだろう。
すごい手間なんで「余計なことをしないでくれ」と激しい怒りを覚えるだろうけど。
追記
KLさんからの指摘にあるように、 ACCSを一方的に「サイバーノーガード派」に分類するのは不適切だ。 ここに謹んで謝罪するとともに訂正する。
元の文章を修正してしまうのは簡単だがフェアでないので、 証拠として残すためにもstrike outだけにしておく。
何ヶ月かに一度、Freshmeat.netをチェックして、 目新しい言語がないかと調べてみることにしている。 「言語おたく」としては当然の行為だ。
で、今回見付けたのが、これ。
名前は「きゅー」と読むのだろうか。RubyやPythonより高速だと主張している。
言語として目新しいのは、
文法や実装のあちこちにRubyの影響が見える。が、文法には独自の発展が見られるし、 ソースコードは私のものよりも整理されているようだ。今後の楽しみな言語である。
他にも、Slateとかも興味深い。
B000BD83ZK 最近になってようやく松江市にもヤマダ電器が開店したのだが、 開店セールで安かったので、妻と一緒に見に行った際につい衝動買い。 ただし、現物は今週まで届かなかった。
で、パンを焼いたらおいしかった。 もっとも以前から持っていた象印のものと極端に違うかというと自信がない。 しかし、米粉のパンが焼けるとか、餅がつけるとか付加的な機能に期待してしまうのであった。 今後が楽しみ。
ところで、またSANYO製品を買ってしまった。 うちは洗濯機も、FAXも、ビデオデッキも、布団乾燥機もSANYO製なのだ。 別にSANYOファンというわけではないはずなんだがな。
判官贔屓？
妹夫婦が引っ越しなので手伝いに行く...のだが、 妹がほとんど荷作りを完了していたのと、 運送業者が驚くほど手際がよかったので、 出番がない。
結局、少しだけ掃除の手伝いをしただけで終わった。 今まで何度か引っ越したことはあるし、他人の引っ越しを手伝ったことも何度もあるが、 こんなに手早いのは初めてだ。
夜にはバプテスマ会。私たちは新しい仲間を歓迎します。
4797336021
近所の本屋で購入。まだ、2章までしか読んでいないが、
この範囲で一番感動したのは、レイアウトルール。
ブロック構造をインデントで表現しつつ、
式と分文の分離を発生させないというすばらしいルール。
13年前、Pythonの文法がこうだったら、私がRubyを作る動機のひとつはなかったろう。 ちなみにもうひとつの動機は、あのオブジェクトモデル。
二台の車に分乗して教会に向かっていたら 途中で電話が鳴った。次女からだ。
「？」と思ってると「うちに他に誰もいない」とのこと。 どうやら置き去りにされたらしい。
後でよくよく話を聞くと、いろいろと不幸な偶然が重なったらしい。
おかげで遅刻しちゃったよ。 誰が悪いって、誰も悪くないよねえ。