|

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

対訳: 権利表現 VS 権利強制: AP通信がニュース配信・トラッキング用フォーマットを作り ccREL に言及した件に関して CC がコメント

Rights Expression vs. Rights Enforcement: clarifying the Associated Press story
権利表現 VS 権利強制: AP通信の件について明らかにする

Ben Adida, 2009-08-01

The Associated Press wants to track reuse of their content through a "news registry." This registry "will employ a microformat for news developed by AP":

AP通信は「ニュース・レジストリ」を通じて彼らのコンテンツの再利用を追跡したがっている。 このレジストリは「AP通信によって開発されたニュース用マイクロフォーマットを採用するだろう」。

The microformat will essentially encapsulate AP and member content in an informational “wrapper” that includes a digital permissions framework that lets publishers specify how their content is to be used online and which also supplies the critical information needed to track and monitor its usage.

そのマイクロフォーマットは基本的に AP通信とメンバーのコンテンツを、 コンテンツがオンラインでどのように使われるか公開者が特定でき、 利用を追跡・モニタリングするのに必要な重要な情報を供給する デジタルな許可フレームワークを含む 情報の「ラッパー(wrapper)」内にカプセル化するだろう。

While Creative Commons is very sympathetic to the difficulty of explaining technical concepts in a short press release, we're worried that the AP's explanation, and in particular their reference to the Creative Commons' Rights Expression Language (ccREL), might well be confusing.

CC は短いプレスリリースの中で技術的な概念を説明することの難しさに大きく共感する一方、 AP通信の説明と、特に CC の権利表現言語(ccREL) に関する言及が 混乱していることについて懸念している。

The reference to Creative Commons appears in the AP's microformat, hNews, which introduces hRights, a supposed "generalization" of ccREL. hRights is presumably the "digital permissions framework" that the AP diagrams as a box/wrapper around news content in order to "track and monitor usage." Unfortunately, as Ed Felten points out, this claim doesn't add up. Microformats and other web-based structured data, including ccREL, cannot track, monitor, or generally enforce anything. They're labels, i.e. Post-It notes attached to a document, not locked boxes blocking access to the content.

hRights を取り入れた AP通信のマイクロフォーマット hNews における CC への言及は ccREL の想定された「一般化」のように見える。 hRights は恐らく、 図示されているように ニュースコンテンツを包むボックス/ラッパーとして AP通信が 「利用法を追跡・モニタリング」するための 「デジタルな許可のフレームワーク」 である。 不幸にも Ed Felten が 指摘しているように、 この主張はつじつまが合っていない。 ccREL を含むマイクロフォーマットとその他のウェブベースの構造化されたデータ を使って追跡・モニタリングすることは不可能であり、 一般的に何かを強制するものではない。 それらのデータはラベルである。 つまり、文書に貼られたポストイット・ノートであって、 コンテンツへのアクセスをブロックする鍵の付いた箱ではない。

When Creative Commons launched in 2002, we were often asked "is Creative Commons a form of DRM?" Our answer: no, we help publishers express their rights, but we don't dabble in enforcement, because enforcement technologies are unable to respect important, complex, and often subjective concepts like fair use. Thus, ccREL is about expression and notification of rights, not about enforcement.

2002年に CC を立ち上げた際、 「CC は DRM の形を取るんですか?」とよく尋ねられたが、 それに対する私たちの回答はこうだった: 「いいえ、 私たちは公開者が彼らの権利を表現するのを助けるが、 強制を行うことはない。 なぜなら、強制の技術では フェアユースのように重要で複雑、そして主観的な概念を 尊重することができないからです」 このように、 ccREL は権利の表現と通知には関与するが 強制には関与しない。

And when you think about it, there's really no other realistic way. If the AP actually wants a "beacon" that reports usage information back to the mothership, then every endpoint must be programmed to perform this beacon functionality. Before it delivers content, every server must check that the client will promise to become a beacon. Which means the AP wants an architecture where every cell phone, computer, or other networked device is locked down centrally, able to run only software that is verified to comply with this policy. That's another reason why we don't dabble in enforcement: the costs of Digital Rights Enforcement (or its politically correct equivalent, Digital Rights Management) to publishers, users, to our culture and to our ability to innovate are astronomically high.

そしてそれ(権利などの表現方法?)についてあなたが考える場合、 実際には他に現実的な方法はない。 もし 利用情報を母艦に報告する「ビーコン」を AP通信が欲しがっているなら、 すべての端末はこのビーコンを機能させるように プログラムされていなければならない。 そして、すべてのサーバは コンテンツを配達する前に クライアントがビーコンになると約束することを チェックしなければならない。 これは、 すべての携帯電話、コンピュータ、またはネットワークに繋がったその他のデバイス が集中的に管理され、 このポリシーに従うことを点検されたソフトウェアだけを実行できる アーキテクチャを AP通信が欲しがっていることを意味する。 デジタルな権利強制 (または政治的にはまさに同じものであるデジタル権利管理(DRM))のコストは 公開者や利用者、私たちの文化、イノベーションを起こす能力にとって 天文学的に高い、 というのが私たちが強制に手を付けないもう一つの理由だ。

Then there's the issue of "RSS syndication" compatibility. We simply don't see how the AP's proposed system would allow both widespread beacon enforcement and compatibility with existing formats like RSS. Compatibility means that current RSS tools remain usable. Obviously, these tools do not currently perform the AP's rights enforcement, so how could they magically be made to start phoning home now?

