では、プロバイダ責任制限法で課せられた
プロバイダの法的責任とは何なのか。
おおまかに言うと次の通りです。
(1) プロバイダは通信の内容に対して責任を負う必要がない
同法によって、プロバイダは基本的に、
通信の内容に対して責任を負う必要が無くなりました。
これは、プロバイダが通信内容を保障しなければ
ならないのであれば、全通信の内容を監視する義務が発生し
事実上、プロバイダ業務が成立し得ないからです。
(2) 権利を侵害する発信の防止措置に関する義務
プロバイダは、発信によって明確に権利の侵害が
行われていると知りえた場合に、権利を侵害した送信者に対して
権利を侵害する送信の防止措置を講じる義務があります。
ただし、これは、技術的に可能な場合に限ります。
(3) 情報公開の義務
プロバイダは、送信によって権利を侵害されたことが明確、
かつ、被害者が情報を得るに値する正当な理由がある場合に、
被害者に対して送信者の情報を提供する義務があります。
(つづく)
昨日の記事で、著作権の話がでたので、
良い機会なのでぽいにまつわる著作権の話に
ついて書いていきたいと思います。
長い話になるので、小分けでぼちぼち行きます。
認識の間違い等があれば、ご指摘ください。
第1回目は、プロバイダー責任制限法についてです。
プロバイダー責任制限法とは、文字通り、
プロバイダーの責任を制限する法律です。
2002年に制定されました。
ここで言うプロバイダーとは、
自分では情報を発信せずに、情報発信者と受信者を媒介する
アクセスプロバイダーの事を指します。
DTIやOCNといったいわゆるISPがアクセスプロバイダーに該当する他、
掲示板の管理人やブログシステムの運営者も
アクセスプロバイダーに該当します。
これとは別に、自らがコンテンツを提供する、
コンテンツプロバイダというのがありますが、
こちらはプロバイダー責任制限法では保護されません。
USENのGyaOなどは、コンテンツプロバイダに該当します。
「BARギコっぽいONLINE」自体は、単なるシステムなので、
自らは何ら情報を発信しません。
ユーザー間の情報を媒介しているだけなので、
ぽい＝アクセスプロバイダーとなります。
よって、ぽいには、
プロバイダー責任制限法が適用されるわけです。
(つづく)
既存のプレーヤー画面のイメージが強くて、
なかなか自由な発想でデザインできないです。
でも、だいぶマシになってきた気がする。
あとは、ステージ側をどうするか。
畳に座布団でいこうかな？
あんまりかっこよくなりすぎるのも
ぽいっぽくないというか。
>> あと、両端は斜めだから、見にくくて、
>> ３つの画面が一度に動くと目が混乱すると
>> 思うから真ん中の一つだけでいいかも？
一応そのつもりー。左右は動画のサムネイルです。
>>あとは、リクエストできる動画の再生時間の問題とかもありますね～。
そうそう。それもある。
5分～10分ぐらいかなぁと思うんだけど、どーだろ。
それとは別にあらし対策で、
ステージの過半数以上が#skipを実行したら、強制スキップとか、
あると良いかなぁと思ってます。
>> ねえ、この傾向だと著作権の問題でるくね？
そーなんだよねー。これも悩みの種の1つ。
これをはっきりさせとかないと公開できないんだよね。
マッシュアップしたときの責任の所在ってどこになるんだろね？
私が責任をかぶってまで、やろうとは思ってないので、
そこらへんわかる方いたら、情報お願いいたします。
>> 君何様なん？
何、人様の画像勝手につかってんの？という解釈で、
一応、YouTubeの画面にモザイク入れておきました。
他の人からも指摘があったので。
>> それはJASRACと話し合ってるで済ませないでね＾＾
この件に関して、私が得た情報は、
ここで随時報告するようにします。
色々まだ煮詰めないとだめそーだ。
>> Youtubeの動画画面って「ゆがみ」とか「回転」とか
>> の変形できるんですかね（´・ω・｀）
>> そのまま平面に貼ると違和感出そうな
「ゆがみ」とか「回転」はできます。が、
これも悩みどころの一つなんですよね。
背景とのマッチという点では、たしかに②のようにパースをゆがめるのが良いんですけど、
そうすると、動画がとても見にくくなるんです。
こんな感じ。
静止画だから良いけど、これが動くと、軽く酔います。
初期表示が③で、必要に応じて切り替えが出来るってのが良さそうなんですが、
作業負荷が上がりそう＆操作が複雑になりそう、なんでどーしようかと。
①でまず実装して、様子を見つつ②、③を検討するのが妥当かな。
あと、動画は良いんですが、意外と文字が回転できなかったりします。
(フォントを埋め込めばいけるけど、4Mくらいファイルサイズがふくれるので実質不可)
画像処理で無理やり表示できないこともないんですが、どうもくっきり斜めにならない。
あと、それとは別に、どこまでリアリティを出す必要があるのか、ってのもあります。
うちはいわゆるチャットなので、コミュニケーション機能以外を強化しすぎるのも、
逆にマッチしないかなと。
完全にパースを合わせたいならSecondLifeみたいに3Dにすべきだし。
でもチャットに3Dってあんまり必要ないですよね。
機能重視か、見た目重視か。
まーバランスの問題なので、適度にかっこ良い感じで実装できればなと思ってます。
とかいいつつ、こないだFlashの3Dを解説してる本買ってきましたが。
>>しっかしまあギコぽいもどんどん進化してきてますなぁ。
>>これで登録なし無料とは最強サイトじゃないっすか。
椅子固定で動けなかった頃にくれべればずいぶん進化してきましたねぇ。
でも進化しても、開発陣が何ら得することが無いという罠
鯖代くらい捻出できると良いんですけどねー( ´ω`)
>>つまり、鰻道の先に実装されるんですね。
>>わかります。
鰻道の先は、神社で人工知能置こうと思ってます。
全然開発進んでませんが。
YouTube画面をどこに置くのかってのも悩みますね。
>>でも軽くしないと入れなくなる気が。
働いてPC買い替えですね。わかります。
ご意見もらえると喜びます。
開発中のスナップショット。
#request YouTubeのビデオID
でユーザーのリクエストを表示する方向で実装してます。
リクエストされたビデオが、
ステージ上の全ユーザーに配信されるような感じ。
配信といっても、YouTubeのビデオを
クライアント側でロードしてもらうだけなんだけどね。
※ リクエストは最大5件まで。
※ 一定間隔を置かないと再リクエストは不可
既に600～700行近くのコードを追加してるけど、まだ完成は遠い感じ。
・プレーヤーの制御
・荒らし対策(#skipでリクエスト強制スキップ)
・BINDの実装見直し
・リクエストの仕様がイマイチ(今の仕様だと1ワールド1箇所しか配置できない)
などなど未消化事項やまもり。
7月いっぱいで更新できればいいかなーと思ってます。
>>なんかニ●ニコ国際映画祭みたいなことが
>>できそうですね。
ニ●ニコ国際映画祭を見たことないのですが、
●コニコのリアルタイム版みたいなもんですね。
まあ、YouTubeのテストプロジェクトでTestTubeってのがあって、
大分前から似たようなことやってるんですけどね
(全然流行ってないけど)。うちのコレも需要あるのか謎。
>>何か違和感を感じますな。
>>無理をいいますが、新しいステージに画面を入れれる場所
>>(渋谷だか新宿だかのビルに埋め込んであるTVみたいな)に
>>クリックできるところを作ってクリックすると動画が
>>見れるとかだといいですね。
正直、これを配置するステージは悩んでます。
マクロスフロンティアっぽく、空中にぽこっと浮いてるのも良いかなとか
思うんですが、一方でぽいの売りである昭和っぽさも大事にしたくて、
そこらへんジレンマ感じてます。
既存のビデオ配信とかはパネルで実装してあるんで、
ステージの雰囲気とはあまり関係ないんだけれど、
今回はステージの部品として組み込むので、
表現の仕方が難しいところです。
前に誰か言ってた電脳コイルでも参考にしてみようかなぁ。
渋谷は、ぽいが見下ろす視点なんで、実装しにくいかも。
>>なんか街角TV邪魔になりそ
一個前の記事は、適当に配置してみただけなんで、
本番はああはなりません。
>>コレってレナじゃん！？
レナですね。
>>俺的に水色の椅子がとても気になる
スケベ椅子です。
>>映画館ステージを作ってそこでランダムで再生すればいいのでは！？
レトロな映画館に配置って選択肢はありかもしれませんね。
ランダムってのはチと味が無いかなぁ。
ただし、リクエストがないときは、YouTubeの人気Top100とかを流す、
ってのは考えてます。
ご意見おまちしとります( ´ω`)
最新ニュースを自動収集するサーバープログラム完成。
cronに登録してテスト稼動中。
perlで書いたけど、CPAN便利だよね。
XML::RSS使って、30分くらいでできた。
このデータをFlashサーバーで読み込んで(1分おきで)
変数に格納すれば、OnBind()で、ぽいの素材に表示できるはずー。
最新ニュースTop100くらいからランダムで1個表示するようにすれば、
適度に飽きないニュースが表示できそうだよね。
マッシュアップ万歳。
これって、データが公開されてれば、
株価とか地震情報とか、天気予報とかも作れそう。
まーウチはチャットだから、目的はあくまで会話のネタの提供なんだけど。
こうなってくると、情報提供用のステージがほしくなるなあ。
電光掲示板だらけの近未来っぽいの。
漫画のBLAME!みたいなメガストラクチャ的なのってかっこいいよね。
でも昭和っぽいのも捨てがたい。
ああ、ちゃぶ台に、電光掲示板とかかっこいいな。
OnBind()はSetする方が未実装だけど、こっちが完成したら、実装予定。
googleのAJAX Language APIってので各国語の翻訳ができるみたい。
これも何年か前から案があったんだけど
ようやく実現できそう。
#translate Japanese
を実行すると、
Fatty: Hellow(こんにちは)
みたいに自動的に翻訳できるといいな。
Flashで実装できるみたいなんだけど、資料みてもよくわからん。
JavaScriptかまして実装するかも。
(最近、Google APIの資料が日本語化されたんだけど、肝心なところは全部英語(´ﾟёﾟ`)
昔はそうでもなかったんだけど、最近英語の仕様書読むのが苦痛だ。
コンピュータの世界って、少しディープなとこにいくとドキュメント全部英語だよね。)
なんにせよ、開発さぼってる間に、
インターネッツの世界は大分進歩してきたよーだ。
でも、酒のみすぎたので、今日は寝る( ´ω`)Zzz
何年も前から実装しようと思ってたんだけど
素材から直接サーバーデータにアクセスできるように改造中。
今までサーバー上のデータを共有する仕組みは
管理人の私しか実装できなかったんだけど、
開発陣でもそれを出来るようにしてみた。
具体的には、
① マップXMLでbind="サーバー変数名"を追加
bindは繋げるとかそういう意味。
これでマップ上のオブジェクトと、サーバー変数を繋げる。
② 素材のASにデータを受け取ったときの処理を追加
こんな感じ
function OnBind( ipValue )
{
(データを受け取った時の処理)...
(例えば受け取ったテキストをTextFieldに表示とか)...
}
※ この関数はサーバー変数が変更される度に自動的に呼ばれる
③ 素材のASでデータを設定する処理を追加
SetBindVariable( "値" );
※ これでサーバー変数の値が変わる(=OnBindが自動的に呼ばれる)
この機能を使えば、素材レベルで、
プチ対戦ゲームとか、掲示板とかお絵かき板を作れるはず。
| 03 | 2024/04 | 05 |
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |