Javaのリスク考察 2018年版

Java

Java10以降、Java SEのリリースサイクルを6カ月単位とすることが発表されてしばらく経ち、また、予告通りJava11からいよいよJavaのサポート体制も変更となった。


本稿ではJavaを使い続けるリスク、あるいはほかの言語ランタイムを使い続けるリスクについて検討してみたい。プログラム言語は用途に応じて様々なものが使い分けられている。特に本稿では選択肢が多く、またJavaのシェアも高いサーバーサイドのWebシステムという戦場で検討してみたい。

ランタイムの有償化リスク

無償で提供されていたプログラム言語のランタイムが、突如有償化するリスクをまず考えてみよう。この点で、Javaはもっともリスクが低い部類であると言える。


JavaのランタイムはGPLライセンスで公開されており、無償でソースコードが公開されている。GPLライセンスは、ソースコードの公開が求められ、また改変を許可し、オリジナルもしくは改変版の複製と頒布が許されるが、その派生物もGPLを求める。なので、独自にJavaを改造・拡張したモノを作ることも許されているが、そうした派生物はソースコードを公開しなくてはいけない。重要なポイントはこれらの「複製と頒布」は有償でおこなっても良いという点である。


ただ、こうした派生物は通常は「Java」を名乗ることができない。これは、GPLライセンスの話ではなく、商標の話となる。特段珍しい話ではなく、改造したものが本家の名前を名乗ってかんばんを乗っ取るというのはできない、というだけの話である。ただし、JavaはOracleの定める手続きに則り互換テストをクリアしてOracleと契約すれば「Java」のかんばんを掲げることができる。


繰り返しになるがGPLのポイントとしては、バイナリ頒布にあたっては無償を強制しない。ソースは無料公開されるが、自分でビルドして実行形式を作るところができないのであれば、誰かの作ったバイナリを求めることになる。ここで有償サポート版のバイナリを購入しても良いし、誰かがビルドして無償で公開してくれるものに期待しても良い。バイナリを有償化で配ろうとも、ソースコードは無償で公開されることがライセンス上保証されている。頒布も自由だ。仮にどこかのサポートの値段がたとえ高騰することがあったとしても、常に誰かが無償ビルド版を作って公開する権利が保証されている。


また、本家がメンテナンスをしなくなったEOL(End of Life)の過去版についても、どこかの誰かがセキュリティアップデート版を作ったのであれば、GPLの波及によりソースコードを公開することになるだろう。リリースサイクルの変更に伴いサポート期間が憂慮される点はあるが、独自にサポートすることを表明している企業もある。こうした際にも、GPLというライセンスは安心感につながる。


Javaに関して言えば、Oracle以外もJavaランタイムを出している個所は有償無償ともに複数ある。Oracleはずっと昔から有償サポートを出し続けてきた。Java11でOracleは有償版だけの機能をいくつかOpenJDKに譲渡し、無償化された。
そしてOracleがいままで出してきた無償版の役割はOpenJDKに移管された。


JavaはSun Microsystemsが開発し、のちにOracleがSunを吸収合併してOracle管轄のものとなった。2010年のことである。OpenJDKの歴史はそれより前の2006年までさかのぼる。OracleがSunを吸収合併したわけだが、OracleはOpenJDKの存在も、JavaがGPLライセンスであることも、分かったうえでJavaを手にしたのだ、ということは把握しておきたい。

競合相手は？

JavaがGPLなのはわかった。ではほかの言語ランタイムはどうなのであろうか？冒頭述べた通り、Javaのシェアが高いサーバーサイドのWebシステムという戦場で検討してみよう。

環境 ライセンス 開発元
Java GPL系 Oracle他
PHP BSD系 (PHPライセンス) The PHP Group
Ruby on Rails BSD系 ※1 Rails Core Team
Python BSD系(Pythonライセンス) Python Software Foundation
C# BSD系(MITライセンス) Microsoft
Node.js BSD系(MITライセンス)※2 Node.js Developers
Swift Apache-2.0 Apple
Go BSD系 Google
scala-native ※3 BSD系
Kotlin/Native ※3 Apache-2.0

