忍者ブログ
プロフィール
メニュー
最新コメント
最新トラックバック
1  2  3  4  5  6  7  8 
 プログラム、すなわち「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」に著作権法上の保護が及び得るのは、以前に述べたとおりです。では、情報システムを構成する他の要素には、どのような保護が予定されているのでしょうか。

 まず、設計書やマニュアルのようなドキュメントがあります。これは明らかに「プログラム」ではありませんから、創作性等の要件を満たす場合に通常の著作物として保護されるにとどまります。したがって、著作権法47条の3の利用権はドキュメントには及ばず、これだけでは片手落ちになる危険があります。黙示の利用許諾が認められる場合が多いでしょうが、正しくは契約上の考慮が必要です。
 ハードウェアやネットワークなどのインフラは、それ自体には所有権以上の権利は発生しませんが(半導体集積回路のような特殊な例外はありますが)、その構成や設定は、ドキュメント化されている限り、著作権の対象となる余地があります。ただ、設定値であるデータの羅列は、創作性の余地がなく、秘密保持契約のようなもので事実上保護していくしかない場合が多いと思われます。
 意外に厄介なのがデータベースです。データベースにも、「その情報の選択又は体系的な構成によつて創作性を有するもの」には著作権法上の明示の保護が及びます(また、創作性に欠けても「費用や労力」の対価として法的に保護される場合もあります)が、これは(それ自体が著作物であったりなかったりする)データを組み合わせた「編集著作物」の一つですから、あくまで実データの入ったデータベースを意味します。つまり、データベース・レイアウトという「ガラ」は、ここで言う「データベース」には含まれません。
 もっとも、SQLで書かれたCREATE文の集合は、これを実行するとテーブルの作成という「一の結果」が生じるので、「プログラム」そのものと言って良いでしょう。しかし、単なるデータベース・レイアウトの定義が「一の結果」を生じさせると言うのは無理がありますから、ドキュメントとして通常著作物の範疇にとどまると思われます。しかも、レイアウトという背後のアイデアが決まると、ほぼ一義的に表現が出来上がってしまいますから、果たして著作物としての創作性が認められるか、心許ないところです。この点は、業務系でない、システム色の強いドキュメント全般に言えることですが。

拍手[0回]

PR
author : ITS 
 昨年の1月に、コンピュータ関連の著作物の利用の円滑化を図るための著作権法の改正がなされました。その中に、「電子計算機において、著作物を当該著作物の複製物を用いて利用する場合...情報処理の過程において、当該情報処理を円滑かつ効率的に行うために必要と認められる限度で、当該電子計算機の記録媒体に記録することができる」とする47条の8があります。この典型として、プログラムが実行時にメモリにロードされる場合が挙げられますが、これについては昔から議論がありました。

 もともとプログラムには、(法の要件を満たす限り)著作物として著作権法上の保護が及びます。もっとも、著作権法は複製等を中心に規律するものなので、プログラムを単に使用することは、著作権法の枠外の問題ということになります。これは、本をコピーすることは法に触れても、読むこと自体は自由であるのと同じ理屈です。良くあるプログラムの使用許諾ライセンスも、必ずしも著作権法上の権利の許諾なのではなく(それも含まれますが)、プログラムを事実上提供して使用できる状態に置く、という意味合いが強いわけです。
 ただ、プログラムを使用する場合には必然的にメモリへのロードという複製を伴うので、結局のところ複製権の侵害になってしまうのではないか、という問題が残ります。しかし、これは改正前でも侵害に当たらない、というのがほぼ確立された見解でした。理屈はいろいろですが、簡単に言えば、法が勝手な複製を禁じているのは、コピーが作成されると権利者がオリジナルについて持っていた著作物に対するコントロールがそれだけ減殺されるからであるが、プログラムの実行時にメモリにロードされたからといってそのような問題は生じないから、ということです。
 実際、プログラムの使用に関して、著作権法第113条2項は「プログラムの著作物の著作権を侵害する行為によつて作成された複製物を業務上電子計算機において使用する行為は、これらの複製物を使用する権原を取得した時に情を知つていた場合に限り、当該著作権を侵害する行為とみなす。」と規定しています。「みなす」とは、本来そうでないものをそうであると扱うことを言いますから、この規定は、プログラムの使用が本来は著作権の侵害に当たらないことを前提にしているわけです。
 この問題は、もう少し広げて考えると、コンピュータの利用に伴う著作物の一時的蓄積(メモリロードやバッファリングが典型です)が著作権法上の複製として侵害行為となるのか、という問題に通じています。欧米諸国の多くでは、物理的な複製を伴う行為をひとまず複製と見た上で、権利侵害と見るべきでない行為を個別的に対象から除外していくというアプローチを採っています。これに対して、日本では、実質的な侵害性のある行為だけを複製であると解釈するというアプローチを採っていると言われていました。今回の改正は、そのような日本法の土壌の中に、欧米アプローチを持ち込んだようにも見えます。条文として書かれた内容は妥当(むしろ従前からの解釈の条文化)だとしても、逆に、条文化から外れたグレーゾーンは黒と解釈されることになるのか、少なくとも黒と解釈され易くなるのか、気になるところです。

拍手[1回]

