読者です 読者をやめる 読者になる 読者になる

JJUGナイトセミナー Java API訴訟問題を考える

JJUGナイトセミナー Java API訴訟問題を考える に行ってきました。

Oracleが訴えるまでの経緯について~SunとOSSとIBMとAndroid~

鈴木雄介さん(JJUG会長)

Oracle vs Googleの前に知っておいてほしいこと

Javaのエコシステム

Javaの魅力

  • 標準仕様と各社別の実装
  • 仕様の策定はオープン
    • 仕様はJCPを通じて作成される
    • 当時はSunを中心にベンダー各社が標準の組織
    • 2011年になってJUG(経由で個人)も参加可能に

各社別の実装

  • ベンダーはJava標準APIを実装した製品を販売する
  • 標準だからロックインが回避できる
    ベンダー独自実装への極端な拒否感があった時代

JCPの目的

  • 標準化の共有と追加実装の許容
  • ただし、標準認定にはSunによるテストが必要
  • パスするとJavaのロゴマークを使える(お金は払う必要がある)
  • とてもよくできたエコシステム

  • 一方Javaは肥大化するばかり

    • 当時は全てを実装しないといけなかった

OSSのエコシステム

  • Apache Software Foundation
    • 1999年設立 オープンソースを支援する任意団体
    • OSSをホストするためのプロセスがある
    • 基本的にApashce Software Licence(AL) 2.0
      • 商用製品やクローズドにも利用可能
      • 公開しなくてもいい

IBMとASF

  • WebSphereはASFの成果物を利用
    • ServletコンテナはTomcatベース
    • HTTPはApacheベース
  • オープンソースを戦略的に活用
    • Linux成功体験がベース
    • Eclipseを2001/11にOSS化
  • OSSを通じた実質的な標準化

  • 2004年 TomcatがRI(参照実装)に

  • コミュニティからのイノベーション

    • 2005年 IoC(後のDI)、Spring
    • 2006年 JBoss旋風
    • JavaSEがついていけてなかった
  • JavaSEでもTomcatのようなことができないか

JavaとOSS

  • 2005/5 ProjectHarmonyが提案
  • Apache Licencse2.0 て提供されるJ2SE 5 の実装を提供すること
  • モジューラーランタイム、つまりJavaVMやクラスライブラリの実装を自由に組み合わせられる仕組みにすること
  • 参加者多数 BEA、IBM、Intel 等
  • 2006/10 ApacheHarmony誕生

  • 2006/11 Sunが対抗してJ2SEをOSS化

    • のちのOpenJDK
    • ただしGPLv2(コード公開義務あり)
      ベンターは不満
  • 2006年 Apache Harmonyが認定を要求

    • Javaが規定するJavaseの利用目的に組み込み系への利用制限があったため適用せず
    • 2007年 公開書簡
      • Harmony 制限外せ
      • Sun やだ
  • 2007/8 SunがTCK(認定のテストキット)を公開

    • ただしGPLv2なら
    • どう見てもOpenJDK専用
    • Apacheが抗議活動をし、JCPでのJSR承認に全て反対する

AndroidとJava

2005年頃からGoogleのAndroid戦略

  • オープンソースによる共有資産を作ることでキャリアも端末メーカーも大きなメリット
  • MSを倒す
  • キャリアや端末メーカーに互換性を提供する
  • Androidコミュニティを構築する

  • この時点ではMozzilaライセンスを検討

  • Andy Rubin氏によるSunへの批判

    • Androidはプラットフォームであり、各社が自由に差別化できるべき
    • SunはOSSにしたとしても、独自実装を含むならSUNから認定を受けるためにロイヤリティを払う必要がある
  • Googleも当初は認定をとるつもり

Android

  • しかたなく独自JVMのDalvkを作る

  • ソフトウェアの呪縛から逃れたかったハードやキャリアが支持

  • Googleはソフトウェアの対価は不要。ユーザーベースが欲しい

  • 結果として分断が生まれた

    • Googleの責任もあり、メーカーのセンスのなさもある

その後

  • SunのOSS戦略は成功せず
  • 2009/4/20 Oracle買収発表

  • 2010/8 OracleがGoogleを提訴

  • 2010/10 IBMがOpenJDKに ー Harmonyは2011/11に活動停止

