ウェブの最近のブログ記事

ネット上の著作権侵害という問題

文章や写真などの著作物には著作権がありますが、他人の著作物を勝手にコピペして利用する著作権侵害をしているサイトも世の中にはあります。ひとが様々な手間暇やお金やノウハウを使って作り出した著作物を勝手に自分の商売に使うのは権利の侵害であり法律問題になります。

ネットの検索で出てきた文章や写真をコピペして自分の資料やウェブサイトに勝手に使うことはもちろん著作権侵害を引き起こします。東京オリンピックのエンブレムの問題が話題になった際、エンブレムのデザインそのものだけでなく、資料に使った写真がネット検索で出てきたものを勝手にコピーしたものだったという点も問題になったのは記憶に新しいところです。

私自身の体験としても、自分が撮影した写真を「旅行キュレーションメディア」なるウェブサイトに勝手に転載されたことが何度もあります。もちろん著作権侵害です。こうしたサイトには見つけ次第連絡し削除を要請しています。しかし悪質なところだと、報告した写真を一旦削除してもまた別の写真をコピペする。それをまた報告して削除させても、また別のをコピペする。それに対して抗議すると、再発防止に取り組んでいますとかなんとか言って、また繰り返す。どうにもならない。

対策: Googleに著作権侵害サイトを検索インデックスから外してもらう

著作権侵害対策のひとつとして、Googleに著作権侵害サイトのURLを報告して、検索インデックスから削除してもらうということをやってみました。

Googleは著作権侵害の報告をウェブから受け付けています。アメリカのDMCA (Digital Millennium Copyright Act, デジタルミレニアム著作権法)という法律に対応してのもののようです。

様々なウェブサイトやブログにこの手続きの経験談が載っています。著作権侵害の被害にあっている人の少なくないことが伺えます。"Google DMCA" なんてキーワードで検索すると出てくるページから一部ご紹介:

こうした説明を参考にして私もやってみました。やり方は基本的に同じですが、時とともに変わっている部分もあるようなので自分の体験を記しておきます。

まず、申し立てフォーム へ行く。Googleアカウントでログインします。(アカウントのない人は作らないといけないのかな?)

記入内容は以下のとおり:

  • 連絡先 (必須項目は、氏名、国、メールアドレス、著作権保有者)
  • 著作権対象物:
    • 問題のサイトのどこが著作権侵害であるか
    • 自分のサイトのURL (ブログやFlickr等、自分で掲載した場所)
    • 著作権侵害サイトのURL

自分のサイトと侵害サイトを逆に記入しないよう注意。あとは、私は嘘ついていませんよという宣誓と署名をして送信したらおしまいです。

上記の体験談にはGoogleからメールが来たという記述がありますが、今はやり方が変わったのか、特に問題がなければメールは来ないようです。ダッシュボードのページがあり、そこから報告のステータスを確認できるようになっています。

削除されてから試しに、Googleで問題のページが検索できるかをテストしてみました。すると、著作権侵害の申し立てにより1件のページが削除されました、と明示された上で、問題のページは検索結果に出てきませんでした。きちんと処理されたようです。よかった!

注意点

この機能が悪意で使われて単にライバルのサイトを蹴落とすために使われると問題でしょうから、本当に自分の権利が侵害されているかという念を押されます。また報告の内容と報告者名はウェブサイトで公開されます。それでためらう人もいるかもしれませんが、実際に自分の権利が侵害されているのなら萎縮せず報告したほうがいいでしょう。

今回、報告は個別のページに対して行ったので、削除も当該ページだけで、サイト全体は削除されていません。自分の権利の侵害への対処という意味では妥当な結果なのでしょうが、問題のサイトは恒常的に著作権侵害を繰り返しています。同サイトの侵害報告が増えればいずれはサイト全体が削除あるいはランク低下という結果になるかもしれません。

おわりに

著作権侵害でお悩みの方はどうぞお試しください。