author : ITS 
 IT紛争を抽象的に論じるとき、「ベンダ対ユーザ」という観点、すなわち「党派性」が色濃く出ます。同じ論点についての考え方一つをとってみても、ユーザの見方とベンダの見方では(類型的に)180度違います。

 例えば、(望ましくない)仕様変更が生じてしまったとして、ベンダから見ればユーザの我儘であって契約範囲外のこと、ユーザから見れば仕様確定に至る当然の道筋であって契約範囲内のこと、となります。医療過誤事件での「医師(病院)対患者」、労働事件での「使用者対労働者」さながらです(もっとも、これらの分野では、当事者ではないはずの弁護士も、自己の信念その他諸々の理由から何れか一方の党派の代理しかしない、あるいはそうならざるを得ないということがあるとも聞きますが、IT分野では、弁護士が少ないこともあってか、そのようなことはないようです。)。
 同じことは、紛争にまで至らない場面でも言えます。契約書のあり方一つをとってみても、ベンダとユーザでは契約上のリスクの所在や、それに対するコントロールの可能性・方法がまったく違いますから、相手方が提示するものはもちろん、一般的なひな形であっても、これを安易に受け入れることは、実は大変に危険なことなのです。
 他方、ITには「技術」としての合理性が支配する(はずの)広大な領域があります。ここで、「技術」というのは、ハードウェアやソフトウェアの技術に限られません。マネジメントやコミュニケーションもまた、ITを論ずる際の不可欠の技術です。先に例として挙げた仕様変更も、多くの場合、組織としての意思がとりまとめられ、これが伝達される過程での、マネジメントやコミュニケーションのミスから生じます。その合理性がどこにあるかを見極めない限り、同じ失敗が繰り返されます。
 しばしば、党派性を帯びた議論は、こうした技術的な合理性を見る目を曇らせることがあります。有事の際に党派性が前面に出るのはやむを得ないとしても、平静にあるとき、合理性を見る目を養っておきたいものです。

拍手[0回]

author : ITS 
 存続条項というものがあります。例えば、「第25条 本契約の終了後においても、第○条、第○条、第○条の各規定は、なお有効なものとして存続する。」というようなものです。後払の支払義務や担保責任などが、契約期間が終了した途端に無効になってしまわないための条項です。

 ところで、列挙する条項の中に、25条自体は要るでしょうか。論理パズルのようですが、契約終了と同時に25条自体が無効になると考えるなら、それを心配して、その中に自らの存続根拠を入れておいても意味がないことになります。他に何の対処もしなくて大丈夫かは別にして、入れる実益はありません。
 他に何かの対処が必要か、これは突き詰めると良く分からなくなりますが(契約終了後も存続条項は「超法規的」に有効であると考えるなら、何も要らないことになります。)、何れにしても、さほど意味のある議論ではありません。契約の「余後効」などを持ち出すまでもなく、権利義務の性質上、契約の終了後に(も)機能すべきものは、解釈上、当然に有効と解されます。存続条項がなくても、後払の支払義務が契約期間の終了と共に消えるというような解釈は、少なくとも日本の裁判所では絶対に出ません。
 ただ、IT系の契約書では必須の秘密保持条項のような、原則としてその有効期間が契約期間に限られると考えられる条項の場合は別です。秘密保持義務を契約期間の終了後にまで及ぼしたいと考えるなら、「この契約の終了後も○年間は...」というのを入れておく必要があります。
 ただし、有効期間を限定しないのは、たとえ義務を負うのが相手方だけだとしても、いただけません。裁判所は、契約当事者を永久に秘密保持義務で縛るようなことは、合理的意思とは言えないと考えて、その効力を5年間に限ってしまうかも知れません。秘密漏示が7年後に起きたとして、「この契約の終了後も10年間は...」と入れておけば良かったものを。ここでは、「大は小を兼ねる」ではなく、「過ぎたるは及ばざるが如し」が妥当します。

拍手[5回]

author : ITS 
 システム開発が頓挫した場合のユーザとベンダの紛争には、「屈曲点」とでも言うべきものがあります。ある段階までは本格的な紛争になりにくく、ある段階を超えると極めて熾烈な紛争になる、ということです。

 本格的な紛争になりにくい方の理由は、容易に分かります。ひとたび開発に入ってしまうと、ユーザとベンダは互いの肝を握り合うような関係となるからです。ユーザは何としても期限までに望むシステムを手に入れなければならず、そのためには少々妥協しても開発を継続するしかありません。ベンダも、多大の労務を先行投入してしまった以上、何としてもこれを回収しなければならず、そのためには少々妥協しても開発を継続するしかありません。ここで奇妙な均衡が出来上がり、紛争化は先送りにされます。実際、開発プロジェクトの7割は失敗であるなどという説もあるにも拘らず、裁判にまで至る紛争は数えるほどしかありません。ただし、この点が重要なのですが、納期が絶対的である場合や、ベンダが中間金を得ている場合などでは、均衡は崩れ、紛争化が早まる場合があります。
 熾烈な紛争になる方の理由は、あまり注目されることはないようですが、これもある意味当たり前だからかも知れません。紛争の「幅」が極めて大きいためです。これは、例えば、マンションに欠陥があって契約が解除されるという場合と、システムに欠陥があって契約が解除されるという場合を比較してみれば明らかです。マンションの方は、仮に契約が解除されても、売主の方に(欠陥はあるとしても)マンションが残ります。代金が返還されれば、買主側にもそれ以上大きな損害が残るわけではありません。ところが、システムの場合、解除されたベンダのもとに残るシステムは、ユーザに固有のカスタム品であって通常まったくの無価値です。しかも、多くの場合、想定以上に膨れ上がった開発費用の負担がまるまる残ります。他方、ユーザも、たとえ代金が返還されても、既に多大の労力を(そのシステム以外には役に立てられない形で)費やしてしまっています。実際、システム開発がらみの裁判例をみると、反訴提起されているものが非常に多いことに気づきます。
 紛争の見立てを行う場合、こうした点を十分考慮に入れておく必要があります。

拍手[1回]

author : ITS 
忍者ブログ | [PR]
 | PAGE TOP
write | reply | admin