「OracleとGoogleの判決文を斜め読む」を読んで裁判の経緯は理解できたものの、判決の詳細があまり理解できなかったので判決文を自分で読んだ。法律的な難しさはあまりなく、技術的な論点と関係する条文および過去の判例などが非常にわかりやすく解説されており、判決の根拠もたとえ話を交えて書かれているなど非常に読みやすい印象を受けた。
全体の内容としては比較的単純で「あらゆるプログラムのコードは著作権で保護される。ただしFair Useによる合法的な利用に関しては差し戻し審で審議せよ」という事のようだ。実は「API」という言葉は一切判決文には出てこないため、内容を良く読む必要がある。
今回の論争のうち最も重要な点は、著作権法のうち 17 U.S.C. 102(b)という条文が、GoogleがOracleからコピーしたコードに対して適用されるか、ということである。102(b)は著作権の制限について書かれた条文であり、GoogleはJavaメソッドの宣言コードは、102(b)で述べられている「method of operation」や「system」に該当し、著作権で保護されないと主張していた。
17 U.S.C. 102(b)には以下のように書かれている(p.2)：
a copyright in a work does not “extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.”
つまり、著作権はアイデアやシステム、プロセス、オペレーションの方法に拡張されることはないと書かれている。Googleとしては、「その著作物が動作するコンポーネントを含むのであれば、102(b)によって著作権による保護は失われる(p.9)」し、「宣言コードとは実行コードが定義するメソッドを『実施（オペレート）する方法』である(p.14)」と主張したい。
地裁では102(b)の適用が認められたが(p.8)、この主張は上訴審では覆されてしまった(p.9)。控訴審ではコンピューターコードは表現であるとされ(p.9)、「コンピュータープログラムはその定義からしてfunctional」であり、「タスクを実行するために設計されている」のだから、地裁の判断は「あらゆるコンピュータープログラムが保護されなくなる」ことを示唆しかねないし、それは「コンピュータープログラムに著作権を付与するという議会の意図にも反する」ことになる、と結論された(p.9)。
今回の判決文では、控訴審の判決が支持され、102(b)の適用は認められなかった。これは以下のように説明されている。
- 102(b)は著作権が与えられる「表現」を制限するものではなく、著作権がどこまで拡張されるかについての制限を定義している(p.12)
- 例えば、自転車の組み立て方を説明する本は著作権の保護対象になるであろうが102(a)、そこで説明されている組み立て方法の実践についての排他的な権利が与えられることはないし、同じ方法のより詳しい説明が書かれた本を他の人が書くことを止めることは出来ない102(b) (p.12)
- 著作憲法はアイデアやコンセプトを表現する手法は保護するが、アイデアやコンセプトの利用それ自体は制限しない(p.12)
- Googleによる、1つの作品に対して102(a)と102(b)が同時に適用されることがありうるという主張は間違っている。なぜならば102(a)は表現物に与えられ、102(b)は表現物によって説明もしくは記述されるアイデアに適用されるからである(p.13)
- 従来の本などでは手順の表現と手順の実施がことなることは明白であったが、コンピュータープログラムは手順の表現かつ、実施の手段でもある。そのためプログラムを「method of operation」や「system」と捉えるのは不自然なことではないかもしれない(p.13)
- 例に従えば、コンピュータープログラムは実際の自転車組み立て手順にアナロジーとして近い(p.13)
- しかしながら、著作権法全体としてみると、コンピューターコードのfunctionalな特徴を102(b)適用の根拠にするのが相応しくないことは明確である(p.13)
- コンピューターコードは著作権の保護対象であり、ここでいう「method of operation」や「system」はコンピューターコードによって起動されるコンピューターの機能である
- たとえばソートアルゴリズムのような
- もし仮に102(b)の適用をコンピューターコード自体に認めてしまえば、あらゆるコンピューターコードが保護の対象外となってしまう(p.13)
- そして、宣言コードと実装コードの境界は明確ではない。どちらも最終的に起動される機能を実行する(p.14)
- 宣言コードは実装コードよりも1ステップ離れてはいる。しかし、Googleはコードに102(b)が適用される条件が、コードと最終的な機能の関係性が直接的であるかどうかに依存するという根拠を示すことがでなかった(p.15)
- むしろ法令文によれば「コンピュータープログラム」とは「直接的または間接的に使用されるステートメントの集合」と定義されている(p.15)
- さらに、102(b)は「著作権で保護されるもの」と「それ以外のもの」を区別するための条文であるが、Googleはそれを102(a)で保護される全体とその一部に当てはめようとしている。102(b)の趣旨は「1つの大きな作品」から「一部の著作権で守られない範囲」を切り取るためのものではないから、主張に欠陥がある (p.16)
以上のように、宣言コードと実装コードという区分は本来著作権法では定義されておらず、法律の趣旨からしても宣言コードは保護の対象内と見なされるという結論となっている。
判決文ではGoogleが主張した判例や他の条文に基づく3つの著作権の無効化手法についても、それぞれ説明が与えられている。
あるアイデアが非常に限られた数の方法でしか表現できない場合、その表現に対する著作権は制限される(p.2)。たとえば余りに単純なアルゴリズムは、いわゆる「誰が書いても同じ」コードになってしまうので著作権が適用されないことがあるかもしれない。
Googleは過去の判例（Baker v. Selden, supra）を引き合いに出して、本件に対してMerger原理を当てはめることも主張していたようだが(p.16)、地裁での支持(p.8)に対して、控訴審(p.9)および今回の判決文では条件の違いからこれを認めず(p.16)、判決文では、控訴審の「メソッドの取り得た名前や構造は無数ある」という宣言に対してGoogleが争わなかったことを根拠として「Androidプラットフォームの構築した際に、被告の宣言コードをコピーする論理的な必然性がない(p.16)」と結論づけている(p.16)。
個人的な印象としても、（呼び出し側コードの書き換えを厭わなければ）同じ動作に対して違うメソッド名を付けることも、引数の名前を変えることも可能であると直感的に理解できるので、merger原理を適用するのは無理があるように思える。
Meger原理に似た原理として、不可欠であったり、あまりにも古典的だったり標準的な表現はscènes à faire原理によって保護されないことがある(pp.2-3)。GoogleはSSOに対してこの原理の適用を求めたが、これは地裁でも却下されているし(p.8)、控訴審でも根拠の不十分さから認められていない(p.9)
JDKの仕組みは確かにJavaの標準的な仕組みではあるものの、ソフトウェア産業全体で見た場合は必ずしもこの原理を適用できるほどの普遍性を見いだすことが出来ないというのは理解できそうに思われる。
Googleは、たとえ宣言コードが著作権で保護されていたとしても、Section 107で定義されるFair Useによって合法的な利用が可能だとも主張している。具体的には「『ソフトウェア開発者はすでに係争中のJava（中略）パッケージで訓練され経験している』ので、コピーはその技術を被告（Oracle）の技術と互換にするために必要であった」としている(p.10)。しかし、控訴審では証拠の不足から判断が出来ないとして、審理を地裁に差し戻している(p.10)。そのため、Fair Useの適用の可否についてはまだ結論が出ておらず、地裁の審理待ちである(p.22)。
なお、判決文では、Googleが懸念するAPIの制限によるイノベーションへの影響や市場の独占については重要な関心事としながらも、それらは102(b)ではなくFair Useの107で扱うべきであるとしている(pp.16-17)。判決文内では差し戻し審で考慮すべき点をいくつか挙げているが、具体的な判断については書かれていない。
たとえば、ある難しいアルゴリズムをメソッドとして実装する場合、そのアルゴリズム自体はアイデアなので（特許は別として）著作権では保護されない。これが102(b)の趣旨である。しかし、アルゴリズムを実装するメソッドのコードは、人によって当然書き方が違うので、著作権で保護される。またさらに、再利用性や可読性、テストのしやすさなどを吟味すると、メソッドの宣言部にも人によって書き方に違いが出てくるのは不自然ではないし、そこには十分な創造性が含まれているので、著作権で保護されるのが妥当であると見なされる。宣言コードと実装コードは便宜上区別されているものの、どちらも最終的にはアルゴリズムを表現したものであることから、102(a)の定義上違いがないと考えられる。
以上のたとえ話はこの記事のために創作されたものであるが、判決文では宣言コードについて、「メソッドの名付けや構成において創造的な選択が果たされている(p.11)」とか「一般的なコードとは異なる特出した品質であると認める(p.14)」といった表現で、宣言コードが102(a)の定義に合致する理由を述べている。
判決文では今回の判決がJavaもしくはJDKの提供するAPIに制限されるということは特に書かれていなかった。たとえば他の言語でも、元となるライブラリと同じシグニチャのメソッドを集めて互換ライブラリを作るなどすると、今回の判決と同様の結論に至るのではないかと思われる。
なお、pp.22-23 に以下のように書かれている。単純にコピーアンドペーストで他所の実装をコピーした場合に比べ、今回は争点が特殊だったということのようだ。
3番目に、本件で取り扱った著作物はその性質上、（最高裁）法廷がコンピュータープログラムに対する著作権原則の適用について初めて言及するにあたり、適したケースとは言い難い。報告されている控訴審の主題の大部分のケースと異なり、本件では一般的なプログラムへのコードのコピーを伴わない。本件ではむしろ、申立人（Google)は、他のコンピュータープログラムを書く際にプログラマを支援するために設計されたプログラミングツールのプラットフォームの一部として配布されている、記述済みのJavaメソッド群のある部分をコピーしている。結果として、両者および下位法廷では、宣言コードと実装コードの区別、Java Standard Libraryの様々な機能についての技術的な重要性、Javaプログラマーがどの程度被告（Oracle)の記述済みのメソッドに親しんでいるのか、などの論点について相当な注意を費やしてきたが、これらはより一般的な論争ではあまり重要ではないであろう。今回の判断は、これにより、より典型的なコンピュータープログラムに伴う著作権侵害の案件の適切な判断に対しては、あまり意義のあるものではないかもしれない。
判決文を読むきっかけを与えて下さり感謝いたします。また、記事内でまとめられている経緯は、判決文を読む上で大きな助けとなりました。
以下、記事の中のうち、判決文で書かれている内容と齟齬があると思われる点について指摘させていただきます。
Unlike many of the cases that have been the subject of reported appellate decisions, this case does not involve the copying of code for an ordinary computer program.
著作権の侵害にはコードのコピーはいらない、ということを言っています。
この文章は「コードのコピーはいらない」ことを述べているのではなく、本件が「an ordinary computer program」のためのコピーではない、ということを指摘しているものと思われます。これは、今回のコードが、JDKおよびAndroidというプラットフォームの一部として、開発者がプログラムを開発するための「building block (p.5)」を構成している点が特質的であるためです。
As a result, the parties and the courts below have devoted considerable attention to questions—such as the distinction between declaring code and implementing code, the technical significance of various features of the Java Standard Library, and the degree to which Java programmers possess familiarity with respondent’s pre written methods—that may have little significance in more common disputes
Java標準ライブラリやツールなどに慣れたJavaプログラマが、即座に利用できるようにAPIをコピーして、OracleがJavaを作り続けることで得てきたエコシステムを横取りするようなことについてたくさん議論してきた、という意味に読めます。
この文章は「エコシステムを横取りするようなこと」を主として議論してきたという点を指摘するものではなく（もちろん議論はされたと想像できますが）、本件で行われてきた議論が、その議論対象のコードの特殊性からして一般的ではなかったということを説明しているものと思われます。宣言コードと実装コードの区別も今回のコードが「building block」であるために発生した区別であり、残りの点もJDKがプラットフォームであるために行われた議論であることから、最後に「より一般的な論争ではあまり重要ではないであろう」と述べられています。
The Court’s resolution of this case therefore might not cast meaningful light on the proper resolution of more typical copyright-infringement cases involving computer programs.
「今回の判決を持って、今後もAPIが必ず著作権保護されるわけではない」としています。つまり、今回著作権による保護が認められたのは特例？
ここで対比されている「typical copyright-infringement cases involving computer programs」は、前述の「an ordinary computer program」のためのコピーによる著作権侵害を主として指していると考えるのが自然だと思われます。「今後もAPIが必ず著作権保護されるわけではない」と読むのは難しいように思われます。
そういう意味ではAPIは著作権保護対象ではないという今までの前提が完全に覆されたわけではなさそうですが、「場合によっては権利が主張できる一方で相手のプラットフォームの競争力を奪う規模でのAPIの利用はフェアユースの範疇を超えている、というのが今回の趣旨のように見えます。
このような判断はなされていません。繰り返しになりますが、Fair Useの審理は地裁に差し戻されており、判決文ではFair Useに対する判断は行われていません。判決文ではむしろ、「請求人（Google）が提起したロックイン効果や互換性といった重要な懸念については、その原理を通して言及されるのがよい(p.22)」と述べられれており、（「原理（Doctrin）」はFair Useを指す）、Googleの主張の重要性に一定の理解が示されています。
Javaの標準ライブラリの「structure, sequence and organization」を強調しているのは、最後の判決の直前のところでも語られていたように、判決が一般解として業界全体に影響が波及するのを恐れていて、あくまでも「Java標準ライブラリの今回のケースだけですよ！」というのを強調しているように見えます(moriyoshi談)。
前述のとおり、比較対象は「一般的なコピー」であり、JDKを特殊化した記述はみつかりませんでした。
アイディアとは具体的には17 U.S.C. §102 (b) の「any idea, procedure, process, system, method of operation, concept, principle, or discovery」で、今回のdeclaring codeはアイディアではなく著作なのでフェアユースではないということですね。
17 U.S.C. § 107で定義されるFair Useは著作権で保護された作品に対して適用されます。そのため、「アイディアではなく著作なのでフェアユースではない」というのは間違いで、著作物だからこそFair Useが適用される余地があることになります。
Oracleは当初より、コード文字列の直接的なコピー（literal copying）だけでなく、コードが表す「structure, sequence, and organization（SSO）」つまり「構造、順序、構成」のコピー（non-literal copying）も問題として取り上げている(p.7)。
SSOに含まれる要素は、一見すると102(b)により定義される「アイデア」や「オペレーションの方法」、あるいは「システム」に該当するように思われる。しかし、ここで注意しなければならないのは、Oracleは法廷において具体的に「the structure, sequence, and organization of each of the 37 Java API packages」つまり「37のJavaパッケージの構造、順序、構成」がコピーされたと述べている点である(控訴審判決のp.11)。Oracleは「構造、順序、構成」という概念（アイデア）それ自身のコピーを問題視しているのではなく、37のパッケージ内に存在している具体的な構造や順序、そして構成のコピーを問題視している。
控訴審の判決文にもこの点が言及されており、Oracleは「package-class-method」という一般的な構成そのものに対しては著作権を主張していない(控訴審判決のp.43)。一方で、「37のJavaパッケージの具体的な名前と構成」には著作権が付与されると主張しており（控訴審判決のp.43）、Oracleが単なるアイデアではなく、具体的な表現のコピーのみを問題としていることが分かる。
差し戻し審の一審判決が出たので少しだけ争点の解説を行いました。
@moriyoshi お返事ありが追うございます。基本的な認識は私も共通しております。
この点は非常に重要な論点だと思います。たとえば、クラウドを例とするとAWS互換のAPIを別のクラウドに実装する場合を考えます。AWSのコードは宣言部も含めて公開されていないため、コード自体のコピーはそもそもコピーのしようがありません。しかし、APIの仕様は例えばドキュメントにメソッドの名前や引数の順序が記載されており（IDLが使われることもあるかもしれません）、その情報を参照することは可能ですし、これを参考にしないと互換APIを作ることは出来ません。この場合、今回の判決に従えば、たとえコードをコピーしていないとしても、メソッドの名前や構成がコピーされている場合、それはSSOとみなされ著作権の侵害になる可能性が感じられます（Fair Useによって救済される可能性は別として）。
例えば引用頂いた英語の例を考えた場合、英語の著作物を勝手に翻訳すると一般的に著作権法上の問題となることから、プログラミング言語間における「翻訳」も同様に問題となるように思われます。つまり、プログラミング言語が違ってもメソッド名や構造が同じ場合はSSOの侵害になるとという認識です。
以上の点に関してはご指摘の通り判決文内では直接的に言及されていない部分ですので、具体的な事例で裁判が行われない限り明確な答えは出ないものと推測されます。私個人としては、たとえプログラミング言語が違う場合も訴訟のリスクは無視できない程度にはあるだろう、というのが現状の認識です。