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

オープンソース政策討論会@RIETIのお知らせ」記事へのコメント

  • 特許や著作権侵害をたてに訴えられた場合や、逆に著作権侵害された
    場合の訴訟費用を負担してくれる仕組みが欲しいかなぁと。
    #法律相談所&交渉支援体制も。

    あと、一定要件を満たした場合に登録可能な、公的な登録制度が
    あると、ありがたいかなぁ、、、
    #いつからそのソースが公開されているかを公的に証明出来るように。
    • >#いつからそのソースが公開されているかを公的に証明出来るように。

      著作権法第76条の二 [e-gov.go.jp]ではいけませんか?

      その方法はプログラムの著作物に係る登録の特例に関する法律 [e-gov.go.jp]に。

      マイクロフィッシュまたはマイクロフィルムってのがなんとも。
      • by Anonymous Coward
        #328568の元ACです。

        ご指摘の条文ではソースが日々変化するオープンソースの開発に
        対応できないのではないかと思いますが、いかがでしょうか。
        #開発中も公開されてしまうプログラムの保護を考慮した条文とは
        #思えませんよね。

        私の言いたかったのはCVSなどソースツリーの改変に対し
        • > #開発中も公開されてしまうプログラムの保護を考慮した条文とは
          > #思えませんよね。

          これはその通りです。印刷媒体であることからしても、ある時点での「完成品」が対象ですね。

          > 私の言いたかったのはCVSなどソースツリーの改変に対してもその
          > 成立に公的な証明を出せる仕組みがあったほうが良いのでは
          > ないかということです

          そうすると、やはり国営(まあ独立行政法人の運営でも)の開発支援環境を整備して、ソースのメンテナンス状況を含めオーソライズする、ということでしょうか。それはそれで開発コミュニティに対する経済的負担を
          • お相手いただきありがとうございます。元ACです。

            > そうすると、やはり国営(まあ独立行政法人の運営でも)の開発支
            > 援環境を整備して、ソースのメンテナンス状況を含めオーソライズ
            > する、ということでしょうか。それはそれで開発コミュニティに対
            > する経済的負担を減らす役割はあるでしょう。

            べつに開発支援環境を用意してもらわないでも、勝手にソース
            ツリーに加えられた改変を記録してくれるDBを用意してくれれば
            良いのです。
            #単純にmirrorサーバでよい、というか、開発者からは直接手を
            #加えられない方が良いわけで。

            重要なのは、著作権や特許の
            • SCO vs Linuxじゃないけど、開発過程がクリーンであることを あらかじめ保証する制度があれば、

              現実問題として、それは誰にもできない事じゃないかな?
              開発者の誰かがNDAを結んでいる事はわかるかもしれないけど、どこともNDAを結んでいないあるいはそのようなリソースにアクセスしていない事を外見上判断するのは難しいですよ。

              # 四六時中公安が付いて回って行動をトレースし、郵便物やネットの通信内容は全て検閲とかするなら別ですが :-D

              開発者本人の自主申告(と良心)に頼るんだと保証はできないでしょう。

              重要なのは、著作権や特許の侵害で訴えられたとき、

              • 特許についてはフォローが付いていますので、著作権のほうに関して。

                > > SCO vs Linuxじゃないけど、開発過程がクリーンであることをあらかじめ保証
                > > する制度があれば、
                >
                > 現実問題として、それは誰にもできない事じゃないかな?

                一応互換製品を開発する際のクリーンルーム方式 [nifty.com]というのがその方法だと思います。確か米国では合法との判例がでています。日本では合法と言われていますが判例は無かったような(どなたかご存知であればコメントを下さいな)。

                この方式は(1)解析チームと開発チームを分離して、(2)解析チームは対象物にアクセスし(REを行い)外部仕様書を作成、(3)開発チームは対象物にアクセスしていない旨宣誓するか何かしてそれを証明し、外部仕様書のみに基づいて開発を行う、というものです。

                従って、開発プロセスはオープンソースとは何の繋がりも無いものです(というか別概念ですね)。

                もしかしたら、政府機関が物理的な「クリーンルーム」とそれを運営する組織を用意して、非オープンなソフトウェアを解析してオープンソースな互換製品を開発することを支援する、というような「ソフトウェア・ロンダリング政策」?を実行することも妄想できますが、非関税障壁とか何とかいろいろ課題はありそうです。

                また、ソフトウェアに含まれる特許権に関しては、クリーンルーム方式で開発したからといって洗浄できるわけではありません。別々に思いついたものでも、先に思いついたほう(米国など)か、先に出願したほう(日本など)が独占できるのが特許なので。

                > 公証人のような形で、(それがクリーンなコードかどうかは別に)そのコード
                > がどの時点で存在し、誰が書いたかという事を証明してくれれば、著作権上の
                > 問題(どっちがパクったかとかの問題)には有効でしょうね。

                一応、先行してコードを作成済みであったことの証明は、ソースコードが非公開な製品との係争の場合、それだけでは十分でないものの、場合により(その製品のバイナリが公開される前に自分がソースを作成していたと証明できれば独立した著作物だと証明可能)意味はあると思います。
                親コメント

吾輩はリファレンスである。名前はまだ無い -- perlの中の人

処理中...