2011年11月16日水曜日

DRMは邪悪なのか

DRMというのは、「Digital Rights Management」の略で、デジタルコンテンツに対する権利保護技術、ということになっている言葉です。

昔、AppleがiTunes Plusという、「従来より値段が高いけれど高音質で、しかもDRMフリー」を謳い文句にした楽曲配信の新サービス開始にあたり、Jobsが「DRM is evil」と宣った件があるのだけれど、つらつら考えているうちに、Jobsの言っていた意味がわからなくなってきたわけです。

というのは、AppleがDRMフリーにしているのは、iTunes Plusになっている楽曲だけで大半は相変わらず1曲120円DRMつきだったりするし(つまり顧客はDRM有無より価格を選んでいる?)、映像はすべて独自の(しかもiTunesのバージョンアップとともにより堅固になっている)DRMつきで、Apple IDで認証され正規購入したものに限って販売(あるいはレンタル販売)していてApple純正のプレイヤーでしか再生できないし、iBookStoreは購入したことがないからわからないけれど、iBooksにサンプルでついてくる「Winnie the Poo」(くまのプーさん)はApple独自のDRMで暗号化されていて、iBooks以外で開くことはできません。サンプルがDRMつきというのは、DRMフリーな本がiBookStoreに存在するのかどうか、疑問に思う次第です。

あと、Kindle Fireはみんなとても気にしていて、出たら買うぞという勢いの人が大勢いるような気配がネットでも漂っているわけですが、Kindle Storeで買った本はKindleでしか読めないんだけどみんな気にしないのかな、と不思議に思ったりするわけです。KindleはMac版もWindows版もiOS版もAndroid版もあるから困らない、とみんな思うんだろうけれど、紙の本なら自分の本棚の整理は自分でできるんだけれど、Kindleしかなかったら、Amazonが扱わない電子書籍は絶対入手できないという点に疑問は感じないのかな、と。ちなみにKindleはAZWというAmazon独自のファイル形式で(なかみはWebをベースとした、EPUBなどと似たもののようですが)、DRMも独自です。

で、楽天が買収したカナダ(トロント)の会社Koboの端末は、DRMなしのいろいろな文書を入れることができて、特にオープンな電子書籍規格であるEPUBに対応していて、DRMについてはAdobeのDRMに対応しているので、SONY ReaderやNOOKのために買った本や、Google Booksで買った本などの「DRMつきEPUB」も入れて開くことができるから、購入の選択肢が広くていいよね、と思っていたわけです。

ところが、AdobeのDRM(Adobe Digital Experience Protection Technology)とはどんなものかと調べてみたら、まず利用者のAdobe IDを登録して、端末やリーダーは6つまでだけれども登録が必要で、その上で認証がとれたらようやく暗号を解いて内容を表示できるようになる仕組みということがわかって、これはどうなのかと思った次第。

特に、DRM管理ツールであるAdobe Contents Server紹介のページで「System Overview」タブを開くと出てくるをじっくり見ていると、どこのオンライン書店であれ、顧客登録したらAdobeにそれが通知され、購買行動を起こしたこともAdobeに通知され、買った本を開くためにまたAdobeと通信するのが示されているのに気づいて、ということは、電子書籍にまつわる利用者の行動大半がAdobeのクラウドに知らず知らずのうちに蓄積されていくのであって、そんなことオンライン書店しか見てない客は知らんよなぁと思ったわけです。この商品についてのAdobeの主張は「自社製品しか認めないAppleやAmazonのシステムよりもfairだ」ということなんですが、「fairの意味ってなによ」と問い詰めたい衝動におそわれたりしました。

著作権の文脈でfairといえば「fair use」であって、著作権所有者と利用者の間で利害が公平であることを指すのですが、ツタヤのTカードよろしく個人情報集めまくりのプラットフォームを構築したAdobeは、著作権所有者と利用者の間の仲介者としてオンライン書店の裏側に潜んで情報を集めているという意味で、同じくあらゆる購買行動をデータ化しているAmazonと、どっこいどっこいなんじゃないかと思うわけです。むしろショップとして対象が見えているAmazonより陰湿な印象すら感じられてもおかしくはないんじゃないかと。

Amazonが顧客情報を持つ強みを発揮して出版社に対し恫喝まがいの営業をかけたり、取り扱いを制限するような報復行動をとっているという話は、探してみると英語や日本語で結構出てきます。サイトでおすすめされる商品、実は裏で巨額のお金がAmazonに渡ってますとか。日本の出版社と書店の間で動いているお金とはちょっと規模が違いますよ的な。

