ソフトウェアの責任の所在2006年12月31日 12時26分56秒

ソフトウェア開発者も、製造物責任法 (PL 法) などのような枠組みで責任の所在を明確にすべきだ、という話。なるほど、大筋では大体その通りだと思う。でも、フリーソフトウェア開発者は「賠償責任」と聞けばみんな心臓をバクバク言わせるだろうな。

まず、ひとえにソフトウェア開発とその提供、といっても、形態は様々であることを無視してはいけない。今書いたように、プロプライエタリ (フリーではない) なのかフリーなのか、有料なのか無償なのか (無償であればすべてフリーというわけではありません、念のため)、パッケージ製品として店頭に売り出しているのか受託開発なのか、スタンドアロンなのか Web アプリなのか、プリインストールや組み込みソフトウェアではどうか、などなど、ソフトウェアは実に様々な形態で提供され、あるいは開発されています。

主に受託開発の仕事に携わるソフトウェア開発者のおおくは、ソフトウェア開発は製造業ではなく、サービス業であるという認識を持っています。おいらもその一人です (今は現場に関わっている身ではないけど)。Web プログラマーも同様でしょう。彼らは製品を配布しているのではなく、システムを手元のサーバー上に構築し、そのシステムが提供するサービスを商品として商売しています。反面、組み込み系や、パッケージソフトウェア (プリインストール含む) 開発に携わる人々の場合、その感覚はまたちょっと違うものなのかもしれません。特に、ハードウェア開発の現場で (委託などではなく) 組み込み系ソフトウェアを開発している人間は、一緒にハードウェアを設計し、製造している、という感覚で従事している人も少なくないのではないかと思います。

製造物責任法の骨子は、リコール賠償であったかと思います。このうち、リコールについては、受託開発を除けば、ほぼすべてのソフトウェア開発の現場において、同様の対応は既に定着しているはずです。例えばパッケージ製品であれば、ネットワークなどを介した修正パッチの自動更新および配布が定着してきています。フリーソフトの場合でも、配布元のサイトにおいて告知と修正版の配布が行われている他、メーリングリストなどに参加してもらうことで、積極的に告知をいち早く伝えようという試みをしている方もいます。自動更新については、.NET Framework が Click Once と呼ばれる、アプリケーション起動時に更新のチェックと自動更新を行う機構を提供しており、Windows 向けに無償のソフトを書いている人々の間ではこれが今後は浸透して行くのでしょうが、基本的にはこうした機構は開発者が自己の技術でこさえるものであり、まだあまり浸透しきっていないのも事実です。

いずれにせよ、このような瑕疵保証責任の追及については、法がある程度のガイドラインを示しても良いようには思います。妥当な線としては、大体以下のような感じかと。

  • 瑕疵保証義務発生の程度
    • セキュリティー保護に影響を与えるもの (いわゆるセキュリティーホール)。
    • プライバシー保護上問題のあるもの (Winny みたいな「ファイル管理できないファイル共有ツール」とか)。
    • 動作結果が人身被害を及ぼす状況を回避し難くするもの (医療機器、交通・航空管制、その他)。但し一部の研究開発分野を除く (宇宙開発とか)。
  • 瑕疵保証義務発生時の対処
    • 告知義務 : 広く一般に知られる形での告知を要する (配布を行う Web サイト上での告知、等) (メール告知は必須とはしない←ユーザーの誰もがメールアドレスを提供する形でのユーザー登録を望むわけではない)
    • 修正および配布の義務 : 定められた期間内に修正し、配布を行わなければならない。
    • 配布差し止め : 定められた期間内での修正が間に合わない場合等、一時的に配布および販売の差し止めが命じられる場合がある。

ちなみにセキュリティーホールについてのみ言えば、現在でも既に IPA が脆弱性情報の届出と瑕疵保証対応の仲介を行っており、少なくとも日本国内のソフトウェア開発者においては、セキュリティーホールに対する瑕疵保証は事実上義務付けられているような形になっています。

では次に、賠償責任についてはどうでしょうか。これについては、少なくともソフトウェアの開発実態に応じて措置が講じられるようでなければならないと思っています。

