忍者ブログ
プロフィール
メニュー
最新コメント
最新トラックバック
 ある企業Aの下に、ある個人の電子メールアドレスと病歴データのセットがあるとします。ここで、電子メールアドレスは「abc123@xyz.com」という、それ自体で個人を識別できるものではないとします(「taro-yamada@its-law.jp」というようなものであれば別ですが)。また、病歴データはプライバシー性が極めて高い、いわゆるセンシティブ情報ですが、これも通常はそれ自体で個人を識別できるものではありません(極めて特徴的な病態であれば別ですが)。したがって、この二つを組み合わせても個人が識別されることはなく、本人の権利利益を害するおそれもない、と(非常に危なっかしい感じはしますが)一応は言えます。

 このような情報における個人の識別性に対応して、個人情報保護法上も、個人情報とは「特定の個人を識別することができるもの(「他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む)」とされています。もっとも、括弧内の問題を含めると、普通の人にとっては個人情報ではないが、個人の特定のために容易に照合することができる情報を持っている人にとっては個人情報に当たる、という場合が出てきます。例えば、会員IDのような個人識別子を持つ通信事業者にとってのみ個人情報となる(そして本人の権利利益を害するおそれが出てくる)、通信ログのような場合です。これを「個人識別性の相対性」などと言います。先ほど「一応」と言ったのは、この点に関係します。
 この個人識別性の相対性のために、もともと個人情報でなかったもの(本人を害する危険のない情報)が、個人情報(本人を害する危険のある情報)に転化してしまうという現象が起こります。仮に、冒頭の情報の提供を受けたB社が、たまたま「abc123@xyz.com」がC氏のアドレスであるという情報を持っていた場合、B社はC氏の病歴データという個人情報を手に入れてしまうことになります。もちろん、この情報は、B社の下では個人情報になっていますから、B社が個人情報取扱事業者であれば、B社はこれを個人情報として適切に取り扱わなければならず、事前同意のない第三者提供も禁じられます。しかし、B社の位置にくる者が、どのような素性の者かは分かりません。
 これ(B社への提供)を個人データの第三者提供の限度で考えれば、電子メール情報のようなキー情報(他の情報と結びつける「共通項」「媒介項」となる情報)を持つ者への提供は、提供先で個人情報になる以上、個人情報の第三者提供であるという解釈をとる余地もないではありません(行為主体であるA社にとっては個人情報でないので、かなり無理な解釈ですが)。しかし、対応するキー情報を提供先が「たまたま」持っていた場合や、情報の提供を受けた提供先が後から対応するキー情報を取得する場合を考えれば、規制のしようもありません。問題は、情報の結合によって匿名情報が非匿名情報に転化すること自体にあるのです。
 インターネットによる電子データの拡散や、ライフログのような多様かつ非定型的な情報の存在を考えると、このような情報の結合は、いついかなる形で起こるか予測できません。個人情報の開示に(たとえ必要な場合でも)漠然とした不安感を伴うのは、このような情報の結合がその原因の一つとなっていることは間違いありません。実際、匿名であるはずのブログや掲示板で、しばしば個人が特定されて名誉棄損等の問題が起こるのも、このような情報の結合によるものと考えられます。法令上は個人情報に当たらないとしても、情報の第三者提供、それもセンシティブ情報やキー情報の第三者提供には、十分な注意をしたいものです。

拍手[1回]

PR
author : ITS 
 プログラム、すなわち「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」に著作権法上の保護が及び得るのは、以前に述べたとおりです。では、情報システムを構成する他の要素には、どのような保護が予定されているのでしょうか。

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

拍手[0回]

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

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

拍手[1回]

