B-CAS問題に関連して「電磁的記録不正作出」という用語が出てきてからしばしば話題に上がってはいることなのですが、
B-CASの改造や、それの使用が電磁的記録不正作出にあたるのかどうかがいまだにどうも個人的にはしっくりこないというか、「そういう解釈は可能なの？」という感じがする。

私が気になっているのは、「電磁的記録不正作出及び供用」について「人の事務処理を誤らせる目的で」と規定されている部分でして。(→http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/basic/legal/02.html の最初の方にある「電磁的記録不正作出及び供用」を参照)
元々この法律は、偽造キャッシュカードとか、偽造テレフォンカードとか、「他者(の機械)に対して使う」ようなものを想定して作られて法律だったから、そういう状況なら「人の事務処理を誤らせる目的」にあたる。というのは分かりやすい。
ただ、B-CAS改造・使用の場合、それを自分(の持っている機械、テレビとか)に対して使うことになるわけで、はたしてそれは「人の事務処理を誤らせる目的」にあたると言えるのか言えないのか・・・。

私の知る限りでは、B-CASの改造・使用は以下のような状態になると思うのだけど:
・自分の持っているB-CASカードを、自分の持っているパソコンで、自分の持っているカードリーダーを使って、自分で改造したものを、自分の持っている機器(テレビとか)に対して、自分で使う。
・・・なんか上記のように書いてしまうと「人の事務処理を誤らせる目的」にあたるというのは難しいのではなかろうかという気がする。

個人的には、以下のように解釈すれば「人の事務処理を誤らせる目的」にあたるといえるかもしれないと思うのだが。
・B-CASカードは、名目上は「利用者にレンタルしているだけ」であるので、所有者はB-CAS社である。B-CAS社の所有している機械(カード)を改造するので「人の事務処理を誤らせる目的」ことになる。
  → ただこの解釈だと、他者の所有する機械(カード)に改造ツールを使って不正なデータを送り、機械(カード)に記録された内容を改ざんするわけだから、「電磁的記録不正作出及び供用」ではなく、他者の機械を不正に使ったということでむしろ「不正アクセス禁止法違反」辺りになるのではないかと思う。
・「人の事務処理を誤らせる目的」というのは、非常に広い意味で解釈される。「人の事務処理を誤らせる目的」という規定は、実際にはほぼ無視して良い。
  → なんかすごく適当で「なんでもありかよ」と思われてしまうような解釈だけど、私の調べた限りではこの解釈をするしかないんじゃないかと感じた。「なにか電磁的記録を作って(使って)、それで誰かが困ったら、適用可能(その辺りの境界線は裁判で決まる)」という感じ。

(これ以外にも、私が思いつかないだけで他の解釈もあると思うし、あくまで個人的な意見ですので、他の方の意見は "人の事務処理を誤らせる目的 b-cas 解釈" などで検索すると良いです。)

本当は何度も裁判が行われて、判例が積み重なってくれるのが一番良いんだけどなぁ・・・。
でも、判例が無く「違法という解釈もありうるし、合法という解釈もありうる」という状況で裁判をやって、万が一「合法」という判決が出てしまうというのは警察やB-CAS社にとっては最悪だろうし、
他の著作権問題のように、ひとりひとりの罪はさほど重くはないけど、多くの人がそれをやってしまうのが困る。という状況では、基本的には特定の個人をどうのこうのするより「逮捕」とか「法的措置」などによる見せしめ効果の方が有効だろうし、
そうすると下手に裁判にするよりも、白黒つけずに(裁判はやらずに)、不起訴にするとか、和解するとかにしておくというのが一番安全なのかもしれない。

個人的には司法がどう判断するのか興味があるので、できれば裁判をやってほしいという気もするのだけれど・・・。
なんかいつも尻切れトンボで、なんというか、残念というか、つまらないというか・・・。

# ところで全然関係ない話だけど、「名目上はレンタルだから、不正に使ったら違法」という理論は、他の問題にも応用できるのではないかと思う。
# 例えばプリンターの互換インク問題とかで、販売したプリンターを名目上は「消費者にレンタルしてるだけ」ということにしておいて、そこに非正規インクを使ったら違法。みたいな感じ。
# プリンター製造業者としては、高価な純正インクの代わりに互換インクを買われるのはたぶん好ましく思ってないだろうから、互換インク製造業者や販売業者と戦う代わりに、「互換インクの使用は違法ですよ。使ったら逮捕されますよ」みたいなのを消費者に対して言って回ったら、結構それをみんな信じて互換インクを買わなくなったりして、意外と効果があるんじゃないだろうか。
# なんとなくだけど、「合法だ」という主張をそのまま信じちゃう人は少ないけど、「違法だ」という主張はそのまま信じちゃう人が多いような気がする。特に、「使った側が(消費者側が)逮捕される」と言えばかなり大きなインパクトがありそう。