まず、有償か無償か、あるいはプロプライエタリかフリーか、といった辺りは、あまり重要ではないのではないかと思っています。無償であっても IE みたいなプログラムが無保証であってもいいとは言い難いし、Apache のようなフリーソフトウェアであっても明らかに回避不可能な物理的・金銭的損失原因があった場合に無保証であってもいいとは思えない (実際多くの場合、「法によって許される範囲での無保証」を唱えています) (もっとも、Apache みたいなプログラムが、物理的・金銭的損失の原因になりうるシチュエーションというのがあるかどうかは知りませんが)。むしろ、会社が業務として開発しているのか、それとも個人が業務とは別に開発しているのか、という点のほうが重要です。端的に言えば、民事上の賠償義務が発生した場合に、支払いに応じる能力があるか否か、がすべてであると思っています。

一介の個人プログラマーが、趣味で配布しているプログラムを使用した結果、物理的・金銭的な損失が発生した場合で、且つその原因が 100% プログラム側にあった場合 (つまり、損失が回避不可能であった場合) であっても、プログラマーに賠償義務が発生すべきではありません。これは、裏を返せば、損失補てんを望むのであれば、誰とも知らない個人が趣味で作ったようなプログラムを利用すべきではない、ということです。このようなリテラシーは、まともな企業であればどこでも持っているものです。この前提は、崩すべきではありません。

逆にいえば、企業に積極的に使って欲しいプログラムを配布するのであれば、それなりのサポート体制を構築した上で配布すべきです。一個人が財務諸表管理プログラムのデモ版を配布するのはアリですが、ホンモノの財務諸表管理プログラムを配布し、それを多くの企業に広く使ってもらいたいのであれば、会社を興し、あるいは基金を設立し、各種サポートを含めた有償のサービスを用意すべきです。

それから誤解があってはならないのですが、違法になるようなケースを同様に議論すべきではありません。個人配布ならプログラムに人を騙すような機能 (スパイウェアとかトロイとか) を忍ばせてもいいなんてことはない (不正指令電磁的記録等作成等の罪に問われる可能性…もっとも「作成」については微妙なところもありますが)。そういう意味でいうと、Winny のようなケースは微妙になってくるわけですが。

具体案としてはまぁ、そんなところかなぁ。

もっとも、フリーでのプログラム配布というのにもまた更にいろんな種類があって、例えばブログにちょっとした howto 的な、それも断片的なプログラムを掲載しているようなケースもあったりする。それを拾ってきて組み込んだプログラムが、拾ってきた部分のバグが原因でいろいろ被害が生じた場合に、責任をどこに求めるのか、とか、最初のプログラムを書いていたブログ主にも瑕疵保証責任は生じるのかとか、そもそも後者のプログラマーはブログ主の意図どおりの用途でプログラムを組み込んでいたのか、とか。あと、説明責任って話も出てきていたけど、話の流れでプログラム例を提示して見せたに過ぎないブログ主に、話の前後関係に関するすべての説明責任が発生しうるのかとか。そうやって考えていくと、だんだんプログラミングの「表現としての性質」に対する縛りが増えていって、技術方面の人々が発言に不便を強いられる世界が出来ていってしまう、っていう問題点もあったりする。その辺のバランスを法的にどう担保するのか、って辺りも結構難しい。とても今の安倍政権に任せられる議題とは思えないw。

マニュアルとかヘルプとかも重要ですね。そもそも、この動作は仕様なのかバグなのか、って辺りが曖昧になるケースがあって、それに対して企業が「仕様である」と発表することで難を逃れるケースが良くある。しかしこれは実は正しくなくて、そもそもユーザーにとっては重要であるはずの動作について、それがバグなのか仕様なのかが曖昧であるっていう状態は、すなわち本来マニュアルに記述されなければならない動作に関する記述が欠けているということなのであって、少なくともこれは文書バグであるわけです。で、文書バグだって立派なバグなのであって、文書上の不備が原因で人身に関わる回避不能な事故が発生する場合だってありうるわけです。開発ツールであれば、ドキュメントに間違ったことが書いてあることを原因として、セキュリティー上の欠陥を負ったプログラムが量産されるなんてこともありえない話ではない。そういった部分も合わせて保証されなければならない。これは当然のことでしょう。

と、まぁ、こんなところかなぁ。書いてていろいろとおかしな部分とかも散見されるかもしれないので、突っ込み大歓迎なのであります。。。

議論の意義2006年12月31日 15時31分55秒

久々にコメント欄が盛り上がった今日この頃。皆様いかがお過ごしでしょうか。先の議論が多くの人々にとって、意義のあるものであったことを、切に願うばかりであります。