※1 RubyはBSDとRubyライセンスとのデュアル、RailsがMITライセンス。サーバーサイドということで敢えてRailsを挙げている
※2 Node.js自体はMIT、JSエンジンはGoogle V8 JavaScript Engineだと修正BSD
※3 いずれも通常のScala / KotlinはJava VM で動作させるが、あえて脱Javaを考えるケースでの比較としてscala-native / Kotlin/Nativeを記載した


個々のライセンスの詳細に踏み込むと大変なのでざっくりとした記載としている。BSDライセンスは自由な改変・再配布・無保証といったところである。GPLとは違い、派生物のライセンスへの波及はない。Apacheライセンスも似たようなものであり、改変も再配布も自由である。派生物のライセンスへの波及もない。もちろん、これらのライセンスも無償を強制しない。


ライセンスという観点で見れば、いずれの環境も、オープンな状態に置かれている。

オープンソースな言語ランタイムの有償化戦略

さて、有償化リスクを検討するために逆に「どうすれば有償化できるか？」について考えよう。GPLにせよ、BSDにせよApacheライセンスにせよ、有償で配布することそのものを否定するライセンスではない。しかし、ソースコードが公開であっても、自分で実際に動く状態のバイナリファイルをビルドするというのはなかなかやる人はいない。なので、バイナリを有償配布するという戦略は常にとることができる。全てのユーザーに金を払わせることはできなくても、一部の人はビルドの手間賃だと割り切って払ってくれるかもしれない。


しかし、いずれのライセンスも、自由な再配布を許しているので、誰かがビルドして無償配布することを防ぐことができない。こうした「有志による無償版」は一定以上の言語ユーザーがいれば必ず作られるだろうと思う。

有償サポートとセキュリティアップデート

現実的には、サポート契約が有料というのが実際に行われていることである。


本家の通常版ではすでにEOL(End of Life)となっている古い古いJava7であるとか、Java6であるとか、さらにもっと前であるとかのバージョンについて、もしセキュリティ上の問題が生じたらコードを修正したバージョンを提供しますよ、といったものである。


Javaは比較的後方互換が厚い言語であるが、完全というわけでもない。過去のある時点でつくられたシステムを新バージョンで動かして何かあったらどうする！という理由で古いバージョンのまま有償サポートを受けて使い続けているという現場は結構ある。そこに金をかけるならバージョン追従にお金を使った方がシステムが長持ちするんじゃないかという気もするが、出来上がった時点でスパゲティコードなシステムなら、敢えて長持ちさせる必要もなく、時がたったら作り直せばいいやぐらいに考えているかもしれない :-P


作り直すときに「過去の仕様を全て再現すること」とか言い出して、過去の問題ある動きを頑張って忠実に再現するような話もあったりなかったり。


話がそれた。古いバージョンのJavaに対する有償サポートは昔から行われていることである。しかし、このセキュリティアップデートのコードもGPLであるから無償で公開されているという点は重要なポイントである。BSD系やApacheライセンスでは、それこそこうしたコードを非公開で高値でふっかけることだって可能なんだから。

バージョンアップの際の締め出し

次に、よく言われる陰謀論であるところの「無償で行きわたらせ、容易に抜け出せなくしてから突如有償化して金をせしめる」について考えてみよう。


まず、オープンソースの状態で行きわたっている言語ランタイムが、ある日突然動かなくなる、ということは、まずない。そうした、時限式の締め出しをするコードが公開されているコード中に見つかったら、それは事件だし、もしそのようなものが見つかれば、その時限爆弾を排除した改変版が出回ることだろう。このとき、商標権といったかんばんの都合上、おなじ名前を名乗り続けることはできないかもしれないが。


ライセンスは契約なので権利者側の一方的な通告で過去の契約を変えることはできない。なので、すでに頒布してしまっている過去版を金を払わないなら使うな、と言うことはできない。完全に有償化するとしたら、あるバージョン以降、ライセンスを変えてオープンソースではなくしてしまうか、あるいは、ソースは公開しても二次利用した改変版を自由に作れないようなライセンスにしてしまうことだ。


