Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
Google v. Oracle API著作権裁判

Oracle v. GoogleのAPI著作権裁判の話

OracleとGoogleの判決文を斜め読む」を読んで裁判の経緯は理解できたものの、判決の詳細があまり理解できなかったので判決文を自分で読んだ。法律的な難しさはあまりなく、技術的な論点と関係する条文および過去の判例などが非常にわかりやすく解説されており、判決の根拠もたとえ話を交えて書かれているなど非常に読みやすい印象を受けた。

全体の内容としては比較的単純で「あらゆるプログラムのコードは著作権で保護される。ただしFair Useによる合法的な利用に関しては差し戻し審で審議せよ」という事のようだ。実は「API」という言葉は一切判決文には出てこないため、内容を良く読む必要がある。

17 U.S.C. 102(b)を巡るGoogleの主張

今回の論争のうち最も重要な点は、著作権法のうち 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)

以上のように、宣言コードと実装コードという区分は本来著作権法では定義されておらず、法律の趣旨からしても宣言コードは保護の対象内と見なされるという結論となっている。

3つの著作権回避策

判決文ではGoogleが主張した判例や他の条文に基づく3つの著作権の無効化手法についても、それぞれ説明が与えられている。

Merger原理

あるアイデアが非常に限られた数の方法でしか表現できない場合、その表現に対する著作権は制限される(p.2)。たとえば余りに単純なアルゴリズムは、いわゆる「誰が書いても同じ」コードになってしまうので著作権が適用されないことがあるかもしれない。

Googleは過去の判例(Baker v. Selden, supra)を引き合いに出して、本件に対してMerger原理を当てはめることも主張していたようだが(p.16)、地裁での支持(p.8)に対して、控訴審(p.9)および今回の判決文では条件の違いからこれを認めず(p.16)、判決文では、控訴審の「メソッドの取り得た名前や構造は無数ある」という宣言に対してGoogleが争わなかったことを根拠として「Androidプラットフォームの構築した際に、被告の宣言コードをコピーする論理的な必然性がない(p.16)」と結論づけている(p.16)。

個人的な印象としても、(呼び出し側コードの書き換えを厭わなければ)同じ動作に対して違うメソッド名を付けることも、引数の名前を変えることも可能であると直感的に理解できるので、merger原理を適用するのは無理があるように思える。

scènes à faire原理

Meger原理に似た原理として、不可欠であったり、あまりにも古典的だったり標準的な表現はscènes à faire原理によって保護されないことがある(pp.2-3)。GoogleはSSOに対してこの原理の適用を求めたが、これは地裁でも却下されているし(p.8)、控訴審でも根拠の不十分さから認められていない(p.9)

JDKの仕組みは確かにJavaの標準的な仕組みではあるものの、ソフトウェア産業全体で見た場合は必ずしもこの原理を適用できるほどの普遍性を見いだすことが出来ないというのは理解できそうに思われる。

Fair Use

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)の記述済みのメソッドに親しんでいるのか、などの論点について相当な注意を費やしてきたが、これらはより一般的な論争ではあまり重要ではないであろう。今回の判断は、これにより、より典型的なコンピュータープログラムに伴う著作権侵害の案件の適切な判断に対しては、あまり意義のあるものではないかもしれない。

「OracleとGoogleの判決文を斜め読む」について

判決文を読むきっかけを与えて下さり感謝いたします。また、記事内でまとめられている経緯は、判決文を読む上で大きな助けとなりました。

以下、記事の中のうち、判決文で書かれている内容と齟齬があると思われる点について指摘させていただきます。

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が適用される余地があることになります。

補足:SSOとアイデアの違い

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が単なるアイデアではなく、具体的な表現のコピーのみを問題としていることが分かる。

link

差し戻し審の一審判決が出たので少しだけ争点の解説を行いました。

@moriyoshi

This comment has been minimized.

Copy link

@moriyoshi moriyoshi commented Jul 3, 2015

Javaの標準ライブラリの「structure, sequence and organization」を強調しているのは、最後の判決の直前のところでも語られていたように、判決が一般解として業界全体に影響が波及するのを恐れていて、あくまでも「Java標準ライブラリの今回のケースだけですよ!」というのを強調しているように見えます(moriyoshi談)。

