ストールマン著 Javascriptの落とし穴

The Javascript Trap

Javascriptの落とし穴

フリーソフトウェア業界では、非フリー（訳注：この文章中のフリーは無料という意味ではない。ソースコードを自由に閲覧、改変、再配布できる権利とでもいうべきものである）なプログラムというのは、ユーザーをないがしろにしているという見解がある。中でも、商業ソフトウェアの使用を完全に拒否して、非フリーなプログラムに対抗している人もいる。この問題は、ブラウザのプラグインにも言えることだ。というのも、フリーなプラグインと、そうでないものがあるからだ。

ところが、ブラウザは、非フリーなプログラムを、ユーザーの了解を得ないままに実行しているのだ。多くの言語が使われているが、最も多く使われているのは、Javascriptだ。

Javascript（公式には、ECMAscriptと言うが、この名前はあまり使われていない）は、かつてはウェブページのおまけ程度にしか使われていなかった。たとえば、気の利いた、決して必須ではない、ナビゲーションや表示といった機能の実現のためだ。従来、これは、本物のソフトウェアというよりは、HTMLマークアップの拡張であるととらえられ、それほど真剣に考慮されてはこなかった。

多くのサイトは、いまだにこのような形でJavascriptを使っているが、Javascriptを本物のプログラムとして扱っているサイトもある。例えば、Google Docsは、500KB程のJavascriptのプログラムを使っている。しかし、そのソースコードは、Obfuscriptと呼ばれ、容量を節約する目的で圧縮されている。コメントなし、空白ほぼなし、メソッド名は一文字、といった具合だ。プログラムのソースコードというものは、簡単に改変できるべきなのだ。圧縮されたソースコードは、ソースコードと呼ぶべきものではない。つまり、本物のソースコードは、ユーザーには提供されていないのだ。

基本的にブラウザというものは、いつJavascriptがロードされたのか、ユーザーには知らせない。多くのブラウザで、Javascriptを無効にすることはできる。しかし、読み込んだJavascriptプログラムが、意匠を認められ得るもので、かつ非フリーであるかどうかを検証できるブラウザは存在しない。この問題に対処しようとしても、検証、拒否、にかかる手間は膨大だ。そもそも、フリーソフトウエア業界の中でも、ほぼすべてのユーザーは、この問題に気づいていない。ブラウザが何も言わないので、ユーザーは盲目になっているのだ。

Javascriptプログラムをフリーソフトウエアとしてリリースすることは可能である。つまり、ソースコードをフリーソフトウェアのライセンスで提供するのだ。しかしたとえ、プログラムのソースが提供されていたとしても、オリジナルの代わりに、独自の改変したコードを実行するのは難しい。現在のフリーなブラウザは、ネット上のページにおいて、ユーザー独自の改変版を代わりに実行する方法を提供していないからだ。これはTivoization（訳注：かつてTiVo社がGPLライセンスに関連して引き起こした問題、TiVo化 - Wikipediaを参照のこと）の問題によく似ている。ただ、Tivoizationよりは、解決が容易ではあるが。

Webサイトがユーザーに送りつけるプログラムの言語は、Javascriptだけではない。FlashはJavascriptの拡張版とも言うべき機能を提供している。Flashの問題を解決するには、さらなる考察が必要である。Silverlightも、Flashに似た問題がある。むしろもっとひどい。なにしろ、Microsoftは、Silverlightを使って、非フリーなコーデックを広めようとしているのだ。Silverlightに対抗できるフリーな実装は、フリーなコーデックなしでは使い物にならないだろう（訳注：このコーデックは、動画のデコーダーの意。そして、この場合のフリーとは、ソースコードはさることながら、規格がオープンかつフリーであることを意味するのだろう。しかし、FlashもVP6という、無料では使えるものの、非フリーな、ソースコードどころか規格すら提供されてないデコーダーを提供しているが、いいのだろうか。現在のffmpegが実装しているエンコーダー、デコーダーは、リバースエンジニアリングの結果の産物である。また、Flashはすでにそうであるし、Silverlightも近い将来、H.264をサポートする方向に動いている。H.264は今後しばらく動画圧縮形式の主流になると思われるが、H.264も特許の問題から、規格がフリーとはいいがたい。とすれば、MSにしろAdobeにしろ、フリーソフトウェア業界にとっての、「問題のひどさ」は変わらないと思われるのだが）