GPLにせよ、BSDにせよApacheライセンスにせよ、自由な改変と再配布ができてしまうので時限爆弾を排除した改変版が出回るのだ。自由な改変と再配布ができないライセンスにしてしまえば、そうした改変版は非合法の「海賊版」となる。合法的に使いたければ必ず金を払え、とさせることができるようになる。


過去のライセンスは変えられないにしても、新バージョンからライセンスを変更することは可能である。しかし

なおライセンス条件を別のものに変更する場合には、対象となっているソフトウェアの著作権者全員が、ライセンスをその別のライセンスに変更することに同意していることが必要です。そのため、リナックスカーネルのように、無数のプログラマーがコミットしている場合には、全員の同意を取り付けるのは非常に難しいですから、ライセンスの変更は事実上不可能でしょう


多数のコミッターが参加しているようなプログラミング言語についていえば、権利的に突然の変更というのは難しいのではないだろうか（参加するにあたってこのあたりの権利を処理するためのなんらかの同意書がとられているかもしれない）。JavaはOracleが商標をもっており、開発を主導してはいるがOracleによる独裁政治でつくられているわけではない。


いささか古い記事で申し訳ないが（おそらく2011年の記事）Javaの仕様策定プロセスJCP（Java Community Process）とそのメンバーについて

つい最近も、このJCPのExecutive Committee（JCPの運営方法などを決める評議会）の委員を選出する選挙が実施されましたが、投票の結果、「SOUJava」というブラジルの Javaコミュニティが選出されました。このように、Javaは現在も、特定のベンダーが支配することのない、オープンなコミュニティで開発が進められて いるのです。

といったことが語られている。


こうした民主的なプロセスが作られているプログラミング言語の場合、独裁的で強硬なライセンス変更は難しいだろう。

ライセンス変更に対するコミュニティの対応は

この時点ですでにだいぶん「アリエナイ」話になっているが、仮に仮に仮に独裁的で強硬なライセンス変更がされたと仮定しよう。この時に、コミュニティはどうするだろうか？


言語ランタイムの開発が少数によってなされているようなケースでは、ライセンス変更後の対抗版というのはなかなか出てくるものではない。強硬なライセンス変更を行った中央に囲われていない人材で、無償版が作られるかはわからないし、すくなくとも大きな停滞期となるだろう。


もし、開発コミュニティが十分に大きく、強硬なライセンス変更を行った中央に囲われていない人材も多数いるような状況であれば、ライセンス変更がされる直前のソースコードをもとに、以降のバージョンが作られ、クローズドな有償版とオープンソースの無償版に分裂していく可能性がある。しかし、オープンソースの無償版が作られるというのは、いささか楽観的な未来予測と言える。

GPLライセンスは派生版もGPLであることを強要するが、BSDライセンスやApacheライセンスは強要しない。GPLライセンスである言語ランタイムは、こうした分裂があったとしても、派生版がGPLであることは保証している点で少しばかり安心感が増す。もっとも、「独裁的で強硬なライセンス変更」という前提となる仮定がまずもってアリエナイものであることは強調しておく。


たとえ、プログラミング言語の追加機能ようなバージョンアップがされないにしても、セキュリティアップデートがされるぐらいにメンテナンスされるのであれば現在その言語ランタイムを使っているプロジェクトが、直ちに立ち往生することはない。それでも、オープンソース版の発展がみこめないとなると、その猶予をもって別の言語ランタイムへの乗り換えが図られることだろう。発展が見込まれる程度にメンテナンスされるのであれば、利用し続けることも可能であろう。


言語のランタイムがオープンソースであれば、別の実装を作ることは容易である。たとえ、言語仕様がISOなどで規格化されたような言語であっても、オープンな実装がなければ、それを作ることは労力的に難しい。（規格化されていれば、個別に権利者と取引しなくとも言語規格をクリアしたことを名乗れるという効果はあるが、作る労力は別の話だ）もちろん、独自に実装しなおしたものであれば、互換性が保たれるかも疑問である。
ランタイムがオープンソースである、派生することができるという状態に置かれていること自体が、ある種の保証であるといえよう。

開発を主導するもの

