スキップしてメイン コンテンツに移動

訴えられそうになった話:経緯、思ったこと、反省点、経過など

今回、ブログに公開したことによって、様々な意見や考え方に触れることできた。

しょうがないねとか、嫌だなーとか、もっと粘ってふんだくればいいのにとか、そんな商標権にそこまで権利ないよとか。
あまり例にない事と言うことや、話題性の高いTwitter上でのトラブルと言うこともあり、色々とあちこちで意見やコメントを見せてもらいました。


経緯

で、なんで僕は今回応じるようにしたのか。

簡単に言ってしまうと、僕は頭悪いし法的な知識はまるでない。そして面倒くさがりである。なのでアカウントIDを譲った。

それにそんな状態で下手に争って負けて変な前例作ったら、みんなに大バッシングくらいそうだし。例え勝てたり和解で終わったとしても弁護士費用の方が高そうだしそんなお金ないし。
というか、それ以前に今後このような事例が増えるようなことにもなって欲しくない。
また、一個人がインターネットにおいて自由にアカウントIDすら使えなくなってしまうことは無論望んでない。
ただし、もちろん他人の権利(法的に保護されているものもそうでないものも)を意図的に侵害するのは論外。

とかなんとかいうのは後付けの理由で、僕なりにちゃんとした理由がある。
最初に挙げたとおり、面倒事はゴメン被りたいというのも一つの理由である。


いちいち法廷でとか書面でとか対応するのは流石に面倒ゴメンだし、前回書いたとおり、たかがウェブサービスのアカウントIDだ。
ぶっちゃけて、何かの拍子にTwitterがサービス終了したり、なくなってしまえばそれで終わりなだけ。
いま、誰が見てもTwitterのサービスそのものには価値はあれど、Twitter上のアカウントIDに価値があるのかと言えば、それぞれの使われ方や気に入り方次第だと思うけれど、一般的にはそんなものは正直皆無。あったとしても、ドメイン名などのパブリックなものと比べれば全然大したものじゃないと思っている。
で、そんなものに対して金品を対価として相手に提供してまで欲しいというなら、僕は逆に美味しいと感じた。

たとえばTwitterではなく、別のウェブサービスだったとしよう。
「君のYahoo!のアカウントID良いね、いくら払うからそれちょうだい」
「君のBloggerのアカウントID良いね、iTunesギフトカードあげるからそのアカウントちょうだい!」
というのと道理は同じであると考えている。
これもYahoo!やBloggerのサービスがなくなってしまえばそれまでの話。(おそらくは数年以上の単位で、そんなことはないと思うけど)

これがドメイン名だとした場合、ドメイン名が勝手に消失する可能性は、WWWのドメイン名ベースでのアドレス解決を行う構造でも代わらない限りない。あるいは登録者自身の不手際でもない限り、消失することはほぼない。

というわけで、アカウントID云々で手間をかけるには、僕はそれほど価値がないと考えているのと、そこに対して金銭的価値を見いだしてくれる人がいるなら、それが僅かであってもこちらにとってはおいしい。



もう一つ。
今回はAnonymizer, Inc.の社長から直接メールで連絡が来た。
どのように僕のメールアドレスを知ったかは知らないけれど、僕はメールアドレスを各所に公開していたので、アカウントから照会ページのリンクでも辿って連絡を付けたのだろう。

そんなことはさておき、今回の件をTwitterの運営元であるTwitter社経由で行っていた場合どうなっていたか。

このページによると、先方も色々手順を踏んでいかなければならなそうだが、最悪の場合、僕のTwitterアカウントはTwitterによって突如凍結されていた可能性もある。

といっても、(恐らく)Twitter側も相当悪質なケースを除いていきなり行ってくるとは思わないが、僕はTwitterをかなり利用しているし、万が一にも突然アカウントを凍結されてしまうのは正直辛い。
なので、それが行われなかっただけでも僕はよかったと思っている。




あとになって思ったこと、反省点