1枚の写真を撮るには、機材の購入費用や現地への交通費、要した時間はもちろんのこと、撮影場所や時間帯の選定、構図や露出の決定のノウハウ、天気や風のような自然条件も必要です。様々な費用や時間、知識、スキル、さらには偶然の巡り合わせの積み重ねによって得られた成果を勝手に盗んで商売するようなパクリサイト自称「キュレーションメディア」には厳しい対処をしていきたいと思います。

PayPalでは使い方によっては本人確認が必要になることがあります。ところがこの本人確認の手続きで書類不備を指摘されて突き返され、時間がかかってしまったと、いくつものウェブサイトに体験談が記されています。今回、そうした体験談を事前調査していたにもかかわらず手間取ってしまいました。

そもそも何が問題になるのかというと、PayPalに登録している名前を、海外とのやりとりのためにローマ字表記にしていると、本人確認書類が漢字表記なので駄目だといわれるというものです。

PayPalの本人確認に使える書類にはいくつかあり、その中には運転免許証が含まれています。ポピュラーな書類なので使う人が多いでしょうが、免許証の名前は漢字表記なので、これだとローマ字で登録しているのと食い違ってしまって突き返される。

そこでとりうる手段はふたつあります。ひとつは、PayPalに登録されている名前をローマ字から漢字に変更すること。こうしたという体験談もウェブで見かけます。ただこの場合は本人確認が済んだ後でまたローマ字に戻すとしたら手間ですし、登録名の変更にしても書類のやりとりが発生してすぐには完了しないはずです。

もうひとつは、確認書類に免許証でなくパスポートを使うこと。これなら最初からローマ字が書いてあるので登録名を変える必要はありません。

今回はパスポートを使うことにしました。これと住所の記されている公共料金の領収書を補完所類として用います。スキャンした確認書類をウェブサイトからアップロードします。

ふふ、我ながら事前調査はばっちり、これで問題ないはず......。

と思ったら、書類不備とのメールが来てしまいました。なぜだ!

理由は簡単で、PayPalに登録されている名前だけでなく住所もローマ字になっていたから、でした。なるほど、公共料金の領収書の住所がローマ字になっているはずがない。

そちらはしようがないので登録されている住所を漢字表記に変更。ウェブからの操作とフリーダイアルの電話を使って再審査。

これでようやく本人確認ができました。

ネット検索すると、この件の手続きの煩わしさを記したブログ等がいくつも出てきます。そういう手間があることは先方も分かっているのでしょうから、ぜひとも、名前や住所に漢字とローマ字のふたとおりの表記があり得ることを前提としたシステムにしてほしいと思います。

最近、ウェブページで、英単語の途中で行を折り返していたり日本語の禁則処理が効いていなくて句読点が行頭に来るようなものを見かけることが多いように思われて、気になっていました。

あるときなど、英語の "use" という短い単語の途中で改行されていて異様でした。なぜこんな表示になってしまっているんだろう。

どうやら、CSSの word-break: break-all という指定が問題のようです。

この指定があると、単語の境界のスペースとは無関係に、右端に来たときに何でもかんでも改行してしまうようです。

例えばYahoo! Japanの検索サイトでもこの指定が見受けられて、そのせいでか検索結果のサマリーでは英単語が途中でちょん切られてしまっています。また、ブログサイトでもこうした指定を見かけました。

おそらく、普通の単語ではない、URLみたいな長い長い文字列がきたときに右端で改行されるようにという意図なのでしょうが、普通の単語がバシバシちょん切られてしまっているのはつらすぎます。

かわりに、word-wrap: break-word という指定を使うと、行の長さより長い場合にのみ単語を途中で改行するようです。普通はこちらを使うのが良いのではないでしょうか。word-break: break-all はよほど特殊な場合にのみ使うものとみなしていいでしょう。少なくとも、普通の文章の段落に適用するものとは思えません。なおどちらの指定でも、ハイフネーションは行われず、単純に行の右端に達した所で "break" するだけです。

