パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

日本政府もオープンソースなOSを積極的採用へ」記事へのコメント

  • by manba256 (10135) on 2002年11月16日 9時33分 (#201274) 日記
    オープンソースのOSにバグが発覚した時に誰の責任になるのでしょうか?
    バグが発見されて、パッチが公開されたとして、そのパッチをあてる責任は誰になるのでしょう。
    パッチが公開されたと言っても、例えばLinuxであれば、そのディストリビューションのサイトでパッチが公開されていない場合、管理者にパッチをあてる責任はあるのでしょうか?
    権威のないサイトから取ってきたパッチに信用性はあるのでしょうか?
    権威のあるサイトが書き変えられてはいないでしょうか?
    パッチの内容を検証をする責任は誰が負うのでしょうか?
    パッチが未公開の場合、作成する義務があるのでしょうか?
    そういう責任を明確化しなければ、そうとう危険な気がします。

    しかし、UNIXであれば、スーパーユーザーを持つ「管理者」に相当大きな負担がかかりそうです。
    責任を明確化すると誰もやりたがらなくなるかもしれません。

    うち大学でも、未だに重大なセキュリティホールのあるapacheやsshなどを使って、安全そうな顔をして平気でいます。
    管理者がぼーっとしていて、踏台に使われることもしばしばあるようです。
    それでも責任はちっとも明確化されていません。
    もちろんこれはオープンソースのソフトウェアに限った問題ではありません。

    安全性が高いから、とかコストが安いから、とか言う前に、責任の所在をはっきりしてほしいものです。
    と言っても、縦割りの官僚社会の中では理系はとにかく責任を負いたくないし、文系は責任を負わせようにも、中身のことがわからんから何も言えんのやろうけど。
    やれやれ
    --
    ------------------------- Excess and Obsolete
    • ほほぅ (スコア:4, すばらしい洞察)

      by KENN (3839) on 2002年11月16日 10時14分 (#201287) 日記

      その理屈でいくと、オープンソースじゃないOSを使えばこんな発言 [srad.jp]やあんな発言 [srad.jp]は出てこない、ということになりませんか?

      親コメント
      • by Anonymous Coward
        オフトピですいません。
        リンクをクリックすればいいのはもちろんわかるのですが、
        「こんな発言」「あんな発言」だけではなくて、もう少し
        わかりやすくして頂けると嬉しいです。
        (webユーザビリティ的にもアレかと)
        • by shitara (392) on 2002年11月19日 2時32分 (#202917)
          今頃出てきてすいません。発端をかいた者です。

          私の言いたかったことは、zymaseさんがおっしゃった「みんながハッピー」に集約されてます。
          ただ、G7さんのおっしゃってる内容もわかります。
          要約を書く書かないのどちらが正しいかなんて私にはわかりませんが、基準というか論点をどこに置くかで答えが変わってしまうのかもしれません。

          私は、どっちが人にやさしいかという基準で、要約があったほうがいいなと思った次第です。
          親コメント
    • 職員一人一人が使うパソコンに Linux を入れる場合は別問題ですが、、

      政府がシステムを導入する場合、OS、DB、アプリケーションサーバーを
      コンポーネントで買ってきて自分で組み立てて使うなんてはずはなく、
      システムインテグレータを呼んできて入札するわけですよね。
      そのとき「OS はオープンソースのものでも OK よ~ん」という条項が
      つくって話でしょう。

      元もと、納入したシステムにバグが出たとしたら、そのバグの原因が
      コンポーネントの一部にあるとしても、顧客に対する責任は納入した
      業者にあるでしょう。これは MS-Windows を使おうが、Linux を使お
      うが同じ話で、顧客にすぎない官僚には責任はないでしょう。

      バグフィックスやアップデートも、サポート契約を結んで納入した業者
      にやらせるのものでしょうし、やらせるべきです。
      --
      コンタミは発見の母
      親コメント
      • ベンダーの機会 (スコア:3, すばらしい洞察)

        by Technobose (6861) on 2002年11月16日 19時31分 (#201548) 日記
         FreeBSDのようなBSDライセンス系やLinuxを初めとするGNUライセンスのソフトの場合、ベンダーに技術とやる気があれば、中身に自分で手を入れられるので、今までよりも製品に対して責任を負いやすくなり、またビジネスチャンスも増えるように思います。これは政府や自治体相手に限らずです。
         ただ納品した製品で使われているOSやミドルウェアのほとんどに自社で手を入れられるとしても、実際に手をかけられるのは、IBMやNECのような大企業のみかもしれません。
         BSD系やGNUなどのソフト採用の機会を増やすなら、中小ベンダーや個人などにもチャンスが広がるような手だてを尽くしてほしいです。
         あ、私はこの場合、ユーザーの側にたつ人間です。(^_^;)
         ただ今までの公共投資って、おいしいところが地元の人たちにわたってないような感じがします。今後、投資が伸びると思われるIT関連では、政府や自治体の公共投資のできるだけ多くを直接、働いている人に渡るような方針で行うべきだと思います。
        親コメント
        • by Anonymous Coward
          その通りだと思います。
          んで、公共投資が地域の企業にうまく配分されるためには、
          まず、政治を地方自治へ分散化するのが先決だとも思います。
      • バグが無くても運用がタコなら、結局は穴だらけですわな

        で、運用は業者が全てやるとは限らんのだよな

        そこまで面倒見られる業者なんか、ほんの一部だと思うんだが?
        --


        (_ _)ZZZZzzzzz...... I'm sleepy
        親コメント
        • そこまで面倒見られる業者なんか、ほんの一部だと思うんだが?
          そーいうのを面倒見るかどうかは契約時に決めること。
          契約してて面倒見てないんなら契約違反です。
          • 運用まで全部、面倒みるなら、それはアウトソーシングということになるのだが、運用そのものを全部、アウトソーシングしてしまえるだけの会社は少ないと思うが?

            普通はせいぜい、運用要員を他の会社から雇うのが精一杯ではないかと?

            つか、国の施設もアウトソーシングで済まそうなんて、普通は無理だろうけどねぃ
            --


            (_ _)ZZZZzzzzz...... I'm sleepy
            親コメント
    • by kine (11700) on 2002年11月16日 12時28分 (#201370)
      > しかし、UNIXであれば、スーパーユーザーを持つ「管理者」に
      > 相当大きな負担がかかりそうです。

      「UNIXだから大変」とか「UNIXじゃないから楽」ということは無いでしょう。
      まともに管理しようとすれば、OSが何であろうとそれなりの手間がかかるのは
      当たり前では?
      親コメント
    • by Kow (2603) on 2002年11月16日 20時11分 (#201565) ホームページ 日記
      |オープンソースのOSにバグが発覚した時に誰の責任になるのでしょうか

      導入した側でバグが発覚した責任を問うのはおかしく無いですか?
      追求するならば「バグを突かれて被害が出た時の責任」ではないでしょうか?
      バグが見つかったということはそれを塞げば被害を事前に防げる可能性があるわけですから。
      オープンソースではバグを見つけた人がそれを直す確立は高くないですか?
      (この場合の「バグを見つける」は「バグの現象に出くわした」とは違います)

      「バグだバグだ、誰だこんなの導入したのは、誰の責任だ、誰だ、誰だ!」

      などとやっている暇あったらもう一歩引いて全体を見渡したほうがいいでしょう。
      そんなに近くちゃ世界中のハッカーが動き回ってるのが見えませんよ?
      親コメント
    • by Anonymous Coward on 2002年11月16日 9時45分 (#201278)
      非オープンソースでもバグが発覚したときの責任は製造者側は
      負わない。 大概のライセンスにそう書いてある。

      ふつーどこが責任を負って対処するかというとそのソリュー
      ションを提供した業者(もちろん契約内容に拠るが)
      そうなるとオープンソースであろうがなかろうが関係ないのだな。

      業者を介さず自分達で導入したものであれば明らかに自分達の
      責任ですよ。これもまたオープンソースであろうがなかろうが
      関係なくね。
      親コメント
      • >ふつーどこが責任を負って対処するかというとそのソリュー
        >ションを提供した業者(もちろん契約内容に拠るが)
        >そうなるとオープンソースであろうがなかろうが関係ないのだな。

         理屈では当然そうなのだが、「契約内容を無視して」自分達で責任を負えない契約主をなんとかしてくだ
      • 20年前の汎用機だと現場プログラミングは常識。
        オープンソース化でその常識に戻るだけと思われ。
        • 汎用機の常識なんぞ持ち込んで欲しくないね。
        • となりのACと同じく、
          20年前の常識なんぞ持ち込んで欲しくないね。

          時代が時代だからなぁ。
          • by Anonymous Coward on 2002年11月16日 12時57分 (#201379)
            おいおい。
            この場合、是非を評価されるべき点は「現場プログラミングが常識として認められる」ことで、「常識の新旧」ではないだろう。
            新しいものは何でも古いものより必ず優れているのか?
            二言目には「時代が違う」と言う人がいるが、「新しい時代」を生きる人間は「古い時代」を生きた人間よりそんなに賢いのか?
            「新時代の最先端を行ってる」気分になりたいだけでは無いのか?
            本当に重要なのは時代や業界に関係なく、先人の良い点・悪い点を謙虚に咀嚼・吟味・評価して、その経験を活かす事だろう。
            親コメント
            • by Anonymous Coward on 2002年11月16日 16時25分 (#201466)
              > 本当に重要なのは時代や業界に関係なく、先人の良い点・悪い点を謙虚に咀嚼・吟味・評価して、その経験を活かす事だろう。

              その結果として、古いものより優れている新しいものを作る・使う・広めるというのが重要でしょう。

              #201379のコメントはちょっと哀しい。
              親コメント
              • >古いものより優れている新しいものを作る・使う・広めるというのが重要でしょう。

                逆の話をしているのでは?と、ふと思いました。
                つまり、もしかして過去より今のほうが「劣って」いるのでは?という。

                確かに「明日」のために今日、新しくて優れているものを頑張って作って用意するのは、重要なことです。
                が、それと、「今日」使われているものが既に優れているかどうか、は別のことです。

                明日のものを作るために参考にするのに相応しいものが、実は今日のものではなく過去のものである、
                ということはありえると思います。

                そして、それはこの話題については、案外当てはまっているのでは…という不安は、あります。

                #なんで不安かというと、俺もその「今日」に生きているからであって、G7
                親コメント
            • まさしく同感ですな。大体、現在使われている技術だって、 汎用機で使われていた技術とそれほど変わっているわけじゃないし。
            • by Anonymous Coward
              >この場合、是非を評価されるべき点は「現場プログラミングが常識として認められる」ことで、「常識の新旧」ではないだろう。

              激しく同意。

              ただ、それでも現場プログラミングは広まらない罠。

              #プログラムが組めなくても、
              #サーバの管理はできる。
              #その逆もまた同じ。
              • >ただ、それでも現場プログラミングは広まらない罠。
                ユーザ側の立場で言うと,うちの会社(製造業)ではUNIX系のシステムでも普通に現場プログラムを要求してます. もちろん規模と重要度によりますし,呼ぶのもテスト~立ち上げの時期のことが普通ですが.
                • 開発中の製品データは社外に出せない.(=データ
          • 20年前の常識なんぞ持ち込んで欲しくないね。

            現在の常識も20年前とそれ程かわっていないとおもわれ

            あと、責任については発注金額が高い分メーカーがOSに手を入れてくれるぐらいしてくれる。まあ責任をお金でかっているだけですけど。昔から。

        • なるほど、こんな常識か。

          http://www.amy.hi-ho.ne.jp/~lepton/program/p2/prog245.html
    • まず、セキュリティアップのためにというお題目がついているのですから、
      セキュリティ対策費みたいな項目を予算化しやすくなるのではないかと。
      予算さえつけば、本来契約外なのに業者に押しつけるとか、外に出せないで
      現場の人が泣くとかの可能性が少しは減るのでは。

      予算化されてれば、発注側と受注側の責任範囲も明確にしやすいでしょう。
      もっとも、官僚組織というのは責任の所在を不明確にするためのものだったり...。
      親コメント
    • 商用ソフトでも、管理者がしっかりしてないと、安全ではないです。 オープンソースのほうが、自己責任で現実的にはより安全ではないですか。 ところで、責任とるとは具体的にはどういうことですか? 管理者が減給処分?
    • そう思っているなら幸せです。
      問題が起きた時のオープンソース/クローズの違いは文句の捌け口
      があるかないかでしかないです。
      いずれにしても、誰かがやってくれるわけじゃないです。
      結局は導入した自分達の責任です。
      • by Anonymous Coward on 2002年11月16日 11時08分 (#201331)
        その、Sunに関してですが。

        Solarisにはapacheが付いています。
        自分でup-to-dateなものをインストールしたりせずに
        OS付属のものを使えば、Sunはそのapacheを
        サポート対象としてくれます。

        ここでいうサポートというのは、バグに対してSun内部の
        バグIDを振って管理してくれるということです。
        客: 「なんかapacheが変な挙動するんですけど」
        Sun:「ああ、バグ登録されています。今patch作ってます」

        そして出てきたpatchをあててみると、apacheのバージョンが
        上がっている、と。もちろん、そのapacheもサポート対象ですが。
        親コメント
      • で、責任はどちらにしろ自分達にあるわけだから、責任転嫁もできなければ自己解決もなかなかできないクローズドなものよりも、責任は自分にあるのはしょうがないけどそれなりに自分で解決することができるのでオープンソースのほうがいい。

        責任問題に関してオープンなのとクローズドなのとどちらがいいかといったら、こういうことになるんだと思います。
        --
        // Give me chocolates!
        親コメント
        • 責任を負いたがらない人たちが責任転嫁できないものを取り入れる訳がないのだが…。

          ま、結局は業者に全ての責任を負わせるんだけどね、
          つまり、何を使っても一緒。
          彼らに大事なのは「やってますと言う”ポーズ”」のみ。
          そこから生まれるものなんて興味ゼロ。

          それが官僚。
          泣くのは業者。
          この構図は未来永劫変わらない。
    • パッチ作りの専門部署を作るのかと思った。
      公務員ハッカー…かっこよくない?

日本発のオープンソースソフトウェアは42件 -- ある官僚

処理中...