Javaアプレットもブラウザ上で動くので、似たような問題がある。一概にいって、アプレットという仕組み自体に、問題がある。勝手に実行させる環境は、問題が多すぎる。

Webサイトは、フリー（オープンと呼ぶ人もいるが）な規格とプロトコルのみを使うべきであるという、強い時代の流れがある。つまり、その規格が公開されていて、誰でもフリーに実装できるべきという意味である。しかし、Webサイト上にプログラムが存在するという事態がでてきては、もはやこの定義だけでは不十分である。Javascriptというものは、規格はフリーで、WebサイトでJavascriptを使うこと自体は悪くない。しかしながら、上記で述べたように、常に問題がないというわけでもない。Webサイトがユーザーにプログラムを送信する場合は、わかりやすく記述されていて、難読化されていないというだけでは、プログラムはフリーであるというには、不十分である。「フリーなプログラムしかユーザーに送信しない」と、Webサイト側で示されていなければならない。

暗黙のうちに読み込んで実行される、非フリーなプログラムとは、「Webアプリケーション」なるものが生み出したいくつかの問題のうちのひとつである。「Webアプリケーション」という用語は、ユーザー側に送られるソフトウェアと、サーバー側で実行中のソフトウェアという、従来の基本的な仕組みを覆すという意味で作られた。この用語は、ブラウザ上で実行されるクライアント側のプログラム、サーバー上で実行されるソフトウェア、サーバーとやりとりするクライアント上のソフトウェア、などを意味する。たとえ、クライアントとサーバーが強調して動作するために、ほとんどひとつのプログラムとみなしても良いような場合でさえ、依然、クライアントとサーバーでは、問題が異なる。この文書では、クライアント側のソフトウェアの問題を考察する。サーバー側の問題は、また別の文書で考察することにする。

現実的に、どうやってWebサイトで使われている、非フリーなJavascriptのプログラムの問題に対処すればいいのか？　以下が提案である。

まず、意匠が認められ得る、Javascriptのプログラムに関する、表示（訳注：この語はcriterion、著作権表示、ライセンス表示などの、フリーかどうかの判断基準としての表示）が必要である。意匠の問題であるので、完璧なひとつの正しい答えよりは、簡単な表示（訳注：criterion）が欲しい。

提案としては、意匠が認められ得るJavascriptというのは、複数のメソッドが定義されていて、外部スクリプトを読み込む、あるいはそれ自体が外部スクリプトとして読み込まれている、AJAXリクエストを使う、である。

この文書の最後で、意匠が認められ得る、Webページ上のJavascriptプログラムの中で、ソースコードが置かれているURLと、そのライセンス表示を、書式化されたコメントで行う方法を提案している。（訳注：その部分、省略、原文を参照のこと）

最後に、フリーなブラウザは、Javascriptをユーザーの自由にできるようにする必要がある。何よりも、ブラウザは、意匠が認められ、かつ非フリーなJavascriptプログラムを実行する前に、ユーザーに知らせるべきである。NoScriptがこれをやってくれるかもしれない。

ブラウザのユーザーには、あるページに対して、独自のJavascriptを指定できる、簡単な手段が必要だ（指定するコードは、完全にページのコードを置き換えるものか、あるいはそのページのフリーなJavascriptプログラムを改変したものである）　Greasefireは、もっともこれに近いことができるが、完璧ではない。なぜならば、ページ上のJavascriptのコードが実行される前に、絶対に書き換えてくれるという保証がない。ローカルプロキシを使えば可能だが、とても不便なので、現実的な解決策ではない。信頼でき、かつ簡単な解決方法を実装しなければならないとともに、Webサイト側も、変えていく必要がある。GNU プロジェクトは、フリーに改変できるWebサイトを推奨するものである。

これらの機能によって、Webページ上のJavascriptプログラムを、現実的な方法でフリーにできる。Javascriptは、我々の自由にとって、もはや障害ではなくなるのだ。まさに、CやJavaがそうであるように。非フリーなコードは拒否でき、さらにはフリーなコードに置き換えることもできる。まさに、非フリーなパッケージを置き換えられるように。Webサイトを自由にする、我々の運動は、今まさに始まろうとしているのだ。

いや、そんなこと言われましてもね、ストールマン導師。それは、規格上ソースが読める形で提供してあるだけで、著作権者はGPLのようなオープンソースライセンスでの配布を意図しているわけでもないし、ましてやフリーに改変していいことを意図しているわけでもないと思うんですけどね。そりゃ、オープンソースにしたい人はすればいいけれど、JavaScriptのコードの著作権は、やはり認められるわけで、著作権者がオープンソースを望んでいなければ、強いるべくもないと思うんですよ。