前述のとおり、比較対象は「一般的なコピー」であり、JDKを特殊化した記述はみつかりませんでした。

この点について補足しておくと、JDKかどうかということではなく、 declaring code と implimenting code という体裁を取るもの一般のコピーの話をしていたのです。

API が必ずしも declaring code という体裁を取るものではないことから、(判決文の中では) APIそのものの定義から著作権の及ぶスコープを議論するつもりはない姿勢をとっていた、という理解です。

@yudai

This comment has been minimized.

Copy link
Owner Author

@yudai yudai commented Jul 3, 2015

@moriyoshi コメントありがとうございます。

moriyoshiさんの真意は「今回の裁判では、いわゆる『API』の実装形態のうち、宣言コードと実装コードに別れている事例についての判断が下されただけであり、その他の形態については未解決である」という事でよろしいでしょうか。
引用文中の「Java標準ライブラリの今回のケースだけですよ!」の部分は、本来であれば「APIの実装が宣言コードと実装コードに別れているケースだけですよ!」が(冗長な表現を無視すれば)正しく、JDKに限定して述べるのは趣旨に反する、ということだと理解いたしました(誤認がありましたらご指摘ください)。

一方で今回の判決では、102(a)の定義において、宣言コードと実装コードの区別が著作権を与える上で考慮されないことが示されています(p.14)。つまり、プログラミング言語によるコードの便宜的な分類は法律上意味を成さないという判断であり、言い換えれば、102(a)の条件を満たす_全ての_コードが著作権の対象になるということです。
そのため、今回の判決で示された著作権保護の対象となるケースは、「APIの実装が宣言コードと実装コードに別れているケース」のみではなく、「APIの実装が102(a)を満たすコードで実装された全てのケース」であると考えるのが妥当だと思われます。

さらに、SSOはOracleが「non-literal copying」つまり、「文字列としての直接的な転写を含まないコピー」として主張したものです(p.7)。SSOは今回の判決文では深く取り上げられていませんが、控訴審の判決文では議論にページが割かれており、Oracleは「37のJavaパッケージの具体的な名前と構成(控訴審判決のp.43)」自体が著作権保護の対象であると主張しており、これが認められています(同p.69)。
この判断が意味するところは、たとえ文字列としてAPIを定義するコードがコピーされていない場合でも、メソッドの名前や引数名、パッケージの名前や構成が同じものを作ると著作権の侵害になりうるということです。そのため、判決内容はいわゆる「API」の範囲をむしろ幅広い範囲で認めているとも言えます。

以上の理由から、

判決が一般解として業界全体に影響が波及するのを恐れていて、あくまでも「Java標準ライブラリの今回のケースだけですよ!」というのを強調しているように見えます

というのは(moriyoshiさんの意図を汲んだとしても)判決文を読む限り妥当ではなく、むしろ幅広い影響が及びかねない判決内容と見るのが正しいのではないかと思います。

@shibukawa

This comment has been minimized.

Copy link

@shibukawa shibukawa commented Jul 3, 2015

結論部分ぐらいしか読んでなくて、後は飛ばしまくっていた&フェアユースの件は間違って理解していたので、詳しく解説してもらえて助かります。

↑のコメントの2人の議論の話ですが、

"今回の判断は、これにより、より典型的なコンピュータープログラムに伴う著作権侵害の案件の適切な判断に対しては、あまり意義のあるものではないかもしれない。"

の部分をどう受け止めるかで他の部分への印象が大きく変わるきがしてます。 @moriyoshi も僕も、ここを読んで「今回のケースは一般化されない部分を含んだ判決である」という理解をして、じゃあその一般化されない領域っていうのはどこか?と考えて、Java共有ライブラリ特有の状況を一部含んでいるのかなと思いました。

僕はその直前にも書かれた、Javaのツールや、スキルを持った(JavaのSSOに慣れ親しんだ)開発者がすでにいるというエコシステム(という言葉は明示的には使われていませんが)についての話が、結論以外の議題の中でもそこそこあった気がするので、コピーする行為以外に、コピー対象が社会的にどのぐらいインパクトがあるのかも判断材料になっていたのかな、と思いました。この場合はLotus 1-2-3の時の「囲い込みに対処する機能コピーは許される」という判例もあり、そうなると今回の訴訟にあたるようなソフトウェアはそれほど多くないのかな、と思いました。