次に、「RSSシンジケーション」の互換性の問題がある。 私たちは、AP通信が提案したシステムが 広範なビーコン強制と RSS のような既存のフォーマットとの互換性の両方を 両立させると 単純には考えない。 互換性とは、現在の RSS ツールが有用なままであることを意味する。 もちろん、これらのツールは現在は AP通信の権利強制を機能させることはできないが、 ではどんな魔法を使えばそれらのツールを使って家に電話をかけられるようになるのだろうか?

That said, there is an interesting nugget in the AP's proposal, one which we encourage them to pursue: tagging content with rights, origin, and means of attribution is a good proposal. When Creative Commons began the work that led to ccREL, there were no established or open standards for expressing this type of structured information on the web, so we had to lay down some new infrastructure. When we published ccREL, we made it easy for others to innovate on top of ccREL: we included "independence and extensibility" as the first principle for expressing license information in a machine readable format. We based ccREL on RDF and RDFa to enable this standards-based extensibility.

とはいえ、AP通信の提案にも興味深くも価値ある部分はあり、 彼らが追跡することを私たちが後押ししたいものがある。 それは権利、出典、帰属の方法とともにタグ付けすることであり、これは良い提案である。 CC が ccREL に至る活動を始めたとき、 ウェブ上のこの種類の構造化された情報を表現するための、 確立された、あるいはオープンな標準は存在していなかった。 そこで私たちは何らかの新しいインフラを作る必要があった。 ccREL を公開したとき、 私たちは第三者が簡単に ccREL の上でイノベーションを起こせるようにした。 機械可読なフォーマットにおいてライセンス情報を表現するために 「独立性と拡張可能性」を第一の原則として含めた。 私たちはこの標準ベースの拡張可能性を可能にするため RDFRDFa を ccREL のベースにした。

The AP could, rather than reinvent a subset of ccREL using an incompatible and news-specific syntax, simply use ccREL and add their own news-specific fields. By doing this, they would immediately plug into the growing set of tools that parse and interpret rights expressed via ccREL. We would be happy to help, but we built ccREL in such a way that we don't need to be involved if the AP would prefer to go it alone. And, of course, the AP can use ccREL with copyright licenses more restrictive than those we offer, if they prefer.

AP通信は、非互換でニュースに特化した文法を使って ccREL のサブセットを再発明するよりもむしろ シンプルに ccREL を使い、 それに彼ら自身のニュースに特化したフィールドを加えることもできただろう。 そうすれば、 何も手を加えずとも、 ccREL を通して表現された権利をパースし解釈する 現在成長中のツール群によって対応することができるだろう。 私たちは喜んでお手伝いしたいが、 上記のようにすでに ccREL を作ったため、 AP通信が独力で行う道を選ぶなら 私たちが関わる必要はない。 そしてもちろん、 彼らが望むなら私たちが提案しているものよりも厳しい著作権ライセンスとともに ccREL を使うこともできる。

Creative Commons License
This work by sonota is licensed under a Creative Commons Attribution 2.1 JP License.
Based on a work at creativecommons.org.
スポンサーサイト

ccREL 日本語訳(カタコト版)

ひととおり終わったので告知しておきます。

途中で三日坊主になるよりは、 機械翻訳と大差ないくらいの品質でも全体を通して日本語になっている方が良いだろうという 方針で作業しました。

残りの脚注の翻訳とともに以後も文章の修正など行う予定ですが、 モチベーションや時間的なリソースなどとの兼ね合いでこのままになってしまう可能性もあると思います。

日本語訳は CC BY 3.0 JP にしておきますので 再配布や改変などが可能です。

置き場所(URL)を将来変更する可能性があります。

参考(外部リンク)

HP mini 1000 + Ubuntu 9.04: タッチパッドのタップによるクリックを無効化 / 横スクロールを有効化

gnome-mouse-properties を実行


「タッチパッド」タブを選択し
「タッチパッド上でのマウスクリックを有効にする」のチェックを外す
「横方向スクロールを有効にする」にチェックを入れる

縦方向スクロールと同様にタッチパッド下部を使った横スクロールができるようになった。

Ren'Py: 画像・音声ファイルなどをアーカイブ化する

通常の手順でパッケージをビルドすると、画像・音声ファイルが丸見えの状態で パッケージが作成されてしまいます。

パッケージ作成の前に以下の手順でデータのアーカイブ化を行うことで、 画像・音声ファイルをひとつのファイルにまとめ、 そのままの状態では画像・音声ファイルを見れないようにできます。


ランチャのメニューで「Archive Files」をクリック

「Include Patterns」で、アーカイブに含めるファイルの種類を指定します。
初期設定では *.png *.gif *.jpg となっており、 画像ファイルだけが対象になっていますので、 例えば音楽もアーカイブに含めたい場合は *.png *.gif *.jpg *.ogg などと拡張子を追加しましょう。

拡張子の追加が終わったら、「Archive」をクリック。
このとき、アーカイブに加えられた元のファイルはプロジェクトフォルダ内の archived フォルダに移動されます。 なので、アーカイブ化を繰り返し行う場合は、オリジナルのフォルダと、それをまるごとコピーした作業用フォルダを作るなどすると多少は手間が省けると思います。

game フォルダ内に data.rpa というファイルができます。 これが、データをまとめたアーカイブファイルのようです。


後は通常の手順どおり、ランチャのメニューから「Build Distribution」を クリックしてパッケージを作成すると、 個々の画像・音声ファイルが含まれず、代わりにアーカイブファイルの入った パッケージが作成できます。

参考(外部リンク)



** ホームに戻る

|
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。