プログラミング言語のような、相応に大規模で複雑で難易度の高いものを作るというのは、並の労力ではない。作れる人材も限られるが、そうした人材の労力をこれでもか、と投じなければ作り上げることはかなわない。そうした人材の趣味の時間に頼っていては難しく、そうした人材が言語開発に没頭できる環境、つまり、彼らが言語を開発することで暮らしていけるようなサポートがされなければ、なかなか言語の発展がすすまないだろうと言える。


そうした暮らしのサポート、いうなればマネタイズまでもが、言語開発者個々人任せというのは少ない人材をさらに少なくする。そういう意味で、言語開発に企業がスポンサードしているというのはマンパワー的にも大きい。しかしながら、企業のスポンサードというのは大抵ひも付きである。スポンサーの意向というのが関与してくるものである。そして、スポンサードしている企業が傾いたとき、言語ランタイムは危機を迎えることになる。


これは、2010年のSun Microsystems が Oracle に吸収合併されたときに懸念されたリスクである。その時代はJavaの停滞期であった。2006年12月11日にJava6がリリースされてから、2011年7月28日にJava7がリリースされるまで実に4年半もの停滞を迎えたのである。


JavaがOracleに移管されてからJavaの仕様策定プロセスであるJCPといった民主的な体制が敷かれたのもSunという中心企業が傾いた際のリスクを痛感したからであろうか。これは私の想像に過ぎないが。もし仮に、今後OracleがJavaを手放すようなことが起きるとしたら、その時はSunからOracleに移行した時よりも混乱はずっと少なくて済むのではないかと思う。


こうした主導企業の停滞のリスクは、Microsoft が擁するC#や、Appleが擁するSwiftでも考えられる。もっとも、この2社がそう簡単に傾くとは思えないが。また、企業によるスポンサードがないプログラミング言語についていえば、もっと端的に中心メンバーが引退するリスクを負っている。実際のところ、世の中の小規模オープンソースプロダクトなんてものは、中心となる一人が離れてしまえばぱったりと更新が止まったりするものである。急に盛んに更新されるようになったな、と思えば後継者となる人物が現れた、といった調子である。


個人の力によるところが大きい世界であるからこそ、そうしたリスクが目立つ。うまく組織化できているプロダクトは安心感が強く、スポンサードの含めてリスク分散されていることがより望ましいと言える。

言語ランタイムのリスク

さて、いくつか検討してきたが、

  • Openになっていない言語ランタイムは突如の有償化と締め出しのリスクがなくはない
  • 小規模な開発コミュニティ、あるいは単独スポンサードのプログラミング言語であれば同様の有償化リスクがなくはない
    • ある程度のコミュニティ規模と、民主的な意思決定プロセスがあればリスクは無視できるほど小さい
  • 仮にこれが生じた場合、開発コミュニティが大きければ分裂してオープンソースの無償版が続くだろう
    • コミュニティが小さい場合は維持できなくなる可能性がある
    • 分裂した場合、商標権の関係などで、おなじかんばんを掲げ続けることはおそらく難しい。名前は変わるだろう
  • セキュリティアップデートのような改変版について非GPLでは非公開・完全有料化のリスクが考えられる
  • 開発を主導するスポンサー企業が傾くなどすると、開発が停滞するリスクがある
    • 一社独占のような体制だとこのリスクはやや大きい。もちろん、企業の財務状況が良ければ無視できる
  • 小規模な開発コミュニティの場合、開発の中心人物に何かあると停滞が大きくなる可能性がある
    • ある程度の大きさに組織化できている開発コミュニティであれば小さな影響に抑えることができるかもしれない

現在の主要な言語ランタイムはいずれもオープンソースのライセンス体系をとっている。権利者がある日突然ライセンスを変更する！と言い出したとしても、過去のライセンス契約が無効になるわけではない。すでに自由に改変できる内容のライセンスでオープンソース化されている以上、最悪のケースでも現行バージョンからの派生物を作ることができる。


無償版ばかりが求められているわけでもなく、業務で利用されるサーバー上のJavaなどは、今も昔も有償サポートが用いられてきた。Oracleは今も昔も有償サポートを提供し続ける。Javaはサードパーティーからも提供される。これはリスクが分散されているポイントでもある。