2021年4月5日に，OracleがGoogleを訴えた事件の最高裁判決が出された。本日（5月10日）に，SOFTICでこの判決を紹介するセミナーが開催され，登壇する機会を得た。
登壇者は私を含め5名（五十音順）。米国法の素人の私には場違いな感じもするが。
- 石新智規弁護士（シドリーオースティン法律事務所・外国法共同事業）
- 伊藤雅浩弁護士（シティライツ法律事務所）
- 奥邨弘司教授（慶應義塾大学）
- 椙山敬士弁護士（虎ノ門南法律事務所）
- 平野高志弁護士（ブレークモア法律事務所）
事案の概要
Googleは，スマートフォン用OSのAndroidを開発するにあたって，当時プログラマに広く知られていたJava Platformを採用しようとしたが，Sun Microsystemsとの交渉がまとまらなかった。代わりに，Java Platform SEに相当するものを自社で開発しようとし，パッケージ，クラス，メソッドの体系を同様のものとし，宣言コード（Declaration Code。クラスやメソッドの名称・パラメータの定義部分）をコピーした。ただし，その具体的な処理部分である実装コード（Implementing Code）は，公開されているわけでもないので，自社で開発した。
その後，Sun MicrosystemsはOracleに買収され，Oracleは2010年にGoogleを著作権侵害等で訴えた。
訴訟の経緯は，非常に複雑で，結論が変わりながら上にあがったり差し戻したりを繰り返したが，10年を経てようやく最高裁の判断が出た（ただし，破棄自判ではなく，CAFC（連邦巡回控訴裁判所）に差戻し。）。
最高裁では，「フェアユース」の成否が問題となったが，Googleがコピーしたのは，Java Platform SE（多数のパッケージ，クラス，メソッドから構成されるソフトウェア部品のようなもの）の宣言コードで，コピーした行数は約11500行にも及ぶが（下図は，判決別紙にコメントを追加したもの。），Googleが開発したJava Platform SE全体の割合からすると1%にも満たない。
最高裁の判断
米国法に明るくない私が説明するとボロが出そうなので，簡単に紹介すると，争点は[1]Java APIの宣言コードやその体系の著作物性と，[2]Googleによるそれらの利用がフェアユースとなるかである。最高裁は，[2]についてフェアユースが成立するとした。それにより，仮に[1]で著作物性があっても請求は成り立たないので，[1]については具体的な判断を示されなかった。
日本法のもとでは・・
気になるのは，日本で，本事件と同様に公開されているAPIをもとに同じAPIを持つソフトウェアを作ったら，（具体的な処理部分を自前で作ったとしても）著作権侵害になるかという点である。
著作物性（10条3項との関係）
我が国の著作権法には，著作物の定義はあるが（2条1項1号），特に限定はない。例示されている中にプログラム（10条1項9号，2条1項10号の2）もあるが，プログラムであれば何でもよいわけでもなく他の著作物と同様に「創作性」が求められる。さらに，10条3項では，アイデアや原理にまで権利が及ばないことを確認する趣旨で，次のような規定が置かれている。
３ 第一項第九号に掲げる著作物に対するこの法律による保護は、その著作物を作成するために用いるプログラム言語、規約及び解法に及ばない。この場合において、これらの用語の意義は、次の各号に定めるところによる。
一 プログラム言語 プログラムを表現する手段としての文字その他の記号及びその体系をいう。
二 規約 特定のプログラムにおける前号のプログラム言語の用法についての特別の約束をいう。
三 解法 プログラムにおける電子計算機に対する指令の組合せの方法をいう
GoogleがコピーしたJava APIの宣言コードはこれらに該当するのかが問題となる。
2号の「規約」の例として「インターフェース」「プロトコル」などの取り決めがあげられていたりする。一般にいうAPI（下記はあおぞら銀行の例）は，単なる取り決めや仕様（引数の数，順序，データ型，戻り値の型など）をいうのであって，抽象論としていえば，APIは「規約」であって著作物性を有しないというのが自然である。
しかし，今回Java APIと言われているものは，具体的なコードの一部を指している(Declaration Code)。この点について，中山信弘『ソフトウェアの法的保護［新版］』(1988）では，あたかも今日の争いのような事態を想定していたような記述があり，インターフェースが具体的なプログラムの形で記述されているような場合には，
「もしこのようなプログラムに著作物性が認められるとすれば，現実には著作物の類似性だけで侵害か否かが決まることになろう」
「アイディアと表現とが密接な関係にあるプログラムの規約につき，それがいかなる形態であれ保護しないことを規定したのが，著作権法10条3項2号であると解すべき」
「保護範囲もまた極めて狭く解すべきであり，事実上デッド・コピーのみが侵害となろう」
などと述べられている（45頁）。インターフェイスだというだけで一律に切り捨てられるわけではない。結局は（ハードルは低くはないが）該当のコード部分の創作性で決まるようにも思われる。
著作物性（プログラムとして見た場合）
では，APIと呼ばれているものの，実際には11500行ものコードをコピーしていたとすれば，その部分に創作性が認められるのではないか。
例えば，東京地判平23.1.28（増田足事件）では，
原告プログラムは，上記アのとおり，株価チャート分析のための多様な機能を実現するものであり，膨大な量のソースコードからなり，そこに含まれる関数も多数にのぼるものであって，原告プログラムを全体としてみれば，そこに含まれる指令の組合せには多様な可能性があり得るはずであるから，特段の事情がない限りは，原告プログラムにおける具体的記述をもって，誰が作成しても同一になるものであるとか，あるいは，ごくありふれたものであるなどとして，作成者の個性が発揮されていないものと断ずることは困難ということができる。
と述べて，100以上の関数がまったく同じであることなどを挙げて著作物性を疑っていない。これと同様に「たくさんあるから多様な可能性もある」としてプログラムの著作物性を認めた例はほかにもある（東京地判平23.5.26など）。
他方で，具体的に創作性があるとされる個所を特定させ，その部分についての創作性を判断している裁判例も多数ある。
後者の判断手法を取られると，一つ一つのAPIの宣言コードはありふれた表現になりがちであり（int max( int a, int b)のようなもの），特に，APIは，わかりやすく必要最低限の記述で書くことが重要であり，用いることができる語句・文字も，普通のプログラムと比べると極端に限られる。そうなると，たとえこれらを積み重ねたとしても全体として創作性が認められることは期待しがたいようにも思える（中には選択の幅がある特徴的なAPIがあるかもしれない。その場合には，当該APIについてのみ創作性が認められるのか，全体として認められるのかは難しいところ。）。
著作物性（編集著作物）
以上の検討からすると，Java API宣言コードについて創作性を認めるのは難しそうである。しかし，パッケージ，クラス，メソッドの体系を作って，プログラマの便宜のためにさまざまなクラス，メソッドを用意したこと自体は何らかの著作権法的な保護を受けられないか。
そこであり得るとすれば，編集著作物（12条1項）がある。
編集物（略）でその素材の選択又は配列によつて創作性を有するものは、著作物として保護する
開発者にとって「あったら便利だな」と思われる関数をあらかじめ用意してメニューとして提供しておく。その関数の選び方や体系的な整理の仕方は，決して誰がやっても同じというわけではない。そうすると，「API群」は編集著作物に該当するかもしれない。その場合，個々の素材であるAPIについての創作性は必要なく，「選択又は配列」に創作性が認められれば良いことになる。
しかし，実際のJava APIは，しらみつぶしに便利そうなものを挙げていったような印象もある。個々のメソッド自体は，他の言語でもライブラリとして提供されているようなものであり，「選択又は配列」に確実に創作性があるとはいえない。
ということで，編集著作物としての保護も，そう簡単なものとはいえない。
権利制限規定
以上のように，膨大な数があるとはいえ，Java APIの宣言コードを著作権で保護することは簡単ではなさそうだ。しかし，もし仮に，著作物性が認められた場合には，日本には米国法107条のようなフェアユース規定がないので，利用者を救済することが難しい。
平成30年著作権法改正によって追加された非享受利用は，「日本版フェアユース」とも言われている。
（著作物に表現された思想又は感情の享受を目的としない利用）
第三十条の四 著作物は、次に掲げる場合その他の当該著作物に表現された思想又は感情を自ら享受し又は他人に享受させることを目的としない場合には、その必要と認められる限度において、いずれの方法によるかを問わず、利用することができる。ただし、当該著作物の種類及び用途並びに当該利用の態様に照らし著作権者の利益を不当に害することとなる場合は、この限りでない。
一 二 （略）
三 前二号に掲げる場合のほか、著作物の表現についての人の知覚による認識を伴うことなく当該著作物を電子計算機による情報処理の過程における利用その他の利用（プログラムの著作物にあつては、当該著作物の電子計算機における実行を除く。）に供する場合
しかし，この「享受」については
プログラムの著作物は表現と機能の複合的性格を有しており，プログラムの著作物に「表現された思想又は感情」とは当該プログラムの機能を意味するものと考えられるところ，その「表現された思想又は感情」の「享受」に該当するか否かは，当該プログラムを実行等することを通じて，その機能に関する効用を得ることに向けられた行為であるかという観点から判断されるものと考えられる。
との解説があり（文化庁『デジタル化・ネットワーク化の進展に対応した柔軟な権利制限規定に関する基本的な考え方』（2019）39頁），APIの宣言コードを利用することは，まさにプログラムの実行を目的とするものであるため，非享受利用とは言い難い。
その他，引用（32条1項）の該当性も考えられるところだが，やはり同様に厳しいだろう。
さいごに
ということで，日本法のもとでは，そもそも著作物性が認められるかどうかという入口部分でのハードルが大きそうであるが，ひとたび著作物性が認められた場合には，権利制限規定によって適法化することは難しいだろうと考えられる。
また，Googleが行ったような宣言コードのコピーは，プログラムの一部（一部といっても量的にはそれなりにある）のコピーであるからプログラムの著作物としての保護を受ける余地があるが，単に同じ仕様，インターフェースのものを開発したというだけでは，一層保護は困難であろう。
本日のセミナーでは，そういったことを前提としつつ，利用規約等で「複製禁止」とした場合の効果についても議論された。
貴重な機会をいただいて感じたことは，次のツイートに尽きる。
セミナーも執筆も，情報を伝達する仕事ではあるものの，やった本人が一番勉強になる。
— Masahiro Ito/伊藤雅浩🍀 (@redipsjp) 2021年5月10日
