～その１．結論とシラバス～
～その２．技術的事項の説明～
～その３．著作物の性質～
～その４．使用の目的と性質～
～その５．使用された部分の量と実質性～
～その６．市場への影響＆結論～
の続きです。
「グーグルによるJavaSEのコードのコピーはフェアユースである」との結論により、オラクルによる権利行使は否定されました。
が、
その結論を支持したのは９人の判事のうちの６人で、２人は反対の立場を表明しています。
今回は反対意見を見ていきます。
（判決文PDFのP44から。）
反対意見の内容を検討しながら書いていたら、反対意見に対して反対する、という内容になりました。
まず、オラクルの功績とグーグルの行為、その影響が語られます。
・オラクルは、ソフトウェア開発者を惹きつけることに成功したプログラミング ライブラリの開発に何年も費やし、オラクル製品の価値を高めたこと。
・グーグルはAndroidにおいてそのライブラリの使用を求めたが、両社が条件に合意できなかったため、グーグルは単純にライブラリから11500行のコードをコピーしたこと。
・その結果、（グーグルは）オラクルとアマゾンのパートナーシップの97.5%を消し去り、数百億ドルを稼ぎ、世界最大のモバイルOSの地位を確立したこと。
・（それほどの影響）にもかかわらず、このコピーがフェアユースであるという多数意見になっている。
続いて、その判断が誤りである（と考える）理由を指摘します。
・裁判所がこのありえない結論に達したのは、先行する問題、すなわち「ここで争われているソフトウェアコードは著作権法によって保護されているのか？」という問題を明確に無視しているためであること。
・多数意見は「判決なしに」そのコードが保護対象として想定されていると主張していること。
・しかし、そのフェアユース分析は、議会がコンピューターコードに与えた実質的な保護とは完全に矛盾していること。
・コピーの権利性の問題をスキップすることで、多数意見は関連条文の半分を無視し、そのフェアユース分析を歪曲していること。
・条文を適切に考慮すると、ここで問題となっているオラクルのコードは著作権で保護されており、グーグルによるその著作権で保護されたコードの使用は公正とは言えないこと。
という形で冒頭の宣言文的な部分が終わり、実質的な論述に入っていきます。
その最初はJava SEについての説明です。
・Javaにおいては、「メソッド」と呼ばれる小さなサブプログラムを事前に作成できること。
・メソッドは、より複雑なプログラムのビルディングブロックを形成すること。
・メソッドが定義されると、開発者は数文字 (メソッド名と関連する入力) を入力するだけで、サブプログラムに含まれるすべてのものを呼び出すことができること。
・事前に作成されたメソッドに精通しているプログラマーは、基本的なサブプログラムをすべてゼロから作成することなく、それらの多くをつなぎ合わせて複雑なプログラムを迅速に開発できること。
・Javaメソッドを作成するために、開発者は２種類のコードを使用すること。
・最初の「宣言コード（declaring code）」では、メソッドに名前を付け、処理できる情報を定義し、出力できるデータの種類を定義すること。
・２番目の「実装コード（implementing code）」には、これらのメソッドを実行するための段階的な指示が含まれること。
今でこそプログラム開発の基本とも言える内容ですが、Javaがリリースされた1990年代においてはどうだったのでしょうか。画期的なものだったのでしょうか。当時のプログラミング事情に詳しい方いたら教えてください。
ともあれ、そのようなJavaのビジネスモデルが次に語られます。
・オラクルの宣言コードは、ビジネス モデルの中心だったこと。
・オラクルは、開発者に Java で書かれたプログラムを作成するよう奨励し、それらのプログラムを実行するために必要なJavaソフトウェアプラットフォームをデバイスに組み込む料金をメーカーに請求することで、金銭的な利益を得たこと。
・この目的のために、OracleはJava 2 Platform, Standard Editionと呼ばれる製品を作成し、これには、約 30,000 のメソッドを含む高度に編成されたライブラリが含まれていたこと。
・Oracle は、開発者がJavaプラットフォーム用のプログラムを作成することを奨励するために、これらのメソッドへの無料アクセスを開発者に提供したこと。
・その見返りとして、開発者は自分のプログラムをあらゆるデバイスのJavaプラットフォームと互換性を持つようにする必要があったこと。
・開発者はプラットフォームを改善することが奨励されたが、有益な変更を一般に公開する必要があったこと。
・企業がプラットフォームをカスタマイズし、それらのカスタマイズをビジネス目的で秘密に保ちたい場合は、別のライセンスを支払う必要があったこと。
次に、そのようなビジネスモデルのもとでJavaがどのように市場に受け入れられていったのかが語られます。
・2005年までに、多くの企業が現代のスマートフォンとなるオペレーティング システムの開発を競い合っていたこと。
・オラクルの戦略は、何百万人ものプログラマーにJavaの学習を奨励することに成功し、Javaソフトウェア プラットフォームは携帯電話の大多数に搭載された。
続いて、グーグルがJavaのコードをコピーし、訴訟が提起されるに至った経緯、そして前審の結果が語られます。
・Googleは、プログラマーが慣れ親しんだ宣言コードをAndroidに組み込むことで、Javaを学んだプログラマーをAndroidに惹きつけたいと考えた。
・しかし、Androidの創始者アンドリュー・ルービンは、宣言コードが著作権で保護されていることを理解していたため、GoogleはOracleにカスタム ライセンスを求め、2005年から2006 年の間に少なくとも 4 回、両社はライセンスの交渉を試みたが成立しなかった。
・交渉決裂の結果、GoogleはとにかくOracleのコードを使用することに決め、 Apple、Microsoftが選択したように独自の宣言コードを作成する代わりに、Oracleの宣言コードの11,500行をそのままコピーし、そのコードをOracleが行ったのとまったく同じように配置し、Androidを「Core Java Libraries」を含むものとしてデバイス メーカーに宣伝した。
・オラクルは予想どおり、著作権侵害でGoogleを訴えた。
・連邦巡回裁判所は、Oracleの宣言コードは著作権で保護されており、Googleによるその宣言コードのコピーはフェアユースではないとの判決を下した。
判決の多数意見を読んだ後であればすんなりと理解できますが、その上でグーグルの行為がギルティという結論に向かうような説明になっているなと感じます。
ここでようやく前段の説明が終わり、意見の内容が始まります。
まず大命題です。
・法廷は、私たちが答えるように求められた基本的な質問、すなわち宣言コードが著作権の保護対象であるか否か、を誤って避けている。
ということで、多数意見の判決では大きくは議論されなかった論点、「宣言コードは著作権の保護対象か否か？」を前面にもってきます。
「宣言コード」というと「コード」なんだからとりあえずは保護対象だろう、と思ってしまうかもしれませんが、そう簡単ではありません。
これはすなわち、「ＡＰＩは著作権の保護対象か否か」という命題です。
この議論の元は米国著作権法§102(b)
いかなる場合にも、著作者が作成した創作的な著作物に対する著作権による保護は、着想、手順、プロセス、方式、操作方法、概念、原理または発見(これらが著作物において記述され、説明され、描写され、または収録される形式の如何を問わない)には及ばない。
ここで、日本の著作権法を知っている者であればすぐに頭に浮かぶ条文があります。
3条 第一項第九号に掲げる著作物に対するこの法律による保護は、その著作物を作成するために用いるプログラム言語、規約及び解法に及ばない。この場合において、これらの用語の意義は、次の各号に定めるところによる。
一 プログラム言語 プログラムを表現する手段としての文字その他の記号及びその体系をいう。
二 規約 特定のプログラムにおける前号のプログラム言語の用法についての特別の約束をいう。
三 解法 プログラムにおける電子計算機に対する指令の組合せの方法をいう。
この条文について解説をするだけで記事がひとつ書けるくらい重要な条文ですが、要点だけ説明すると
プログラムを作成するために必要な「ツール」になるような要素には著作権の保護は与えられない
という事を規定している条文です。
で、APIについて考えてみましょう。
プログラムを作成するために必要な「ツール」、ではないですか？
これこそがこの裁判で最も重要な論点だったはずなのですが、たしかに判決文を読む限りにおいては、この論点は避けられているように感じます。
で、我慢できなかった判事二人が反対意見を提出したわけですね。
つまり、この反対意見の存在こそがこの判決の価値を数倍に高めていると言っても過言ではない。
私はそう思います。
で、意見の内容に入っていきます。
・コンピュータ コードは、知的財産において独特の空間を占めていおり、著作権法が保護する著作物と、特許法が保護する発明とにまたがっていること。
・その前提を踏まえたうえで、「コード」は著作権法によって保護されると議会によって決定され、その保護に宣言コードも含まれること。
・条文では「コンピュータープログラム」を「特定の結果をもたらすためにコンピューターで直接的または間接的に使用される一連のステートメントまたは命令」と定義しており、この定義は、宣言コード (事前に作成された実装コードをトリガーすることによって、コンピューターの機能を間接的に実行する一連のステートメント) を明確にカバーしていること。
・過去の様々な著作物性のテストに照らしても、Javaプラットフォームでコードを宣言する行は、その「非常に低い」しきい値を容易に満たすこと。
この辺の意見は結局水掛け論になってしまう部分だし、ちょっとうがった見方をすると「技術がわかってない人かな？」とも思ってしまいます。
特に、コンピュータプログラムの定義、すなわち「特定の結果をもたらすためにコンピューターで直接的または間接的に使用される一連のステートメントまたは命令」に対する宣言コードの当てはめについてはどこまでも相容れない部分なのかもしれません。
私は、
単なる機能の名前と機能を実行させるためのルールでしょ？
と思ってしまいます。
が、反対意見としてこの意見が出てくることによってこの裁判の重要性がしっかりと際立っているのが素晴らしいと思います。
次に、グーグルの主張が語られます。
・Googleは、コードの宣言は「操作方法」であり、したがって条文によれば保護から除外されると主張した。
・その条文は、著作権保護から「記述、説明、図解、または具現化された形式に関係なく、アイデア、手順、プロセス、システム、操作方法、概念、原理、または発見」を除外していること。
・この条項は、著作権保護がアイデア自体ではなく、アイデアの「作者の表現」のみをカバーするという「アイデア/表現の二分法」を成文化していること。
・例として、宣言コードというアイデアを発明した本を書く人は、その本の表現には著作権保護があるが、宣言コードというアイデア自体には著作権保護は及ばないこと。
・Googleは、実装コードが著作権法によって保護されていることを認めているが、宣言コードははるかに機能的であり、したがって保護の範囲外の「操作方法」であると主張していること。
これは多数意見において語られた判決理由とほぼ一致した議論かと思います。
が、反対意見においてはこれを否定します。
・その議論は間違いであること。
・宣言コードと実装コードとは「密接に結びついている」こと。
・宣言コードは、一連の実装コードの範囲を定義し、プログラマーにそれをショートカットで使用する方法を提供するものであること。
・宣言コードは実装コードと連動するため、それ自体には機能がないこと。
・実装コードも同様、宣言コードがなければ、開発者はすべてのプログラムをゼロから作成する必要があり、複雑なプログラムの作成には非常に時間がかかること。
・したがって、宣言コードと実装コードの両方の機能は、通常、一心同体であること。
ということで、宣言コードと実装コードとは切り離せないものであって、全部まとめて著作権の保護対象であるという意見に見えます。
ですが、ここには穴があるように思います。
宣言コードと実装コードとが切り離せず一体という主張をするのであれば、それが著作物として認められる条件、日本の著作権法でいうところの創作性を発揮する条件も宣言コードと実装コード全体ではじめて、という主張も然りでしょう。
そして、コピーされたのは宣言コードのみなのです。
続いて、条文に沿った指摘が行われます。
・グーグルの主張はまた、保護されたコンピューターコードを「特定の結果をもたらすためにコンピューターで直接的または間接的に使用されるステートメントまたは命令のセット」として定義するという議会の決定に対して釈明できていないこと。
・したがって（※原文 Hence, 「このために」とでも訳すのでしょうか。）、議会は、コードの宣言と実装の間の明確な区別を拒否した。
英文にありがちな日本語に訳しにくい文章ですが、おそらく、「Googleは条文に沿った釈明ができていない。これこそが、条文の趣旨である」→「グーグルの行為は条文に反している」ということが言いたいのではないでしょうか。
・実装コードはコンピュータを直接動作させること。
・宣言コードは実装コードとの連携によりそれを間接的に行うこと。
・「操作方法」の保護を禁止する一般論と宣言コードを保護する特別論に直面した場合、「特別は一般を包括する」
・この文脈から、§102(b) の「操作方法」という語句は、コードが機能的であるという理由だけで宣言コードが保護から除外されないことが明らかであること。
ということで、条文に沿った解釈を繰り広げた上で宣言コードは間接的にコンピューターを動作させるものであって著作権法の保護対象であり、一般論と特別論とでは特別論が優先させるので§102(b)にも反しないと結論付けています。
続いて、§120(b)が無意味なものではないというフォローが入ります。
・しかし、その解釈が「操作方法」を無意味にするわけではなく、「関連付けられている隣接する単語によって、より正確な内容が明らかになる」こと。
・「アイデア」、「原理」、「概念」など、同じサブセクション内の他の用語は、「操作方法」が、オラクルが作成した特定の表現ではなく、コンピューター コードによって実装される機能とアイデア（例えば、数学の関数、会計方法、またはコードを宣言するというアイデアなど）をカバーしていることを示唆していること。
・オラクルは、宣言コードを使用するアイデアの著作権を取得することはないが、そのライブラリにあるそのアイデアの特定の表現の著作権を取得すること。
反対意見が言いたいことはつまりはここに表れている気がします。
「宣言コード」という仕組みが独占されるわけではなく、（当たり前ですが）具体的に作成された特定の表現、つまりここでは参考資料で説明されているような、宣言コードの「java.lang.Math.max」といったコードが保護されるということでしょう。
言いたいことはわかるものの、「プログラムコードの著作物性」「創作性」という点に目を向けるとやはり厳しいと思ってしまいます。
この論が通るためには、「java.lang.Math.max」というコードが単独で創作性を満たす必要があります。
しかし、プログラム著作物の創作性は複数の命令が組み合わされて、ある目的を持ったプログラムとして完成して初めて保護されるレベルに達するのではないでしょうか。
この、「java.lang.Math.max」という、特定の実装コードを呼び出すための単独の命令、「名付け」とも言える文字列に単独で創作性を見出すことはやはりできません。
加えて、「アイデアを表現する方法が他に無い」というグーグルの主張にも反対意見が述べられます。
・Googleはまた、アイデアを表現する方法が 1 つしかない場合、“merger doctrine”は著作権保護を禁止するため、宣言コードは著作権保護の対象ではないと主張していること。
・この議論は、Google の§102(b) の議論が失敗するのと同じ理由で失敗する。
・たとえその論理が存在するとしても、Googleはそれが102(b)条の単なる「an application」（条文？書類？）であることを認めていること。
・いずれにせよ、Google が宣言コードの行をコピーする方法は 1 つしかなかったかもしれないが、Oracleがコードを記述する方法は無数にあり、確かに、Apple、Microsoftは、独自の宣言コードを作成することに成功していること。
merger doctrineについてはこちらを。
著作権法はアイデアそのものを保護することはないので、そのアイデアから生まれる表現の道筋が1本に限定される場合には、その表現を保護することは実質的にそのアイデアを独占させることになってしまうので、例外的に著作権法で保護されませんよ、という話です。
可算名詞としての「application」がここで何を意味するのかいまいち分からなかったですが、「一般論に過ぎない」的な事が指摘されているのでしょうか。
それよりも、アップルやマイクロソフトは別の宣言コードを作った、という部分の方がここでは重要でしょう。
というわけで、ここまでが「宣言コードは保護対象か否か」という議論でした。
次にフェアユースの議論に入っていくことになりますが、長くなったので分けることにします。
ここまでの内容としては、宣言コードが著作物として保護される対象か否か、§102(b)との関係で保護が否定されるものではないか、という点が語られました。
その結果は、
やはり個人的にはこの反対意見には同意できません。
グーグルがコピーした（？）のは宣言コードのみで実装コードはコピーしていないわけですが、「宣言コードと実装コードは連動して機能するものであって一体として著作物として保護されているのだから、宣言コードをコピーしただけでも著作権侵害を構成する」という反対意見の論旨には、上述の通りやはり疑問を感じます。
ただし、判決文において宣言コードの著作物性や§102(b)の適用についての議論が十分ではないのも事実。
この反対意見によってこの裁判の結論の説得力はむしろ増しているのではないでしょうか。
ということで、次回に続く
