「ライブドアブログにコメントすると、コメントの著作権はブログ主に」は有効か

事情があって[1] 、ライブドアブログ(livedoor Blog)の利用規約ガイドラインを見ていたのですが、妙なものを見つけました。

「利用規約」

そもそもライブドアは、その利用規約

1.3.1 利用者が掲載等を行ったデータの利用

  1. 利用者は、本サービス等の利用に際して利用者が掲載・表示・送信等(以下「掲載等」といいます。)を行ったデータ(映像・音声・文章・写真・電子メール・メッセージ・アップロードされたウェブコンテンツ、ソフトウェアその他一切のデータをいう。以下同様とします。)につき、当社が、利用(複製、上演、演奏、公衆送信(自動公衆送信における送信可能化を含みます。)、口述、展示、頒布、譲渡、貸与、翻訳・翻案を含み、以下「利用等」といいます。)することを、無期限かつ無償にて、非独占的に許諾します。
  2. 利用者は、利用者が掲載等を行ったデータにつき、当社が自らの判断で、有償・無償を問わず、当社の指定する第三者に対して利用等を許諾する非独占的な権限を、無期限かつ無償にて付与します。
  3. 利用者は、前二項に基づく当社ないし当社の指定する第三者による利用者が掲載等を行ったデータの利用等について、著作者人格権を主張せず、行使しないものとします。
  4. 利用者は、利用者以外の第三者の情報やコンテンツ等の著作物が利用者が掲載等を行ったデータに含まれる場合、当該第三者から利用等の許諾を得、または、当該第三者に著作者人格権を行使させないなど、当社ないし当社の指定する第三者が当該データの利用等を行うについて支障の生じないよう、適切な権利処理を行うものとします。

としています。ここでの「利用者」とは、「本サービス等を利用される方(以下「利用者」といいます。)は、本規約の内容に同意して、本サービス等を利用するものとします。」と定義されています。

これには問題があると私は思いますが、ここにブログを開設しようとする人は登録段階でこの利用規約に同意することになっているので、それはそれでしかたがありません。

「ガイドライン」

ところで、分かりにくいのですが、「利用規約」とは別に「ガイドライン」というものが存在します。

livedoor Blogガイドライン(以下「本ガイドライン」といいます。)は、弊社が提供するサービスであるlivedoor Blog(以下「本サービス」といいます。)のご利用につき、弊社が別途定める利用規約(以下「利用規約」といいます。)とあわせて適用されるものです。よくお読みになられて、本サービスをご利用下さい。

本ガイドラインに規定がない場合、原則として、利用規約の規定が適用されます。本ガイドラインの規定が利用規約の規定と矛盾・抵触する場合、その矛盾・抵触の限りにおいて、本ガイドラインが優先して適用されるものとします。

というものですが、livedoor ユーザーの登録の段階でも、その後の「新しいブログを作成する」段階でも特に注意を喚起されることもありません。

そのガイドラインに次のような節があります。

コメントに関する権利帰属

  1. 利用規約1.3.1(利用者が掲載等を行ったデータの利用)にかかわらず、他の利用者(ブロガー)が管理するブログ内に記載したコメントの著作権は、当該ブログを管理する利用者(以下「ブログ管理者」といいます。)に帰属するものとします。
  2. ブログ管理者が管理するブログにコメントを投稿した利用者(以下「投稿者」といいます。)は、当該コメントを投稿した時点で、当該コメントに関する一切の著作権(著作権法第27条および第28条に規定される権利も含みます。)が、ブログ管理者に譲渡されることを承諾するものとします。
  3. 投稿者は、前二項により譲渡されたコメントのブログ管理者による利用につき、著作者人格権を行使しないものとします。

つまり「ライブドアブログにコメントすると、コメントの著作権はブログ主に」ということになります。さらに、明確にはわかりませんが「利用規約1.3.1」と合わせて考えると、そのコメントをLINE株式会社が自由に利用できることになるようです。

「ライブドアブログにコメントすると、コメントの著作権はブログ主に」は有効か

ブログ主が、ブログ開設(その前のlivedoorユーザー登録)時に「利用規約」に同意しているなら、その内容に問題があるとは言え、利用規約1.3.1はしかたないかもしれません。

「ガイドライン」は、ブログ開設時に特に注意は喚起されませんが、他の項目に紛れて目立たないとは言えフッタなどにリンクがあるし、百歩譲って、ライブドアブログのブログ主はこれを承知していたとしましょう。

ところが、ライブドアブログ(LINE株式会社)とは一切何の合意も交わしておらず、通常の注意力をもってしても「ガイドライン」を目にする機会を与えられない[2] コメント投稿者が、ブログの記事を読んでそのコメント欄に書き込んだ途端、「一切の著作権が、ブログ管理者に譲渡されることを承諾するものとします」というのは、たいへん無理があるのではないでしょうか。

たとえば、コメント投稿者が後になって同じ内容を自分のブログに書いたら、ライブドアブログのブログ主に著作権侵害で訴えられる、という事態もあり得ます。

おまけ

言うまでもありませんが、当ブログ「半月記」へのコメントの著作権は、原則としてそのコメントを書いた人にあります。

  1. 当ブログのある記事が丸ごと転載されているのをたまたま発見し、その転載されているのがライブドアブログ(livedoor Blog)でした。この件についてはまた別に書こうと思っています。
  2. いくつかのライブドアブログで開設されているブログを見ても、コメント欄のまわりにこの点についての注意書きや「ガイドライン」へのリンクがあるものはありませんでした。

自分のグローバルIPアドレスを調べる方法

自分用メモ。インターネット接続プロバイダによって自分に割り振られているIPアドレスを調べる方法。

外部のどこかにアクセスして、そこが接続してきた元のIPアドレスを返してくれる、というサービスを利用するしかない。

次のものはコマンド一発でIPアドレスのみを返してくれるので、スクリプトに組み込むのに便利。

dig whoami.akamai.net @ns1-1.akamaitech.net +short

サーバーを指定しないで試しているとき、たまに間違ったIPアドレスを返してきた。キャッシュされていたものだろうか。サーバーを指定すると、いまのところ常に正しい値が得られている。

HTTP でも同様のものがあって、curl を使って

curl -s http://whatismyip.akamai.com

こちらはIPv6もあるらしく(いま自分では試せない)

curl -s http://ipv6.whatismyip.akamai.com/

Spamhaus に登録されていないか自動で定期的にチェックする方法

メールサーバーを自前で運用しています。その IP アドレスがときどき Spamhaus のリストに載ってしまうことがあります。もちろんこの自前サーバーは Spam 発信源ではありません。

Spamhaus の Blocklist Removal Center にアクセスして確認できます。どうやら自分の IP アドレスを含む xxx.xxx.xxx.xxx/15 が一網打尽にされてしまったようでした。リストから削除してもらうには、そのページから所定の手続きを踏みます。

が、はじめにリストに載ってしまったかどうか気づくのが難しいのです。メールを出しているつもりが相手に届かないという状況はなかなか気づけません(電話をかけて、自分の耳元では「プルルル…」と鳴っているのに実はどこにも繋がっていない状況を想像してみてください。ふつうは、単に相手が出ないとか相手の機器に問題があるとか、とにかく受け手に何か問題があるのだと思い、まさか呼び出してさえいないとは思わないでしょう)。相手先のサーバーからエラーメッセージでも返ってくればまだましなのですが、黙って無視するだけという場合もよくあります。今回はメール以外でもよく連絡をとっている相手に、たまたま別の手段で連絡をとった際に発覚しました。

広範囲のリスト掲載の巻き添えを食らうのは 10年ほどのあいだに2,3回という頻度なので、まさに忘れた頃にやってくるという感じです。上述の Blocklist Removal Center にアクセスして確認すればいいのですが、そうしょっちゅうもやっていられません。

自動的・定期的にチェックする方法はないかと探してみたら、FAQ に How do I check my DNS server results? というのがありました。

自分の IP アドレスがたとえば 203.0.113.50 だとしたら、それを逆さまにして .zen.spamhaus.org を付け足したものを DNS で検索します。

dig +short 50.113.0.203.zen.spamhaus.org