「メソッドの名前や引数名、パッケージの名前や構成が同じものを作ると著作権の侵害になりうる」まで広く汎化して認めてしまうと、「典型的な〜あまり意義のあるものではない」という結論にはならないと思うんですよね。

@moriyoshi

This comment has been minimized.

Copy link

@moriyoshi moriyoshi commented Jul 3, 2015

丁寧な返信、ありがとうございます!

moriyoshiさんの真意は「今回の裁判では、いわゆる『API』の実装形態のうち、宣言コードと実装コードに別れている事例についての判断が下されただけであり、その他の形態については未解決である」という事でよろしいでしょうか。
引用文中の「Java標準ライブラリの今回のケースだけですよ!」の部分は、本来であれば「APIの実装が宣言コードと実装コードに別れているケースだけですよ!」が(冗長な表現を無視すれば)正しく、JDKに限定して述べるのは趣旨に反する、ということだと理解いたしました(誤認がありましたらご指摘ください)。

ご認識されているとおりです。

一方で今回の判決では、102(a)の定義において、宣言コードと実装コードの区別が著作権を与える上で考慮されないことが示されています(p.14)。つまり、プログラミング言語によるコードの便宜的な分類は法律上意味を成さないという判断であり、言い換えれば、102(a)の条件を満たす全てのコードが著作権の対象になるということです。

はい、これは API を成すものは何か、の議論とは無関係で、コードが著作権でカバーされる、ということだと認識しています。

そのため、今回の判決で示された著作権保護の対象となるケースは、「APIの実装が宣言コードと実装コードに別れているケース」のみではなく、「APIの実装が102(a)を満たすコードで実装された全てのケース」であると考えるのが妥当だと思われます。

たとえば、API を定義するものという観点では、IDL (interface definition language) のような、特定のプログラミング言語の実装から離れた、中立的なインターフェイスを記述するための言語があります。このような言語から何らかの生成器により生成された、特定の言語の declaring code のコピーに IDL の著作者の権利が及ぶかどうかは、この判決文からは判断できないかと思われるのですが、いかがでしょうか。

さらに、SSOはOracleが「non-literal copying」つまり、「文字列としての直接的な転写を含まないコピー」として主張したものです(p.7)。SSOは今回の判決文では深く取り上げられていませんが、控訴審の判決文では議論にページが割かれており、Oracleは「37のJavaパッケージの具体的な名前と構成(控訴審判決のp.43)」自体が著作権保護の対象であると主張しており、これが認められています(同p.69)。
この判断が意味するところは、たとえ文字列としてAPIを定義するコードがコピーされていない場合でも、メソッドの名前や引数名、パッケージの名前や構成が同じものを作ると著作権の侵害になりうるということです。そのため、判決内容はいわゆる「API」の範囲をむしろ幅広い範囲で認めているとも言えます。

明確に言及されているわけではないので、推測を含みますが、verbatim なコピーでなかったとしても著作権が及ぶという部分は、同じプログラミング言語で記述されたソースコードにおける議論かと思います。

これはたとえば、下記の部分から汲み取ったものです。

�on 13-1021.Opinion.5-7-2014.1 p44:

On appeal, Oracle does not—and concedes that it cannot—claim copyright in the idea of organizing functions of a computer program or in the “package-class-method” organizational structure in the abstract. Instead, Oracle claims copyright protection only in its particular way of naming and organizing each of the 37 Java API packages. Oracle recognizes, for example, that it “cannot copyright the idea of programs that open an internet connection,” but “it can copyright the precise strings of code used to do so, at least so long as ‘other language is available’ to achieve the same function.” Appellant Reply Br. 13-14 (citation omitted). Thus, Oracle concedes that Google and others could employ the Java language—much like anyone could employ the English language to write a paragraph without violating the copyrights of other English language writers. And, that Google may employ the “package-class-method” structure much like authors can employ the same rules of grammar chosen by other authors without fear of infringement. What Oracle contends is that, beyond that point, Google, like any author, is not permitted to employ the precise phrasing or precise structure chosen by Oracle to flesh out the substance of its packages—the details and arrangement of the prose.