CD、DVD、紙の書籍といった現物は、著作者の意向がある程度反映されたり利用者も匿名で入手できるし保管も移動も自由にできるわけですが(さらに中古市場もあって、文化的なアーカイブの機能も果たしているのですが)、音楽配信や映像配信、電子書籍ではどうも著作者でもなければ利用者でもない、プラットフォームを握っている側の力があまりにも強すぎるのではないかという考えにだんだん傾いてきました。

特にDRMについては、個人の特定が可能な運用が基本にあって、さらに、現物で可能だった保管や移動の自由が制限される可能性が十分にあります。オンライン書店なくなったら本が読めなくなったとか、端末壊れたらデータが再取得できるかはDRMかけた側の都合次第とか、「せっかく買ったのになんだか理不尽な感じ」のことがいろいろと想定できるのです。「絶版」が、本当の意味で世の中から消えることを意味する可能性が十分にあるということです。中古市場がないわけですから。

まぁ、絶版問題については国会図書館とかにはDRMフリーで納入すべしとか法律かなんかで縛るとか手段はあるのかもしれないんですが、「だったら出さない」とか「たっぷりお金はいただきます」とかの本末転倒な話もありそうで、著作者と利用者おいてけぼりという未来が、なんとなく感じられなくもありません。っていうか、古文書とかが発掘されたとして、まぁ未来はいまのDRMなんか瞬時に外せるのかもしれませんけど、解読不能になったら歴史はどうなるのとか血迷ったりしてしまいました。

古書店に行くと、一般には絶対流通しない、関係者限定の本とか、特定の機関が限られた数だけ配布した本とか、地下活動していた人が配布していた冊子とかが何気なくそこにあって、これもすべて文化だよなぁと思うのですが、未来はどうなるのかなぁ、と。

たぶん、そんなあれこれがあって、海外には独立系の電子書籍サイトがいっぱいあるのかもしれません。入ったことはありませんが、プロプライエタリなDRMなんかはついていないんだろうなぁ、とも。

DRMつきの著作物が流通する意義は認めていますので、それはあっていいのですけれど、できればオープンな仕様で、仲介者のビジネスもクリアな形であれば、なんだか不透明な現状よりは、よほどいいとは思うのです。どうもこう、不況だととにかく中身がおんなじなら安けりゃあとはなんでもいいというところに走りがちではあるのですが。我が身を振り返っても。

2011年11月11日金曜日

子どもとケータイの関係が心配な親はiPhoneを選ぶべき

Androidについて知らないのでこういうタイトルになっているんだけれど、もしAndroidでも同じことができるなら「スマホ」と範囲を広げてもいい。

なんでもかんでも、新しいものが出るとすぐに規制したがる人々がいて、もちろん「よくわからないものは信用しない」のは正しい態度なのだけれど、「だからお上がきちんと取り締まらなければならない」という議論に引っ張られるのは、まさに「自由からの逃走」(フロム)だと思う。そんなに管理社会、監視社会が好きなのかね、と。

「子どもとケータイの関係」が問題になっているのは、i-Modeがすべての発端だったのではないだろうか。 ドコモが戦略的に「勝手サイト」への誘導を図った結果、大人がしっかり騙されてエロサイトなどに誘導され、ドコモは通信料がとれて儲かったという話を「しかるべき筋」の話としてきいているので、こう書くわけだけれど。

通話とメールだけなら、ここまでみんなして「困った、困った」と騒がなくてよかったはずで、Webに直通したおかげでいろいろと、ダークだったりグレーだったりするビジネスが生まれたと考えるわけです。

で、スマホは規制がかからないから危ないとか、また大きな勘違いを喧伝している人々がいて、たぶん規制したい側が意図的に流したネタをうっかり信用している人が伝言している状況だと思うのだけれど、どうしたものかと思う。

どうも知らない人が多いようなので、わざわざ書くまでもないことを書くわけだけれど、iOSには、アプリの起動制限をかける機能があります。親がパスワードをかけて、動かしていいアプリを決めることができるのです。

iOS: 機能制限について (Apple公式ページ)

極端な話、電話とメールだけにすることも可能なわけです。特に、SafariとApp Storeを動かないようにできるという点がとても大事。これだけで、i-Mode被害のほとんどは回避できるはず。

