朝5時くらいに起きて妻と一緒にテレビで観ていました。
ショートプログラム1位のSasha Cohenが金メダルを取ってアメリカ勢の連覇が続いてしまうのは嫌でした。
何故って、別にCohenが嫌いというわけではなく、ソルトレーク五輪でアメリカのサラ・ヒューズが金を取ったとき、その異常なまでの喜び方にとても嫌な印象を受けていたからです。
日本人ではありえないくらい口が大きく開いて怪獣のように叫び続けていて…それは、もう衝撃でした。カルチャーショックというか。単純すぎるというか。アメリカ勢が優勝すると、またあれを見せられるのかと思うと、それくらいなら、Irina Slutskayaが前評判通り勝ってくれた方が良いという気分でした。
でも、Cohenが最初のジャンプで早々に転倒すると、前の走者までが失敗続きだったせいもあって、もうちょっと頑張ってもらいたい気持ちになりました。
その次の走者が荒川さん。それまでの選手に比べると完成度が明らかに違って4分の演技を長く感じさせない。他の選手は時間をもてあましていたり、スタミナ切れやミスが目立っていたのです。それだけに、彼女が次々と優雅に技を決めていくたびに、もう観ているほうがドキドキさせられ、さらに、得点には大きく結びつかないにも関わらずイナ・バウアーを本当にやった!(美しい演技を見せたいという彼女の取り組みは、NHKスペシャルで特集されていました。金メダルをとった荒川さんに着目していたところをみると、この番組には先見の明がありましたね)。そのとき既に観客席は、ほぼスタンディングオベーションの状態。イナバウアーと、連続ジャンプを組み合わせることで、明らかに他の選手と違う彼女らしさを見せ付けてくれました。
けれど、ドキドキしすぎて、もうよく覚えていません。
引き続いての村主(すぐり)さんも、転倒もなく充実した演技でした。けれど、目立った失敗がなかったのはこれまでの選手の中で荒川さんに続いてようやく2人目だったにも関わらず、なぜか点数が伸びない。3回転-2回転のジャンプが2回転-2回転になったせいか。昨年12月の全日本選手権では荒川さんを凌いで優勝したのに、とても不思議でした。スピンやステップがレベル4と判定されなかったのか…。こればっかりは、技の判定も含めたフルの採点表が公開されないと、素人目にはどの技の点数が足りなかったのか、まったくわからないです。
そして、ロシア勢でフィギュア全種目の金メダルを独占の可能性や、ソルトレークで敗北したときと同じ最終滑走というプレッシャーが重なったためか、Slutskayaに元気がなく、転倒、彼女だけができるダブルビールマンスピンも見られず…。残念でした。
荒川さんか村主さんがメダルを取れるとは思っていたけれど、かなり意外な展開です。あのスルツカヤの演技で、村主さんが負けたとは到底思えないのですが。。。だって、2回転倒した人が銀メダル、1回の人が銅メダル、一度も転んでないのに4位なんて。
魅せる演技では、荒川さんがダントツでした。こういう息を呑むような演技のことを英語では、mesmerizingと表現するそうです。次にやはり村主さん。彼女の涙をこらえた記者会見でもわかるように、観ている方も悔しさを共感できます。どうしてあんなに低い点なの? CohenとSlutskayaは、緊張しすぎで思うように動けていない様子が手に取るようにわかってしまったというのに。
もし完全な結果(技の判定含む)が手に入る場所をご存知の方はぜひ教えてください。
2006年2月24日金曜日
2006年2月21日火曜日
GPLの選択は当事者間の問題か?
コメントに対する回答をここにも乗せます。
先日書いたブログからは、GPLがviral(伝染性)ライセンスだから批判しているような印象になるかもしれません。でも、僕は、そういう一面が嫌いではありません。企業にとって、GPLであるが故に、それを使うために企業がコミュニティに貢献せざるを得ない状況を敢えて作っているところは、少数のプログラマが大企業に対抗するのに必要不可欠だったわけだし、こういったレジスタンス的な活動は、むしろ大好きです。
GPLライセンスの製品には巣晴らしいものが多々あります。主要なオープンソースプログラムはGPLへの対応済みであって、一度GPLの輪の中に入ると幸せでしょう。
でも、そこからGPLから抜け出し、GPL以外の選択肢を取るのは相当大変です。僕の主張は、安易にGPLを選択しないで、ということです。GPLの選択は確かに当事者間の問題ですが、内容をよく吟味せずにGPLを選択する当事者が増えてしまうのは困り者だと、僕は思っています。
ソース公開義務を課したり特許による攻撃を防ぎたいならMPLや、その微修正版のSunのCDDLがあります。copyrightの表示だけを義務付けたいなら、 New BSDライセンスも使えます。Apache License v2.0なら、著作物を改変した人の名前も追うことができるようになります。
でも、オープンソース開発後進国の日本では、GPLがv3になろうとしているのに、こうしたことが驚くほど話題になっていないのです。少なくとも、GPLが有名だから、という理由で、GPL採用する人には歯止めをかけたいのです。種々のライセンスを使う人には、それなりのメリットや理由があります。でも、それを理解するには日本語の情報源があまりにも少ないと思うのです。
この昔の記事はオープンソース開発を創めるにあたって、役にたつかも。著者の八田さんは、オープンソースに関連して頑張っている数少ない日本人のようです。
先日書いたブログからは、GPLがviral(伝染性)ライセンスだから批判しているような印象になるかもしれません。でも、僕は、そういう一面が嫌いではありません。企業にとって、GPLであるが故に、それを使うために企業がコミュニティに貢献せざるを得ない状況を敢えて作っているところは、少数のプログラマが大企業に対抗するのに必要不可欠だったわけだし、こういったレジスタンス的な活動は、むしろ大好きです。
GPLライセンスの製品には巣晴らしいものが多々あります。主要なオープンソースプログラムはGPLへの対応済みであって、一度GPLの輪の中に入ると幸せでしょう。
でも、そこからGPLから抜け出し、GPL以外の選択肢を取るのは相当大変です。僕の主張は、安易にGPLを選択しないで、ということです。GPLの選択は確かに当事者間の問題ですが、内容をよく吟味せずにGPLを選択する当事者が増えてしまうのは困り者だと、僕は思っています。
ソース公開義務を課したり特許による攻撃を防ぎたいならMPLや、その微修正版のSunのCDDLがあります。copyrightの表示だけを義務付けたいなら、 New BSDライセンスも使えます。Apache License v2.0なら、著作物を改変した人の名前も追うことができるようになります。
でも、オープンソース開発後進国の日本では、GPLがv3になろうとしているのに、こうしたことが驚くほど話題になっていないのです。少なくとも、GPLが有名だから、という理由で、GPL採用する人には歯止めをかけたいのです。種々のライセンスを使う人には、それなりのメリットや理由があります。でも、それを理解するには日本語の情報源があまりにも少ないと思うのです。
この昔の記事はオープンソース開発を創めるにあたって、役にたつかも。著者の八田さんは、オープンソースに関連して頑張っている数少ない日本人のようです。
2006年2月20日月曜日
Stallmanが嫌う知財という言葉
"Did You Say "Intellectual Property"? It's a Seductive Mirage"
という意見がありました。GPLに関する議論で、知財(intellectual property)という言葉を使うのは、安易でしたね。
GPLの発案者であるRichard M. Stallman氏が、ソフトウェア業界へ多大な貢献をしてきたこと(企業にプログラムや技術を独占されないようにしてきた)や、Linuxなどの発展を促進したことについては周知の事実です。でもね。。あの人の顔をみる限り、僕の好きなタイプの人間ではありません(検索してみるとすぐでてくるはず)。GPL信奉者となることは避けたいです。
本題に戻ると、オープンソースのプログラムで問題となる知財は、主に著作権(copyright)と、特許権(patent)です。 GPLは、著作権に関しては手厚く保護しているライセンスと言えます。一方、特許権に関しては、GPLでは、特許のライセンス料を徴収することが禁止されています。
日本の著作権法や特許法とGPLの関わりについてはこちらが詳しいです。
経済産業省のページ
けれど、特許権の行使に関しても、個人レベルで開発している僕にとってはあまり大きな意味を持ちません。特許侵害されても、踏み倒される危険性の方が大きいですから。
僕が嫌っているのは、個人の貢献が、GPLのopen sourceでビジネスを展開している企業に何の対価もなしに吸収されてしまうことです。それも、GPLでライセンスされているプログラムを使用しているという理由だけで。
これを避けるためには、GPLライセンスのプログラムを使わず、自分が著作権(あるいは著作人格権)を持つプログラムや他のオープンソースライセンスを利用したプログラムで、身を固めるしかありません。(時間と労力がかかるけれど、これはこれでプログラマにとって楽しいことです。知識を吸収できるし、経験も増えます)
上のリンク先の文章から引用すると、
とあります。こういった濫用と思われる行為から自分のコードを守るには、どのような権利を駆使すればいいのでしょう? そして、それは知財のうち、どれにあたるのか。
いうなれば、非商用でソースコードの開示義務を課すライセンスが欲しい。商用への対応はデュアルライセンスにすることで切り替えられるけれど。。。それでは、開発者が集まらないだろうからオープンソースにするメリットがありません。
という意見がありました。GPLに関する議論で、知財(intellectual property)という言葉を使うのは、安易でしたね。
GPLの発案者であるRichard M. Stallman氏が、ソフトウェア業界へ多大な貢献をしてきたこと(企業にプログラムや技術を独占されないようにしてきた)や、Linuxなどの発展を促進したことについては周知の事実です。でもね。。あの人の顔をみる限り、僕の好きなタイプの人間ではありません(検索してみるとすぐでてくるはず)。GPL信奉者となることは避けたいです。
本題に戻ると、オープンソースのプログラムで問題となる知財は、主に著作権(copyright)と、特許権(patent)です。 GPLは、著作権に関しては手厚く保護しているライセンスと言えます。一方、特許権に関しては、GPLでは、特許のライセンス料を徴収することが禁止されています。
日本の著作権法や特許法とGPLの関わりについてはこちらが詳しいです。
経済産業省のページ
けれど、特許権の行使に関しても、個人レベルで開発している僕にとってはあまり大きな意味を持ちません。特許侵害されても、踏み倒される危険性の方が大きいですから。
僕が嫌っているのは、個人の貢献が、GPLのopen sourceでビジネスを展開している企業に何の対価もなしに吸収されてしまうことです。それも、GPLでライセンスされているプログラムを使用しているという理由だけで。
これを避けるためには、GPLライセンスのプログラムを使わず、自分が著作権(あるいは著作人格権)を持つプログラムや他のオープンソースライセンスを利用したプログラムで、身を固めるしかありません。(時間と労力がかかるけれど、これはこれでプログラマにとって楽しいことです。知識を吸収できるし、経験も増えます)
上のリンク先の文章から引用すると、
GPLに準拠するソース・コードの比率が小さいソフトウ
エアの全体に対して,ソース・コードの開示などの制約が
かかるのは民法の権利濫用の法理で無効になる可能性があ
るとの意見がある。
とあります。こういった濫用と思われる行為から自分のコードを守るには、どのような権利を駆使すればいいのでしょう? そして、それは知財のうち、どれにあたるのか。
いうなれば、非商用でソースコードの開示義務を課すライセンスが欲しい。商用への対応はデュアルライセンスにすることで切り替えられるけれど。。。それでは、開発者が集まらないだろうからオープンソースにするメリットがありません。
2006年2月16日木曜日
GPLから知財を守ろう
GPL(GNU General Public License)の欠点は、知財(IP: Intellectural Property)を公開しなさいという、押し付けがましいライセンスだということに尽きる。GPLの特徴は、GPLでライセンスされたプログラムを改変したり、それを利用するプログラムを配布する際は必ずソースコードを公開しなくてはならない、というものだ。
ソフトウェア開発の重要なメリットは何よりコストを低くできること。プログラマの知識や経験に対する対価は高くつくが、設備投資が必要な製造業より、PCがあれば開発できるという手軽さは何よりの強みだ。それゆえ、GPLの持つソースコードを誰でも利用できるようにするという性質は、新製品を開発したところで、競合他社にコピーされてしまい、独自の技術と呼べるものではなくしてしまう。
けれど、ソフトウェアがコピーできることが問題なのではない。広くソースコードを公開することによって、オープンソース開発のコミュニティを広げ、機能追加、バグの早期発見&修正が促進されることは多々ある。ソースを公開し、製品を利用するためのサポートビジネスを主に展開するところも多い。GPLの本当の問題は、自分の開発したプログラム、すなわち「知財」を公開しないという選択肢が与えられないところだ。つまり、GPLライセンスを持ったプログラムを利用した場合、自分の知財の放棄を強要されるわけだ。個人認証など、セキュリティの肝となっている部分にGPLプログラムを利用できないのは明らかだ。
(ライブラリの形で利用する場合はソース公開のライセンスは適用されないというLGPLもあるが、プログラムをリンクして使う、つまり、ソースコードにヘッダをincludeするもの、単に通信して利用するものなど、さまざまな形態がありうるにもかかわらず、ライセンスの適用範囲が非常に曖昧だ。)
GPLを推進するFree Software Foundation(FSF)が目指すものは、まさに、知財が個人の所有物となることを防ぐことである。ソフトウェアの開発に、特許侵害を懸念していては、健全な開発ができないという思想である。確かに、特許という審査に時間のかかるものとソフトウェア開発は相容れない。submarine特許による脅威に常にさらされているのもソフトウェアだ。それに、自分のソースコードを自由に使っていいというcontribution(貢献)のおかげで、かなりのソフトウェアが成長してきたことは明らかだ。
けれど、自分が公開しているのだから、あなたのソースコード、つまり知的財産も公開しなさいという主張を、他に押し付けなくてはいけないというのは、非常に心苦しい。当然、企業はGPLプログラムには参入しにくい。フリーで手にはいるものをわざわざ買う顧客はいない。 ソースコードの開発者は本当にGPLを選択する必要があったのだろうか。GPLを付与しているプログラマがすべて、FSFと同じ主張だとは思えない。
GPLを採用しつつも、顧客企業に非GPLの形でソースコードを提供できるデュアルライセンスの形をとっているところもある。MySQLや、BerkeleyDBのSleepycat(先日ORACLEに買収された)がこの形を取れるのは、プログラムをほぼ100%自社開発しているからである。コミュニティによるcontributionは少数のパッチやバグ報告で、主要な機能はすべて自己で開発している。この場合のGPLの役割は、開発者にGPLを適用することを押し付けて、ソースへの改良や、それを応用したプログラムすべてのソースコードを自社のものとすることにある。 Sleepycatの収益の70%がライセンス契約によるものという話であるから、GPLによる束縛を避けて、知財を非公開にしたいという需要が大きいことが見て取れる。
形が違うだけで、これではGPLソフトウェアといっても、proprietary(商業)ソフトウェア専門のMicrosoftと大きな差異はないように思われる。結局は、自社開発。企業側は、ソースをGPLにすることで逆に知財保護に利用している(これが行き過ぎで、他の知財剥奪になるのが問題)。FSFが掲げる特許に縛られないソフトウェアの世界とはかけ離れている。いろんなプログラムを利用して新しいものを気楽に作るという目標から逸れてきている。今では、GPLは自社製品への囲い込みを狙うMicrosoftより性質が悪いと感じる。
拡張自在のブラウザFirefoxで注目を集めるmozilla.orgのMPL(Mozilla Public Licence)は、その点、知財に関して注意が払われている。MPLが適用される部分に改変を加えた場合はソースを公開しなければならないが、MPLとは独立に自分で開発したソースコードは非公開とすることができる。こちらのほうが知財の放出を強制されることもなく、よっぽど健全であろう。 自分の書いたソースコード、つまり知財がコミュニティの中でどのように進化するかも見てとることができる。
オープンソースソフトウェアに関しては、日本OSS推進フォーラムでよくまとめられている。
GPLに関しては、こちらのリンク集が詳しい。
ソフトウェア開発の重要なメリットは何よりコストを低くできること。プログラマの知識や経験に対する対価は高くつくが、設備投資が必要な製造業より、PCがあれば開発できるという手軽さは何よりの強みだ。それゆえ、GPLの持つソースコードを誰でも利用できるようにするという性質は、新製品を開発したところで、競合他社にコピーされてしまい、独自の技術と呼べるものではなくしてしまう。
けれど、ソフトウェアがコピーできることが問題なのではない。広くソースコードを公開することによって、オープンソース開発のコミュニティを広げ、機能追加、バグの早期発見&修正が促進されることは多々ある。ソースを公開し、製品を利用するためのサポートビジネスを主に展開するところも多い。GPLの本当の問題は、自分の開発したプログラム、すなわち「知財」を公開しないという選択肢が与えられないところだ。つまり、GPLライセンスを持ったプログラムを利用した場合、自分の知財の放棄を強要されるわけだ。個人認証など、セキュリティの肝となっている部分にGPLプログラムを利用できないのは明らかだ。
(ライブラリの形で利用する場合はソース公開のライセンスは適用されないというLGPLもあるが、プログラムをリンクして使う、つまり、ソースコードにヘッダをincludeするもの、単に通信して利用するものなど、さまざまな形態がありうるにもかかわらず、ライセンスの適用範囲が非常に曖昧だ。)
GPLを推進するFree Software Foundation(FSF)が目指すものは、まさに、知財が個人の所有物となることを防ぐことである。ソフトウェアの開発に、特許侵害を懸念していては、健全な開発ができないという思想である。確かに、特許という審査に時間のかかるものとソフトウェア開発は相容れない。submarine特許による脅威に常にさらされているのもソフトウェアだ。それに、自分のソースコードを自由に使っていいというcontribution(貢献)のおかげで、かなりのソフトウェアが成長してきたことは明らかだ。
けれど、自分が公開しているのだから、あなたのソースコード、つまり知的財産も公開しなさいという主張を、他に押し付けなくてはいけないというのは、非常に心苦しい。当然、企業はGPLプログラムには参入しにくい。フリーで手にはいるものをわざわざ買う顧客はいない。 ソースコードの開発者は本当にGPLを選択する必要があったのだろうか。GPLを付与しているプログラマがすべて、FSFと同じ主張だとは思えない。
GPLを採用しつつも、顧客企業に非GPLの形でソースコードを提供できるデュアルライセンスの形をとっているところもある。MySQLや、BerkeleyDBのSleepycat(先日ORACLEに買収された)がこの形を取れるのは、プログラムをほぼ100%自社開発しているからである。コミュニティによるcontributionは少数のパッチやバグ報告で、主要な機能はすべて自己で開発している。この場合のGPLの役割は、開発者にGPLを適用することを押し付けて、ソースへの改良や、それを応用したプログラムすべてのソースコードを自社のものとすることにある。 Sleepycatの収益の70%がライセンス契約によるものという話であるから、GPLによる束縛を避けて、知財を非公開にしたいという需要が大きいことが見て取れる。
形が違うだけで、これではGPLソフトウェアといっても、proprietary(商業)ソフトウェア専門のMicrosoftと大きな差異はないように思われる。結局は、自社開発。企業側は、ソースをGPLにすることで逆に知財保護に利用している(これが行き過ぎで、他の知財剥奪になるのが問題)。FSFが掲げる特許に縛られないソフトウェアの世界とはかけ離れている。いろんなプログラムを利用して新しいものを気楽に作るという目標から逸れてきている。今では、GPLは自社製品への囲い込みを狙うMicrosoftより性質が悪いと感じる。
(確かに、大学の書類等もOffice製品のフォーマットで囲い込まれてしまって、Officeの購入を余儀なくされるという腹立たしい現状はあるが、それは、むしろ、安易に製品を選択する大学側の意識の問題である。Officeの信頼性を検証をしたという話は聞いたことがない)
拡張自在のブラウザFirefoxで注目を集めるmozilla.orgのMPL(Mozilla Public Licence)は、その点、知財に関して注意が払われている。MPLが適用される部分に改変を加えた場合はソースを公開しなければならないが、MPLとは独立に自分で開発したソースコードは非公開とすることができる。こちらのほうが知財の放出を強制されることもなく、よっぽど健全であろう。 自分の書いたソースコード、つまり知財がコミュニティの中でどのように進化するかも見てとることができる。
オープンソースソフトウェアに関しては、日本OSS推進フォーラムでよくまとめられている。
GPLに関しては、こちらのリンク集が詳しい。
2006年2月15日水曜日
日本版SEC設置法案
今、「ウォール街の大罪」という本を読んでいます。日本でアメリカのSECにあたるものは何かと調べていたら、民主党のページにヒット。ということは、そういうものができるのはいつになることやら。
個人投資家は、見た目にだまされないよう、勉強することで自衛しないといけないようです。
個人投資家は、見た目にだまされないよう、勉強することで自衛しないといけないようです。
2006年2月9日木曜日
ys: 「 なにか間違ってはいないか? 『待機児童ゼロ作戦』で急速に進む子育ての外注化 」
取材や調査の結果から、政治の問題点を鋭い視点で追求するところにに好感を持てた櫻井よしこさんなのですが、今回の記事にはがっかりさせられました。
でも、3歳になっても保育園に預けられる保証すら、今の東京都にはないのです。子供が3歳になりました、さぁ、保育園に手助けしてもらって、仕事を再開しよう、なんて虫のいい話はできません。 詳しくは調査していませんが、僕の知る2つ区の方針では、0~2歳まで保育園で預かった子は、優先的に次の3歳児保育も受けられます。ただでさえ、園の許容枠を超えて入園させている事情から、途中から入園させるのは非常に難しいのです。区役所や保育所に電話しても、非常に冷たくあしらわれてしまいます。 実際、僕は来年度保育園に入園させる保証を得るために、引越しせざるを得ない状況になりました。
愛情をかけて育てることは、確かにこの上ない幸せです。 ただ、この価値観を浸透させ、企業や社会の子育てに対する姿勢を改めさせるのには、時間がかかります。
現代は核家族化が進行しています。でも、核家族は子育てが一番しにくい形態だと思います。 一人が働き、一人が子供とべったり。 育児のストレスがたまりやすいのにキャリアも積めない、社会からどんどん切り離されていきます。もちろん育児に専念する人の輪もありますが、働く人のコミュニティとは別物です。もし、キャリアも積めないまま、稼ぎ手が不慮の事故でいなくなったらどうするのか。 働く人のコミュニティから切り離された状態で、社会保障の乏しい日雇い労働者になる以外の道が開けるとはとても思えません。
社会保障が不安だからこそ、保育は今必要なんです。けれど、東京都は「待機児童ゼロ作戦」を掲げていても、保育園を待機児童をゼロにできるほど増設しているわけではありません。
櫻井さんの主張そのものは間違っていないと思いますが、この意見を向けるべき本当の相手は、育児を施設にまる投げしている母親ではないと感じます。(本文中では母親となっているが、ここは父親も含むべき)
という意見には同感です。 子供の教育問題は、親に対して親としての教育がなされていないことに起因するという話にも理を感じます。だから、昔の日本の親の子育てへの懐古心から、彼女は以下のような疑問をぶつけています。
「長時間施設に預けることは感心できないのだ」
東京都はそれでも、「待機児童ゼロ作戦」 を掲げる。ゼロ歳児まで含めて、すべての子どもを保育園に預ける作戦だ。働く女性たちを支援する目的ではあっても、なにか基本的に間違ってはいないだろう か? むろん、行政は住民の心や要望を反映する。こうした施策の背後には、「子どもが3歳になるまでは母親は仕事を持たずに家にいるのが望ましい」という 考えを支持する母親たちが、この10年間に88%から25%に激減した社会の実情がある。
でも、3歳になっても保育園に預けられる保証すら、今の東京都にはないのです。子供が3歳になりました、さぁ、保育園に手助けしてもらって、仕事を再開しよう、なんて虫のいい話はできません。 詳しくは調査していませんが、僕の知る2つ区の方針では、0~2歳まで保育園で預かった子は、優先的に次の3歳児保育も受けられます。ただでさえ、園の許容枠を超えて入園させている事情から、途中から入園させるのは非常に難しいのです。区役所や保育所に電話しても、非常に冷たくあしらわれてしまいます。 実際、僕は来年度保育園に入園させる保証を得るために、引越しせざるを得ない状況になりました。
子どもを産むからには、愛情と手間をかけて心身ともに健全な子どもに育てることが、親としてのなによりの喜びである、という素朴な原点を、社会全体で再認識したいものだ。
愛情をかけて育てることは、確かにこの上ない幸せです。 ただ、この価値観を浸透させ、企業や社会の子育てに対する姿勢を改めさせるのには、時間がかかります。
現代は核家族化が進行しています。でも、核家族は子育てが一番しにくい形態だと思います。 一人が働き、一人が子供とべったり。 育児のストレスがたまりやすいのにキャリアも積めない、社会からどんどん切り離されていきます。もちろん育児に専念する人の輪もありますが、働く人のコミュニティとは別物です。もし、キャリアも積めないまま、稼ぎ手が不慮の事故でいなくなったらどうするのか。 働く人のコミュニティから切り離された状態で、社会保障の乏しい日雇い労働者になる以外の道が開けるとはとても思えません。
社会保障が不安だからこそ、保育は今必要なんです。けれど、東京都は「待機児童ゼロ作戦」を掲げていても、保育園を待機児童をゼロにできるほど増設しているわけではありません。
櫻井さんの主張そのものは間違っていないと思いますが、この意見を向けるべき本当の相手は、育児を施設にまる投げしている母親ではないと感じます。(本文中では母親となっているが、ここは父親も含むべき)
2006年2月6日月曜日
[VC++] Including libraries from your source codes
と記述しておくと、ソースコード中でリンクするライブラリを指定できるのです。
#pragma comment(lib, "your_favorite.lib")
Boostがこの方式を採用してとても便利になりました。
VC++ 2003(あるいは、それ以前のversion)を使っていると、linker optionにGUI画面でライブラリ名を列挙して記述しなくてはいけなくいため、新しいプロジェクトを作成するたびに同様の操作をし、記述をコピペすることが多く、割と面倒だったのです。
ヘッダファイルなどに、このpragmaを入れておいて、後は必要なライブラリに自動的にリンクしてくれるようにすると、プログラムをコンポーネント毎に分割する際の精神的な障害が減ります。
2006年2月1日水曜日
サン、「Solaris」にGPL第3版の適用を検討
記事によると、Solarisがdual licenseになるかも、という文脈で、SunのCOOの
Jonathan Schwartz氏が
とあります。
ちょっと待て。ZFSやGRUBがライセンスの選択で何か失敗していたのか? けれど続きを読んでも、そんな失敗の内容は書いてありません。
上のリンクは、訳ですが、原文はこちら。
該当部分を抜き出すと、
どうやら、Why recreate the wheel...?を、「轍(てつ)を踏まない」と訳したらしい。どう考えても、dual licenseに対応させるために、Sun自慢のDTraceなどの技術を一から作り直すなんて効率の悪いことはしないという意味です。
「轍を踏まない」は失敗を繰り返さないという意。日本語の使い方を間違ったのか、原文の意味を理解していないのか。
そもそも、大本のJonathanのブログはこちら。
実を言うと、僕は、最初にブログの方を読んでいました。公式の場ではないので、Solarisがdual licenseを検討しているという内容で、確かにそういうことを検討しないと使いにくいよな、と思っただけです。 が、記事になると、検討しているだけのことに、それが一大事であるかのように誇張されてしまう。さらに、誤訳も混じって、意味不明な情報に。
記事って情報源がわかってしまうと、かなり陳腐になりますね。
Jonathan Schwartz氏が
LinuxとOpenSolarisの関係を効率化し、互いに実りあるものにするためにできることに取り組みたい」と記し、「『DTrace』と『ZFS』や、『GRUB』と『Xen』の轍は踏まない」と続けた
とあります。
ちょっと待て。ZFSやGRUBがライセンスの選択で何か失敗していたのか? けれど続きを読んでも、そんな失敗の内容は書いてありません。
上のリンクは、訳ですが、原文はこちら。
該当部分を抜き出すと、
"We want to do what we can to drive more efficiency and cross-pollination between Linux and OpenSolaris," Schwartz said. "Why recreate the wheel with technologies like DTrace and ZFS--or GRUB and Xen?"
どうやら、Why recreate the wheel...?を、「轍(てつ)を踏まない」と訳したらしい。どう考えても、dual licenseに対応させるために、Sun自慢のDTraceなどの技術を一から作り直すなんて効率の悪いことはしないという意味です。
「轍を踏まない」は失敗を繰り返さないという意。日本語の使い方を間違ったのか、原文の意味を理解していないのか。
そもそも、大本のJonathanのブログはこちら。
実を言うと、僕は、最初にブログの方を読んでいました。公式の場ではないので、Solarisがdual licenseを検討しているという内容で、確かにそういうことを検討しないと使いにくいよな、と思っただけです。 が、記事になると、検討しているだけのことに、それが一大事であるかのように誇張されてしまう。さらに、誤訳も混じって、意味不明な情報に。
記事って情報源がわかってしまうと、かなり陳腐になりますね。
登録:
投稿 (Atom)
License
Leo's Chronicle by Taro L. Saito is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.1 Japan License. |