何も返事がなければ、リストに載っていません。

もし 127.0.*.* の返事があれば、リストに載っています(その意味は FAQ の What do the 127.*.*.* Return Codes mean? を参照のこと)。

というわけで、この1行を cron で定期的に実行して様子を見ることにしました。

DoSPOT 設置をあきらめる

ずっとデスクトップ PC の前に座っている生活なので無線 LAN はあまり考えていませんでしたが、最近 Nexus7 を手に入れたので、これまた数年前に入手していた無線 LAN ルーター WN-G300DGR を置いて使ってみていました。まあ特に支障はありません。

そこへ「DoSPOT」の営業の電話がかかってきました。DoSPOT というのは、客側から見ると、時間・回数制限付きの公衆無線アクセスポイントということになります。また、「フレッツ・スポット」のユーザーなら制限なしに利用できます。設置側としては、「Wi-Fi 使えます」と言えますし、「フレッツ・スポット」提供エリアとしてそのページに掲載されるという宣伝効果? が期待できます。またオーナー側に SSID (一般客には公開しない) があり、既存の無線 LAN ルーターに置き換えることができるかなと思えました。月額500円(税抜)ですが、1年間は無料というのでとりあえず OK しました。

LAN 環境

ところで現在の LAN 環境は、LAN 内部に公開サーバーを置いていたり、ネットワーク接続のプリンターがあったりという、単に外につなげればいいというだけではなくそもそも単純ではない状態です。したがって内部向けの DNS サーバーが存在し、これを参照するようにしないと自分のところの Web を内部から見ることができません。

DoSPOT ルーター

しばらくして、担当者が DoSPOT ルーターを持って「工事」にやってきました。が、設置場所の問題だの既存の無線 LAN ルーターを外したりだのややこしかったので、「設置はこちらでやるから」と言って機械だけ置いていってもらいました。DoSPOT ルーターは NEC 製 の MW-3301-R (PDF) というものでした。

さて自分で設置して設定しようとすると、MW-3301-R が上述の LAN 環境に対応できないことが判明しました。

有線 LAN ポートが足りない

まず MW-3301-R には有線 LAN ポートが2口しかありません。一方、既存の無線 LAN ルーターには3口あって、宅内にはそれを全部塞ぐだけの機器があります。増設ならともかく置き換えることはできません。すると今度は(設置場所に)電源の口が足りません。

DNSの設定ができない

MW-3301-R の設定は、それに接続した PC などのブラウザで Web 画面をとおして行います。と言っても設定を変更できるのは、オーナー向け SSID (デフォルトでは「DoSPOT-OWNER」)についてのみ。それについては DNS の設定もできるので、プライマリに内部向け DNS サーバー、セカンダリにゲートウェイ(プロバイダの DNS を代理している)を設定することで事なきを得ました。

ところが、客側が接続する SSID (「DoSPOT-FREE」や「NTTWEST-SPOT」)に関する設定は一切できないようです。DoSPOT カスタマーセンターに電話して聞いてみたところ、はじめは DNS について「オーナー向け設定と連動しているかも」との回答だったのですが、とてもそのような挙動には見えないので強くそのように言うと、数時間後に「再現テストしてみたところ連動しておらず、それらは一切設定変更できません」との回答がありました。

DoSPOT の売り文句

