しかし、どうして「オープンソース」という単語の定義としてOSDを使うという主張が批判を受けるのか。 その発想の過程に興味がある。 なぜそこまで「オープンソース俺定義」を守りたいのか。
OSD準拠のオープンソースを守ることのメリットについては 八田さんの記事が詳しい。
では、この定義でない似非オープンソースを守ることに意義はあるのか。 批判する動機はなんなのか。
「他人の自由」そのものに反発する人ってのはそんなにいないと信じたいので、 スラッシュドットにそんな意図の人はいなかったと希望的に仮定すると、 その反発ってのは表現(だけ)によって引き起こされたのだろうか。
表現にカチンときて反発されたのだとしたら、 オープンソースのメリットなんてどーでもいいってことなのかなあ。
あと、オープンソースはすでに登録商標です。
いずれにしても気分が悪かったので、やり方を考え直してみよう。
オープンソース運動の成功は「オープンソース」という単語が正しく用いられるかどうかではない。 もちろん正しく使われるに越したことはないけど。
それよりもむしろ
が成功といえるだろう。前者は開発者へのアピール、後者はいわゆる中間層へのアピールである。
匿名で意見を述べる人たちは(潜在的には開発者あるいは中間層なのかもしれないけど)、 匿名に隠れている間は、結局無責任なエンドユーザなので説得したり交渉したりする必要はない。
ということは、開発者には
を紹介し、中間層には
の事例を紹介するべきなのだろうか。
オープンソースでない無料ソフトウェアを開発している人々が、 正しいオープンソースにしない理由ってのはなんなんでしょうね。
もちろん、彼らを強制することはできないわけだが、 彼らの抱えている不安と誤解を解消することで、世の中の幸せの総和が増えるかもしれない。
ただいまの松江地方は雷が鳴っております。
B00005MIBU 以前、BSで放送していた時には見逃していて、 今回教育チャンネルで再放送しているものは録画しつつ見ている。
黒板がディスプレイ化し、ノートの代わりにノートPCを広げる教室の様子など、 近未来の表現がなかなか芸が細かいし、登場人物の性格が良いところが結構気に入っている。 話の展開ものんびりしつつ、少しずつ謎を深めていく感じで気持ちいい。
でも、録画が削除されちゃった関係で、2週ほど見逃していたら話が少々妙なことになっている。 いや、ストーリーとして宗教を扱うのは日本に限らずあちこちにあるんだけど、 このスタッフならもうちょっと別の流れでもきれいに話を進められたのではなかろうか。 神さまが宇宙人だったってのはいくらなんでも安易すぎ。
苦情を言うほど無粋ではないが、個人的にちょっとがっかりしたのは確か。 でも、そこはおいておいてもまだ面白いのだ。
また聞きなのですが、sourceforge.jpにプロジェクト申請する際に、
と言われることがあるんだそうです。まあ、至極もっともです。
で、OSI承認の申請をしませんかと勧められました。承認されると OSIのリストに加えていただけるそうなのです。
申請の手順は<URL:http://www.opensource.org/docs/certification_mark.php>にあるそうです。
しかし、Rubyのライセンスは PerlのArtisticライセンスを少々いじってできているので、Artisticが持つ問題と類似の問題を抱えています。 よって、GPLとのデュアルライセンス以外の局面でまともに使えるとは考えていません。
GPLを適用した時点でOSD準拠ですから、 改めてOSI承認を求めて、単体では問題をはらんだライセンスをリストに追加する必要はないと思います。 GPLに抵抗があるだけなら、単純にBSDライセンスにした方が良いと思います。
Rubyのライセンスがあれなのは
という理由ですから、そういう事情のないソフトウェアがRubyライセンスを適用する必然性はほとんどないと思います。
ということで、自分のソフトウェアに安易にRubyライセンスを適用しないように。
また、万が一必要があって適用することがあってもGPLとのデュアルライセンスを選択してくださいね。
なお、Riteでは以下のライセンスを採用するつもりです。 こっちは単体で適用するつもりなので、OSI承認なのかどうか調べないとな。
/* * Copyright (C) 2003 Yukihiro "matz" Matsumoto * * Permission is granted for use, copying, modification, distribution, * and distribution of modified versions of this work as long as the * above copyright notice is included. */
今書いたことですが、どうせ不可分なら、なひさんのおっしゃるように「Rubyライセンス」でデュアルを指すとしてしまった方が絶対いいですよね。なんでこんなことに気がつかなかったんだろう。 幸い、ライセンスの条文に「GPLまたは以下の条件」と書いてありますから、ますます都合が良いですね。
ということで、みなさんこれからRubyライセンスという時には 「GPLとのデュアルライセンスである」と覚えてくださいね。
まあ、いずれにしても現在積極的にRubyライセンスを利用する必然性はないんですけどね。
あ、白状すると昔は意味があると思ってました。不勉強でしたから。
買う。『アキバ署！』を読むためだ。なるほどねえ。 匿名性による問題というべきか。ストーリーとしては興味深い。
ところで、それとは別に「げんしけん」なる連載があるのだが、 これはもしかすると「現代視覚文化研究会」の略か...あ、あらすじにそう書いてあるじゃん。
私が通った某大学(特に名は秘す)にも同名のサークルがあり、 私は学部1年の時、ごく一時期名簿に名前が載っていたような気がする(活動は何もしなかった)。 ああ、あの頃は若かった。
でも、「東京の大学」じゃないしなあ。
おおっ、プレスが出ている。先日、取材されたって言ってたのはこれか。
ま、そんな感じです。
これを作っている人は純粋に業務としてオープンソースソフトウェアを開発しているので、 オープンソースとしては新しい形に開発スタイルと言えないことは無いだろう。 ま、最初の一歩としては上出来では(自画自賛)。
まだ成長途上だけど、これが広く使われるようなツールになるといいなあ。
Rubyがブロックの終端に採用している「end」はRubyのコードを特徴づけている。 「end」の羅列があるおかげで、ひとめてRubyのプログラムだとわかる。
しかし、endには視覚的にインパクトがありすぎるという欠点がないわけでもない。 すぐ慣れるけど。
で、ちょいと例としてQuのような「;;」を「end」の代わりにする 文法を許してみた。ソースの書き換えは6行。これで
class Foo < Bar
def foo(x)
p x
;;
;;
のようなソースが書けるようになる。うーん、Rubyに見えないな。
この機能は予告なく無くなる可能性があるので、本気では使わないこと*1。
*1 しまった、April Foolにこの機能を取り込めば良かったな
長らく使ってきたUNIQLOのパソコンバッグだが、 とうとう縫い目がほころびてきた。 実際、世界各国に持ち歩いてきたわけだし、 それなりに荒い扱いをしてきたからしょうがないといえば しょうがないのだが。
で、ここずっとカバンを探していたのだが、 なかなか琴線に触れるものがなかった。 コンピュータを入れるカバンだから、 電気屋とかの類のところが良かろうと思っていたので、 あちこちの電気屋を見てきたのだが、 あんまり品揃えが良くない。
で、妻の助言を受けて、SATYの鞄屋によってみた。
なんと、PC対応のバッグなぞいくらでもあるではないか。 盲点であった。餅は餅屋。
ほどほどのサイズのものをひとつ購入。 ほんとは普段使い用にもうちょっと小さいのも欲しかったのだが、 ふたつもみっつもあってもなあ。
先日、Googleからきた小切手の換金を私の銀行にお願いしていたのだが、 書類に不備があったとかで、わざわざオフィスにまで来てくださる。 うっかり遅刻してしまって、待たせてしまう。
銀行を呼びつけて、待たせる、なんて、すっごい偉そうじゃない？
書類の方はサインひとつで完了。 ついでに、PayPalからの入金について質問してみる。 昨年のRubyConfの交通費をPayPalで受け取ったのだけど、 自分の口座に送金しようとして失敗したのであった。 手数料だけ取られたし。
けど、担当者はPayPalのことをご存じなかった。 でも、調べてはもらえるとのこと。 PayPalと自由にやりとりできるようになれば、ずいぶん楽になる。
目が覚めたら6時14分で、とっくにセミナリーの時間になっている。 やっちまった。
教会に着いたら、みんなまだ待っててくれてる。 雨降りじゃなかったのがせめてもの救いだ。
みんな、ごめんね、もう遅刻しないから。
しかし、ここのところ「うっかり」が多すぎる。 疲れてるのか？
そうなのか？
並列プログラミングの的敵は共有データであり、
それをPythonから取り除くにはどうしたらいいのか
という思考実験。
とりあえず、classとmodule(の中身)をimmutableにすることと、 mutableなattributeに@sharedというannotationを付けることを提案している。
が、共有される状態を取り除くためには、 そんな些細な変更ではダメだと思うな。 それこそ言語が違ってしまうくらいの変更を加えるか、 プロセス(or スレッド or ファイバ)を なんらかの「越えられない壁」で区切ってしまうしかないような気がする。
確かに。
まあ、受託なんてやってる会社は 少なくとも「ベンチャー」ではないよな。NaClも含めて。 全然冒険してないもの。
まあ、私は冒険好きじゃないんで、それはそれで望むところではあるんだけど。 でも、そろそろ受託じゃない自前のサービス提供するようなこともやってみたい気がする。 お客さんの都合に振り回されない事業も必要だと思うし。
昔は「Javaなんて遅くて使えない」なんて評価が目立ったけど、 今じゃ下手するとJavaの方がCよりも速いことがあるよね、という話。
興味深かったのがここ。
Compiled JS is about 9x slower than C on this test. If CPU speed doubles every 18 months, then JS in 2007 performs like C in 2002.
コンパイルされたJavaScriptはCの9倍遅い。 もし、CPU速度が18ヶ月で倍になるのだとすれば、 2007年のJavaScriptは2002のCと同程度に速い
そうなのか。ハードウェアの進歩は恐るべし。
Google Developer Dayの鵜飼さんのセッションのログ。
徹底した開発体制は参考になる。 うちにもずいぶん改善の余地はありそうな。
もちろんRubyの開発体制も。
普通に考えたら、この種のデータ1500万件を 1年間で処理するのは絶対に無理だと思うんだけど。 「政治生命を賭ける」んだよね。私なら絶対にやらない。
どうやって「なあなあ」に済ませる気だろう。 むしろその辺の政治的手腕に注目したい。 きっと、みんなに忘れてもらうようにマスコミを誘導するんだろうな。