GOG.comは、昔は「正式名称がGood Old Gamesで、略称がGOG」だったのですが、
2012年に、古いゲームだけじゃなくて新しいゲームも扱うようにするよ。ってことで、GOG.comを正式名称にしました。(その時のニュース、WikipediaのGOG.comの記事内の"History")

今回のストーリーとは関係ないですが、動画の取り扱いを始めるのと同時に、地域別価格の導入も発表されてます。(公式発表、日本語でのニュース)
実は、今年の二月にも「GOG.comとの契約(DRMフリーでの販売)を渋っているパブリッシャーやデベロッパーも、地域別価格を導入することで契約しやすくなる」というような理由で地域別価格の導入が発表されたのですが、
反対コメントが相次いだことを受けて二週間ほどで撤回した。という経緯があります。

撤回を発表した際、GOG.comは「DRMフリーが最も重要で、Fair Priceはあまり重要ではなく犠牲にすることもやむを得ないと考えていたが、誤りだった」と述べています。また、地域別価格導入に対してはフォーラムに1万件以上のコメントがありました。
数日前のSteamが日本円表記に対応、メーカーによっては北米との価格差も | スラッシュドット・ジャパンにしてもそうですが、やはりおま値に対しての反発はかなりあるなぁと思ったもんです。

今回は、一度撤回した地域価格の導入を再度進めるということですが、
GOG.comの発表によれば前回とは異なり、アメリカドルと自国通貨の両方の通貨(値段)が画面に表示され、ユーザーがどちらの通貨(値段)で買うかを選べるそうです。(日本円は対象外で実際どんな感じなのかはわからないので、間違ってるかも)
自国通貨(地域別価格)の方が高ければ、アメリカドルで買うことができるということで、少しフォーラムを読んだ限りでは今回はだいぶ好意的に受け取られているみたいです。

ただ、一部のゲームはどちらの通貨で買うか選べない(パブリッシャーの意向？)ようになっており、その場合、もしアメリカドルでの値段より自国通貨での値段の方が高ければ、差額をGOG.comが負担してくれる。ということになりました。
「GOG.comが負担」といっても、ユーザーが支払う値段が安くなるわけではなく、アメリカドルでの値段より高く払った分がStore Credit(ギフトコード的なものらしい)として戻ってくるそうです。

以前、jpegtranとかjpegoptimとかでいろいろ遊んでたとき、JPEGでも規格上は一般的に使われるHuffman codingだけでなくArithmetic coding(算術符号)も利用できるってことを知った。
Huffman codingの代わりにArithmetic codingを使うようにファイルを変換してもデータは劣化せず(ロスレス)、サイズは6%くらい小さくなるらしいので、
(すでに他の人が書いてるけど)ベースラインの代わりにプログレッシブを使って、それに加えてArithmetic codingを使うようにすると、ずいぶん(もう覚えてないけど10%くらい？)小さくなった気がする。
どちらもロスレスな変換だし、jpegtranの-progressiveと-arithmeticオプションで一括変換できるから「こりゃいいや」と思って使おうとしたけど、Arithmetic codingは特許の影響(特許自体はすでに切れているらしいが)で対応してるソフトウェアがとても少なくて諦めた。

ちなみに、jpegtranはプログレッシブ変換とかArithmetic coding変換以外にも、画像の回転とか反転もロスレスでできます。他にもロスレスでいろいろな処理ができるっぽいので、詳しくはjpegtranのmanpageを。
それと、Arithmetic codingのJPEGファイルのサンプルは http://filmicgames.com/Images/Patents/bedroom_arithmetic.jpg にあるので、表示できるか試したりしたい方はどうぞ。

製品にコピーレフトなソフトウェアを使っており、またそのソースコードを提供してはいるものの、ソフトウェアを改変させない(もしくは改変が非常に困難となる)ような機構を故意に(ブートローダーやファームウェアなどハードウェア的に)組み込んでいるというのは Tivoization (TiVo化) をいい、TiVo社がそういった製品を発売した2006年ごろに話題となりました。

GPLv2ではTivoizationがライセンス上は(GPL/フリーソフトウェアの目的や思想とは反するものの)可能でしたが、GPLv3ではTivoizationに対して制限する条項が盛り込まれました。