まとめ

  • Javahaベンダーによる標準システムのエコシステムをつくったのはよかった
  • しかし、OSSの実装の共有と独自実装の流れになった

個人的見解

  • GoogleがJavaを分断したは正しい
  • SunがOSSを利用したビジネスをできなかったことも問題

    • OSSを戦略的に利用できなかった
    • JavaをOSS化しなければもっと分断したと思われる
  • なぜ訴えたか

    • JavaMEで得ていたライセンスがなくなったのはAndroidのせい?
  • IBMすごい
    • Harmonyを始めたのも終わらせたのもIBMなのに訴訟の話には出てこない
    • うまく暗躍してる感じ

Oracle vs Google訴訟の全貌と概要 ~APIは著作権で保護されるべきか~

栗原潔さん(弁理士)

訴訟の概要と争点

論点は3つ
最初の二つは解決済み

  • 特許権侵害

    • OracleがSun買収に伴い獲得した特許権
    • Oracle敗訴
  • Javaライブラリ実装コード本体の無断複製

    • 対象はわずか rangeCheck() の9行のみ
    • 違反だが違反金は(たしか)$0
  • JavaAPIの著作権侵害

    • APIは書作権で保護されるか
    • API利用はフェアユースになるか
    • 2016/6 保護されるがフェアユースにあたるとの評決
    • Oracleは控訴の方針

法律議論の注意点

  • 解釈論
    現在の法律をどう解釈すべきか
  • 立法論
    そもそも法律はどうあるべきか

著作権制度の大原則

  • 申請しなくても創作したら自動的に生じる
  • 著作権法は表現を保護するものであって、アイデアを保護するものではない(二分論)
    • 表現とアイデアが常に明確に分離可能とは限らない
    • 特にプログラムについてはそう言える

そもそも論

  • なぜプログラムは著作権法で保護されるのか ー 本来音楽、美術、文学等に関連した法律で、技術産業とは縁が薄かった
  • 1980年代にプログラム保護が急務だったため、政策的に「文芸の著作物」として保護することが決められた
    • 日本は特別法による保護を主張していたが、米国の圧力で断念
    • ベルヌ条約で国際的調和を早期に実現する以上やむをえない決断だったと言える

米国フェアユース制度とは

著作権の例外規定

  • 日本
    • 法律に明記された制限規定に従う
  • 米国
    • 公正な利用であれば著作権が制限される(フェアユース)

社会にメリットがあると判断されればフェアユースとなる

  • 仕様の目的および性質(非営利だとフェアユースになりやすい)
  • 著作権のある著作物の性質
  • 全部コピーか一部か
  • 潜在的市場または価値に対する仕様の影響
    • 実際はこの要素が重要視されることが多い
    • コピーされたことで元の商品が本当に売れなくなったか等

例:家庭でテレビを録画しても侵害にならない理由

  • 日本
    • 私的利用目的のため
    • 判断基準は法律にどう書いてあるか
      • 予測可能性が高い
  • 米国
    • タイムシフト録画はフェアユースであると最高裁判決が出されたから
    • 後に法制化
    • 判断基準は実態として損害があったか等
      • 社会・技術の変化に迅速に対応

フェアユースに関するOracleとGoogleの言い分

Oracle

  • GoogleはAndroidから420億ドルの広告料を受けている
  • フェアユースは報道、教育、研究などに適用されるもの
  • Googleはスマホ市場の遅れを取り戻すために流用した

Google

  • APIの再利用はイノベーションの源泉
  • Javaは最初からフリーでオープンなものとして構築された。これにより産業と社会は大きな御社を受けた(証言:ジョナサン・シュバルツ)
  • Oracleはスマホ市場で競合しておらず、ライセンス収益を求めているだけ

一旦フェアユースとなったが、Googleが正しいとは必ずしも言い難く、ひっくり返る可能性はあると思う。

個人的見解

  • 実装コードの大量デッドコピーに限定されるべき
  • そもそもソフトウェアのSSOは著作権で保護されるべきではない
    • 車のエンジンで他社のを見て真似るようなことは普通にされていることで、プログラムだけ許されないのはおかしい。特許は別。
  • 互換プラットフォームのためのAPIは制限されるべきではない(ただし、こんかいは完全な互換PFとは言い難い)
  • 仮にGoogleが敗訴してもAndroidが販売禁止になることはなく、お金で解決されるだろう