反省点としては、まず向こうの要求に応じる応じないはさておき、一旦連絡してもう少し考える時間をもらうこともできたかなと。
1週間ですべてを決断しろとまではメールでも書いてなかった。(が、提示条件をのんで対応する意志があるなら1週間以内に対応しろとは書いてあった。)返信がなければ法的に権利を主張する(出るとこ出る)よ。とはあったけど。

ただ、相手が提示する条件を受けるには、結局のところ1週間以内で意志決定し、(ないよりマシ程度にいい条件を取るなら)対応をせざるを得なかったのかなーというのは事実。

でもね、そんなに欲しいアカウントIDを、Twitterサービス開始から4〜5年経ってしばらくしてからひょこひょこやってきて、お前のそれ、ウチの名前だから。勝手に使ってるなよ、おとなしく寄こさないなら訴えることもあるからな。
っていうのもなんかなーと思うんです。
やろうと思えばサービス開始時にでもアカウントを取ることはできたわけで。
少なくとも日本でTwitterが注目され始めたのは、Twitterのベータサービス開始(2006年7月)から半年〜1年後だったとみてる。(自分を含め、古くから利用している日本人ユーザのアカウント登録日から推測)
あと商標権が、他者のウェブサービスにおけるアカウントIDにまで範囲が及ぶのも正直微妙。

ただ、上にも書いたとおり、Twitterの利用規約的にはアウトっぽいのもあったので、下手に争ってアカウント丸々凍結されたら、この場合そっちの方が怖い。


経過について

そんなこんなで最初の連絡を受けてから既に1週間経った訳ですが、向こうから連絡が来たのは最初のメールと、その後僕が一度質問を送ったものへの回答メールの2回のみ。

2回目に来たメールには、今度は丁寧な英語で回答が返ってきた(僕が質問を英語で送っていたので)。
そのメールには「アカウント変更したら改めて教えてね。そしたら、ウチのサービスを君に提供する準備するから。で、そのとき登録に必要だから、君の情報(メールアドレスとかその程度)教えてね。登録できたらその情報も送るから。」と書かれていた。
その後改めて、こちらから「アカウント変更したので確認とかアカウント名の取得とかよろしくね」と返信したものの、以降連絡が来なくなってしまった。

もしかしたら忙しい社長さんなのかも知れないが、せめて1週間以内でという指定で要求してきたのであれば、なおさら素早く対応してくれても良いと思うのは日本人だからですかね。。。

一昨日に改めて催促のメールも送ってみたけれど、これでまた何も連絡なかったら、ちょっとはこっちも強気に要求してもいいよね。

後日談
その後、催促してみたり何度かメールを交わして、最初にメールでもらっていたとおり、最後まできちんと対応してもらいました。

コメント

このブログの人気の投稿

さくらのクラウドでマストドンのインスタンスをサブドメインで作る

タイトルに「の」と「で」が多すぎますが気にせずいきますこんばんは。

さくらのクラウドで、いま話題のMastodon(マストドン)のインスタンスを作成してみました。
Mastodonは普通にソースを展開して自分で普通にセットアップする方法や、Docker-composeを用いた方法などがありますが、さくらのクラウドでは、スタートアップスクリプトを用いて、管理画面から必要な項目を入力、スクリプトを選択するだけで簡単に立ち上げることができるようになっています。

さくらのクラウドのMastodonスタートアップスクリプト 実は少し前にこの方法で立ち上げたりもしていたのですが、本当に簡単でサクサクできてもの自体は30分程度で完了します。
管理者ユーザーを作成するには、通常のユーザー登録と同じ手順で画面からユーザーを作成後、一度コンソールからログインして、mastodonユーザーで下記のコマンドを実行する必要があります。

# su - mastodon % cd ~/live % bundle install % RAILS_ENV=production bundle exec rails mastodon:confirm_email USER_EMAIL=登録時のメールアドレス % RAILS_ENV=production bundle exec rails mastodon:make_admin USERNAME=作成したユーザーID mastodon:confirm_email でメール受信確認をスキップして承認済みに、mastodon:make_admin で指定したユーザーを管理者に設定します。