Point 3 店舗や施設の情報をお客様に見てもらえる

  • Wi-Fiを利用する際に店舗ホームページを表示できる
  • 店舗や施設のホームページを紹介

    お客様がDoSPOTを利用される際に店舗や施設のホームページを紹介します。

    同じことを客側から

    Point 3 店舗や施設の情報を確認できる

    • 店舗情報、クーポン、ブログなどをチェック。
    Wi-Fiを利用する際に店舗ホームページで情報をゲット!

    無料ログインの際に、店舗ホームページがある場合は表示されますので、店舗情報やクーポンのチェック、ブログなどが閲覧可能です。

    とあるのですが、これがまったく使えないということになります。

    そのほか残念なところ

    時刻の設定が、再起動のたびに元(1970年1月1日)に戻ってしまうようです。と言ってもログにもこの時刻は使われていません。何なんだろう。

    「DoDPOT-FREE」は暗号なし。うーん、そうなんだ……。

    結局使わないことに

    DoSPOT がまったくダメとは言いません。うちの環境に合わなかったというだけです。有線 LAN のポート数は事前に知ろうと思えば知ることはできました。それを見落としていたのはこちらの落ち度でした。DNS の設定については、実際に試してみるまでわかりませんでした。その手段がまったくないとは思っていませんでした。

    既存の無線 LAN ルーターかまたはそれよりちょっとだけましな、マルチ SSID のできる機器で、ひとつの SSID を自分で客用に設定してやればすむ話です。宣伝効果? は、FREESPOT マップ にでも登録すればいいかもしれません。そもそも Wi-Fi 環境うんぬんで客足に影響するような商売でもありませんし。いずれにせよ無料だからまだいいようなものの、月額料金、電気代(これは微々たるものか)を払って、こちらに何の得があるというのでしょう (いや、そういう形態の商売もあるでしょうが)。しばらく放置して、無料期間が終わるまでに解約することにしようと思います。やれやれ。

    チャットサポートを構築する (その4) 連絡先の設定とまとめ

    【2018年4月20日追記】この記事は内容が古くなっている部分があります。「あらためてチャットサポートを構築する」もご覧ください。【追記ここまで】

    共有名簿 (shared roster)

    ふつうの XMPP では、相手先名簿 (roster) は JID に紐付けられ、サーバーに保持されています。ところが匿名サーバーの場合、接続要求があった際にそのアカウントが新たに一時的に生成されるため、その JID には相手先名簿がありません。そこで、XMPP の共有名簿(shared roster)という機能を使うことにします。

    ejabberd の設定ファイル ejabberd.cfg では

    {modules,
     [
      ...
      {mod_shared_roster,[]},
      ...
    ]}.
    

    とモジュールを有効化しておきます。

    ejabberd のウェブ管理画面の「ヴァーチャルホスト -> anonymous.example.net -> 共有名簿グループ」の画面で、まずひとつのグループを作成します。たとえば

    • 名前: support
    • 説明: サポート窓口
    • メンバー: support@example.net
    • 表示グループ: (空欄)

    のようにします。ここで support@example.net は、窓口側(問い合わせを受ける側)の JID です。

    さらにもうひとつグループを作成します。

    • 名前: all
    • 説明: 全ユーザー
    • メンバー: @all@
    • 表示グループ: support

    ここで @all@ は、「全ユーザー」を意味します。

    これで、「anonymous.example.net の全ユーザーの名簿に support グループのメンバー(ここでは support@example.net のみ)を自動的にセットする」ことができ、上述の(3)をクリアできました。

    チャットサポート構築のまとめ

    ここまでで、どうにかチャットサポートを構築できました。まとめますと、「チャットサポート」に求められる要件、

    1. アプリケーションの事前インストールが不要
    2. アカウント(JID)の登録が不要
    3. 連絡先が登録済み

    に対して、(1)は Converse.js を導入することで、(2)はクッキーを利用し匿名サーバーを設定することで、そして(3)は共有名簿 (shared roster) を使うことでクリアして、一応「チャットサポート」的なものができました。そしてこれらを WordPress のサイトに導入するために プラグイン化しました。試しにこのサイトに設置してみました。画面の右下に小さなタブが見えると思います。

    とりあえずはできたものの、課題も残っています。

    前にも書いたとおり、事前接続のところがよく理解できていないこともあって、匿名サーバーだと使えますが、特定の JID を事前設定しようとするとうまくいきません。また、ページ遷移に対応できていません。

    匿名サーバーの場合、共有名簿を使ってみましたが、多重に読み込んでいるのか、同じ相手先が増殖することがあります。どういうことなのかよくわかりません。また、これは匿名サーバーの宿命なのですが、接続した時点で相手先からは認証されていないので(その時点で生成された ID なので当然)、その相手先の在席状況が不明で「オフライン」と表示されてしまいます。印象が悪いので、WordPress のプラグインではこれを隠すようにしてみました。

    今回、恥を忍んで中途半端な状態でも公開してこのような文を書いたのは、誰か能力のある人がちゃんとした実装を教えてくれることを期待してのことです。XMPP ならまだしも、Strophe.js や Converse.js で検索しても、とにかく日本語での情報は非常に少なく、どこで聞いたらいいかもわからないほどです。

    何かわかる方がありましたら、教えてください。または情報をぜひ公開してください。お願いします。

    チャットサポートを構築する (その3) Converse.js を WordPress で使うプラグイン ConverseJS for WordPress

    【2018年4月20日追記】この記事は内容が古くなっている部分があります。「あらためてチャットサポートを構築する」もご覧ください。【追記ここまで】

    (その1)テストのページに示したように、Converse.js は、css と設定のための script を読みこめば簡単に設置できます。ということは、WordPress のサイトにも設置できます。これを実現するプラグインを作り、公開しました。

    GitHub にも置いています

    Converse.js を同梱しているので、このプラグインをインストールするだけで済みます。

    ダッシュボード -> 設定 -> Converse.js で、主な設定値の変更ができるようにしています。設定値の詳細は Converse.js のマニュアルを参照してください。

    設定項目の最初の Converse.js URL は、空白にすると、プラグイン同梱の converse-min.js を読み込みます。ただのファイル名 converse.jsconverse-no-otr.min.jsconverse-no-locales-no-otr.min.js と書くと、やはりプラグイン同梱のものを読み込みます。外部のものを使いたい場合は、正しい URL を設定してください。

    2番めの BOSH Server URL は、空白にすると、Converse.js が用意しているテストのための https://bind.opkode.im を使います。なるべくほかの BOSH サーバーを指定してください。

    (その2)にも書きましたように、事前接続はまだよく理解していないので、正しい実装ができていません。設定の prebind (事前接続)にチェックを入れ、JID とパスワードを入力しておくと、正しく接続できて名簿も取得できるように見えるのですが、会話ができません。Converse.js の GitHub でのこの議論と同じだと思うのですが、具体的にどうしたらいいかわかりません。詳しい方がありましたら、ぜひ教えてください。下に述べるように、匿名サーバーに接続してチャットサポート的に使うことはできます。

    設定例

    オープンな XMPP クライアント

    初期状態のままで、ふつうの XMPP クライアントのようになります。右下にウィンドウが表示されているはずです。JID とパスワードを入力すれば、そのまま使用できます。

    チャットに使用するアカウント (JID と呼ばれます)を持っていなければ、公開サーバー(たとえば STEP.im)で作ることができます。あるいは WordPress.com のアカウントを持っていれば、name@im.wordpress.com の形で、JID として使うことができます。

    facebook のチャットにも使えます(たぶん)。JID に (ユーザー名)@chat.facebook.com を入力します。facebook はその中で閉じているので、facebook 以外と会話することはできません。

    チャットサポート

    匿名サーバーに事前接続することで、チャットサポートの形にすることができます。

    prebind にチェックを入れます。JID 欄には匿名サーバーのホスト名だけを入れます。パスワード欄は空のままにしておきます。これで、これが設置してあるページを開くと、自動的に匿名サーバーに接続し、IDを割り振られます。

    一応これで使えるのですが、やはり事前接続の正しい理解と実装ができていないので、ページ遷移(WordPressの同一サイト内で別のページに移動した場合)に対応していません。いったん接続が切れて、また新たに接続する(匿名サーバーだと新しいIDになってしまう)ことになってしまいます。詳しい方がありましたら、ぜひ教えてください。

    この項もう少し続く

    チャットサポートを構築する (その2) サーバー ejabberd の準備

    【2018年4月20日追記】この記事は内容が古くなっている部分があります。「あらためてチャットサポートを構築する」もご覧ください。【追記ここまで】

    前回の「チャットサポートを構築する (その1)」は、Converse.js を設置し、(テストのページ)のように、普通の XMPP クライアントとして使えるというところまででした。

    BOSH サーバー

    ここからしばらく、サーバー側の設定の話になります。

    クライアントが Converse.js などウェブベースのもので内部状態を保持できないような場合、BOSHという仕組みを介することで、接続を維持します。XMPP サーバーの ejabberd の場合、設定ファイル ejabberd.cfg次のように書くことで、BOSH サーバーにもなります[1]

    ポート 5281 (HTTPSの場合)を listen するところに http-bind と書き足します。

    {listen,
     [
      ...
    {5281, ejabberd_http, [
           ...
           http_bind,
           ...
           ]}
      ...
    ]}
    

    モジュールの設定のところで

    {modules,
     [
      ...
      {mod_http_bind, []},
      ...
    ]}
    

    を読み込むようにします。

    匿名サーバー

    XMPP サーバーには匿名サーバーという機能を持つものがあります。一般にクライアントがサーバーに接続する場合、事前に登録して作成しておいた user@example.net という形をした JID と、パスワードが必要になりますが、匿名サーバーは、そのサーバー名だけを指定して接続を試みると、@ より前のユーザー名を乱数のようにそのつど生成して接続します。

    サーバーアプリケーション ejabberd の場合、ejabberd.cfg につぎのように設定して SASL 匿名サーバー (anonymous.example.net という名前だとします) を設置します。

    {hosts, [ ..., "anonymous.example.net"]}.
    
    {host_config, "anonymous.example.net", [
                                   ...
                                   {auth_method, anonymous},
                                   {anonymous_protocol, sasl_anon},
                                   {s2s_default_policy, deny},
                                   {{s2s_host,"example.net"}, allow},
                                   ...
    ]}.
    

    s2s_... は、匿名サーバーに接続したユーザーは特定のサーバー以外への通信を禁止するという設定です。

    クライアント側の事前接続

    ここからクライアント側の話です。

    「チャットサポート」として利用できるためには

    1. アプリケーションの事前インストールが不要
    2. アカウント(JID)の登録が不要
    3. 連絡先が登録済み

    であることが必要です。前回はこの最初の項目、Converse.js をごくふつうに設置する(テストのページ)ところまで行いましたが、このままでは客側にアカウント (JID) を入力してもらわなければなりません。

    Converse.js のマニュアルに Server-side authentication という章があります。別の何らかの方法で事前にサーバーに接続しておき、その情報を引き継げば、上述の2番めの項目をクリアできます。接続先を匿名サーバにすればパスワードも不要になります。しかし、マニュアルには具体的な方法はありません。

    次のような方法を考えてみましたがこれで正しいのかよくわかっていません。とりあえず(ある場合には)うまくいっています。もし詳しい方がありましたら、ぜひ教えてください。

    Converse.js の初期設定を書く <script> のところの先頭に書き足します。

    <script TYPE="text/javascript">
    var BOSH_SERVICE = 'https://anonymous.example.net:5281/http-bind';
    conn = new Strophe.Connection(BOSH_SERVICE);
    conn.connect('anonymous.example.net', '', onConnect);
    
    function onConnect(status)
    {
         wpCookies.set('jid', conn.jid);
         wpCookies.set('sid', conn.sid);
         wpCookies.set('rid', conn.rid);
    }
    

    Strophe.js は Converse.js に同梱されているので、Converse.js を利用できるようにしていれば、使えます。接続すると JID、SID、RID が確定するので、それをクッキーとして書き出します。ここでは WordPress の wp-include/js/utils.js を利用した記述 wpCookies.set になっていますが、もちろんそれでなくてもかまいません。

    それに続く Converse.js の設定では

    require(['converse'], function (converse) {
        converse.initialize({
            ...
            bosh_service_url: BOSH_SERVICE,
            prebind: true,
            jid: wpCookies.get('jid'),
            rid: wpCookies.get('rid'),
            sid: wpCookies.get('sid'),
            ...
        });
    });
    </script>
    

    と、bosh_service_url を指定し、prebindtrue とし、jid, rid, sid をクッキーから読み込みます。

    この項まだ続く

    1. BOSH サーバーには2種類あります。local BOSH サーバーは、入り口はどこからでも接続できますが、ローカルのアカウントにしか接続できません。それに対して open BOSH サーバーは、他所のサーバーのアカウントにも接続できます。ejabberd の BOSH は local タイプです。