それにしても、"word-break" と "word-wrap"、まぎらわしいですね...。

ある日本語のウェブサイトを見ていたら、他言語版のページへのリンクのアイコンに国旗が使われていて、それがかなり問題と思えるものでした。

英語、韓国語、簡体字中国語、繁体字中国語のそれぞれへのリンクがあります。この中で最も問題と思われるのは、中国語版へのリンクが簡体字・繁体字の両方とも、中華人民共和国の国旗がアイコンとして使われていたことです。うーむ。

繁体字中国語版というのは主に台湾・香港の人向けでしょう。香港はともかく (といっていいのかはいまいち自信がありませんが)、中華民国政府のもとにある台湾の人がこれを見てどう思うのか。大体、同じアイコンでは区別の役に立たず、「繁体字」「簡体字」とそえてある文字を読まないといけないのだから、アイコンを使う意味がないのではないでしょうか。

また、別のサイトでも同様の事例を見つけました。こちらはもう少し配慮してあって、英語や韓国語については国旗のアイコンが使われているものの、中国語については「中(簡)」「中(繁)」という文字表記になっていました。

問題は中国語だけではありません。英語にイギリスの国旗のアイコンが使われていましたが、もちろん英語が話されるのはイギリスだけではないわけです。アメリカ英語でなくイギリス英語だという意思表示であるわけでもないようです。リンク先をちょっと検索してみたら "organization" が米国式の綴りでしたし、第一、そこまで気の回る人なら言語のアイコンに国旗を使おうとは多分考えないでしょう。

言語が国に対応するという考え方はあまり実際的とはいえません。英語やアラビア語のように複数の国で話される言語もあれば、ヒンディー語のようにインドの言語であってもその国の多数の言語のひとつである場合もあります。クルド語やチベット語はどうすればいいか。

言語に国旗を対応させるという方針でやればやるほど、矛盾が表面化することになるでしょう。

先日、私の使っているWindows XP機で、Firefoxの日本語入力にトラブルがありました。事実上日本語入力ができない状態になったので、かわりのブラウザとして、SRWare Ironを試してみました。まあ別にIEでも良かったのですが、この機会に試してみようということで。

Ironとは何かを一言でいうと、Google Chromeから固有IDなどプライバシー上の懸念を取り除いた、「より良いChrome」だといえるでしょう。Chromeは、マシンにインストールすると固有のIDを発生させ、そのIDをいちいちGoogleに送信します。IronはChromeと同じくオープンソースのChromiumを元にしていますが、こうした固有IDのようなプライバシー上の懸念につながる機能は入っていません。

SRWareのサイトに、ChromeとIronの機能上の比較表があります。よく見てみるといいでしょう。

ただ、私はWindows XPの文字表示を綺麗にするためにgdippを使っているのですが(参考: Windows の文字表示を改善するgdipp)、何かの理由で、gdippが効いているとIronの(多分Chromeも)の文字表示が汚くなってしまうようです(ウェブをざっと検索するとgdipp側の問題らしく書かれたページがあります)。そのため、gdippの設定ファイルでIronを適用除外するようにしました。gdippの機能が活かされないので、文字表示はWindowsのデフォルトのちょっと残念な感じになってしまっています。

使っているウェブブラウザが1種類だと、そのブラウザに何か問題が発生したときに困ってしまいます。今後しばらくは、代替手段の確保という意味もあって、FirefoxとIronの2つを常に用意しておこうかと思います。

ちなみにSRWareというのはドイツの企業のようです。アメリカよりもプライバシーを重視するヨーロッパらしいといえるかもしれません。

参考記事:

昨年(2011年)の10月に、北海道の道東自動車道(道東道)、夕張〜占冠(しむかっぷ)間が開通しました。これにより、札幌圏と帯広圏が、初めて高速道路で結ばれました。食料基地である道東地域と、消費地の札幌圏、重要港湾を持つ苫小牧とが高速道路でようやく接続され、大変意義のある開通でした。