正直な所、私と @shibukawa の間でも認識の違いというものがあって、そこが混乱の元の一つだったかもしれません。

@yudai

This comment has been minimized.

Copy link
Owner Author

@yudai yudai commented Jul 4, 2015

@shibukawa コメントありがとうございます。

“今回の判断は、これにより、より典型的なコンピュータープログラムに伴う著作権侵害の案件の適切な判断に対しては、あまり意義のあるものではないかもしれない。"
の部分をどう受け止めるかで他の部分への印象が大きく変わるきがしてます。 @moriyoshi も僕も、ここを読んで「今回のケースは一般化されない部分を含んだ判決である」という理解をして、じゃあその一般化されない領域っていうのはどこか?と考えて、Java共有ライブラリ特有の状況を一部含んでいるのかなと思いました。

ご指摘のとおり、引用頂いた部分の受け止め方に違いがあるようです。

該当段落の趣旨は「今回のケースは一般化されない部分を含んだ判決である」ということではなく、「Java共有ライブラリ特有の状況についてこれ以上議論しても、今後の案件にとっては意味が無い」ということだと認識しています。というのも、この文章が書かれている章が「B. This Court’s Review Is Not Warranted(p.19)」であり、該当の段落は請求人がさらなる審理を請求できない理由の一部であるからです。節のタイトルも「Other factors counsel against further review in this case.」となっています(p.22)。つまり、この節は再審をしない理由を「コードの細かい特徴をこれ以上突いても意味が無い」と述べているのであり、判決の判断材料として「コードの特徴」が重要であったと述べているものではないと考えられます(そのためp.15で既に重要ではないと述べられている「宣言コードと実装コードの違い」についても触れられています)。むしろ最高裁はこれまで時間を割いてきたこれらの争点は、102(a)の適用に対しては大きな意味を持たず、これ以上の議論をしても後続の裁判で役に立つ知見が得られないと考えているものと思われます。

僕はその直前にも書かれた、Javaのツールや、スキルを持った(JavaのSSOに慣れ親しんだ)開発者がすでにいるというエコシステム(という言葉は明示的には使われていませんが)についての話が、結論以外の議題の中でもそこそこあった気がするので、コピーする行為以外に、コピー対象が社会的にどのぐらいインパクトがあるのかも判断材料になっていたのかな、と思いました。

たしかに、判決文中には社会的なインパクトをGoogleが指摘していることへの言及が複数箇所あります。例えば「イノベーションの基礎的なビルディングブロックの長期的な独占(p.16)」や「囲い込み効果や互換性への正当な懸念(p.17)」といった表現です。しかし、判決分中では、これらの社会的インパクトに関する懸念はFair Useの観点から議論すべきであり、その作品がそもそも著作権で保護されるかどうかについては関係がないと述べられています(p.17)。そしてFair Useの適用可否の審理が地裁に差し戻されていることを考慮すると、本判決文に「社会的インパクト」の有無が大きく影響していると考えるのは妥当ではないものと考えられます。

また、判決分中の「これらはより一般的な論争ではあまり重要ではないであろう」という文において、書き出しが「As a result」で始まっている点にも注目が必要です。これは「前文の結果として」ということなので、その前文である「本件ではむしろ、申立人(Google)は、他のコンピュータープログラムを書く際にプログラマを支援するために設計されたプログラミングツールのプラットフォームの一部として配布されている、記述済みのJavaメソッド群のある部分をコピーしている」ことこそが「今回のコードの特徴」であるということになります。さらにこの文も文頭が「Rather」から始まっていることから、その比較対象となる「特徴的ではない事例」が「報告されている控訴審の主題の大部分のケース」であり、それは「一般的なプログラム」だということもわかります。つまり、ここでの比較されているのは「社会的インパクトの有無」ではなくて、「プログラマ用の開発環境で使用される記述済みJavaメソッドの一部のコード」と「一般的なコンピュータープログラムにおけるコード」です。