ちなみに、FSFなどフリーソフトウェア陣営はTivoizationに否定的でしたが(GPLv3にアップグレードする理由でもTivoizationを防げるという事が挙げられています)、Tivoizationは正当な行為という立場の人も少なくなく(リーナスなど)、その辺りがGPLv3策定時にもめた部分でもあります。

毎度の事ながら、Amazon.com のレビュー は9割が最低評価になっており、EAの公式フォーラム でも批判が殺到しております。

JavaScript は、C++ や Python などと並んで GTK+/GNOME の公式 Binding の一つになっています。(リストにあるうち足跡マークがついているものが公式 Binding)

私は GTK+ で JavaScript を使った事はありませんが、Hello World チュートリアルを少し読んでみた限りでは簡単に作れそうな雰囲気です。

ただ Python や Ruby などにあるような便利機能が無いので、それらと比べると JavaScript で書くのはちょっと面倒というか冗長かなぁ・・・。という感があります。慣れの問題かもしれませんし、CoffeeScript とか使えば問題ないのかもしれません。

ちなみに、元記事にもあるように、JavaScript は GNOME Shell を拡張するための言語として採用されていますが(→GnomeShell/Extensions - GNOME Live!)、JavaScript で書かれた GTK+/GNOME のデスクトップアプリケーションというのは見当たりませんでした。

ライセンスとは全然関係ないですが・・・

ずっと昔、Proxomitron が無くなり Proximodo の開発が始まったころだったと思うのですが、自分もいわゆるコンテントフィルタリングHTTPプロキシの開発に参加(もしくは自作)しようと思っていたことがあります。ただ、コンテントフィルタリングはブラウザ上で行なうべきなのではないだろうか(例えばGreasemonkeyやStylishなどのように)。と思って結局開発には参加しませんでした・・・。

ブラウザ上で行なうべきだと考えた理由としては、

• - HTML文書に対して単純なテキストマッチングを行なうだけだと、例えば属性の順番が違うとか、スペースのあるなしとか、属性値がダブル/シングルクォートで囲われているかとか、実体参照とかに対応するのが難しい(Proxomitronでもそうだったけど、パターンが複雑になりすぎる)。そうすると、プロキシ上でHTMLをパースして(SAXのような感じで)、それを元にマッチングや書き変えを行なう必要があるけど、世の中のHTML文章には文法エラーが非常に多いし、そういった文法エラーがあった場合の扱いをブラウザと一致させなきゃいけない。
• - HTML文書の文字エンコーディングが指定されてない場合、文字エンコーディングを推測しなきゃいけない。
• - HTTP 1.0 の頃は問題なかったけど、HTTP 1.1 ではコンテントヘッダで Content-Length を指定しなきゃいけない(HTTPコネクションを維持するため)。コンテントボディを書き換えた場合、それに応じてヘッダを書き換えなきゃいけないため、コンテントボディを全て読み込んで書き換えが終わり、コンテントボディの長さが分かるまでブラウザにはデータが送れなくなってしまう。それを回避するには、コンテントボディ全体を chunked コーディング(Transfer-Encoding: chunked)に変換しなければならない。
• - コンテントボディが最初から chunked コーディングになっていた場合は、それをデコードしてからマッチングと書き変えを行い、また chunked コーディングに変換しなおしてブラウザに送る事になる。
• - コンテントボディが圧縮されていた場合(Content-Encoding: gzip など)、プロキシ上でそれを一旦展開しなきゃいけない。
• - HTTPSなページは書き換えられない。それを回避するためには、中間者攻撃のような感じで、プロキシが独自に発行する証明書をブラウザに信頼させて、ブラウザから送られたHTTPSトラフィックをプロキシ上で復号した上で、改めてプロキシがサーバーへHTTPS接続を行なう必要がある。証明書の確認や失効の処理について、今まではブラウザが行なっていたものを、プロキシが責任を持ってやらなきゃいけなくなる。
• - 結局、ブラウザが行なっている処理の結構な部分をプロキシ上で実装しなきゃいけない。全てのネットワークトラフィックを(ローカルにあるとはいえ)プロキシを通すのはなんかリソースがもったいない気がするし、ブラウザが行なう処理をプロキシも行なうというのも二度手間感がある。

とかいう理由だったような記憶があります。

実際にブラウザ上でユーザースクリプトやユーザースタイルシートを使っていると「単純なテキスト置換でも実現できる事、むしろそのほうが手っ取り早い事」というようなケースもあるのですが、「もしやるのであれば、ブラウザのネットワーク入出力をフックして、そこで書き換えた方がいいのではないだろうか」と思ってます。