この付近をウェブの地図サイトで眺めていたところ、興味深いことに気付きました。結論からいうと、大多数の地図サイトが2012年2月時点でこの開通に対応している中、Googleマップだけが、開通前の地図を掲載し続けているのです。

試しに、Yahoo!ロコの地図を見てみましょう。

Yahoo地図の道東道

画像の中ほどを左右に走っているのが道東道です。切れ目なく続いているのが分かります。

同じ場所を今度はGoogleマップで見てみるとどうか。

Googleマップの道東道

なんと、高速道路の緑色の線が途中で途切れてしまっています。これは去年の10月まで未開通だった部分です。Yahooの地図は開通の情報が反映されていますが、Googleマップには反映されておらず、古い情報を掲載しているのです。

他の地図サイトではどうだろうかと、いくつか調べてみました。思い当たった地図サイトを以下に掲げますが、これらのサイトはいずれも、夕張〜占冠間の開通を反映した地図になっていました。

Googleにどういう事情があるのかは知りませんが、これだけ多くの地図サイトが反映している重要な変化をGoogleマップだけが反映していないというのは、Googleの姿勢に何か問題があると考えるのは無理のないことではないでしょうか。Googleは、利用者の個人データの収集ほどには熱心に最新の地図を提供していないといえるのではないでしょうか。

Googleマップが有名だからというので鵜呑みにしていると、古い情報を見せられていることに気付かないというリスクがあることになります。

上に掲げたYahooとGoogleの地図をよく見比べると、利用者に提示している情報量の適切さという点でも、Yahooに軍配が上がります。Yahooの方が市町村の名前と位置をより多く(なおかつ多すぎずに)表示しています。Googleマップの方は、驚くことに、道東の主要都市である帯広を、この縮尺でも表示しません。

GoogleマップはAjax技術で一世を風靡しましたが、地図サイトとしての有用性という面では、また別な評価が必要なようです。

ウェブは進化している。そう思っている人が、たぶん多いのでしょう。確かに、15年前の素朴なウェブページと今のものとはいろいろ違って見えます。

しかし、ウェブの根本的な考えである「ハイパーテキスト」という機能の面から見ると、ウェブの登場以来、あまりというかほとんど進化していないように思えます。

ハイパーテキストを提唱して有名なのはテッド・ネルソンです。著書『リテラリーマシン』は日本語にも翻訳されています。ウェブの開発にもネルソンのアイディアが影響していると何かで読んだことがあります。しかし、ネルソンが構想していたものに比べると、ウェブで実現されているハイパーテキスト機能は貧弱なものです。

例えば、ウェブで他の文書を引用するときには他のページからコピー・アンド・ペーストするという原始的な方法をとります。一方ネルソンの唱えるハイパーテキストでは、高度なリンク機能を使って、コピーではなくオリジナルの文書の一部そのものを挿入するとされています(「トランスクルージョン」)。ウェブでリンクというと単に他のページへのジャンプしかできませんが、ハイパーテキストの議論の中には、文書の断片同士を組み合わせて新たな創作を可能にするような高度なリンク機能が考えられているのです。

そうした、高度なリンクのようなハイパーテキスト性の実現は、今日のウェブの発展の中にはありませんでした。単なる片方向のジャンプでないリンク機能としてXLinkという仕様が考案されたこともありましたが、XBRLをほぼ唯一の例外として、実装上は顧みられていません。

ウェブの発展というのは、ハイパーテキストの機能を高めることでなく、例えば、Javaアプレットで動くホームページを作るとか、Flashで動くホームページを作るとか、DHTMLで動くホームページを作るとか、Ajaxで動くホームページを作るとか、HTML5で動くホームページを作るとか、大体においてそういう方面に関心が向けられてきました (今の人は動くホームページなんていうダサい言い方はしませんが)。

大体が、リンク先のファイルをリネームしたら即座にリンク切れとなるような原始的なシステムがそのまま温存されているということからも、ハイパーテキストとしての機能が重視されていないことが分かるというものです。