以上より、社会的インパクトの有無が今回の判決に重要性を持っていたと考えるのは妥当ではないものと考えられますがいかがでしょうか。また、裁判所は今回の「判決」が「一般化されない部分」を含んでいるとは考えておらず、むしろ102(a)を条文の通り適用するだけの立場であり、「宣言コードや実装コード」あるいは「市場へのインパクト」といったJava標準ライブラリ固有の争点についてこれ以上重箱の隅を突くような議論は必要ないと考えているように見受けられます。

「メソッドの名前や引数名、パッケージの名前や構成が同じものを作ると著作権の侵害になりうる」まで広く汎化して認めてしまうと、「典型的な〜あまり意義のあるものではない」という結論にはならないと思うんですよね。

「典型的な〜あまり意義のあるものではない」の部分は文章上は2通りの解釈が可能だと可能だと思われます。

  1. ケース自体が特殊であり一般的なケースとは相容れないことから、このケースの子細議論しても一般的なケースにとっては無関係である
  2. ケース自体は一般的な議論で決着が付くのに、このケースの子細について深い議論をしても意義がない

私の認識としては、前述の理由より2がこの段落の趣旨だと考えています。

ところで、若干話はそれてしまうのですが、引用頂いた判例の解釈に疑問があります。

この場合はLotus 1-2-3の時の「囲い込みに対処する機能コピーは許される」という判例もあり、そうなると今回の訴訟にあたるようなソフトウェアはそれほど多くないのかな、と思いました。

というのも、Lotus v. Borlandの判例が「囲い込みに対処する機能コピーは許される」根拠となると認める資料が見つからないのです。今回の判決文、控訴審の判決文ともにこのケースへの言及がありますが、どちらにおいても102(b)を適用した判例として取り上げられているだけで、「囲い込み」のような市場競争上の観点には触れられていません。引用部分の表現はshibukawaさんの記事から参照されている「コンピュータ関係の創作保護についての最近の米国での話題」に見つけることが出来ますが、私が調べた限りでは他の資料にはそのよう事が書かれておらず、具体的な根拠を見つけることが出来ませんでした。もしなにか他に資料をご存じでしたら教えて頂けますと幸いです。

@yudai

This comment has been minimized.

Copy link
Owner Author

@yudai yudai commented Jul 4, 2015

@moriyoshi お返事ありが追うございます。基本的な認識は私も共通しております。

たとえば、API を定義するものという観点では、IDL (interface definition language) のような、特定のプログラミング言語の実装から離れた、中立的なインターフェイスを記述するための言語があります。このような言語から何らかの生成器により生成された、特定の言語の declaring code のコピーに IDL の著作者の権利が及ぶかどうかは、この判決文からは判断できないかと思われるのですが、いかがでしょうか。

この点は非常に重要な論点だと思います。たとえば、クラウドを例とするとAWS互換のAPIを別のクラウドに実装する場合を考えます。AWSのコードは宣言部も含めて公開されていないため、コード自体のコピーはそもそもコピーのしようがありません。しかし、APIの仕様は例えばドキュメントにメソッドの名前や引数の順序が記載されており(IDLが使われることもあるかもしれません)、その情報を参照することは可能ですし、これを参考にしないと互換APIを作ることは出来ません。この場合、今回の判決に従えば、たとえコードをコピーしていないとしても、メソッドの名前や構成がコピーされている場合、それはSSOとみなされ著作権の侵害になる可能性が感じられます(Fair Useによって救済される可能性は別として)。

明確に言及されているわけではないので、推測を含みますが、verbatim なコピーでなかったとしても著作権が及ぶという部分は、同じプログラミング言語で記述されたソースコードにおける議論かと思います。

例えば引用頂いた英語の例を考えた場合、英語の著作物を勝手に翻訳すると一般的に著作権法上の問題となることから、プログラミング言語間における「翻訳」も同様に問題となるように思われます。つまり、プログラミング言語が違ってもメソッド名や構造が同じ場合はSSOの侵害になるとという認識です。

以上の点に関してはご指摘の通り判決文内では直接的に言及されていない部分ですので、具体的な事例で裁判が行われない限り明確な答えは出ないものと推測されます。私個人としては、たとえプログラミング言語が違う場合も訴訟のリスクは無視できない程度にはあるだろう、というのが現状の認識です。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.