これでインスタンス管理者として様々な操作をGUI上から行えます。

同類の記事は恐らく既にたくさんあるので、詳しい作り方に関してはそちらを参考にしてください。

気になるところが 上記のさくらのクラウドニュース内で記載されているMastodonスタートアップスクリプトでの構築方法に関する記事内で、一つ気になるところがありました。
それが
※サブドメイン(例:mstdn.example.com)には対応していません。 という記述部分です。

つまり、このスタートアップスクリプトを利用した場合、サービス専用のドメインを用意する必要があります。
既存のドメインをなるべく利用したい場合には向…

iPhone7はApple Payでゲーム系ICカードとしても使えるか?

先日発売されたiPhone7をはじめiPhone6以降の機種で、日本でもようやく、Apple Payが使えるようになりました。
iPhone7は長年ユーザーが待ち望んできた防水対応もさることながら、日本向けiPhone7/7 Plusでは、NFCだけでなくFeliCaを搭載し、Apple PayではJR東日本のモバイルSuicaやEdyが使える、というのが今回の注目にもなりました。
Apple Payが始まることで、こちらも日本のユーザーが待ち望んでいたモバイルSuicaをはじめとする、国内の様々な場所で使われている非接触IC系サービスの恩恵を受けられるようになります。



ということは、非接触系ICカードを利用している場所の一つである、ゲームセンター。ここにある数々のゲーム筐体、最近では非接触ICカードリーダーが備え付けられていて、独自の電子マネー機能を持ち合わせたり、カード情報を読み取ってプレイヤーのプレイデータを読み込むのに使用されたりしています。これらは果たしてiPhone7でも使えるのか…。
検証
まず、現在国内で主流の非接触IC系ゲームプレイカード(以下、プレイカード)は下記の種類があります。

e-AMUSEMENT PASS (コナミ)
Aime (セガ)
バナパスポート (バンダイナムコ)
NESiCA (タイトー)
※これ以外にもあるかもしれませんが、自分が主に音ゲーを好んでやるため、音ゲー機種が出ているサービスのみを対象にしています。

これらのサービスに対応する機種でiPhone7のApple Payが使えるか検証してみます。

PHPで相対パスから絶対URL(URI)を作成する

HTMLページをパースしてURLを取り出す処理を書いていたのですが、ページ内のリンクなどが全部絶対URLで記述されていれば非常に楽なのですが、現実としてそうでもなく、ページによっては相対パスで書かれていたりして、正規表現で偏にリンクからURLを抜き出すだけではうまくできませんでした。

そこで少しググってみたら

PHPで相対パスから絶対URL(URI)を作成する|PHPプログラムメモ|プログラムメモ

という記事を発見!おぉ、これは便利!
と思って使わせてもらおうと思ったのですが、いくつかテストしてみて、相対パス処理で不備があるなーと思ったところがあったのでちょっと改良させてもらいました。

37~38行目は正直いらない気がしたのですが、 PHP 5.3 のCLIでWindows上でテストした際に、なぜか \/ (アルファベットのVではなく、\/ ) で出力されたのが気になったので、無駄かもしれないけどあえて記述。
あと $parse の初期化もここまでする必要ないけど、念のためNotice対策を…w

相対パスから絶対URLする関数

< ?php
/**
* 相対パスから絶対URLを返します
*
* @param string $base ベースURL(絶対URL)
* @param string $relational_path 相対パス
* @return string 相対パスの絶対URL
* @link http://blog.anoncom.net/2010/01/08/295.html
* @link http://logic.stepserver.jp/data/archives/501.html
*/
function createUri( $base = '', $relational_path = '' ) {

$parse = array (
'scheme' => null,
'user' => null,
'pass' => null,
'host' => null,
'port' => null,
'path' => null,
'query' => …