author : ITS 

 システム開発委託契約で、成果物の著作権をベンダとユーザのいずれに帰属させるのかは、激しく議論されているところです。ベンダからは、著作権法上の原則である、社会的な生産効率の向上につながる、ユーザの優越的地位の濫用の疑いがある、等々が主張されます。ユーザからは、開発費用を全部負担している、著作物には自己のノウハウが入っている、ベンダが倒産したら困る、等々が主張されます。しかし、このように抽象的に「どちらに帰属させるべきか」という議論は、本来おかしなものです。問題が政策論ではなく、契約論なのだとすれば、経済交渉の視点を欠いたまま結論が出せるわけがありません。

 本来は、契約の当事者が著作権に値段をつけて、取引すれば良いだけの話なのです。あれこれと理由をつけて綱引きをしているのは、それが契約金額が決まった後で、契約条項の交渉としてのみ行われるからです。要するに、著作権に値段がついていないから、タダだから、双方とも欲しがるのです。もし、ベンダが、著作権の取得によってライセンス・ビジネスが可能になるとか、ノウハウが蓄積されて将来の開発コスト低減につながるとか、具体的な見込みを持っているのであれば、「著作権留保なら2億円、著作権譲渡なら2億5千万円」というような見積提示になるでしょう(ネットの開発代金から著作権の分だけ足されるのか引かれるのかは、詮索する意味がありません。ネットの開発代金なるものも、所詮は交渉で決まるものだからです。)。この差額の5千万円がベンダにとっての著作権の価値です。同様に、ユーザでも著作権取得の場合と利用権のみ取得の場合とで、異なる予算を設定するでしょう。そして、その差額がベンダ提示の差額より大きければ著作権を取得するし、小さければ取得しないことになるでしょう。結局、著作権は、これを経済的により高く評価した方に帰属することになり、それだけの経済的価値を発揮するよう十分に活用されることでしょう。
 しかし、実際にこのような取引が行われているとは、聞いたことがありません。これは、結局のところ、ベンダもユーザも著作権をゼロ評価しているということなのでしょうか。タダならともかくお金を出して著作権を取得しても、それに見合った活用はできない、と考えているということなのでしょうか。

拍手[0回]

author : ITS 

 「納入物の著作権」で、カスタムシステムは「たとえ一部であっても、そのままでは使えない」と書きましたが、モデル契約書ではパッケージ化のような、より積極的な使い方を想定しています。しかし、純然たる汎用モジュールのようなものを除けば、これにはベンダにとっても大きな危険が潜んでいます。

 ベンダが同業他社向けに開発したシステムを「パッケージ」と称して安易に売り込み、ユーザも「機能が目に見える低廉なシステム」としてこれを受け入れた結果、開発が破綻する事例が後を絶ちません。理由は簡単です。こうしたシステムの開発では、カスタマイズがとどまるところなく続くからです。元が他社向けのカスタムシステムなのですから、当然と言えば当然です。ユーザが「パッケージ」を見て「これはいい」と言っても、頭の中にあるのは、自社向けにカスタマイズされた似ても似つかぬシステムです。ところが、その「パッケージ」の素晴らしさに自信を持っているベンダは、もう百里の途の九十九里まで来ていると思いがちです。結果、同床異夢の悲劇が生じます。
 業務についてもシステムについても標準化を徹底し、拡張性を十分考慮した本来のパッケージですら、カスタマイズを入れた途端、カスタマイズが新たなカスタマイズを呼び、システムの安定性は大きく損なわれます(パラメータ設定するものは別にして)。カスタムシステムでこれをやろうものなら、間違いなく稼働前に「サボテン化」します。
 工数のズレも深刻です。全体で100のボリュームのあるシステムがあるとします。これをカスタムメイドでやる場合、工数は100、ズレがシステム全体の2割出たとすればズレは20、工数は2割増です。ところが、これを工数20のカスタマイズでやろうとすると、ズレの総量は同じく20であっても、工数倍増ということになります。システムの規模に比べて工数が少ないが故の「レバレッジ効果」です。
 そうだからといって、パッケージ化そのものが否定されるわけではありません。初めから複数の企業に使われることを想定して標準化や拡張性に十分配慮しておく、費用負担や秘密保持についてもきちんと考慮しておく、これらのことをユーザを交えて事前にやっておくことです。これは、ベンダとユーザとの共同事業に他なりません。要するに、この問題は、再利用などという後づけの問題では済まないのです。著作権の帰属は前提問題に過ぎないのです。

拍手[1回]

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