(7/7追記)僕は斜め読みだったんですが、もっときちんと読んだ上で解釈を書いてくれている方がいます。僕も時間をとって全文を読みたいとは思っていますが、まだ時間がかかりますし、yudaiさんの会社の方が妥当性は高いと思いますので、そちらをご参照ください↓
朝っぱらから色々衝撃が走った第一四半期の最終日ですが、OracleとGoogleの裁判について、どのあたりが問題だったとされるのか気になるので判決文等を読んでみました。
経緯
- 2010年8月、OracleはGoogleを訴える。当初の争点は特許侵害 (publicKey1)
- 2012年4月、サンフランシスコ連邦地裁の法廷開始
- 2012年5月、Googleの特許侵害はないとの陪審評決。ただし、フェアユースは意見が別れる。
- 2012年6月: Oracle対GoogleのJava/Android訴訟、損害賠償金ゼロで合意。今回議論された37件のJava APIについては著作権の保護とならないとされた。
- 2012年10月: オラクル、「Java APIを著作権の対象と認めず」判決を不服とし上訴
- 2014年5月: 控訴裁は地裁の判決を覆し、APIが著作権の対象だとする判断を下した。これらAPIの使用がGoogleの主張する「フェアユース」にあたるかどうかについては、審理を地裁に差し戻し
- 2014年10月: グーグル、米最高裁に上訴申し立て
- 2015年6月: 米最高裁がグーグルの上告を棄却
一度はGoogleに有利な判決が出たものの、その後Oracleが上告し、Oracleの主張が認められてAPIの著作権保護が認められました。その後Googleも上告しましたが、今日ニュースになった最高裁の棄却の決定を持って決定されました。
これまでの著作権とソフトウェア
今回の資料でも過去の経緯としてこのあたりの話がちょいちょい出てきます。操作(method of operation)は著作権の保護の対象にはならない。というのがポイントでした。このリンク先の資料では、これらの判決から、ソフトウェアの保護は著作権から特許を使った保護の方向に向かっていった、としています。
また、APIそのものについては、フェアユースの観点から自由に利用可能であると考えられていました。ReactOSやWINEなどの実装が問題ないとされてきたのもこれが拠り所ですね。
2014年5月の判決
結論部分(最後)を翻訳します。
上記の理由から、私たちは問題の37のJava APIパッケージの宣言コードや構造、配列、および組織は、著作権保護を受ける権利があると結論付けています。したがって、我々は、陪審の侵害の評決を回復するための命令で地裁の著作に関する判断を撤回します。陪審員は、フェアユースに掛けているので、我々はこの決定と一致し、さらに手続きのためのGoogleのフェアユースの保護に関する抗告を差し戻します。
Googleの上訴に関して、地裁として次のような決定を行ったことを確認します：（1）Googleが8つのJavaファイルの逆コンパイルを行ってAndroidにコピーをしたことについての法律問題としての判決を求めるOracleの動きを支持します。と（2）rangeCheck関数に関して法律問題としての判決を求めるGoogleの上告を棄却します。したがって、我々は、さらなる手続のために差し戻します。
この前回の判決が世界に衝撃を与えたのは、フェアユースの観点で自由に利用できると言われていたAPIが、「著作権保護の受ける権利がある」という今までにない司法判断がくだされたことによります。
また、プラスアルファとして、逆コンパイルやrangeCheck関数(TimSort内で使われているアルゴリズムの盗用疑惑)についても、Googleにとって不利な判定がくだされています。
declaring codeとimplementing codeとSSO
本文中で、事例つきできちんと詳解されています。このうち、最初の行が"declaring code"で、残りのロジックが"implementing code"となっています。C/C++なら、前者がヘッダーファイル、後者がソースファイル(テンプレートライブラリとか例外はありますが)となるでしょう。
public static int max(int x, int y) {
if (x > y) return x;
else return y;
}
判決の中で、一部逆コンパイルやアルゴリズムの盗用疑惑はありますが、99%のコードに関しての議論は特に見つけられませんでした。クリーンルーム実装したのかどうかも特にこの資料内では触れられていません。今までは大事なものは「ロジック」とされていましたが、今回主要な争点になっているのはdeclaring code。いわゆるAPIです。7000行ものdeclaring codeのリテラルコピーがあったとされます。
また、もう一つコピーしたと言われるのが、Structure, Sequence, Organization(SSO)です。ロジックを含むコードそのものではなく、declaring codeから導きだされるソフトウェアの構造等の論理構造の真似(非リテラルコピー)が問題である、というのがOracleの主張です。
2015年6月の判決文
結論としてはシンプルです。
上告を棄却します
それまでのところを見ると、いろいろ興味深い議論がされています。
Google は declaring code は 17 U.S.C. Section 102 (b) の
“In no case does copyright protection extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery” that is “described, explained, illustrated, or embodied” in the work.
に該当するものと主張していたが、これは誤り (that argument is incorrect) で、この条文は例えば
Although a book on how to build a bicycle may be eligible for copyright protection, that copyright does not include any exclusive right to practice the bicycle-building method that the book explains; nor can the author prevent another person from writing a better book with a clearer explanation of the same process.
のように、著作権が適用される範囲を限定したもので、declaring code自体の著作権を否定する物ではない、と言われています。
また、
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.
著作権の侵害にはコードのコピーはいらない、ということを言っています。
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を作り続けることで得てきたエコシステムを横取りするようなことについてたくさん議論してきた、という意味に読めます。
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が必ず著作権保護されるわけではない」としています。つまり、今回著作権による保護が認められたのは特例？
まとめ
そういう意味ではAPIは著作権保護対象ではないという今までの前提が完全に覆されたわけではなさそうですが、「場合によっては権利が主張できる一方で相手のプラットフォームの競争力を奪う規模でのAPIの利用はフェアユースの範疇を超えている、というのが今回の趣旨のように見えます。
APIが〜APIが〜と外野で言われる訴訟ですが、曖昧なAPIという用語ではなく、declaring codeという、Javaを前提とした具体的な用語を用いているのが印象的です。Javaの標準ライブラリの「structure, sequence and organization」を強調しているのは、最後の判決の直前のところでも語られていたように、判決が一般解として業界全体に影響が波及するのを恐れていて、あくまでも「Java標準ライブラリの今回のケースだけですよ！」というのを強調しているように見えます(moriyoshi談)。
とはいえ、少なくとも、Javaの37のパッケージの7000行にのぼる宣言文の個所にはAPIの著作権が認められました。Javaという言語を土台としてJavaの思想を理解した開発者がすでにいます。アメリカの定義では著作権法はアイディアを保護するものではないとしています。アイディアとは具体的には17 U.S.C. §102 (b) の「any idea, procedure, process, system, method of operation, concept, principle, or discovery」で、今回のdeclaring codeはアイディアではなく著作なのでフェアユースではないということですね。
Java外のことについても適用できるような抽象度の高い判決ではないため、似たような事案で侵害になるかどうか今後も裁判をしてみないと分からないという曖昧で少しモヤモヤする判決でした。
Thanks
PySpaメンバー: @morisyohit, @nishio, @akisutesama, @ishimoto, @takabow