と思って読んでみたが、どうも上の批判は、少し的外れらしい。この導師は大真面目だからだ。というのも、向こうの立場に立って考えれば、フリーではないソフトウェアの実行を拒否したいという原理主義者の言で、GPLにあらずんばコードにあらず、非フリーなコードは一行たりとも動かさない、という思想を実現するための提案なのだから、その立場にたってみれば、当然といえば当然だ。しかし、もしストールマン導師が、非フリーなプログラムを完全に拒絶しているとすれば、いったいどんなサイトを見ているのであろうか。「このサイトの一切のHTML、Javascriptなどのソースコードは、これをGPLライセンスの元に提供す」などと公言しているサイトは、数えるほどしかないだろうし、わざわざ公言するサイトが増えるとも思われない。

実際、Javascriptは、単なるHTML拡張のためのおもちゃではなく、もう言語として万人の認めるレベルになっている。そして、Javascriptは、その仕組み上、ソースコードが明らかにされた状態で提供されるので、ライセンスを明確にしておくのは、合衆国アメリカでは、まあ、間違ってはいないと思う。ただ、日本の法律では、暗黙のうちに著作権が認められるので、何も明示しないと言うことは、たいていの場合、俺が著作権を持っているから勝手に使うな、というような意味であるが。

参考のため、訳して引用してみることにした。ライセンスは、Creative Commons Attribution-No Derivative Works 3.0 United States Licenseだが、正当な引用目的であるので、翻訳しても問題ないだろう。ただ、100%ストールマンの意図通りに訳せたかというと怪しいものだ。この文章の根底には、フリーなソフトウェアしか認めない、非フリーなソフトウェアは、俺の環境では絶対に実行したくない、という思想がある。他人の著作物に対しても、フリーにしろと強要するのは無理だから、せめて、俺の環境では、フリーなソフトウェアだけ走らせたいという思想だ。（なんだかさっきから何度も同じ事を書いているような気がする）

翻訳にかなり時間がかかった上、やはり原文を読んだ方がわかりやすいということには変わりはない。やれやれだ。見ての通り、結構、現実的だ。俺は非フリーなコードを認めない。だから、少なくとも俺の環境では、非フリーなコードを走らせたくない。だから、そのコードがフリーである場合は、一定の書式に従ってライセンス表示をしよう、という提案である。Javascriptの圧縮は、実際必要なのだから、本物のソースコードは、別の場所でもいいから、提供すると。GPLの思想によく似ている。唯一のツッコミどころといえば、SilverlightでMSをより悪いと叩いているところぐらいなものか。H.264も同じじゃないか。

しかし、このフリーなWebページという試みは成功するのだろうか。フリーなOSはある。フリーなコンパイラはある。フリーなソフトウェアもたくさんある。したがって、フリーではないソフトウェアを拒否すると言うことは、現実に可能だ。しかし、もはやほとんどのサイトが、意匠権を主張できるほどに、Javascriptを使っているだろうし、多くは、フリーにしたがらないだろう。フリーなWebページ以外否するということは、現実的に可能だろうか。誰かが、すべてのWebページのフリーなJavascriptの実装を書いてくれるという期待は無謀だと思うのだが。

追記：タイトル変更、翻訳した引用文を上に移動。

追記２：
常日頃思っているのだけれど、もし、全世界の個人で手軽に扱えるネットワークの帯域が、少なくとも現在のHDDの読み書き速度並になり、そのレイテンシも、十分短くなれば（光の速度は超えられないが）、サーバーとクライアントの垣根は、ほとんどなくなってしまうのではないだろうか。そういう新時代においては、GPLコードを利用したサービスをサーバー上で提供して、ユーザーで実行するクライアントのプログラムは、単にデータをサーバーに送り、結果を受け取るだけの、単純なプログラムになる。このようにすれば、たとえGPLコードを利用しているといえども、ソースコードをフリー化を回避できるのではないだろうか。なぜならば、GPLのコードはサーバー側で動いているに過ぎないのだから。ストールマン導師は、あれでいて、自分の思想の枠内では現実的だから、現代の常識でGPLライセンスのデザインをするにきまっているが、もし将来、現在の常識が通用しなくなった場合、どうなるのだろう。