知的財産権 概論 著作権法に見る知的財産権 特集プログラマのための 拡大するソフトウェア保護の実態と問題点 財ソフトウェア情報センター , ソフトウェアはいったいどのように法的に保護一、産物であるソプトウェアは絵画や小説と異なる されるべきなのだろうかよ上こまでプログラマ、のばいうまでもなくまた般的な工業製品 とも異なるよの独特な存在形態故ににソフト の創意が認められるのであろうかよ知的財産権 ウェアの法的保護には難問がつきまとうよ現在 は知的・精神的創作物保護を目的とする諸権利 の総称であり引現在ソフトウェアはこの知的財のシフウ土アの法的保護の実態とその問題点 産権によって保護されている。しかし 3 知的生 を考察しあるべき知的財産権の姿を模索する。 P R T A 4 「著作権法によってソフトウェアは保護される」というのか世界的潮流で ある。しかし文学や音楽などの著作物を保護する著作権法によって , ソフトウェアを法的に保護するには無理かありはしないか。著作権法か ら見たソフトウェアの知的財産権保護の実態を紹介する。 ついて成立する諸権利の総称て、ある。知的 法 , 商標法 , 著作権法 , 不正競争防止法 , 財産権は大別すると , 産業上の諸権利の保 トレードシークレット法 , 半導体集積回路 知的財産権の概要 護を目的とした工業所有権と , 文化的創作 保護法 , 種苗法などがある (TabIe 1 参照 ) 。 物の権利の保護をおもな目的とした著作権 トレードシークレット法は英米法系の国 知的財産権とは , 産業上経済的価値のあ とにわかれ , それぞれ個別の法律に基づい て、採用しており , 米国て、は州法に定めてい る発明・考案のような技術思想 , 商品や包 て保護を受け , 各対象となっている知的財 る。トレードシークレットとは , 技術ノウ 装紙のデザインのような意匠 , 商品名 , / 産を排他的に支配・利用て、きる権利が保障 ハウや顧客名簿などを含む経済的価値をも ウハウを含む企業秘密などから , 文化的価 っ秘密情報て、ある。わが国てはこの法律に される。 値のある文芸 , 芸術分野などの創作物にお 代わるものとして , 平成 2 年 ( 1990 年 ) 6 月 22 それぞれの具体的な保護の根拠となるお よぶ人類の知的・精神的創作活動の産物に もな法律には , 特許法 , 実用新案法 , 意匠 日に不正競争防止法が改正され , 生産・販 34 C MAGAZINE 1991 6
特集・プログラマのための 知的財産権 している。プログラムの発明性については , さて , WheIan 対 JasIow 事件が , 法律専 覚による総体的な印象をいうものて、ある。 門家の間て、さまざまな議論を呼んだのは当 従来から特許庁を中心に専門家の間て、種々 1976 ~ 77 年ごろに , 子供向けの本 , グリー 然のことて、あったが , 注目すべきは , 米国 ティングカード , ファンタジーなどの著作 の議論がなされてきた。 物の訴訟て、適用された概念て、ある。この考 議論の内容は , 三つに大別される。第 1 は のコンヒ。ュータ関連産業がこの判決内容を え方を技術的精密な分析 , あるいは技術専 肯定説て、あり , 第 2 は否定説て、あり , 第 3 は 強く支持したことて、あった。プログラムに その中間説て、ある。 ついては , 単なる文字的な表現 ( コード ) だ 門的な証明が必要とされるプログラム関連 訴訟に無批判に用いられていいものか , 疑 けて、なく , アイデアも含めて保護してほし 第 1 の肯定説は , 「プログラムはコンヒ。ュ 間を感じざるをえない。米国の学者たちも いというのが , その、、本音〃て、はないか。そ ータに一連の動作を生じさせるものて、ある して , 著作権法の枠内て、 , そのような産業 疑問を抱いているようて、ある。 が , コンヒ。ュータの各部の動作はすべて自 界の、、本音〃に応えるためには , 可能なかぎ プログラムは , 小説や絵画 , 音楽などの 然法則の利用によるものて、あり , したがっ 従来の著作物と比べ りの拡大解釈が必要て、あろうと思われる。 言語と目的による制 て , プログラムは , 自然法則を利用した技 約が強い。 拡大解釈のための理論構成は法律専門家の また , 豊富な言葉を使って美的 術的思想の創作て、ある」とするものてある。 仕事て、あるが , 現在の著作権法の枠内て、現 な表現をするのて、はなく , 機能効率の向上 第 2 の否定説は , 「肯定説がプログラムの 実に対応する際に , 拡大解釈以外に方法が を考えているのて、あるから , 表現の自由度 効用・効果を見てプログラム自体を見てい は伝統的著作物に比し非常に低いといわざ ないと指摘する。プログラムそのものは , ないと・すれば , ある意味て、は , その法律自 数学的 , 論理的機能単位から成っており , るをえない。したがって , 類似性の主張が 体が法律生命を失いつつあるのて、はないか どこまて、可能て、あるか , 法律専門家の研究 とも考えられる。 プログラムによって問題が解けるのは , 数 学的 , 論理的性質を正しく利用しているか , 前項て、説明したように , 著作権法 成果を待ちたい らて、ある。それは , 数学的または論理的法 の世界て、は , いわゆる、、海賊版〃が権利侵害 以上 , コンヒ。ュータブログラムの権利保 護に関する著作権法の世界の一側面を見た となることは当然て、あるが , 「 Similarity( 類 則の利用て、あって , 自然法則の利用とは関 が , 一言て、総括すれば , 極めて不安定な世 係ない。したがって , 発明性は認められな 似性 ) 」があっても侵害を認定される。とこ 界て、あるということにつきよう。 い」という考え方て、ある。 ろが , この類似性についても一般的な判断 第 3 の中間説とは , 「解決しようとする問 基準があるわけて、はない。ケースパイケー 題が自然法則の利用に関する技術的課題な スの判断を待つ以外にないのて、ある。 らば , その解法は自然法則を利用したもの たとえば , 米国の税関て、は , 輸入プログ と考えられるから , そのようなプログラム ラムの記述の中に , 一定の割合 ( 30 % といわ 特許による保護がまれなケースと受け取 は自然法則を利用した技術的思想の創作 , れているが , 公表はされていない ) て、同じス られ , ひたすら著作権による保護が社会の すなわち発明として特許性を有するものと テップがあれば , 違法プログラムと判断さ 関心を集めてきたが , こ数年間 , 急速に いうべきて、ある」というものて、ある。この説 れ , 通関が差止になるといわれている。事 ソフトウェア関連発明に特許が与えられて に従えば , プログラムの種類によって判断 実とすれば , まったく横暴な話といわざる いる。また , 本年 3 月 25 日には岡山県のある が異なってくるのは当然てある。 をえない。何パーセントかの類似によって 特許管理会社が , ソフトウェア関連特許に このような議論が繰り返される中て , わ 全体としてのプログラムの類似を判断する かかる侵害差止請求訴訟を起こしているこ が国の特許庁は , 昭和 50 年 ( 1975 年 ) 3 月 , プ といった恣意的なやり方は , とても公正な とからもわかるとおり , ソフトウェア特許 ものとはいえないて、あろう。 ログラムに関する出願の審査基準を公表し に対する関心が急速に高まっている。 た。同審査基準の考え方は , プログラムが また , 米国のプログラム関連訴訟におい ソフトウェア特許の実態に関する資料情 コンヒ。ュータの使用を前提としている点て て当該プログラムの類似性を証明する際に 報 , ソフトウェア特許保護上の諸問題に関 「 Look & Feel 」というスタンダードが , し は自然法則の利用といえても , それは一般 する議論はいまだ不足しているが , これま 的なものて、 , 個々のプログラムの特有のも ばしば適用されている (Atari lnc. 対 て、の議論を中心として , 以下に特許の世界 のとはいえない。したがって , 個々のプロ Amusement WorId lnc. , Broderbund を摘記してみよう。 グラムの発明性は認められない。しかし , Software 対 Unison WorId lnc. , DigitaI 特許は発明に対して莎えられる。わが国 個々のプログラムが利用している手法の因 Communication 対 SoftkIone Distribut の特許法第 2 条 1 項は , 発明とは自然法則を 果関係があり , その因果関係が自然法則に ing など ) 。 Look とは , 見たり読んだりした 由来しているか否かによって , そのプログ 利用した技術的思想の創作てある旨を規定 場合の視覚的な特徴て、あり , Feel とは , 感 特集プログラマのための知的財産権概論 43 特許法の世界
以上の中て、コンヒ。ュータ関連産業にとっ て直接的な法律問題は , 第 1 の間題て、ある。 当然のことながら , 第 2 , 第 3 の問題は , 契 約て、カバーし得る面が多く , また , 第 3 の問 題については , 英国法からもわかるように 結果物が著作物といえる場合を想定したも のて、あって , 医療診断システムの診断結果 のアウトブットに適用されるものて、はない しかし , これらの問題は , コンヒ。ュータ産 業と法との軋轢を示すものとしては十分て、 あろう。 本年 3 月 25 ~ 27 日 , 米国スタンフォード大 学において , WIPO ( 世界知的財産権機構 ) が , シンポジウム「 The lntellectual Prop erty Aspects Of Artificial lntelligence 」 を開催した。会議て、は , 伝統的著作権法の 規範の大幅な変更 , 特許による保護 , 新し い立法の必要性など , さまざまなアプロー チが試みられたという。もちろん結論には いたっていないが , コンヒ。ュータ新技術と 法との軋轢の問題が , 国際的な議論の俎上 にのばったといえよう。 WIPO から入手した資科はかなりのポリュ ームて、 , これは各国の専門家が , すて、に相 当な研究を行っていることの証左て、ある。 一方 , わが国においてはどうか。少なくと も , いまだこの問題をテーマとした研究レ ポートなどを目にしたことはない。米国と 並ぶ情報化先進国て、あるわが国て、 , なぜこ のような問題に関する研究が行われないの て、あろうか , また仮にどこかて、行われてい るとしても , なぜその成果が世に出てこな いのて、あろうか。コンピュータ新技術は , 今後も , 現行の知的財産権法体系にさまざ まな問題を投げかけるて、あろう。わが国国 内の調査研究の活性化が , 今こそ望まれて 待たれるテクノロジー ロイヤーの出現 コンピュータブログラムは , 法律的には 小説などと同じように , リタラリワーク ( 文 ・衄の著作物 ) として著作権保護の対象 となっているが , 常識的に考えれば , 小説 などとはまったく異質のものて、あることは 明らかて、ある。 だろうか。 法律専門家によって組織的になされないの 国を誇るわが国て , なぜこのような試みが Provision 」を公表した。米国と並び技術先進 取引形態をふまえ , 「 Software Licensing ・著作権部会」は , 多様化するソフトウェア 1990 年 12 月 , 米国弁護士会の「特許・商標 が必要てあると思われる。 の豊かなロイヤー , とくに若手の戦力集団 て、はなく , 技術に興味をもち , かっ理解カ 日本て、いわゆる大物ロイヤーと呼ばれる方々 プログラムのような技術に関するかぎり , かろうか。 もてる能力を発揮するとは難しいのて、はな 評価の対象に関する知識・理解がなくては , 度のあり方に関する有識者としても , 法的 紛争時はもとより , 新技術に対応する法制 戦力的に有利て、あるかは歴然としている。 技術関連紛争が起きた場合 , 日米どちらが しかし , 国際的あるいは国内的に , 一度 , あろう。 することの必要性について認識が低いのて、 紛争も少ないため , ロイヤーが技術を理解 か。わが国て、は , 米国と違って , 技術関連 び , この道に入られた方々て、はないだろう 国のロイヤーの多くは , 終始法律のみを学 統計資料に基づくものて、はないが , わが 一方 , わが国て、はどうか。 を歩んて、いる。 学して , 法律を学び , ロイヤーとしての道 得したうえて、ロースクール ( 法律学校 ) に入 学て、電子工学や数理工学などの基礎学を修 人々の経歴を見ると , そのほとんどが , 大 米国のテクノロジーロイヤーと呼ばれる ろう。 は , 技術内容に関する深い理解が必要て、あ ラムを対象とした的確な法律評価のために 定し得ないて、あろう。したがって , プログ する「技術的製品」て、あることは , 何人も否 また , プログラムがマシンに対して機能 特集・プログラマのための 知的財産権 研究の活性化 , 研究体制の整備 最後に指摘しておきたいのは , プログラ ムの権利保護問題について , わが国て、は専 門家の手による研究論文が極めて少ない とて、ある。 日本の法律専門誌がこの種の問題を扱う のは , 年に 1 回か 2 回て、はないだろうか。国 際的な問題て、あるため , 内外の動向を常時 追跡することが必要てある。しかしながら , 日本語て、書かれたものて、このような必要性 に応えるものは現在皆無て、あるといっても 過言て、はない また , 研究体制にも問題があると思われ る。必要に応じ , 各所て、相当な努力がなさ れているものと確信しているが , それらは なんらの連絡協調もないままに行われてい るのが実情て、ある。本来 , プログラムの法 的保護などの間題は , 特許法 , 著作権法 , 独禁法 , 不正競争防止法 , 民法上の不法行 為 , 契約論などを含んだ全体的な視野に立 って , 総合的に考究されるべき問題てある。 このことは , これまて、にも , しばしば有識 者によって指摘されてきているが , いまだ その成果は見られない 知的財産権間題という言葉は , この問題 が GATT ウルグアイラウンドの議題とされ てから , 頻繁にマスコミなどにも取り上げ られ , ーっの流行語になっていることは事 実て、ある。とりわけコンピュータブログラ ムの権利保護問題は , 日米産業界に大きな 紛争事件が起きたことや , いわゆる「プログ ラム権法」問題における通産省と文部省の意 見対立 , 米国の干渉などがあって , 社会一 般の流行的な関心を集めたのは周知のとお りてある。 しかし , 知的財産権問題は一過性のもの て、はなく , 21 世紀を前にして国際的に検討 すべき重要課題てある。このような認識に 立ち , その研究体制 , 人材 ( 学者 , 弁護士な どの専門家 ) 育成制度などを包含した総合的 施設の確立が必要てあると考える。 特集プログラマのための知的財産権概論 51
に関する会議などても中心的テーマの一つ として取り上げられ , 関係論文も目立って きている。 その実態については詳細な資料を得てい ないのて、全容を紹介することはて、きないが , 部分的な情報によっても , 特許によるプロ グラムの法的保護問題が , 従来のようにレ アケースとして放置しえない段階に到達し ていることは明らかて、ある。 いずれにせよ , 著作権と特許権は互いに 排斥しあうのて、はなく , 異なった形態の知 的財産権に関する LegaI System として , 併 存していくてあろうと思われる。 本バートて、は , 著作権法による保護の世 界 , 特許法による保護の世界を概観する。 著作権法の世界 42 C MAGAZINE 1991 6 にならざるをえない。米国 1980 年改正著作 る保護は実際問題として不安定ということ 律専門家も指摘するように , 著作権法によ とアイデアの境界設定が難しく , 米国の法 プログラムについては , その性質上 , 表現 とくに 考え方や方法があるわけて、はない うことになると , 一般的もしくは標準的な デアとをどのようにして二分するのかとい が , それて、は現実の問題として表現とアイ 原則は原則として , それ自体明確て、ある を確認している。 保護しない旨の確認規定を設けてその立場 ラムについては , 第 10 条 3 項て、 , アイデアは いう」と規定し , さらにコンヒ。ュータブログ 学術 , 美術又は音楽の範囲に属するものを を創作的に表現したものて、あって , 文学 , 保護の対象となる著作物とは「思想又は感情 かにしている。日本の著作権法第 2 条て、も , 米国著作権法て、は , 第 102 条て、これを明ら 国際的にも認められている基本原則て、ある。 護し , アイデアは保護しないというのが , 著作権法て、は , 表現 expression のみを保 なことは何か。 まず , 著作権による保護の世界て、特徴的 権法の基礎となった 1978 年 CONTU (NationaI Commission on New Tech nological Uses 0f Copyrighted Works) 最終報告書には , 次のように記述されてい "AIthough the distinction tries to achieve the separation Of idea from form Of expression , that objective is better realized through the courts exercising their judgement in particu lar cases. つまり , 「コンヒ。ュータブログラムの何が 表現て、 , 何がアイデアなのかの区分は , 争 いが起きたとき , 裁判所が個々のケースて、 判断し , 裁判所の判決を積み重ねながら明 確化していくのがよい」ということて、あっ た。結局 , ケースパイケースて、裁判所が判 断するということて、あって , 通俗的にいえ ば , 裁判をやってみなければわからないと いうことて、あろう。 米国の著作権法学者 PauI GoIdstein 教授 ( スタンフォード大学 ) はその著書 [fC 叩 y right 』の中て、 , コンピュータブログラムの 表現とアイデアの二分について , "Separating protectible expression from unprotectible ideas in computer programs in inevitably calls for deli cate policy judgements" と述べている。表現とアイデアの理論的一 分の難しさを端的にいわれたのて、はないか と思われる。 いずれにせよ , ケースパイケースて、判断 されるのて、あり , 米国の動向を知るために は , 実際の裁判て、裁判所が何をアイデアと みなし , 何を表現とみなしたか , またその 判断理由は何かなどについて , ーっーっの 判例をたんねんにフォローする以外にない 継続的に米国判例を研究することの必要性 はここにあるといえよう ( 米国の最新動向は 後述する ) 。 周知のとおり , 日本と違い , 米国にはプ ログラムの権利保護に関する判例が数多い が , そのなかて、も看過て、きないのは , 1986 年の WheIan 対 JasIow 事件て、ある。 事件の概要を一言て、いえば , EDL 言語て、 書かれたプログラムを BASIC 言語に書き換 えたというものて、ある。単純に考えると , 表現が違っているのだから問題ないと考え られるが , 現実には被告の著作権侵害が認 定されている。裁判所はどのような手法を 用いて表現とアイデアを二分し , 侵害の認 定に至ったのて、あろうか , 興味のあるとこ ろてある。 1930 年 , 米国て、 , Nichols 対 Universal Picture Corp. という , 劇と映画に関する事 件があった。この事件を担当したラー ・ハンド判事が採用したのは , 前項て、述へ た抽象化テストと呼ばれる手法て、あった。 この手法は二つの著作物から付属的な事項 を取り除く抽象化をつづけていく段階て、 , それらがもはや保護されなくなる点を確定 し , 表現とアイデアの間に線を引くという 方法て、ある。 WheIan 対 JasIow 事件において , 裁判所 は , プログラムにこの方法を適用した。そ の結果 , プログラムのような Utilitarian Work の機能の目的はアイデアて、あり , 機能 の目的に必要て、ないものはすべて表現て、あ るとの結論に達し , この考え方に基づいて , コンヒ。ュータブログラムの著作権法による 保護範囲は , コードだけて、なく , その構造 , 手順 , 構成 ( SSO ) にまて、およぶという判断を 示したのて、ある。 これは従来の伝統的な解釈から考えると , 相当な拡大解釈て、はないかと思われる。抽 象化テストは , 著作権法がプログラムとい うものをまったく想定していなかったはる か昔の文芸作品に用いられた手法て、あって , プログラムという技術製品に無批判に適用 されてよいものかどうか , 常識的に割り切 れないものを感じざるをえない さらに米国の司法判断は , 1988 年の pearl Systems ヌ寸 Competition lnc. 事件におい て , システムデザインも著作権保護の対象 て、あると判断している。保護範囲の拡大傾 向が進んだといえよう。
特集・プログラマのための 知的財産権 確にしていかなくてはならない 立場からみれば , 将来の類似システムの開 していることにより , 競合製品を著作権侵 「解法」は , 「プログラムにおける電子計算 害と判断した。 発に備えてソプトウェアハウスのもつ独自 機に対する指令の組み合わせの方法」 ( 10 条 今後 , これらの判断がプログラム関連訴 のモジュールやルーチンなどの権利を留保 3 項 3 号 ) と定められている。これは問題処理 訟の基準として定着していくのかどうか注 しておくことが望ましい の手順を指すと考えられ , 一般的にはアル 目する必要がある。 こて、問題なのは , 開発契約が形式上は ゴリズムと呼ばれている。そして , この部 請け負いて、も , 実情は直接発注会社によっ ②著作権の原始的帰属 分は保護の対象外て、あることを確認してい て指揮命令される派遣の形て、行われること プログラムが開発されると同時にその著 が多いため , このような場合には前記 15 条 作権が発生する ( 著作権の原始的帰属 ) が , , こて、とくに問題となるのが翻案て、ある。 の規定により , 発注者に権利が発生するの プログラムは従業員などによって職務上作 翻案とは , 小説のドラマ化 , シナリオの映 て、はないかとの意見もある。つまり , 使用 成されたり , 外注して開発されることが多 画化などに代表されるように , 原作の形式 者と従業員の関係を雇用がある場合に限る を内面形式と外面形式に分け , 原作の内面 い。これらの場面て、 , 権利の帰属は誰にな か , 実質的な指揮命令関係がある場合も含 形式てあるおもな筋 , 仕組み , 構成などを るかについて , 明確にしておく必要がある。 めるかの問題て、あり , 現在意見が分かれて もとに , 異なる外面形式 ( 表現 ) の二次的著 著作権法第 15 条第 2 項て、「法人の発意に基 いる。 作物を作成することて、あり , その二次的著 づきその法人などの業務に従事する者が職 ③同一性保持権 務上作成するプログラムの著作物の著作者 作物は原作の表現の範囲内 ( 同一性におい は , その作成のときにおける契約 , 勤務規 この権利は , 前述のとおり著作者人格権 て ) て、あると説明されている。これをプログ 則そのほかに別段の定めがないかぎり , そ ラムにあてはめると , 翻案によって保護さ の一つて、あり , 著作者に無断て、行う著作物 の法人とする」と定めている。「法人などの ( プログラム ) の改変を禁ずる権利てある。 れる内面形式とは , プログラムにおいてど 業務に従事する者」とは , 典型的には役員 , プログラムにも当然この権利が関係する。 こまて、の範囲を考えるべきなのか , 問題と 従業員だが , 従業員には派遣社員やパート プログラムの場合は , つねにデバッグ , リ なる。小説などの筋にあたると思われるア ルゴリズムが翻案によって保護されるとす などのアルバイト社員も含まれるのかとい プレース , バージョンアップなどのための 修正が必要て、ある。これに備えて改正著作 う問題がある。 れば , 保護の除外項目として解法を定めた 一般的には , 派遣先の会社の指揮命令を 権法 20 条は , 「著作者は , その著作物および 意味がないことになる。 受けて派遣先の業務を行うのて、あるから , その題号の同一性を保持する権利を有し , このように , プログラムにおいて保護さ その意に反してこれらの変更 , 切除そのほ 両者は含まれると解釈されている。したが れないとするアイデアと , 保護されるとす って , これら役員や従業員が勤務時間内に かの改変を受けないものとする」とし , 同条 る表現との境界がどこにあるのかが不明確 会社の指揮命令によって会社の業務として 2 項 3 号て、「特定の電子計算機においては利用 て、あり , 現在は , 個別に判断している状況 て、ある。これについて , 詳細に後述する 1986 開発したプログラムは , 勤務規則などに取 し得ないプログラムの著作物を当該電子計 年の「ウェラン対ジャスロー事件」に対する り決めがない以上は , その会社に原始的に 算機において利用し得るようにするため , またはプログラムの著作物を電子計算機に 米国控訴審判決は , 「プログラムの著作権の 著作権が発生することになる。 おいてより効果的に利用し得るようにする 保護は , プログラムのコードの文字による 次に , プログラムの開発をソフトウェア 表現を超え , その構造 (Structure), 手順 ために必要な改変は適用しない」としてい ハウスなどに委託するケースを考える。 (Sequence), 構成 (Organization) にまて、およ る。 の場合 , 受注したソフトウェアハウスは発 ぶ」として , 従来の著作権法の保護範囲より したがって , ユーザが行うこのような場 注会社の従業員とはいえないのて、 , プログ 合の改変は , 著作者に許可なく行えること ラムの著作権は受注したソフトウェアハウ 広く解釈している。さらに , 1990 年 6 月に となる。ここて , 「より効果的に利用し得る 米国連邦地裁の「ロータス対ペーパーバック」 スに発生することになる。開発費用を発注 ようにするために必要な改変」とは , バージ 会社が負担したとしても , 権利の原始的帰 判決ても , 「著作権法によるプログラムの保 ョンアップなどを考えると , どの程度の範 属には無関係てある。したがって , 発注会 護は , 文字的要素 ( コード ) だけてはなく , 囲が相当するのか。利用者はその改変が効 社が著作権をもっためには , 当該開発依託 非文字的要素 ( プログラムの構造 , 手順 , 構 果的かっ必要と判断しても , 開発者 ( 著作者 ) 成 , ユーザインタフェイス ) にまておよぶ」 契約にソフトハウスから発注会社に著作権 はそう判断しないかもしれない。改変した を移転する旨を定めておく必要がある。依 としたうえて , ューザインタフェイスの「メ 部分の量 , 内容によっては翻案と評価てき 託開発のケースを , ソフトウェアハウスの ニューコマンドの構造 , 手順 , 構成」が類似 特集プログラマのための知的財産権概論 39
マレチタスキングの 実際 マルチタスキングは , 実行途中の関数か ら , 別の関数の実行途中へと飛び込み , し かも両者のステートは破壊されないという トリックて、す。具体的には , 関数コールと リターンを , 通常とは違う方法て、行うのて、 す。通常の関数コールて、は , 関数をコール すると , スタックがセットアップされます。 それからその関数の本体が最後まて、実行さ れ , 関数の返り値がコール側に返されると ともに , スタックの後始末も行われます。 しかしマルチタスキングて、は , アクチベ ーションピコードのセットアップは通常の 関数の場合と同じて、すが , もっと早い段階 ( 関数の通常のリターンよりも前 ) て、外に出 て , アクチベーションレコードをセープし ます。そして , アクチベーションレコード をリストアして , もとの場所へと戻るのて、 す ( 訳注 : アクチベーションレコード ( activa tion record ) ・・・・・・変数の現在値なども含め , ある時点て、のその関数の実行ステートのこ 本稿は , 先制制御的て、はない (non-pre- empt ⅳ e ) 並行処理を行う , きわめて単純な task クラスを作ることによって , マルチタ スキングの解説をします ( これだけて、も十分 に複雑なのて、 , タスク制御など高度な機能 については今回は触れません ) 。先制制御的 (pre-emptive) なタスキングシステムて、は , タスクがそのとき何をしているかに関わり なく , 一律にスケジューラによって中断さ れます。タスク制御を伴うシステムて、は , どのタスクをどういう順序て、実行するかと いう点が制御されます。タスクは , 他のタ スクのステートをチェックして自分が走る べきかを判断し , また , 他のタスクを起動 させたりします。 こういう機能は , 実用レベルのマルチタ スキングにとってはきわめて重要て、すが , それによってシステムは , 高度に複雑難解 なものになります。そこて、本稿のプロジェ クトて、は , コンテキストスイッチという , マルチタスキングの最も基本的な考え方だ けを利用することにします。コンテキスト スイッチはタスク側が制御し , スケジュー ラがタスクから強制的に制御を取り上げる のて、はなく , タスクが自発的に制御をスケ シューラに渡します ( 訳注 : コンテキストス イッチ (context switch ) ・・・・・・実行文脈の切り 換え / タスクの切り換えによって起こる事 本稿て、取り上げるマルチタスキングシス テムは , 限られた機能しかもっていません が , 実用性がまったくないわけて、はありま せん。オプションの種類はけっして多くあ りませんが , これだけて、も , コードをスッ キリと編成するために , 非常に便利に利用 て、きます。プログラマがありとあらゆる指 示を記述しなければならないような命令的 な状況 ( たとえば C と PascaI は命令的な言語 て、す ) を再編して , セットアップだけを行え ば , 後はタスクが自分て、自分の面倒をみる という状態を作ります ( いわゆるオプジェク ト指向風になるのて、す ) 。 マルチタスキングを , オプジェクト指向 の手法を拡張するための方法として見るこ とがて、きます。オプジェクト指向プログラ ミングて、は , オプジェクトが受け取るメッ セージを指定し , そしてそれらのメッセー ジに対応する動作を指定します。マルチタ スキングのオプジェクト指向プログラミン グて、は , 自分の行動をわきまえているいく つものオプジェクト群を作り , それらを勝 手に動作させ , オプジェクトたちが自分た ち自身て、相互に制御しあえるようにします。 これはシミュレーションのための完璧なシ ナリオて、あり , そして , シミュレーション にたとえることのてきる問題が , 現実には 多いのて、す。 態 ) 。 単純なシミュレーションて、は , 完全に独 立的なエンティティの集団を扱います。そ ういうエンティティは , 自分の現在のステ ートと , 他のエンティティのステートに従 って振舞います。その好例が , シミュレー ションの古典ともいうべき Life て、す 0Life の 各工ンティティは , 自分のまわりのエンテ イティの数によって行動を決め , 毎回のサ イクルて、自分のステートをテストします。 そこて、 , 各工ンティティに自分のプロセス をもたせることがて、きるのて、 , Life シミュレ ーションの実行は , そういうプロセスを走 らせていくことを意味します。各工ンティ ティ ( それはオプジェクト ) が , 自らのすべ きことを知っているのて、す ( 訳注 : 工ンティ ティ ( entity ) ・・・・・・一般的には存在者とか存在 物と訳され , コンヒ。ュータ関連の文中て、は 工ンティティという片カナ語が使われるこ とが多い。要するに , 他と区別されうる一 個のくっきり / かっきりとした「まとまり物」 のこと ) 。 スケジューリング マルチタスキングはスケジューラが制御 します。実行途中の関数から飛び出て , 他 の関数に飛び込むことを , コンテキストス イッチと呼びます。コンテキストスイッチ を実行するためには , 現在のアクチベーシ ョンレコードをどこかにセープし , それか ら , 命令ポインタ ( 68000 系の用語て、はプロ グラムカウンタ ) やスタックポインタ , フラ グなど ( 全マシンステート ) もセープして , 今の居場所を記憶します。このマシンステ ートのセープに , C のライプラリ関数 setjmp ( ) を利用します。 それから次は longjmp ( ) を使って ( 今セー プしたのとは別の ( 別にセープされている ) マシンステートをリストアして ) , 場所のま C 十十で書く単純なマルチタスクカーネル 15 っただ中へと飛び込むのて、すが , その場所
の規定がない。プログラムにとってほかの 過去に , 表現とアイデアとの二分が試み 技術同様にリバースエンジニアリングが必 られている。それは , 1930 年の「ニコルズ対 ④複製 , 翻案 要なことは誰もが認めるところて、あると田 ーサル」判決 ( 米国控訴審 ) て、ある。内 こて、問題となるのが , プログラ 容は , 原告の書いた劇と , 被告の作成した 先の 20 条 2 項 3 号と同様プログラム利用の われる。 特質を考慮したものて、 , 改正著作権法 47 条 ムをリバースエンジニアリングする過程て、 映画において , 著作権侵害があるか否かて、 複製などを伴うことが一般的て、あることて、 の 2 に「プログラムの著作物の複製物の所有 あった。この判決て , 「抽象化テスト」と呼 ある。しかし , このことをもって著作権の 者は , 自ら当該著作物を電子計算機におい ばれる方法が用いられた。それは , 具体的 て利用するために必要と認められる限度に 侵害というのて、あれば , プログラムのリバ 作品から個別事象を取り除いていくと , 段々 おいて , 当該著作物の複製又は翻案 ( これに ースエンジニアリングは不可能となる。そ と一般性が増し , 最後には , 何に関する作 より創作した二次的著作物の複製を含む ) を して , 本来表現を保護するはずの著作権法 品かということと , その作品の表題だけに することがて、きる。ただし , 当該利用に係 が , 実際はアイデアまて、保護してしまうこ なる。この抽象化のある段階て、表現とアイ る複製物の使用につき , 第 113 条第 2 項の規 デアの境界線を引くというものて、もある。 とになる。 定が適用される場合は , このかぎりて、はな リバースエンジニアリングが問題となら しかし , どの段階て、境界線を引くかは , い」がある。この規定によって , プログラム ない小説や音楽などを対象としていた著作 義的に決め得るものて、はなく , 結局は , 創作 権法に , プログラムが取り込まれたのて、あ の複製物の所有者は , プログラムの利用に 者 ( 開発者 ) の保護と競争とのバランスをと 必要な限度て , 著作権者に許可を得ずに複 るが , この問題を著作権法て、どのように解 るという視点に立って判断せざるをえない 製や翻案をすることがてきる。 釈すべきか , 現在 , 国際的に議論されてい 明確な基準がない以上 , 後述するように 実際の判例からその判断基準を個々に研究 るところて、ある。 具体的には , バックアップ , リプレース , カスタマイズなどのための複製 , 翻案が考 なお , この種の議論により多くのプログ する必要がある。 えられる。しかし , これらを行うことがて、 ラム関連の技術者が参加することが , より きる「必要な限度」については必ずしも明確 適切な方向を見出すことになるだろう。 とくに翻案については前述のよ て、はない ⑥侵害の判断 うに , 原著作物に対してどの程度の量的 , 平成元年 6 月 20 日 , 東京高裁て、 , わが国て、 質的改変が許されるのかが問題て、ある。 著作権侵害の有無は , コヒ。一行為があっ 同条の「プログラムの複製物の所有者」に たか否かて、ある。しかし , これを直接証明 初めて , プログラムのデッドコヒ。ーて、はな く創作性および保護範囲を判断する判決 ( シ は , レンタルやリースの形て、利用を許諾さ することは困難なため , 現実には , 他人の ステムサイエンス事件 ) が下された。この事 れているユーザーは , プログラムの複製物 著作物にアクセスがあったことと , 問題の 件は , 著作権侵害差止仮処分申請却下決定 著作物間に実質的類似性があることを証明 の所有者て、はないため含まれない。 この場 に対する抗告事件て、 , 債務者プログラムの することによって推定させることがて、きる。 合は契約によって , バックアップのための ーっが , 債権者プログラムの一つを翻案し プログラムは , 機能的制約により , その 複製の可否など , 利用の範囲を定めること たものか否かをおもな争点としたものて、あ 表現方法がほかの著作物に比べ非常に狭い このような特質をもっプログラムについて , る。概要は以下のとおりて、ある。 ⑤リバースエンジニアリング [ 事実関係 ] 実質的類似性の判断をどのようにするかが ・システムサイエンス ( 債権者 , 抗告人 ) は , 問題て、ある。プログラムのどこがどの程度 リバースエンジニアリングは , 他社製品 バイオテクノロジー分野の装置を開発・ 似ていれば侵害となるか , すなわち , 保護 の調査・解析によってその技術情報を抽出 製造・販売する会社て、 , この装置に搭載 することて、ある。技術の世界て、は , 自己の 範囲の問題て、ある。 するプログラム 4 本 ( 争点となった CA ー 7 Ⅱ 技術水準を高め , より高度な製品を開発す 著作権法の保護範囲はアイデアの表現て、 プログラムを含む ) を開発した。 るために不可欠なものて、ある。そして , 技 あり , アイデア自体は保護されないのが原 一方 , 東洋測器と日本テクナート ( 債務 則てある。しかし , 具体的に表現とアイデ 術の保護を目的とした特許法や半導体チッ 者 , 相手方 ) は , システムサイエンスが開 アとを区別することは困難て、ある。そして , プ法には , 試験または研究のためのリバー 発した 4 本のプログラムのうちの 3 本を複 現在は定まった基準がない状態にある。と スエンジニアリングが認められている。し 製し , ほかの 1 本は CA-7 Ⅱプログラムと かし , コンピュータの利用技術て、あるプロ くに , 前述の翻案の解釈については混迷を 類似のものを開発 ( CA ー 9 プログラム , これ グラムの保護を明示した著作権法には , きたしている。 40 C MAGAZINE 1991 6 る場合も考えられる。 日本における プログラム関連の判例
関数へのポインタ N mo 化 第 7 回 きだあきら してきた。今回は関数へのポインタについて解説する。 前回までは ( テータ ) オプジェクトへのポインタについてお話 関数へのポインタ くわからないとかいう場合が少なくないよ か関数へのポインタは苦手てあるとか , よ 通りポインタをマスターした人ても , なぜ タは難解て、あるという話をよく聞く。ひと い。それにもかかわらず , 関数へのポイン 扱うことがて、きるのは不思議なことてはな らないのだから , 関数へのポインタを取り する型の情報を備えたアドレス値にほかな してポインタは , 端的にいえば対象物に関 して操作することは可能なはずて、ある。そ 数と同様に , 関数もそのアドレスを取り出 て、メモリ上に記憶されるのて、あるから , 変 を除けば , 変数も関数もすべて何らかの形 考えてみれば , 記憶クラスが register の変数 になる。 C 言語のインプリメンテーションを 「関数」という実体を間接的に指し示すこと ている。関数へのポインタは , 当然ながら さて , C には関数へのポインタが用意され て、ある。 制限 ( 自由度と考えるべきか ? ) がっくだけ オプジェクトの型は何て、あるか不明」という 変わりはない。ただ void * は「ポイント先の ェクトを指し示すためのものて、あることに が違ってくるが , それて、も何らかのオプジ のものて、ある。なお , void * の場合少し話 体 ( オプジェクト ) を間接的に指し示すため C におけるポインタは , 一般に具体的な実 関数へのポインタは , 関数を間接的に呼 び出すための機能て、あるとも解釈て、きる。 目的とする関数名を指定して呼び出すのが , 一般的な直接呼び出して、ある。それに対し て , あらかじめ目的とする関数へのポイン タを , 「関数へのポインタ」型の変数に格納 し , そのポインタ変数の値を利用して呼び 出すのが「間接呼び出し」て、ある。「間接呼び 出し」の機能をもつ言語は C だけて、はない 有名なところて、は ,PascaI や FORTRAN に も存在する。さらに Lisp 系の言語て、は間接 呼び出しは日常茶飯に用いられている。し かし , それらの言語て、は , 間接呼び出しを 行うことが困難な作業て、あるとは認識され ていないようだ。て、はなぜ , C における関数 へのポインタは , 苦手意識をもって受け止 められるのだろうか。 関数へのポインタを難解なものにしてし まっている理由として , ーっはその構文的 な記法の問題があると思われる。関数への ポインタ funcp を宣言する場合は , 以下のよ うに書かなくてはならない ( int を返す関数へ のポインタ funcp , 引数の型情報は省略して いる ) 。 int (*funcp)( ) ; また funcp を通じて関数を呼び出す際に ANSI 以前のコンパイラて、は次のように宣言 と類似した形式て、書く必要があった ( 引数は ないものとする。また , 呼び出した関数が 返してきた値は無視している ) 。 これらの記法は , 見慣れた普通のポイン タ変数宣言や , 関数呼び出しとかなり異な っており , 一見して難解て、あると感じさせ てくれる。大げさにいえば , これらの記法 は , それを見慣れていない人にとっては何 のことか , わけのわからない呪文に等しい このことが , 関数へのポインタに対する最 初の , そして最大の問題て、あろう。しかし ながら , 幸いなことに ANSI 標準とそれ以前 のいくつかの処理系て、は , 以下のように記 述することが可能て、ある。 funcp( ) ; これならば , 通常の関数の直接呼び出し とまったく変わらない。この記述を可能に するために , ANSI て、は関数呼び出しに関す るセマンティクス ( 意味的解釈 ) を K & R のも のとは変更している。これは非常に興味深 ことなのて、後て、詳しく述べる。 ただ , 関数へのポインタを通して関数を 呼び出す場合には上述のように直接呼び出 し的な記述が可能になったが , 残念ながら funcp を変数として ( 関数の仮引数以外の場 所て、 ) 宣言する場合には , ANSI ても最初に あげたとおりの int ( * funcp)( ) ; という記述 を強いられる。 関数へのポインタが難解て、あるもうーっ の理由は , その必要性・必然性が理解され こともあるのてはないかと考えてい る。多くの教科書が適切な使用例を示して ことが , 関数へのポインタに対する 理解を阻んているのてはないだろうか。 ANSI C ー more 105
アルゴリズム 0 テータ構造入門 分割した部分に対して , 再帰的に処理 て、 , 列 b から要素 15 を取り出して列 c に入れ 同じ再帰的アルゴリズムて、も , クイック ると Fig. 2 ②になります。再び先頭どうしを を行う ソートて、は , 重要な処理は分割のステップ 比較すると , 今度も列 b の先頭の要素 26 のほ となっていたのに対して , マージソートは , て、行われていました。そして , 再帰呼び出 うが小さいのて、 , 要素 26 を列 b から取り出し 分割した部分に対して , 再帰的に処理 しをした後には , 何も処理をする必要はあ を行う て列 c に入れます ( Fig. 2 ③ ) 。 りません。 仕事をする 同様にして , 列 a から要素 30 と要素 46 を取 つまり , クイックソートて、は , り出し , その次に列 a から要素 75 を取り出し 仕事をする ます。この時点 ( Fig. 2 ⑥ ) て列 a は空になり Fig. 2 マージ処理 ます。そこて、最後に , 列 b に残された要素 90 を列 c に追加してマージ処理が終了します (Fig. 2 ⑦ ) 。 ジソートの しコリズム マージを利用して整列を行う手順は次の ようになります。 ①データ列を真ん中でニつの部分列 a , 列 b に分割する ②部分列 a と列 b を , それぞれなんらかの 方法で整列する ③整列ずみの部分列 a , 列 b をマージする ステップ②て、は , この手順を再帰的に適 用して部分列を整列します。この手順を再 帰的に適用するたびに部分列の大きさは半 ただーっの要素になったとき再 分になり , 帰呼び出しは終了します。 このようにデータを分割して , 分割され た個々の部分を個別に処理するというのは , クイックソートのときに利用した分割統治 法の典型的なものて、す。マージソートのア ルゴリズムを , Fig. 3 に疑似コーディングて、 示しましよう。 Fig. 3 は , たったいま説明し た手順をそのまま書き下ろしたものて、す。 最初の if 文は再帰呼び出しが停止する条件に なっています。 マージソートのアルゴリズムて、は , 二つ に分割した部分列を再帰呼び出しによって 整列してから , マージ処理を行います。ク イックソートは異なり , 分割のステップ (Fig. 3 ② ) は与えられた列を二つの部分列に分け るだけて、 , とくに意味のある処理は行いま せん。実際の仕事は , マージのステップ ( Fig. 3 ⑤ ) て、実行されます。 ① ( 2 ) C 15 b 26 90 15 26 C b 90 a 46 7 5 ④ C 15 26 30 26 30 46 15 b 90 15 26 30 46 7 5 C b 90 26 30 15 46 7 5 90 アルゴリズムとデータ構造入門 59
プログラマがエデイタなどを使って ( 画面 上て、 ) 書いた C のプログラム ( ソースリスト ) は , いったんディスク上の ( ーっまたは複数 の ) ソースファイルとしてストアされるのが 普通て、す。 そして , そのソースファイルの名前を指 定して C コンパイラを起動します。 C コンパ イラの最近のデフォルトの ( = 何もとくに指 定しない場合の ) 使い方は , リンクまて、一貫 して行ってしまう ( = 最後に実行プログラム がて、きてしまう ) 使い方て、す。 昔のように , コンパイルとリンクがそれ ぞれ別工程て、 , リンク ( = リンカの起動 ) も プログラマによる明示的な作業行為として 存在しているならば , main( ) に関する初心 者の疑問も、、わかりが早かった〃て、しよう。 現代のような , コンパイル / リンクの一貫 言語処理系が取り扱う対象物が , 工程だと , プログラマが指定したソースファイルだけ て、あるかのような外見を , 初心者の印象と してえてしまいます。 そういう一貫工程の場合 , 実はリンクの 過程て、 , プログラマのソースファイルから 生成されたオプジェクトコードに , 処理系 が最初から暗黙裡に提供している「スタート アップコード」という名のオプジェクトがリ ンクされます。それによってやっと , 最終 的な実行プログラムが完成します。一貫工 程て、は , このことがユーザの知らない , 目 に見えないところて、行われてしまうのて、 , 初心者が知らないのも無理ありません。 スタートアップコードは , どのプログラ ムにも必ず必要な , いくっかの準備作業を 行っているだけの短いプログラムて、す。 Turbo C / C 十十の場合だと , 製品ディスクのどこか にある CO. ASM というソースファイルを眺 めれば , スタートアップコードがやってい ることが , だいたいわかります。 て、 , このスタートアップコードの最後の 102 C MAGAZINE 1991 6 方て、コールしている ( = 制御を渡す ) 関数の 名が , なぜか C の世界て、は慣例的に main な のて、す。 CO. ASM の最後の方に , call main という命令が書かれています。 われわれの本来のプログラムの実行が始ま ります。 そして , もちろん , われわれの主プログ ラムは ( 自分て、 exit( ) などをコールしなけれ ば ) , 最後にまたスタートアップコードへリ ターンします。 C 言語の世界て、は , プログラムの「入口」 「頭」は main ( ) 関数だということが慣例化し 常識化していますが , スタートアップコー ドの call main を call f00 などと書き換えて , それをアセシプルしてオプジェクトを新た に作れば , 「主プログラムの実行は f00 ( ) とい う名の関数から始まる」という ( 積極的な意 味は何もない ) 事態が確立してしまいます。 こうすると , 当然 , main( ) 関数て、はなく , f00 ( ) 関数が必要だということになります。 しかし , そういうプログラムは , 他人が見 て理解しづらいことは , いうまて、もありま せん。ましてや , 他人様のコンパイラて、は コンパイルがて、きません。 繰り返せば , 要するに , スタートアップ コードの最後の方て、コールしている関数の 名が , たまたま ( どの C 処理系て、も ) main な のだということて、す。たったそれだけのこ とて、す。必然的あるいは絶対的事情などは 何もありません。 標準装備品としての 標準ライプラリ関数 standard といえば , C 言語には standard library というものがつきものて、す。標準ラ イプラリと訳し , そこに揃っているおよそ 数百個の関数を , 標準ライプラリ関数と呼 ぶのが普通のようて、す。この場合の「標準」 は , たとえば自動車の仕様なんかて、「ナニと ナニは標準装備」というときの「標準」とほば 同じ意味て、しよう。 それて、も , 標準ライプラリ関数のいくつ かは , C て、プログラミングする場合 , 本稿の 冒頭て、述べた意味て、の「標準」に , 事実上な っています。どこて、も , 気にせずにヒョイ ヒョイ使うのて、 , そのことがときには「ドジ 源」にもなります。 C 言語の市販処理系は , いずれも , 「標準」 に対しての「オプション関数セット」なるも のは提供していないようて、す。しかし一方 , 車の世界の純正オプション仕様に相当する ものは存在しない代わりに , 市販製品や PDS などて、 , 様々なライプラリが提供されてい るのが , C の世界の特徴と言えるて、しよう。 市販ライプラリ製品の評価も , 本誌のよう なプログラミングジャーナリズムの重要な 仕事の一つて、す。 市販の C 処理系の「標準装備品」として提 供されている標準ライプラリ関数は , その 中身が何層かに分かれます。いちばん中核 にあって , オペレーティングシステムの違 いを超えて , ほとんどすべての C 処理系が同 一仕様て、サポートしている ( はず ) の関数群 が , C 言語の ( 実質的に ) 世界的な標準規格て、 ある ANSI C が規定している標準ライプラリ 関数て、す。 I / O ( 入出力 ) 関数て、は , fread( ) や fwrite() がその典型て、す。 その外側の層として位置づけるのがふさ わしいと思われるのが , 伝統的な UNIX 互換 の関数群て、す。その中て、 , I / O 関数として典 型的なものは , read() と write() て、す。 標準ライプラリには , 様々な種類 ( 様々な レベル ) の I / O 関数があり , これも初心者を まどわせます。使い方を誤ると , 見事にド ジ源となります ( いずれは , このテーマも扱 ってみたいと思っています ) 。 ただし , これらの , いわゆる UN Ⅸ互換関