「OracleとGoogleの判決文を斜め読む」を読んで裁判の経緯は理解できたものの、判決の詳細があまり理解できなかったので判決文を自分で読んだ。法律的な難しさはあまりなく、技術的な論点と関係する条文および過去の判例などが非常にわかりやすく解説されており、判決の根拠もたとえ話を交えて書かれているなど非常に読みやすい印象を受けた。全体の内容としては比較的単純で「あらゆるプログラムのコードは著作権で保護される。Useによる合法的な利用に関しては差し戻し審で審議せよ」という事のようだ。実は「API」という言葉は一切判決文には出てこないため、内容を良く読む必要がある。102(b)という条文が、GoogleがOracleからコピーしたコードに対して適用されるか、ということである。operation」や「system」に該当し、著作権で保護されないと主張していた。work.”つまり、著作権はアイデアやシステム、プロセス、オペレーションの方法に拡張されることはないと書かれている。Googleとしては、「その著作物が動作するコンポーネントを含むのであれば、102(b)によって著作権による保護は失われる(p.9)」し、「宣言コードとは実行コードが定義するメソッドを『実施(オペレート)する方法』である(p.14)」と主張したい。地裁では102(b)の適用が認められたが(p.8)、この主張は上訴審では覆されてしまった(p.9)。控訴審ではコンピューターコードは表現であるとされ(p.9)、「コンピュータープログラムはその定義からしてfunctional」であり、「タスクを実行するために設計されている」のだから、地裁の判断は「あらゆるコンピュータープログラムが保護されなくなる」ことを示唆しかねないし、それは「コンピュータープログラムに著作権を付与するという議会の意図にも反する」ことになる、と結論された(p.9)。今回の判決文では、控訴審の判決が支持され、102(b)の適用は認められなかった。これは以下のように説明されている。(p.12)著作憲法はアイデアやコンセプトを表現する手法は保護するが、アイデアやコンセプトの利用それ自体は制限しない(p.12)Googleによる、1つの作品に対して102(a)と102(b)が同時に適用されることがありうるという主張は間違っている。102(a)は表現物に与えられ、102(b)は表現物によって説明もしくは記述されるアイデアに適用されるからである(p.13)従来の本などでは手順の表現と手順の実施がことなることは明白であったが、コンピュータープログラムは手順の表現かつ、実施の手段でもある。operation」や「system」はコンピューターコードによって起動されるコンピューターの機能であるたとえばソートアルゴリズムのようなもし仮に102(b)の適用をコンピューターコード自体に認めてしまえば、あらゆるコンピューターコードが保護の対象外となってしまう(p.13)そして、宣言コードと実装コードの境界は明確ではない。どちらも最終的に起動される機能を実行する(p.14)宣言コードは実装コードよりも1ステップ離れてはいる。Googleはコードに102(b)が適用される条件が、コードと最終的な機能の関係性が直接的であるかどうかに依存するという根拠を示すことがでなかった(p.15)むしろ法令文によれば「コンピュータープログラム」とは「直接的または間接的に使用されるステートメントの集合」と定義されている(p.15)さらに、102(b)は「著作権で保護されるもの」と「それ以外のもの」を区別するための条文であるが、Googleはそれを102(a)で保護される全体とその一部に当てはめようとしている。(p.16)以上のように、宣言コードと実装コードという区分は本来著作権法では定義されておらず、法律の趣旨からしても宣言コードは保護の対象内と見なされるという結論となっている。Googleが主張した判例や他の条文に基づく3つの著作権の無効化手法についても、それぞれ説明が与えられている。Merger原理あるアイデアが非常に限られた数の方法でしか表現できない場合、その表現に対する著作権は制限される(p.2)。余りに単純なアルゴリズムは、いわゆる「誰が書いても同じ」コードになってしまうので著作権が適用されないことがあるかもしれない。supra)を引き合いに出して、本件に対してMerger原理を当てはめることも主張していたようだが(p.16)、地裁での支持(p.8)に対して、控訴審(p.9)および今回の判決文では条件の違いからこれを認めず(p.16)、判決文では、控訴審の「メソッドの取り得た名前や構造は無数ある」という宣言に対してGoogleが争わなかったことを根拠として「Androidプラットフォームの構築した際に、被告の宣言コードをコピーする論理的な必然性がない(p.16)」と結論づけている(p.16)。個人的な印象としても、(呼び出し側コードの書き換えを厭わなければ)同じ動作に対して違うメソッド名を付けることも、引数の名前を変えることも可能であると直感的に理解できるので、merger原理を適用するのは無理があるように思える。faire原理によって保護されないことがある(pp.2-3)。GoogleはSSOに対してこの原理の適用を求めたが、これは地裁でも却下されているし(p.8)、控訴審でも根拠の不十分さから認められていない(p.9)JDKの仕組みは確かにJavaの標準的な仕組みではあるものの、ソフトウェア産業全体で見た場合は必ずしもこの原理を適用できるほどの普遍性を見いだすことが出来ないというのは理解できそうに思われる。Useによって合法的な利用が可能だとも主張している。具体的には「『ソフトウェア開発者はすでに係争中のJava(中略)パッケージで訓練され経験している』ので、コピーはその技術を被告(Oracle)の技術と互換にするために必要であった」としている(p.10)。控訴審では証拠の不足から判断が出来ないとして、審理を地裁に差し戻している(p.10)。Useの適用の可否についてはまだ結論が出ておらず、地裁の審理待ちである(p.22)。Useの107で扱うべきであるとしている(pp.16-17)。判決文内では差し戻し審で考慮すべき点をいくつか挙げているが、具体的な判断については書かれていない。たとえ話たとえば、ある難しいアルゴリズムをメソッドとして実装する場合、そのアルゴリズム自体はアイデアなので(特許は別として)著作権では保護されない。これが102(b)の趣旨である。アルゴリズムを実装するメソッドのコードは、人によって当然書き方が違うので、著作権で保護される。再利用性や可読性、テストのしやすさなどを吟味すると、メソッドの宣言部にも人によって書き方に違いが出てくるのは不自然ではないし、そこには十分な創造性が含まれているので、著作権で保護されるのが妥当であると見なされる。宣言コードと実装コードは便宜上区別されているものの、どちらも最終的にはアルゴリズムを表現したものであることから、102(a)の定義上違いがないと考えられる。以上のたとえ話はこの記事のために創作されたものであるが、判決文では宣言コードについて、「メソッドの名付けや構成において創造的な選択が果たされている(p.11)」とか「一般的なコードとは異なる特出した品質であると認める(p.14)」といった表現で、宣言コードが102(a)の定義に合致する理由を述べている。今回の話は一般的な話なのか判決文では今回の判決がJavaもしくはJDKの提供するAPIに制限されるということは特に書かれていなかった。他の言語でも、元となるライブラリと同じシグニチャのメソッドを集めて互換ライブラリを作るなどすると、今回の判決と同様の結論に至るのではないかと思われる。以下のように書かれている。単純にコピーアンドペーストで他所の実装をコピーした場合に比べ、今回は争点が特殊だったということのようだ。3番目に、本件で取り扱った著作物はその性質上、(最高裁)法廷がコンピュータープログラムに対する著作権原則の適用について初めて言及するにあたり、適したケースとは言い難い。報告されている控訴審の主題の大部分のケースと異なり、本件では一般的なプログラムへのコードのコピーを伴わない。本件ではむしろ、申立人(Google)は、他のコンピュータープログラムを書く際にプログラマを支援するために設計されたプログラミングツールのプラットフォームの一部として配布されている、記述済みのJavaメソッド群のある部分をコピーしている。Libraryの様々な機能についての技術的な重要性、Javaプログラマーがどの程度被告(Oracle)の記述済みのメソッドに親しんでいるのか、などの論点について相当な注意を費やしてきたが、これらはより一般的な論争ではあまり重要ではないであろう。今回の判断は、これにより、より典型的なコンピュータープログラムに伴う著作権侵害の案件の適切な判断に対しては、あまり意義のあるものではないかもしれない。「OracleとGoogleの判決文を斜め読む」について判決文を読むきっかけを与えて下さり感謝いたします。記事内でまとめられている経緯は、判決文を読む上で大きな助けとなりました。以下、記事の中のうち、判決文で書かれている内容と齟齬があると思われる点について指摘させていただきます。program.著作権の侵害にはコードのコピーはいらない、ということを言っています。program」のためのコピーではない、ということを指摘しているものと思われます。(p.5)」を構成している点が特質的であるためです。disputesJava標準ライブラリやツールなどに慣れたJavaプログラマが、即座に利用できるようにAPIをコピーして、OracleがJavaを作り続けることで得てきたエコシステムを横取りするようなことについてたくさん議論してきた、という意味に読めます。この文章は「エコシステムを横取りするようなこと」を主として議論してきたという点を指摘するものではなく(もちろん議論はされたと想像できますが)、本件で行われてきた議論が、その議論対象のコードの特殊性からして一般的ではなかったということを説明しているものと思われます。block」であるために発生した区別であり、残りの点もJDKがプラットフォームであるために行われた議論であることから、最後に「より一般的な論争ではあまり重要ではないであろう」と述べられています。programs.「今回の判決を持って、今後もAPIが必ず著作権保護されるわけではない」としています。program」のためのコピーによる著作権侵害を主として指していると考えるのが自然だと思われます。「今後もAPIが必ず著作権保護されるわけではない」と読むのは難しいように思われます。いう意味ではAPIは著作権保護対象ではないという今までの前提が完全に覆されたわけではなさそうですが、「場合によっては権利が主張できる一方で相手のプラットフォームの競争力を奪う規模でのAPIの利用はフェアユースの範疇を超えている、というのが今回の趣旨のように見えます。このような判断はなされていません。Useに対する判断は行われていません。Useを指す)、Googleの主張の重要性に一定の理解が示されています。organization」を強調しているのは、最後の判決の直前のところでも語られていたように、判決が一般解として業界全体に影響が波及するのを恐れていて、あくまでも「Java標準ライブラリの今回のケースだけですよ!」というのを強調しているように見えます(moriyoshi談)。前述のとおり、比較対象は「一般的なコピー」であり、JDKを特殊化した記述はみつかりませんでした。codeはアイディアではなく著作なのでフェアユースではないということですね。Useは著作権で保護された作品に対して適用されます。Useが適用される余地があることになります。copying)も問題として取り上げている(p.7)。SSOに含まれる要素は、一見すると102(b)により定義される「アイデア」や「オペレーションの方法」、あるいは「システム」に該当するように思われる。コピーされたと述べている点である(控訴審判決のp.11)。いう概念(アイデア)それ自身のコピーを問題視しているのではなく、37のパッケージ内に存在している具体的な構造や順序、そして構成のコピーを問題視している。控訴審の判決文にもこの点が言及されており、Oracleは「package-class-method」という一般的な構成そのものに対しては著作権を主張していない(控訴審判決のp.43)。一方で、「37のJavaパッケージの具体的な名前と構成」には著作権が付与されると主張しており(控訴審判決のp.43)、Oracleが単なるアイデアではなく、具体的な表現のコピーのみを問題としていることが分かる。link差し戻し審の一審判決が出たので少しだけ争点の解説を行いました。organization」を強調しているのは、最後の判決の直前のところでも語られていたように、判決が一般解として業界全体に影響が波及するのを恐れていて、あくまでも「Java標準ライブラリの今回のケースだけですよ!」というのを強調しているように見えます(moriyoshi談)。前述のとおり、比較対象は「一般的なコピー」であり、JDKを特殊化した記述はみつかりませんでした。いう体裁を取るもの一般のコピーの話をしていたのです。APIそのものの定義から著作権の及ぶスコープを議論するつもりはない姿勢をとっていた、という理解です。コメントありがとうございます。moriyoshiさんの真意は「今回の裁判では、いわゆる『API』の実装形態のうち、宣言コードと実装コードに別れている事例についての判断が下されただけであり、その他の形態については未解決である」という事でよろしいでしょうか。引用文中の「Java標準ライブラリの今回のケースだけですよ!」の部分は、本来であれば「APIの実装が宣言コードと実装コードに別れているケースだけですよ!」が(冗長な表現を無視すれば)正しく、JDKに限定して述べるのは趣旨に反する、ということだと理解いたしました(誤認がありましたらご指摘ください)。一方で今回の判決では、102(a)の定義において、宣言コードと実装コードの区別が著作権を与える上で考慮されないことが示されています(p.14)。プログラミング言語によるコードの便宜的な分類は法律上意味を成さないという判断であり、言い換えれば、102(a)の条件を満たす_全ての_コードが著作権の対象になるということです。そのため、今回の判決で示された著作権保護の対象となるケースは、「APIの実装が宣言コードと実装コードに別れているケース」のみではなく、「APIの実装が102(a)を満たすコードで実装された全てのケース」であると考えるのが妥当だと思われます。copying」つまり、「文字列としての直接的な転写を含まないコピー」として主張したものです(p.7)。SSOは今回の判決文では深く取り上げられていませんが、控訴審の判決文では議論にページが割かれており、Oracleは「37のJavaパッケージの具体的な名前と構成(控訴審判決のp.43)」自体が著作権保護の対象であると主張しており、これが認められています(同p.69)。この判断が意味するところは、たとえ文字列としてAPIを定義するコードがコピーされていない場合でも、メソッドの名前や引数名、パッケージの名前や構成が同じものを作ると著作権の侵害になりうるということです。そのため、判決内容はいわゆる「API」の範囲をむしろ幅広い範囲で認めているとも言えます。判決が一般解として業界全体に影響が波及するのを恐れていて、あくまでも「Java標準ライブラリの今回のケースだけですよ!」というのを強調しているように見えますというのは(moriyoshiさんの意図を汲んだとしても)判決文を読む限り妥当ではなく、むしろ幅広い影響が及びかねない判決内容と見るのが正しいのではないかと思います。2015結論部分ぐらいしか読んでなくて、後は飛ばしまくっていた&フェアユースの件は間違って理解していたので、詳しく解説してもらえて助かります。↑のコメントの2人の議論の話ですが、"今回の判断は、これにより、より典型的なコンピュータープログラムに伴う著作権侵害の案件の適切な判断に対しては、あまり意義のあるものではないかもしれない。"の部分をどう受け止めるかで他の部分への印象が大きく変わるきがしてます。僕も、ここを読んで「今回のケースは一般化されない部分を含んだ判決である」という理解をして、じゃあその一般化されない領域っていうのはどこか?と考えて、Java共有ライブラリ特有の状況を一部含んでいるのかなと思いました。僕はその直前にも書かれた、Javaのツールや、スキルを持った(JavaのSSOに慣れ親しんだ)開発者がすでにいるというエコシステム(という言葉は明示的には使われていませんが)についての話が、結論以外の議題の中でもそこそこあった気がするので、コピーする行為以外に、コピー対象が社会的にどのぐらいインパクトがあるのかも判断材料になっていたのかな、と思いました。1-2-3の時の「囲い込みに対処する機能コピーは許される」という判例もあり、そうなると今回の訴訟にあたるようなソフトウェアはそれほど多くないのかな、と思いました。「メソッドの名前や引数名、パッケージの名前や構成が同じものを作ると著作権の侵害になりうる」まで広く汎化して認めてしまうと、「典型的な〜あまり意義のあるものではない」という結論にはならないと思うんですよね。2015丁寧な返信、ありがとうございます!moriyoshiさんの真意は「今回の裁判では、いわゆる『API』の実装形態のうち、宣言コードと実装コードに別れている事例についての判断が下されただけであり、その他の形態については未解決である」という事でよろしいでしょうか。引用文中の「Java標準ライブラリの今回のケースだけですよ!」の部分は、本来であれば「APIの実装が宣言コードと実装コードに別れているケースだけですよ!」が(冗長な表現を無視すれば)正しく、JDKに限定して述べるのは趣旨に反する、ということだと理解いたしました(誤認がありましたらご指摘ください)。ご認識されているとおりです。一方で今回の判決では、102(a)の定義において、宣言コードと実装コードの区別が著作権を与える上で考慮されないことが示されています(p.14)。プログラミング言語によるコードの便宜的な分類は法律上意味を成さないという判断であり、言い換えれば、102(a)の条件を満たす全てのコードが著作権の対象になるということです。成すものは何か、の議論とは無関係で、コードが著作権でカバーされる、ということだと認識しています。そのため、今回の判決で示された著作権保護の対象となるケースは、「APIの実装が宣言コードと実装コードに別れているケース」のみではなく、「APIの実装が102(a)を満たすコードで実装された全てのケース」であると考えるのが妥当だと思われます。ような、特定のプログラミング言語の実装から離れた、中立的なインターフェイスを記述するための言語があります。著作者の権利が及ぶかどうかは、この判決文からは判断できないかと思われるのですが、いかがでしょうか。copying」つまり、「文字列としての直接的な転写を含まないコピー」として主張したものです(p.7)。SSOは今回の判決文では深く取り上げられていませんが、控訴審の判決文では議論にページが割かれており、Oracleは「37のJavaパッケージの具体的な名前と構成(控訴審判決のp.43)」自体が著作権保護の対象であると主張しており、これが認められています(同p.69)。この判断が意味するところは、たとえ文字列としてAPIを定義するコードがコピーされていない場合でも、メソッドの名前や引数名、パッケージの名前や構成が同じものを作ると著作権の侵害になりうるということです。そのため、判決内容はいわゆる「API」の範囲をむしろ幅広い範囲で認めているとも言えます。コピーでなかったとしても著作権が及ぶという部分は、同じプログラミング言語で記述されたソースコードにおける議論かと思います。これはたとえば、下記の部分から汲み取ったものです。間でも認識の違いというものがあって、そこが混乱の元の一つだったかもしれません。コメントありがとうございます。“今回の判断は、これにより、より典型的なコンピュータープログラムに伴う著作権侵害の案件の適切な判断に対しては、あまり意義のあるものではないかもしれない。"の部分をどう受け止めるかで他の部分への印象が大きく変わるきがしてます。僕も、ここを読んで「今回のケースは一般化されない部分を含んだ判決である」という理解をして、じゃあその一般化されない領域っていうのはどこか?と考えて、Java共有ライブラリ特有の状況を一部含んでいるのかなと思いました。ご指摘のとおり、引用頂いた部分の受け止め方に違いがあるようです。該当段落の趣旨は「今回のケースは一般化されない部分を含んだ判決である」ということではなく、「Java共有ライブラリ特有の状況についてこれ以上議論しても、今後の案件にとっては意味が無い」ということだと認識しています。Warranted(p.19)」であり、該当の段落は請求人がさらなる審理を請求できない理由の一部であるからです。case.」となっています(p.22)。この節は再審をしない理由を「コードの細かい特徴をこれ以上突いても意味が無い」と述べているのであり、判決の判断材料として「コードの特徴」が重要であったと述べているものではないと考えられます(そのためp.15で既に重要ではないと述べられている「宣言コードと実装コードの違い」についても触れられています)。最高裁はこれまで時間を割いてきたこれらの争点は、102(a)の適用に対しては大きな意味を持たず、これ以上の議論をしても後続の裁判で役に立つ知見が得られないと考えているものと思われます。僕はその直前にも書かれた、Javaのツールや、スキルを持った(JavaのSSOに慣れ親しんだ)開発者がすでにいるというエコシステム(という言葉は明示的には使われていませんが)についての話が、結論以外の議題の中でもそこそこあった気がするので、コピーする行為以外に、コピー対象が社会的にどのぐらいインパクトがあるのかも判断材料になっていたのかな、と思いました。たしかに、判決文中には社会的なインパクトをGoogleが指摘していることへの言及が複数箇所あります。「イノベーションの基礎的なビルディングブロックの長期的な独占(p.16)」や「囲い込み効果や互換性への正当な懸念(p.17)」といった表現です。Useの観点から議論すべきであり、その作品がそもそも著作権で保護されるかどうかについては関係がないと述べられています(p.17)。Useの適用可否の審理が地裁に差し戻されていることを考慮すると、本判決文に「社会的インパクト」の有無が大きく影響していると考えるのは妥当ではないものと考えられます。result」で始まっている点にも注目が必要です。これは「前文の結果として」ということなので、その前文である「本件ではむしろ、申立人(Google)は、他のコンピュータープログラムを書く際にプログラマを支援するために設計されたプログラミングツールのプラットフォームの一部として配布されている、記述済みのJavaメソッド群のある部分をコピーしている」ことこそが「今回のコードの特徴」であるということになります。この文も文頭が「Rather」から始まっていることから、その比較対象となる「特徴的ではない事例」が「報告されている控訴審の主題の大部分のケース」であり、それは「一般的なプログラム」だということもわかります。ここでの比較されているのは「社会的インパクトの有無」ではなくて、「プログラマ用の開発環境で使用される記述済みJavaメソッドの一部のコード」と「一般的なコンピュータープログラムにおけるコード」です。以上より、社会的インパクトの有無が今回の判決に重要性を持っていたと考えるのは妥当ではないものと考えられますがいかがでしょうか。裁判所は今回の「判決」が「一般化されない部分」を含んでいるとは考えておらず、むしろ102(a)を条文の通り適用するだけの立場であり、「宣言コードや実装コード」あるいは「市場へのインパクト」といったJava標準ライブラリ固有の争点についてこれ以上重箱の隅を突くような議論は必要ないと考えているように見受けられます。「メソッドの名前や引数名、パッケージの名前や構成が同じものを作ると著作権の侵害になりうる」まで広く汎化して認めてしまうと、「典型的な〜あまり意義のあるものではない」という結論にはならないと思うんですよね。「典型的な〜あまり意義のあるものではない」の部分は文章上は2通りの解釈が可能だと可能だと思われます。ケース自体が特殊であり一般的なケースとは相容れないことから、このケースの子細議論しても一般的なケースにとっては無関係であるケース自体は一般的な議論で決着が付くのに、このケースの子細について深い議論をしても意義がない私の認識としては、前述の理由より2がこの段落の趣旨だと考えています。ところで、若干話はそれてしまうのですが、引用頂いた判例の解釈に疑問があります。1-2-3の時の「囲い込みに対処する機能コピーは許される」という判例もあり、そうなると今回の訴訟にあたるようなソフトウェアはそれほど多くないのかな、と思いました。Borlandの判例が「囲い込みに対処する機能コピーは許される」根拠となると認める資料が見つからないのです。今回の判決文、控訴審の判決文ともにこのケースへの言及がありますが、どちらにおいても102(b)を適用した判例として取り上げられているだけで、「囲い込み」のような市場競争上の観点には触れられていません。引用部分の表現はshibukawaさんの記事から参照されている「コンピュータ関係の創作保護についての最近の米国での話題」に見つけることが出来ますが、私が調べた限りでは他の資料にはそのよう事が書かれておらず、具体的な根拠を見つけることが出来ませんでした。なにか他に資料をご存じでしたら教えて頂けますと幸いです。お返事ありが追うございます。基本的な認識は私も共通しております。ような、特定のプログラミング言語の実装から離れた、中立的なインターフェイスを記述するための言語があります。著作者の権利が及ぶかどうかは、この判決文からは判断できないかと思われるのですが、いかがでしょうか。この点は非常に重要な論点だと思います。クラウドを例とするとAWS互換のAPIを別のクラウドに実装する場合を考えます。AWSのコードは宣言部も含めて公開されていないため、コード自体のコピーはそもそもコピーのしようがありません。APIの仕様は例えばドキュメントにメソッドの名前や引数の順序が記載されており(IDLが使われることもあるかもしれません)、その情報を参照することは可能ですし、これを参考にしないと互換APIを作ることは出来ません。Useによって救済される可能性は別として)。コピーでなかったとしても著作権が及ぶという部分は、同じプログラミング言語で記述されたソースコードにおける議論かと思います。引用頂いた英語の例を考えた場合、英語の著作物を勝手に翻訳すると一般的に著作権法上の問題となることから、プログラミング言語間における「翻訳」も同様に問題となるように思われます。プログラミング言語が違ってもメソッド名や構造が同じ場合はSSOの侵害になるとという認識です。以上の点に関してはご指摘の通り判決文内では直接的に言及されていない部分ですので、具体的な事例で裁判が行われない限り明確な答えは出ないものと推測されます。私個人としては、たとえプログラミング言語が違う場合も訴訟のリスクは無視できない程度にはあるだろう、というのが現状の認識です。