いみじくも、「ペアレンタルコントロール」という説明になっていることを、ケータイを買う親はかみしめてほしいわけです。自分の子どもがなにをしてはいけないか、それぞれの家の都合で決められるということです。この自由を手放してはいけない。

でもって、もしWebが必要ということがあるなら、それこそ「子ども向けWebブラウザ」アプリを出して、それをインストールして使ってもらうことにすればよい。ビジネスチャンスはここですよ。まぁ、有名企業やキャリアの名前で出さないと商売にならないかもしれないけれど、それならそれ、ソフトバンクさんも、富士通さんも、その他みなさん商売してください。

大人を騙して金を巻き上げる商売する側と、規制したい当局は、いろいろと惑わせるような話を大々的に流してくると思うけれど、大人の皆さんは冷静に考えて、せっかくの自由を売り渡すようなことはゆめゆめしないようにお願いします。

2011年11月8日火曜日

FFmpegとMacPorts

動画変換最強プログラムのffmpeg(巷のGUI動画変換アプリも中身はffmpegのコマンドラインを作っているだけだったりする)だけれど、Lion 10.7.2 + Xcode 4.2では、MacPorts版がコンパイルできない。

LLVM GCCではMMX関係のマクロの展開に失敗しているような感じで、未解決のシンボルがどうのといって止まってしまう。

困っていたのだが、検索してみたところ、configure時に--cc=clangオプションをつけて、clangでコンパイルすればよいという説明があり、試してみたら成功した。

おそらく、コマンドラインはこんな感じだと思う。
port install ffmpeg-devel configure.cc=clang
僕は、最新版のGitリポジトリから入れた。とはいえ、依存ライブラリから全部自前では面倒なので、いったん普通にportでffmpegを入れようとして、依存ライブラリが全て入ったところでffmpegのconfigureに失敗するところから始めた。

まず、
port clean ffmpeg
したあと、適当なディレクトリに
git clone git://git.videolan.org/ffmpeg.git
して最新のソースツリーを取得し、そのあとでMacPortsが与えるオプションを用いてconfigureを実行する。

ただ、気のせいかどうかわからないけれど、gitの結果できるffmpegディレクトリのなかに再びffmpegディレクトリがあったような気がするので、あれば消しておく必要がある(実行ファイル名とディレクトリ名がぶつかり、エラーになるから)。.gitignoreにffmpegと書いてあるので、次回のpull時に復活する可能性はないはず。

与えたオプションは以下の通り。
./configure --prefix=/opt/local --enable-gpl --enable-postproc --enable-swscale --enable-avfilter --enable-libmp3lame --enable-libvorbis --enable-libtheora --enable-libdirac --enable-libschroedinger --enable-libopenjpeg --enable-libmodplug --enable-libxvid --enable-libx264 --enable-libvpx --enable-libspeex --mandir=/opt/local/share/man --enable-shared --enable-pthreads --extra-ldflags="-L/opt/local/lib" --extra-cflags="-I/opt/local/include" --enable-version3 --arch=x86_64 --cpu=x86_64 --cc=clang
あとは、make && make installすれば/opt/local/bin以下にffmpeg関係のバイナリが入る。

MacPortsのffmpeg-develはまだsvnのリポジトリを参照しているようで、まだ0.7あたりのようだ。gitのほうは、すでに0.8は終わってその次になっているので、gitからビルドしたほうが、より高速で高機能かつ高画質なバイナリが得られるはず。ffmpeg-develリストを読む限り、少なくともMacに関しては、「VDA (Video Decode Acceleration Framework)」が最近入ったので、H.264のデコードがGPUによって行われる分、変換が高速になるはず。また、DCTのテーブルも調整されているので、画質向上も図られていると思われる。

なお、MacPortsで入っているx264が古いためか、MP4にエンコードする際にCPUのもつMMX等のスーパースケーラー機能がないと勘違いし、ひどく遅くなる。x264もGitで最新版にしておく必要があるようだ。
git clone git://git.videolan.org/x264.git
configureのオプションは、MacPortsにしたがって、
./configure --prefix=/opt/local --enable-pic --enable-shared
としておいた。make && make install後、ffmpegを再度ビルドしなおせば、例えばCore2Duoの場合なら
[libx264 @ 0x7fee9a0bc800] using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.1 Cache64
のように、きちんとCPUに装備されている並列計算機能を利用してくれる。失敗した場合は、この表示が「none!」になってしまう。