電子書籍が話題になっていますが、ここでもハイパーテキスト性は軽んじられています。というか、ウェブよりも退化しているといえるのではないでしょうか。私は世の中の電子書籍の機能を全部知っているわけではないので見落しがあるかもしれませんが、聞き及ぶ限りでは、いくつもの電子書籍がハイパーテキスト的に結ばれて自由にテキスト間を行き来できるという機能はないようです (少なくとも、広く話題にはなっていません)。世の中の関心はそれよりも、紙の本の見栄えを画面上に忠実に再現することにあるようです。

電子書籍が「アンビエント」(ambient, 包囲した、取り巻く)だといった本がありましたが、その言葉は真のハイパーテキスト環境のために取っておくべきだろうと思います。たかが無線インターネットで電子書籍を買えるだけのことでアンビエントとは言い過ぎでしょう。

ハイパーテキストの考え方はネルソンよりも前、ヴァネヴァー・ブッシュの論文 As We May Think (1945) にも遡ることができる、決して新しくないアイディアです。それだけ普遍性の高いアイディアだともいえるでしょうが、今のところ十分に顧慮されているとはいいがたいように思います。

拙著『プログラマのための文字コード技術入門』のmixiページを勢いで作ってみました。

どのように活用するかは、まだ未定です。もしかすると、企画倒れに終わってしまうかもしれません。が、邪魔にはならないと思いますので、mixiのアカウントをお持ちの方はフォローしてみていただけると嬉しいです。はげましのコメントなどお送りいただけるともっと嬉しいです。

ふと思い立って、このブログにFacebookの「いいね!」ボタンを付けてみることにしました。

参考にしてのは「Movable Type に「いいね!」ボタンを設置する」という記事です。ここに書いてあることをほぼそのままやってみました。

多分うまくいっているのではないかと思います。とりあえずこの記事でテストしてみよう。

いいねと言ってもらえるような記事を書いているかという根本的な疑問もないではないが、それはそれ。

ツイートボタンと横に並べたいのだけど、思ったような格好にならない...。後日再挑戦しようか。

Firefoxでルビ

| コメント(0) | トラックバック(0)

以前から、Firefoxでルビを表示させるのに、XHTML Ruby Supportというアドオンを使っていました。Firefoxはそのままではルビに対応していないのです。

ただ、アドオンの問題も分かっていました。このアドオンでは、ルビを振られる文字列がCJK統合漢字拡張Bから始まっていると、その漢字が化けてしまうのです。例えば「𣖔木作(ほうのきざく)」という具合にルビを振ると、先頭の「𣖔」が正しく表示されないということです。

この問題は開発者に報告した方がいいなあと思いつつ、なんとなく有耶無耶にしてしまっていました。BMP外の文字を含むときはルビタグを使うのを避けるという変な習慣もついてしまいました。

そうこうするうち、Firefox 4が出ましたが、このアドオンは新しいFirefoxのバージョンに対応していません。その一方で、HTML Rubyというルビのための新しいアドオンが出ています。

HTML Rubyを試してみると、上述の問題はありません。FirefoxとHTML Rubyでこのページをご覧の方は、上記のルビ付き文字列がきちんと表示されているはずです。

今後、FirefoxについてはHTML Rubyを使って下さい、ということにして、「𣖔木作」みたいなのもルビタグでルビを振ってしまっていいかな、と思い始めています。

なお、アドオンの機能については、ごく単純なルビについてしか試していません。複雑なルビは私は使わないと思うためです。あしからず。

最近のブログ記事

MovableTypeでブログにTweetボタンを設置してみる
ふと思い立って、このブログにTwitte…
byflowで遊ぶ
ここ何日か、byflowという最近できた…
tenki.jpの地震情報を貼ってみる
天気情報サイトtenki.jpの地震情報…
Flickrで遊ぶ
何ヶ月か前からFlickrを使っています…
Movable Typeのお節介
このサイトではMovable Typeを…

広告