おいらは議論の意義とは、知の共有であると思っております。もちろん、正解のない議論というものも間違いなく存在しますし、必ずしも結論を出さなければならないというわけでもありません。かといって、既に結論が出されている物事に対して、議論があってはならないとも思わないし、結論が出たらそれで必ず議論を閉じなければならないとも思わないわけです。

情報技術者が Winny などのファイル管理不能なファイル共有プログラムに対して取るべき見解については、共通認識が既に出来上がっていると言って良いと思います。それについては、「議論の余地はない」と言っても差し支えないでしょう。でも、「議論があってはならない」わけではありません。綿密に議論を通さなければ、そもそもこうした共通認識を、彼らが何故、理解できないのかを知ることもできないからです。このような知の共有は、共通認識として広めるべき事項を、どのようにして広めてゆくべきかと言う戦略を練る上で、重要になってくるのではないでしょうか。

hidew さんのケースでは、そのポイントは「Winny は非常に危険なツールである」という言葉に集約されているように思います。「Winny は危険」という固定観念のみが先行し、Winny が「何故、危険だと言われているのか」が十分に周知されていない現状が垣間見られたように思います。処方箋としては、おいらがコメントで書いたような、本人に説明させる、その上で、見識の相違点について説明する、というスタイルはそれなりに効果的なのではないかと思います。他に、他の類似する (同じように危険であるように見えて実は) 危険ではないケースとの比較を示すという方法も有効かもしれません (Winny はネットワークに繋がっているから危険→WinMX が Winny ほど危険ではないと言われる所以は? とか)。

もう一つ、重要な点として、メディアや書籍による影響力も、決して無視できない要素であるように思います。これらのソースから得られる情報の信憑性を評価するのは読み手・視聴者の責任だ、と言うのは簡単ですが、現実問題として、すべてのケースにおいてそれが絶対に可能な人というのはなかなかいないでしょう。その人にとって決して得意ではない分野であれば尚更です (多くの Winny ユーザーは情報技術者ではありません)。そういう人々が頼らざるを得ないメディアや書籍などの場において、素人談義が垂れ流されるべきではないのは確かです。もちろん、時代に応じたコンセンサスというのはありますので、湯浅氏の本を一方的に責めることはできません (つかそもそも読んでないから批判のしようもないけど)。対論を要するならば、誰かが正しい内容で本を出してバランスを取る必要があるかもしれません。

いずれにせよ、理解に乏しい人間が、誤った認識で発言を繰り返している状況に対して、「あきれた」とか、「どうしようもないね」とか、「まぁ一人ぐらいいいか」とか (^_^; 、ネガティブな心象を吐露するだけしてほったらかし、というのでは、到底フェアであるとは思えません。議論の場に引きずり込んだ以上、責任は果たすべきです。せめて、「ここにすべて書いている」っつってリンクを示すぐらいはしてあげて欲しいです。高木センセーに足りない部分があるとすれば、そういう部分なんではないかと思います。別に義務でもなんでもないんだけどね。

まぁ、でも、議論の場に引きずり込むこと自体にも、それなりに意義が無いわけではないので (事実おいらは有効に釣られたw)、それを差し控えさせたくて言っているわけでは無いのですが。

それでは、以上を持ちまして、年末のご挨拶に代えさせていただこうかと思いまする (なんちてw)。来年もよろしゅう。。。

旧メールアドレス停止しますた。2006年12月31日 23時59分59秒

年末までトップでお知らせです。

停止するメールアドレス

以下のメールアドレスを停止します。つか、しました。

  • murachi +++あっとまーく+++ harapeko.jp

受信拒否設定するメールアドレス

ASAHIネットの「ID宛メールの受信拒否設定」を利用し、以下のアドレスへのメールの受信を一切拒否する設定としました。

  • en8t-mrym XXXアットマークXXX asahi-net.or.jp

利用可能なメールアドレス

以下の通りです。

  • 通常用
    • mainハイフンwindow ☆☆AtToMaAkU☆☆ harapeko.jp
  • 非常用 (携帯電話に送信されます)
    • pハイフソtelハイ(略)info * art merc * harapekoどっとjp
  • ホットライン
    • 連絡くだされば作りまっせ(へっへっへ)

………さすがに警戒しすぎかしらw