  |
はてなキーワード: commonsとは
レンゲの有用性
レンゲはセイヨウミツバチの良い蜜源となるため、多くのはちみつがレンゲの蜜から作られています。また、マメ科植物であるため、前回の記事で詳しくお話した窒素固定を行うことができます。そのため、水田の肥料（緑肥）として利用することができ、水田の休閑期に見られる一面のレンゲ畑は緑肥のために栽培されていることが多いです。
レンゲによる緑肥の利点
レンゲ畑
レンゲ畑
レンゲを稲を植えていない時期に植え、成長させて窒素をたくさん取り込ませたところで、植物体ごと土の中にすき込みます。これにより、化学肥料を与えずに窒素分を田んぼに供給することができます。化学肥料は手軽に安く利用できる反面、問題点もあります。耕作地に撒かれた化学肥料の50％くらいが利用されずに土壌から流れ出し、川や海の富栄養化に影響すると言われています。また、化学肥料だけを土壌に与えていると土壌に住む微生物やミミズを代表とする土壌動物の餌が不足し、生息しにくい環境になります。そういった生物が居なくなると、土が硬くなり、植物も生育しにくい土壌になると考えられています。有機物を土壌に与えることは、土壌が劣化してしまうのを防ぐのに欠かせません。レンゲによる有機肥料を用いた農法は化学肥料を使用するよりも知識や技術が必要になりますが、持続的な田んぼの利用や周囲の環境への影響を考えると、良い手法であると考えられます。
レンゲ畑の減少
レンゲの栽培は、1960年代以降に急激に減少しました。その原因は、稲の苗を植える時期が早まり、レンゲの栽培時期と重なるようになったことや、化学肥料を容易に使えるようになったこと、農家が家畜を飼わなくなり、その飼料としてレンゲを栽培することがなくなったことが挙げられます。また、アルファルファタコゾウムシ Hypera postica というレンゲの害虫が1982年に海外から侵入し、九州から西日本に広がり、開花前のレンゲが全滅するという被害がおこりました。
アルファルファタコゾウムシ Photo by AfroBrazilian, CC BY-SA 3.0, via Wikimedia Commons
これに対し、日本では、生物的防除として1988年からタコゾウチビアメバチというアルファルファタコゾウムシの天敵がアメリカ合衆国から導入され、2006年までに福岡、熊本、大分、山口、岡山、兵庫、岐阜で定着したことが確認されました。それらの地域では、アルファルファタコゾウムシのレンゲへの被害が減少してきたことが報告されています。しかし、生物的防除は、外来種を積極的に導入する方法であり、在来種にどのような影響が起きるのか想定することが難しく、非常に危険な手法です。生物学的防除として沖縄に導入されたマングースは、結局目的の生物が駆除できず、むしろ在来種に多大な影響を与え、しかも、一度広がったマングースを駆除するのも困難な状態になっています (沖縄のマングースについて1, 沖縄のマングースについて2)。幸い、今のところは在来種への影響は明らかになっておらず、レンゲへの被害は減少しているようです。
近年は、2015年から施行された「農業の有する多面的機能の発揮の促進に関する法律」で、緑肥を行う農家への国からの支援も行われるようになって来ました。レンゲ畑、復活の兆しが見えてきたのかもしれません。
なぜ中世の人々はこんな破廉恥な彫刻を作ったのか。主に2つの説がある。1つはやはり子授祈願だ。日本でも「子宝の石」やら「子授け岩」なんてものが各地にあるように、触れることで子宝を授かると期待する。これの根拠としては、彫像の陰部が特にすり減っているものが多いためだ。長い間、多くの人々が撫でてきたせいである。
もう1つの説が人魚に通じるものであり、こちらは「魔除け」を期待したものだという。その根拠は2つ。まずはシーラ・ナ・ギグの設置場所である。教会ではアーチの中央最上部、すなわち要石にあることが多い。これは魔除けとして一般的な位置であり、上で紹介したハドリアヌス神殿のメデューサもそうである。もう1つの根拠は、古来より女性が陰部を見せつける行為には、魔を払う効果があるとされているからだ。
Charles Dominique Joseph Eisen, Public domain, via Wikimedia Commons, Link
例えば古代エジプトでは、女性が陰部を畑に対して晒す風習があった。これによって畑から悪霊を追い出し、収穫が増えることを期待してのことだ。また、エジプト人はブバスティス祭では、舟が街に近づくと、女性たちは服を頭の上までまくりあげて陰部を晒したという。これを見たヘロドトスはカルチャーショックを受け、その行為に「アナ・スロマイ」と名付けた。
ヘロドトスは知らなかったようだが、アナ・スロマイがあるのはエジプトに限った話ではない。例えばカタルーニャには「女陰を見せれば海が鎮まる」ということわざがあり、漁師の妻が夫を海に送り出す際に陰部を海に見せるという習慣がある。ロシアの伝承では、若い女性がスカートをまくりあげることで、クマを追い払えるという。
投票率が低いという話を聞くと、「コモンズの悲劇」を思い出す。
コモンズの悲劇（コモンズのひげき、英: Tragedy of the Commons）とは、多数者が利用できる共有資源が乱獲されることによって資源の枯渇を招いてしまうという経済学における法則。
中略
たとえば、共有地（コモンズ）である牧草地に複数の農民が牛を放牧する。農民は利益の最大化を求めてより多くの牛を放牧する。自身の所有地であれば、牛が牧草を食べ尽くさないように数を調整するが、共有地では、自身が牛を増やさないと他の農民が牛を増やしてしまい、自身の取り分が減ってしまうので、牛を無尽蔵に増やし続ける結果になる。こうして農民が共有地を自由に利用する限り、資源である牧草地は荒れ果て、結果としてすべての農民が被害を受けることになる。
——————引用ここまで。
つまり、個人レベルで行動を最適化すると、集団レベルで良い結果にならないことがある、という話だ。
専門的な言い方を許してもらえれば、自然選択とはごく限られた場合を除いて、個体または遺伝子のレベルにかかるものなので、集団にとって有利なことでも、個体にとってコストなら進化し得ない。
投票率の話に戻す。
お金はかからないが、投票先を選んだり、並んだり、時間的なコストは絶対にかかる。
また、重要な点として、このコストは個体レベルにかかっている。
一方で、投票すると言う行為によって得られるメリットは集団レベルのメリットであり、
個体レベルで見たとき、コストをペイできるだけのメリットがあるとは言い難い。
もちろん、ひとりひとりの投票がひとりひとりにとって重要な意味をもつという主張は正しいが、あくまでそれは集団レベルの話。
個体の行動を最適化すると、むしろ投票に行かないことが合理的であるように思う。
---
では、どう改善していくか。
こうした人たちに投票の集団レベルの意義を説いても意味がない。
あくまで個体レベルで議論しないと、聞く耳すらもってくれないだろう。
叩かれることは大きなコスト、それも個体レベルのコストなので、投票に行かないコストが、投票に行くコストを上回り、投票に行く方が合理的になる。
ただ、これには大きな落とし穴がある。嘘をつけばいいのだ。
すなわち最適な行動は、「投票に行かずに、行ったと主張すること」になる。
逆に言えば、嘘をつけないシステムを作ればそれでいい。
ラーメンチェーン店の一風堂は、投票済証明書を提示した人を対象に、替玉一玉もしくは半熟塩玉子をサービスするという「選挙割」をおこなっている。
タピオカドリンクを販売するTapistaでは、ドリンクが半額になる。
意外とこのようなサービスを実施する企業は多いし、増えてきているように思う。
とくに、鉄道や携帯会社など、インフラに近いサービスを提供する企業ほど、こういうことをすると効果的だろう。
実際には、投票に行かない人にもちゃんと周知させる必要があったり、さまざまな問題があるは思うが、個人レベルでのメリットを上げることができれば、投票率は上がる。
---
投票するという行為に伴う個人レベルでのコストと天秤にかけることが重要である。
最後に話は逸れるが、投票率を上げることと、国政を正しく導くことは、必ずしも同義ではないと思う。
そもそも個人の考えと支持者の考えが完全にマッチすることはかなり稀なはずなので、政策ごとに国民の意見を反映できる別のシステムを作るのも重要だ。
語源の楽しみ。家にいて、そこらへんにある言葉を拾うだけでいろいろ考えた気になる。暇なときに最適な楽しみである。
たぶん、それで得られる思索は、ほんとに言語学とかやっている人には当たり前のことなのだろうけど、まあ趣味ですから、許してほしい。逆にそういう専門の人の面白い語源の本もまた好みである。
アメリカ上院はSenate。この語源はラテン語Senatus、すなわちローマの元老院。その単語をそのまんま使っているということに僕は衝撃を受けた。つづりの違いは言語の違いに過ぎないから、たぶんアメリカ人は学校の歴史の授業で、ローマの歴史を学ぶ時とアメリカ合衆国の政治機構について学ぶ時に同じ単語Senateをもとに学習しているわけである。そこに歴史の一貫する深い流れを感じ取ることが、感覚としてあるのではないか。ちなみに下院はHouse of Representativesで、一般名詞で形成されている。
ところで、どうしてこのように名付けたのだろう。
たぶん、アメリカ民主主義が、設立当時はイギリスよりもフランスを継承している意識が強かったことに由来しているのだろう。イギリスは、貴族院と庶民院（下院）であって、それぞれHouse of LordsとHouse of Commons。それに対し、フランス上院と下院は、SénatとAssemblée nationaleであり、上院には同じ単語を使用している。フランス上院のことは日本語訳でも直接的に「元老院」の訳語をあてることもあるようで、Wikipediaはそうしている。単語としては同じなんだからアメリカ上院も時には元老院と呼んでもよさそうだ。
アメリカ上院議員はSenator。オバマ大統領が大統領選を戦っているとき、「Senator Obama」とよく呼ばれていた。
このときこのひびきは通常の日本語訳では「上院議員オバマ」であるが、原語では「元老院議員オバマ」と同じものなわけであり、これはつまり歴史を好むアメリカ人にとっては「元老院議員カエサル」と同じ響きをもって伝わっているのだろう。ここがうらやましい。
明治維新が起きてすぐのころ、明治4年の制度では正院の長は太政大臣であり、三条実美が就いていた。過去の太政大臣と言えば、藤原道長であり、平清盛であり、当然のことながら、豊臣秀吉である。なんで「太政大臣」の名前を廃したのかな、と残念に思うところ。
もちろん、より有名なところ（だが現在には継承されていないもの）として、ドイツ皇帝「カイザー」、ロシア皇帝「ツァーリ」は、それそのものがローマ皇帝または副帝の称号「カエサル」を引き継いでいる。
こういうのを見ると、欧米では歴史が単語レベルで地続きであることが多いのだなと思う。しかしもちろん日本でも、大連（おおむらじ）と大臣（おおおみ）の権力争いの末大臣家が勝ち残ったことが、現在でも内閣の大臣の名称に残っていることなどは、語源から歴史の深みを感じるところではあるのだ。
原文：https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread
原題：Apache Commons statement to widespread Java object de-serialisation vulnerability
翻訳日：2015年11月12日（午後にタイトルを日本語にしました）
－－－－
Apache CommonsのJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント
著者：Bernd Eckenfels（コミッター）, Gary Gregory（Apache Commons副責任者）
AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときのセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクト・シリアライゼーション（訳注：seriarization／シリアル化／直列化＝ネットワークで送受信できるようにメモリ上のオブジェクトデータをバイト列で吐き出すこと。シリアル化されたJava オブジェクトはRMIなどのリモート通信プロトコルで使用される。）を使用する際に任意のJava関数の実行や操作されたバイトコードの挿入さえもを行う方法の説明です。
Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereやJBoss、Jenkins、WebLogic、OpenNMSといった様々な製品を調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオを記述しています。
両者の調査活動は、開発者がJavaのオブジェクト・シリアライゼーションに信頼を置きすぎていることを示しています。認証前のシリアル化されていないオブジェクトにも。
Javaにおけるオブジェクトのデシリアライゼーション（訳注：de-serialization／非直列化＝ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと）が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効なオブジェクトツリーだけを保証しています。
不幸にも、型のチェックが起こるまでの間に既にプラットホームのコードが生成されて、重要なロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者のコントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまいます。脆弱性のあるアプリケーションのクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は（ローカルのOSのコマンドを実行するRuntime.exec()の呼び出しを含めて）機能を実行することができます。
これに対する最も良い防御は、信頼されていないピア（通信相手）とは複雑なシリアル化プロトコルを使うことを避けることです。ホワイトリストのアプローチ http://www.ibm.com/developerworks/library/se-lookahead/ を実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができます。しかしながら、これは常にできることではなく、フレームワークやアプリケーションサーバがエンドポイントを提供しているような時にはできません。簡単な修正方法がなく、アプリケーションはクライアント・サーバプロトコルとアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。
これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムや Springフレームワーク、 Apache Commons コレクションからのクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン）を見つけています(訳注：provided)。これはこの脆弱性のエクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日、攻撃者が簡単に得られるチェーンです。
(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c
この脆弱性のために利用される(訳注：blamed)ことができない確かな機能を実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的に修正していくことが要求されます。モグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。
Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題に対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています。議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能を提供するかどうかです。
これには前例があります。Oracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャーが定義されているとデシリアライゼーションを拒否します。
これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできます。Apache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャーの存在と独立したこの機能を無効化することを計画しています。
しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンの Apache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。
このブログポストのレビューのために Gabriel Lawrence に感謝したいと思います。
Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラスを提供する Java ライブラリです。InvokerTransformer はコレクションにあるオブジェクトを（特にリフレクション呼び出しを通じてメソッドを呼び出すことで）変換するために使うことができる Transformer ファンクションインターフェースの実装の一つです。
一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]
コメント：
Oracle は Weblogic にセキュリティアラートを発行しています：
あなたのスマホにある写真を、ちょっとだけ役立ててみませんか?
最近、Wikipediaを運営しているWikimedia財団から、iOS(iPhone、iPod touch、iPad)およびAndroid向けに「Wikimedia Commons」なるアプリがリリースされました。これは、Wikimedia Commonsというサイトに写真をアップロードするためのアプリです。
iOS: https://itunes.apple.com/us/app/wikimedia-commons/id630901780?mt=8
Android: https://play.google.com/store/apps/details?id=org.wikimedia.commons
英語のリリースアナウンス: http://blog.wikimedia.org/2013/04/29/announcing-the-official-commons-app-for-ios-and-android/
アプリの説明の前に、簡単に前提の解説を。Wikipediaに写真がたくさんアップロードされていることは見ている人ならご存知かと思います。これらの写真は「Wikimedia Commons」というサイトに一括して集められ、ここの写真をWikipediaの日本語版や英語版、その他姉妹プロジェクトで使えるようにしています。ここに一枚に写真をアップロードすれば、様々なプロジェクトで一度に利用可能なのです。
そして、このアプリを使うと、スマートフォンで撮影した写真や、過去に撮影した写真を簡単にアップロードできます。使い方は、以下の通り。
ちょっと面倒ですが、まずはWikipedia日本語版でアカウントを作成してください。このアカウントは、全ての姉妹プロジェクトで使い回せます。もし既に持っている場合は、ここは飛ばしてください。
スマホで、アプリを選んで、インストールしてください。アプリを立ち上げると、アカウントを求められるので、上記で作成したものか、既に取得しているアカウントでログインしてください。
写真は、その場で撮影するか、スマホのアルバムの中から選択できます。
ご存知かと思いますが、Wikipediaは、データを複製したり改変したりすることができます(これは、いわゆる「著作権フリー」とは違うので、ご注意を)。写真も同様で、著作権上の問題の無いことが前提になります。従って、漫画の一ページや、CDのジャケット、ゲームの画面などは利用できません。自分の家庭内のものか、公道から撮影した写真を使ってください。
基本はどんな写真でも構いません。ただ、知人らが写っているものは、肖像権の問題などを考えると、ちょっと面倒かもしれません。大まかに推奨するものは、
といったものでしょうか。
写真を選択すると、「タイトル(iPhoneだと「タイ…」と省略されています)」「説明」と書かれた入力欄が出てくると思います。ここに、アップロードする際の名前を、説明文を書き入れます。
Wikimedia Commonsは、いわゆるWikiサイトなので、既に名前が使われている場合は、その名前を使うことができません。なので、面倒ですが、できるだけ一意になる名前を使ってください。決めるのが難しい場合は、撮影日を入れるなどすれば良いでしょう(例:富士山_20130507)。
説明文も同様に、入力してください。
いわゆる普通の写真共有サービスではないので、ちょっとだけ注意事項があります。
というわけで、面倒なことこの上ないけど、もしお暇なら、手元のスマホの写真の一二枚をあげてくれると、みんなでより良いアーカイブができると思います。ほんの5分、お手伝いくださいな。
JRuby上で動くRubyとJavaのログを同じファイルに保存したいときなど
JRuby界隈で何かいい方法ないかな～と探していたけど見つからないので
RubyのLoggerのインターフェースをcommons-loggingを使用して実装してみた
使用バージョンは以下
require 'logger' class CommonsLoggingLogger def initialize(name="ruby") @progname = nil @logger = org.apache.commons.logging.LogFactory.getLog(name) end def add(severity, message=nil, progname=@progname, &block) if message.nil? and block_given? message = yield end case severity when Logger::DEBUG debug(progname){message} when Logger::INFO info(progname){message} when Logger::WARN warn(progname){message} when Logger::ERROR error(progname){message} else fatal(progname){message} end end def debug(arg0=nil, &block) @logger.debug make_log(arg0, &block) end def info(arg0=nil, &block) @logger.info make_log(arg0, &block) end def warn(arg0=nil, &block) @logger.warn make_log(arg0, &block) end def error(arg0=nil, &block) @logger.error make_log(arg0, &block) end def fatal(arg0=nil, &block) @logger.fatal make_log(arg0, &block) end def debug? @logger.isDebugEnabled end def info? @logger.isInfoEnabled end def warn? @logger.isWarnEnabled end def error? @logger.isErrorEnabled end def fatal? @logger.isFatalEnabled end def level if debug? Logger::DEBUG elsif info? Logger::INFO elsif warn? Logger::WARN elsif error? Logger::ERROR else Logger::FATAL end end def level=(lv) #do nothing end def sev_threshold level end def sev_threshold=(lv) #do nothing end def datetime_format nil end def datetime_format=(fm) #do nothing end attr_accessor :progname private def make_log(message_or_progname, &block) if block_given? progname = message_or_progname || @progname message = yield else progname = @progname message = message_or_progname end progname_message(progname, message) end def progname_message(progname, message) progname.nil? ? message : "#{progname}: #{message}" end end
もしかしたらこうなるかもしれない未来。
「ジーク・サイバー！ --- 或る学者の演説」を読みながら、こんなことを考えていた。以下は創り出した未来予想図。こういう演説をもし実際に聞くことができるなら、Think Cの演説よりもっと興奮できる未来が、あるのかもね。たとえばこんな感じ。
ネットワーカーの国際組織 The World EFFと世界規模の主要な通信キャリア、家電メーカーなどは、WIPOに働きかけ、カリフォルニア州バークレイ市において、ベルヌ条約の全面改正を討議する国際会議を20XX年に催した。ここにおいて成立したのが、「20XX年の改正ベルヌ条約 (正式名称 20XX年のバークレイ条約)」。旧ベルヌ条約の根幹である「著作権はすなわち創作者の権利である」というドグマを捨て、創作者本人の知的労働の権利保障を中心とする第一部、文化の発展のための権利調整を中心とする第二部、商業利用される著作物の保護制度を中心とする第三部からなることが、大きな改正点である。
「ニュー・コモンズ」と発音する。Free Software Foundation (FSF) が200X年にリリースした、P2Pテクノロジーと利用者相互のコンテンツ・スクリーニングを組み合わせた情報の自由流通ネットワーク・アプリケーションの名称、およびそれが形成するオーバーレイ・ネットワークを指す。発表当時から、そのファイル転送の効率性と民主的なスクリーニングがネットワーカー達の熱狂的支持を集めたが、ただちに各メディア企業、とくに映画産業と音楽産業からの訴訟攻撃に直面し、ついに20XX年 米国最高裁判所において、著作権の間接侵害が認定され違法化された。さらに各国裁判所も同判決に追随し、主要先進国の大部分においてGnu-Commonsは違法化された。
これらの判決に反発奮起したネットワーカー達によって、関係団体への不買運動および猛烈なロビイングが開始された。さらに判決において著作権の間接侵害と指摘されたソフトウェア部分の改修改善が急ピッチで進められた。ロビイングが奏功して、20XX年に開始されたベルヌ条約の全面改正作業と平行して、Gnu-Commons の改修も進められ、Gnu-Commons Ver.3において、改正ベルヌ条約完全準拠のファイル共有ネットワークとして運用が開始された。以下の演説は、総統によって提唱された、条約や法律のオーバーレイ(上書き書換え)と、オーバーレイ・ネットワーク・テクノロジーによるコンテンツの自由流通の実現を目的とした、世界の著作権枠組みを一変させる運動、通称「オーバー・レイ作戦」の成功と、Gnu-Commons Ver.3 リリース祝う祝賀演説として配信されたものである。
我が忠勇なるネットワーカーたちよ。今や著作権絶対主義者どもが主張する"永久の知的財産"なる概念は「改正ベルヌ条約」の発効と「Gnu-Commons」のリリースによって完全に否定された。これらの成功の輝きこそ我らネットワーカーの正義の証である！
決定的打撃を受けた著作権絶対主義者の主張に いかほどの正当性が残っていようと、それはすでに形骸である。
あえていおう！力スであると！
知識は、我らのもっとも効率的な情報流通ネットワークたる「Gnu-Commons」によって流通伝達されて、はじめて最大限の自由と、最大限の効率と、最大限の幸福を達成することができる。これ以上、知識を独占させては、人類そのものの存亡に関わるのだ。
それら既得権者の集団が、金の力で「改正ベルヌ条約」を覆し、訴訟により「Gnu-Commons」を違法化することはできないと私は断言する。著作権絶対主義の無能なる者どもに思い知らせ、明日の未来のために、我らネットワーカーは立たねばならんのである！！
Inspired by Gihren Zab and GeetState
Special thanks and deep respect to...
Adolf Shirater http://orion.mt.tama.hosei.ac.jp/hideaki/indexj.htm
Lawrence Lessig http://blog.japan.cnet.com/lessig/archives/003976.html
Thank you for reading this speech...
No copyrights reserved.
Please feel free to copy and paste this speech anywhere you want.
Please feel free to create any kind oｆ stuff, like flash, picture, novel ,so on.
どうも、J-CASTニュースの記事に付いている画像は、取材の時に撮ったというわけではないらしい。
どれも、著作権的にはフリーらしいので悪いことしているわけじゃないけど、こういうのって、取材の時の様子だと考えてしまうんじゃない？ こういう場合、テレビのニュースなら「資料映像」って付くけど、週刊誌などでは関係ない写真でもばんばん使う。新聞だったら「写真と本文は関係ありません」なんて入れる（例）。
J-CASTのいう1.5次情報
*ってのは、週刊誌レベルってことか。
あと、ウェブのスクリーンショット率の高さにも言及したかったけど眠い。
おまけ。
