Oracle が Android プラットフォームのコードに関して Google を初めて提訴してから 10 年、2 つのテクノロジー大手は、ついに最高裁で対決することになりました。 それ以来、3回の裁判と2回の控訴がありました。 何十億ドルという金額がかかっており、ベテランの訴訟代理人、専門家証人、そして非技術系の陪審員にプログラミングを説明するための奇妙な裁判資料のパレードに何百万ドルも費やされてきたと思われます。 このすべては、水曜日の朝、パンデミックの真っ只中にあるテレカンファレンスでの最高裁の口頭弁論で、拍子抜けするほど終わりに近づいているかもしれません。
最初に Android を開発したとき、Google はモバイル プラットフォームを Java と互換性を持たせることに決めました。 当時、iOS 環境向けのアプリは Objective-C で書かれていました。これは、どこにでもある C 言語に似ていますが、それ以外はほとんど iOS アプリ開発の文脈でしか使用されていない言語でした。
Google は、堅牢な開発者コミュニティを持つ人気のプログラミング言語である Java と相互運用できるようにすることで、Android の競争力を高めることを目標としていました。
Googleは、堅牢な開発者コミュニティを持つ人気のプログラミング言語であるJavaと相互運用できるようにすることで、Androidの競争力を高めることを目指していました。 オラクル社とグーグル社にとって、この訴訟は、Java Standard Editionを所有するオラクル社が、数十億ドル規模のAndroidの一部を手に入れる権利を有するか否かに関わるものである。
控えめに言っても、この訴訟が最初に提起されたときは、別の世界でした。 この訴訟は、Larry Ellison 氏がまだ Oracle の指揮官であり、Eric Schmidt 氏が Google の CEO であったときに始まりました。 グーグルは現在、アルファベットの子会社になっている。 Androidはバージョン11になりました。
しかし、シリコンバレーから遠く離れた場所で、単なる 60 億ドルや著作権法の未来よりもはるかに多くのものを包含する大変化が起こっています。 Google が前回、高裁に訴訟の見直しを求めて以来、3 つの最高裁の席が空席になっています。 2014年、SCOTUSは審理を拒否し、この事件をサンフランシスコの地方裁判所に差し戻し、再審に回した。
ギンズバーグの遺産で最も重要でない部分は、彼女が著作権法のケースで最も信頼できる票であり、権利所有者に有利な票を投じる傾向があったということです。 彼女の喪失は、Google v. Oracle が 8 人の判事によって審理されることを意味し、したがって、法廷が分裂する可能性があります。 (
Google v. Oracle が 2010 年に始まったとき、7 つの特許と著作権の主張がありましたが、2012 年までに、この訴訟はわずか 37 の Java API に絞られ、約 11,500 行のコードで構成されるようになりました。 (この11,500行のコードは、リバースエンジニアリングの対象となる既存のコードから切り離された「クリーンルーム」と呼ばれるプロジェクトで書かれたものである。 このようなエンジニアリングの偉業は、Google社とJavaプラットフォームを所有するSun Microsystems社との交渉が決裂したときに必要になった。
ここでいうアプリケーション プログラミング インターフェース (API) とは、ソフトウェア プログラミングにおける明確に定義されたインタラクションの集合体のことです。
ここでいうアプリケーション プログラミング インターフェース (API) とは、ソフトウェア プログラミングにおける明確な相互作用の集まりのことで、サービスやライブラリ、その他の機能にすばやくアクセスするための略記法です。
API は正確には辞書ではありませんが、Oracle v. Google が大きな問題を提起するほど、辞書に近いものです。 技術的には、問題となっている 37 の Java API パッケージを使用しなくても、Java でプログラムすることは可能です。 なぜなら、これらのAPIにはjava.langとjava.utilという、計算や日付と時刻を表すような機能を提供する基本パッケージが含まれているからです。
明確にしておきたいのは、37 の Java API はクリーン ルームで再実装されたということです。 Oracle は、それらが一字一句同じであると主張しているのではなく、API の「構造、順序、および構成」が著作権法に違反するほど類似していると主張しているのです。 これは、これらのAPIのパッケージ、クラス、メソッドの名前が同じであることを意味する。
最初の訴訟では、2012 年に、特許請求に関する裁判と著作権請求に関する裁判の 2 つの裁判が行われました。 特許裁判では、陪審員は、Google はいかなる特許も侵害していないと裁定しました。 著作権裁判では、APIの宣言コードと「構造、順序、組織」が著作権で保護されるかどうか、そしてGoogleの使用がフェアユースかどうかという2つの法的ポイントが争点となった。
陪審員は、フェアユースについては評決を下しました。 しかし、裁判官は、偶然にも趣味でコードを書いていたのですが、API の宣言コードと SSO は結局のところ著作権の対象外であるという判決を下しました。 著作権法は、いかなる「アイデア、手順、プロセス、システム、操作方法」にも適用されず、パッケージ、クラス、およびメソッドの名前とソートの方法は、著作権に値すると判断するにはあまりにも機能的でした。
この特定の裁定こそ、2014 年に連邦巡回控訴裁によって覆されたものでした。 最初の陪審員がフェアユースについて吊るし上げたため、2016 年にフェアユースに関するさらに別の裁判のために、まったく新しい陪審員が招集されなければなりませんでした。
しかし、2018年、連邦巡回控訴裁判所（2014年にこの裁判を陪審に戻したのと同じ控訴裁判所）は、裁判で示された証拠が明らかにフェアユースの判断ができないことを示しており、したがってそもそも陪審にかけるべきでなかったとして、陪審の評決をオラクルに有利に設定しなければならないとの判決を下したのです。
陪審員の評決を無効にすることは、最高裁にとって議論を呼ぶに違いない方法で Big Judge Energy であり、水曜日の口頭弁論では、著作権訴訟における裁判官と陪審員の役割についてかなりの議論が交わされることになりそうです。 誰がいつフェアユースを決定するのかという問題は、多くの異なる法的ケースに外挿できるものであり (SCOTUS は大好きです)、また数学 (SCOTUS は大好きではありません) とは関係ありません。
残念ながら、この訴訟の本当の中心は、すべての数学などのパートにあるのです。 Google 対 Oracle の最高裁の判決は、ソフトウェア業界に大きな影響を与えるかもしれません。最も重要なのは、最高裁が著作権性の問題、つまり、Java API の宣言コードと構造、順序、組織がまったく著作権法の対象となるかどうかという問題を再検討するかもしれないからです。
この Google と Oracle の 10 年に及ぶ遺恨試合は、まったく合理的ではないでしょう。 Google による Java API の再実装は、これまでほとんど当然のこととされてきた、長い繰り返しの伝統の一部です。 Oracle 自身の MySQL のような製品は、IBM の SQL の反復として作成されました。
これは、コピーペーストがシリコンバレーの中心であると言っているのではありません。 しかし、違いのための違いではなく、同じに見えることを奨励したい点があります。 大雑把に言うと、コーディングとは機械と会話することです。 しかし、今日、ソフトウェアを開発する人の中で、実際に機械と直接会話している人はほとんどいません。 ソフトウェアは、幾重にも繰り返されるレイヤーの中に存在し、最終的にはコンピュータのむき出しの金属に到達する囁きのゲームなのです。 新しい言語は古いものから派生し、新しいライブラリは既存のものの上に構築され、依存関係は今にも終わりそうなジェンガのゲームのように互いに積み重ねられています。 そして、Google 対 Oracle は、進行中のジェンガ ゲームの最下層で起こっているケースです。
私たちは、最高裁がそれを知っているかどうかを確認しようとしています。
訂正。 記事の以前のバージョンでは、Android のコードベースが数十億行のコードであると誤って記述していました。 これは数百万行です。
このような誤りを犯しましたことをお詫びいたします。