2006-09-21

■

EncryptedXmlにハマって仕事が進まない。まいっちんぐ。

2045年の著作物利用権

id:inflorescencia:20060919から:
http://slashdot.jp/comments.pl?sid=333061&cid=1023171

…特に、CCライセンスに時限設定の選択肢を付加するという話を聞いたことがあったので、今後それが実現されるかお尋ねしたいと思います。
私としては、例えば「1年目はby-nc-nd、2年目からはby」などと設定ができればCM等の分野でもCCライセンスの利用が広がる可能性が高いでしょうから、導入していただきたいと思います。
しかしどうやって実装するかが技術的課題だと以前指摘されていました。この話題を聞いてしばらく経ちますが、導入予定はあるのでしょうか。

エラい、エラすぎる。良い質問を考えられましたな。この辺は聞いてみたいなあ。

時限付きのCC設定の例として、inf.さんは時間経過とともに制限が緩やかになる方向を例示しているのだけど、実質的にはこれは期限付きライセンスの問題ではなかったりする¹。1年後により緩やかなライセンスで発行すれば良いだけの話で、現在発行されているライセンスに変更を加える必要は無い。問題はむしろライセンスがより制限的になる場合だ。

たとえば、「この楽曲は50年間cc-byで提供する。その頃私はこの世には居ないだろうから、その後は権利者の意思次第だ」みたいな形で年限の付いた楽曲があって、それを使用して作られた映画があったとする。50年後、その映画の権利料をもとに日々の生活を営んでいる作者のもとに、その楽曲の権利者がやってきてこう言う。「お前の利用権は失効した。ただちに映画の公開を中止しろ。許諾は一切しない。」

映画の作者はもう50年もフリーで提供されていたものが、今さらになってフリーでなくなるなんて、想像もしないことだろう。

こういう話が社会問題になってくると、ではとりあえず20年の暫定利用許諾期間をおきましょう、とか、そういう妥協的な解決が図られることになるかもしれない（って、不動産の賃借権かっつーの）。2045年²になっても現行著作権システムがまだ影響力を持っているとしたら、それはそれで哀話だ。

話がおもいっきり横道(?)にそれてしまった。

そんなわけで、時限などの条件付きCCを実用可能にするには、ライセンスが存在するだけでは足りなくて、複合著作物のソースリストに基づく保護期間の計算みたいなのも簡単に出来なきゃいけないんだろうな、と思うところです（条件は最小限度の個数でモデリング出来る必要があって、extensibilityは一切考慮すべきではないでしょう）。でもそれ以前にCC複合著作物の構成を表現するデータ構造みたいなのが必要だっていう気もしてきた。

CCはあまり複雑な技術的ソリューションを必要としないように作られているのがひとつのメリットなんだよね。今のところ作品、作者、許諾条件の3要素で事足りているわけだし…

着せ替えマウス

http://slashdot.jp/articles/06/09/21/0048225.shtml

言われるまで気付かなかったけど、これあまこる（mono meetingの会場）じゃんよ。つか多分作ってるのも現物も見てたわ…

ちなみに萌え産業とか言われてますが、作者はまともな人で、そんなこと夢にも考えていないと思います。そんな言葉がそもそも通じないかも。

PythonSpeed

matzにっき経由。
http://newworld.ddo.jp/wiki/PythonSpeed

PythonでもRubyでも通用する高速化³のテクニックは、実のところMonoでもだいたいは通用します。まあ、高速化のテクニックっていうのは、対象バージョンによってかなり変わるものなんだけど。

関数の中で、ローカル変数はグローバル変数、組込み定数、属性の参照より高速にアクセスされます。そのため、内部ループの中に局所化したローカル変数へアクセスするより遅くなることがあります。例えば、 random.shuffle()というコードを random=self.random という1文で局所化します。これによってshuffleのループがself.ramdomを何度も参照するのを防ぎます。ループの外側で、向上率は非常に小さいかまれに悪くなることもあります。

この辺は現行バージョンのMonoだとどうかな。conspropがあってregallocが無いので、むしろ局所変数代入の分だけ遅くなるかも。CPythonにregallocがあるかどうかは知らないけど。

思いつきで書いてるだけなので、やってみれば分かる気もする。